From exim@www1.ietf.org Sun Nov 2 22:31:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04982 for ; Sun, 2 Nov 2003 22:31:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGVQo-0001Aa-CV for nsis-archive@odin.ietf.org; Sun, 02 Nov 2003 22:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA33V6vn004490 for nsis-archive@odin.ietf.org; Sun, 2 Nov 2003 22: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 1AGVQk-00019y-AL; Sun, 02 Nov 2003 22:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGVQE-00018M-Q6 for nsis@optimus.ietf.org; Sun, 02 Nov 2003 22:30: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 WAA04895 for ; Sun, 2 Nov 2003 22:30:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGVQB-0006kX-00 for nsis@ietf.org; Sun, 02 Nov 2003 22:30:27 -0500 Received: from smtp011.mail.yahoo.com ([216.136.173.31]) by ietf-mx with smtp (Exim 4.12) id 1AGVQA-0006kT-00 for nsis@ietf.org; Sun, 02 Nov 2003 22:30:26 -0500 Received: from unknown (HELO KimHui) (lingkimhui@202.14.153.7 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Nov 2003 03:30:25 -0000 From: "Ling Kim Hui" To: Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt Date: Mon, 3 Nov 2003 11:30:43 +0800 Message-ID: <000801c3a1ba$e03f9c40$4e71510a@KimHui> 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.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Mr Hancock, Thanks a lot for your timely reply. After checking the mailing list archieve, I realized that the framework draft -04 has already gone through the working group last call. Does it mean that the draft -05 will go directly to AD/IESG for review? Sorry for asking, since I am not that familiar with the review procedure. I agree with most of your comments, though I have a few more thoughts about them. > i consider this as coming under the broad heading of route changes. > there are actually several different categories of route change anyway > (different peer because of topology change, different peer because of > NE failure but no rerouting, same peer but different ingress or egress > interfaces, same peer but different intermediate routers, ...) > > exactly how each case is distinguished and handled will have to be > done during protocol design. different protocol designs and indeed > different implementations will be able to do different types of route > change handling, so the framework can't really define this. This makes things clearer to me. But I think the case we listed out is more of a detection of false route change. Largely in the draft, the route change is defined as the change of route for data traffic. It is correct that details of handling the route change is a protocol design issue, but my feeling is that in the framework, we should point out different scenarios, so that protocol designer could be aware of those issues. Therefore, it would be good to include some text to clearly identify the route change cases (including the false route change) > the information is the flow id (4.6.1). we specifically don't call > this the flow classifier, since the NTLP isn't interested in packet > classification; another name for the flow id would be 'flow routing > information' (which is what the NTLP draft calls it). the NSLP might > use the flow id as part of a packet classifier. Is the flow ID the only field that needs to be visible to the NTLP? How would the NTLP uses information in the NSLP payload? Should it be accessible by the NTLP? Shouldn't that be encrypted? I know this maybe depend on the implementation, but is it possible to give me some guidance on any possible implementation method, since I am really curious how it should be realized? > formally, the f/w is not a standards track document, so it > cannot define and manage identifier formats in this way. at > the moment it seems likely that the session id will be an object in > the NTLP, so the NTLP specification will pin this down and the sort > of problems you indicate cannot arise. I am a bit confused here. Does this mean that the session ID instead of Signaling Application ID would be used for demultiplexing the NSLPs? Would the NTLP define how the Session ID be formatted? As described also in your mail, the Session ID is not able to fully replace the Signaling Application ID. Therefore, I think the SAID format still has to be formally defined to achieve interoperability. If the framework could not do it, would NTLP draft able to define it? I feel maybe it is better to put a pointer in the framework draft to that. Also, I am not quite clear about the statement "it seems likely that the session id will be an object in the NTLP". Does it mean the Session ID would be generated and maintained in NTLP, and it would be carried at NTLP headers? Thank you very much for your time and attention. Regards, Kim Hui _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 3 04:49:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25468 for ; Mon, 3 Nov 2003 04:49:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbKZ-0002DO-U6 for nsis-archive@odin.ietf.org; Mon, 03 Nov 2003 04:49:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA39n3P2008513 for nsis-archive@odin.ietf.org; Mon, 3 Nov 2003 04:49:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbKX-0002Cm-SF; Mon, 03 Nov 2003 04:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbK4-0002CH-JO for nsis@optimus.ietf.org; Mon, 03 Nov 2003 04: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 EAA25436 for ; Mon, 3 Nov 2003 04:48: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 1AGbK1-0002p0-00 for nsis@ietf.org; Mon, 03 Nov 2003 04:48:29 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AGbK0-0002ox-00 for nsis@ietf.org; Mon, 03 Nov 2003 04:48:28 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA39mTY28986 for ; Mon, 3 Nov 2003 11:48:29 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 3 Nov 2003 11:48:29 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 3 Nov 2003 11:48:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Nov 2003 11:48:27 +0200 Message-ID: Thread-Topic: [NSIS] 2 slightly more interesting questions about the layer split Thread-Index: AcKggNH6URWrDENHRpO5i2WfRK1eFQCLpW+wAABTNfA/zzht4A== To: X-OriginalArrivalTime: 03 Nov 2003 09:48:28.0215 (UTC) FILETIME=[A1E8CC70:01C3A1EF] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] NSIS at IETF 58 Sender: nsis-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 Next Steps in Signaling Agenda IETF 58 TUESDAY, November 11, 2003 1415-1515 Afternoon Sessions II =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Agenda bashing & WG Update 15 min Milestones Requirements Doc update Framework Doc update Analysis document update=20 - Jukka Manner - 5 min Security Threats for NSIS doc update=20 - Hannes Tschofenig - 5 min RSVP Security Properties doc update=20 - Hannes Tschofenig - 5 min NSIS Mobility discussion=20 - Open - 30 min THURSDAY, November 13, 2003 0900-1130 Morning Sessions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Agenda bashing & WG Update=20 - chair - 10 min GIMPS: General Internet Messaging Protocol for Signaling=20 - Robert Hancock - 30 min NSLP for Quality-of-Service signaling=20 - Sven van den Bosch - 30 min A NAT/Firewall NSIS Signaling Layer Protocol=20 - Hannes Tschofenig or Martin Stiemerling - 30 min NATFW NSLP security issues and solution - Martin/Miquel Martin or Hannes Tschofenig - 10 min NATFW NSLP migration considerations - Cedric Aoun - 10 min Closing & discussion=20 - chair - 10 min Reading Material WG drafts http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-03.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-0= 3.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-0= 3.txt Individual submissions http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw-migration-= 00.txt=20 http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-01.txt http://www.ietf.org/internet-drafts/draft-lee-nsis-mobility-nslp-00.txt http://www.ietf.org/internet-drafts/draft-luu-ntlp-con-imp-00.txt http://www.ietf.org/internet-drafts/draft-martin-nsis-nslp-security-00.tx= t http://www.ietf.org/internet-drafts/draft-martin-nsis-nslp-natfw-security= -00.txt http://www.ietf.org/internet-drafts/draft-tschofenig-rsvp-doi-01.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 3 04:55:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25636 for ; Mon, 3 Nov 2003 04:55:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbQM-0002OB-7g for nsis-archive@odin.ietf.org; Mon, 03 Nov 2003 04:55:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA39t2mr009163 for nsis-archive@odin.ietf.org; Mon, 3 Nov 2003 04:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbQL-0002Nf-My; Mon, 03 Nov 2003 04:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbQH-0002NM-VO for nsis@optimus.ietf.org; Mon, 03 Nov 2003 04:54: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 EAA25627 for ; Mon, 3 Nov 2003 04:54:46 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGbQE-0002sI-00 for nsis@ietf.org; Mon, 03 Nov 2003 04:54:54 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AGbQE-0002sF-00 for nsis@ietf.org; Mon, 03 Nov 2003 04:54:54 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA39stY09033 for ; Mon, 3 Nov 2003 11:54:55 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 3 Nov 2003 11:54:53 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 3 Nov 2003 11:54:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Nov 2003 11:54:52 +0200 Message-ID: Thread-Topic: [NSIS] 2 slightly more interesting questions about the layer split Thread-Index: AcKggNH6URWrDENHRpO5i2WfRK1eFQCLpW+wAABTNfA/zzht4AAApYgg To: X-OriginalArrivalTime: 03 Nov 2003 09:54:53.0138 (UTC) FILETIME=[87576320:01C3A1F0] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Details about NSIS at IETF 58 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I've sent a preliminary agenda for NSIS 58. One open discussion that = the WG needs to consider is how to spend on the mobility discussion. = The following drafts have been submitted, but there has been no = discussion on the list about this documents. http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-01.txt http://www.ietf.org/internet-drafts/draft-lee-nsis-mobility-nslp-00.txt http://www.ietf.org/internet-drafts/draft-luu-ntlp-con-imp-00.txt br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 3 05:28:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26404 for ; Mon, 3 Nov 2003 05:28:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbwH-0003tL-6k for nsis-archive@odin.ietf.org; Mon, 03 Nov 2003 05:28:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3AS1qM014941 for nsis-archive@odin.ietf.org; Mon, 3 Nov 2003 05: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 1AGbwG-0003ss-WB; Mon, 03 Nov 2003 05:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbvv-0003sc-87 for nsis@optimus.ietf.org; Mon, 03 Nov 2003 05:27:39 -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 FAA26384 for ; Mon, 3 Nov 2003 05:27:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGbvr-0003Fb-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:27:35 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AGbvr-0003FY-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:27:35 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id hA3ARZc27486; Mon, 3 Nov 2003 11:27:35 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hA3ARYs15425; Mon, 3 Nov 2003 11:27:35 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 3 Nov 2003 11:27:15 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC03CE@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Details about NSIS at IETF 58 Date: Mon, 3 Nov 2003 11:27:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi john, no discussion on the documents? we incorporated a number of comments based on discussions of the last few months into draft-fu-nsis-mobility-01.txt ciao hannes > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, November 03, 2003 10:55 AM > To: nsis@ietf.org > Subject: [NSIS] Details about NSIS at IETF 58 > > > Hi all, > > I've sent a preliminary agenda for NSIS 58. One open > discussion that the WG needs to consider is how to spend on > the mobility discussion. The following drafts have been > submitted, but there has been no discussion on the list about > this documents. > > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-01.txt > http://www.ietf.org/internet-drafts/draft-lee-nsis-mobility-ns > lp-00.txt > http://www.ietf.org/internet-drafts/draft-luu-ntlp-con-imp-00.txt > > br, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 3 05:31:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26546 for ; Mon, 3 Nov 2003 05:31:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbzC-00042d-5i for nsis-archive@odin.ietf.org; Mon, 03 Nov 2003 05:31:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3AV19o015505 for nsis-archive@odin.ietf.org; Mon, 3 Nov 2003 05:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbzB-00041p-JD; Mon, 03 Nov 2003 05:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbym-00041O-Jb for nsis@optimus.ietf.org; Mon, 03 Nov 2003 05:30:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26512 for ; Mon, 3 Nov 2003 05:30:25 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGbyj-0003Ke-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:30:33 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AGbyi-0003Kb-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:30:32 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA3AUXF09843 for ; Mon, 3 Nov 2003 12:30:33 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Nov 2003 12:30:32 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 3 Nov 2003 12:30:31 +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] Details about NSIS at IETF 58 Date: Mon, 3 Nov 2003 12:30:31 +0200 Message-ID: Thread-Topic: [NSIS] Details about NSIS at IETF 58 Thread-Index: AcOh9UHlWfDwK+MjR9GcANCUkZeAyQAAA38w To: , X-OriginalArrivalTime: 03 Nov 2003 10:30:31.0180 (UTC) FILETIME=[81B6B4C0:01C3A1F5] 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 Hannes, I want people to discuss it now, or speak-up on the mailing list that = this would be a good thing to discuss. So, resend your mail to the mailing = list, in a more positive light. I want to avoid a virtual mobility bof within the NSIS meeting. John > -----Original Message----- > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: 03 November, 2003 12:27 > To: Loughney John (NRC/Helsinki); nsis@ietf.org > Subject: RE: [NSIS] Details about NSIS at IETF 58 >=20 >=20 > hi john,=20 >=20 > no discussion on the documents? we incorporated a number of=20 > comments based > on discussions of the last few months into=20 > draft-fu-nsis-mobility-01.txt >=20 > ciao > hannes >=20 > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Monday, November 03, 2003 10:55 AM > > To: nsis@ietf.org > > Subject: [NSIS] Details about NSIS at IETF 58 > >=20 > >=20 > > Hi all, > >=20 > > I've sent a preliminary agenda for NSIS 58. One open=20 > > discussion that the WG needs to consider is how to spend on=20 > > the mobility discussion. The following drafts have been=20 > > submitted, but there has been no discussion on the list about=20 > > this documents. > >=20 > > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-01.txt > > http://www.ietf.org/internet-drafts/draft-lee-nsis-mobility-ns > > lp-00.txt > > http://www.ietf.org/internet-drafts/draft-luu-ntlp-con-imp-00.txt > >=20 > > br, > > John > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 3 05:35:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26734 for ; Mon, 3 Nov 2003 05:35:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc35-0004WF-Qk for nsis-archive@odin.ietf.org; Mon, 03 Nov 2003 05:35:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3AZ201017305 for nsis-archive@odin.ietf.org; Mon, 3 Nov 2003 05: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 1AGc34-0004V1-Cn; Mon, 03 Nov 2003 05: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 1AGc2e-0004Tx-6T for nsis@optimus.ietf.org; Mon, 03 Nov 2003 05:34:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26650 for ; Mon, 3 Nov 2003 05:34:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGc2a-0003OA-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:34:32 -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 1AGc2a-0003O7-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:34:32 -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; Mon, 03 Nov 2003 12:34:30 +0200 Date: Mon, 3 Nov 2003 12:34:30 +0200 (EET) From: Jukka MJ Manner To: john.loughney@nokia.com cc: nsis@ietf.org Subject: Re: [NSIS] Details about NSIS at IETF 58 In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John, We also had the following draft submitted about routing and mobility implications on NSIS work. http://www.ietf.org/internet-drafts/draft-hancock-nsis-routing-mobility-00.txt Regards, Jukka On Mon, 3 Nov 2003 john.loughney@nokia.com wrote: > Hi all, > > I've sent a preliminary agenda for NSIS 58. One open discussion that the WG needs to consider is how to spend on the mobility discussion. The following drafts have been submitted, but there has been no discussion on the list about this documents. > > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-01.txt > http://www.ietf.org/internet-drafts/draft-lee-nsis-mobility-nslp-00.txt > http://www.ietf.org/internet-drafts/draft-luu-ntlp-con-imp-00.txt > > br, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 3 05:38:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26829 for ; Mon, 3 Nov 2003 05:38:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc5y-0004yw-JC for nsis-archive@odin.ietf.org; Mon, 03 Nov 2003 05:38:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Ac1Ja019101 for nsis-archive@odin.ietf.org; Mon, 3 Nov 2003 05: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 1AGc5x-0004xw-KS; Mon, 03 Nov 2003 05: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 1AGc5M-0004pO-OU for nsis@optimus.ietf.org; Mon, 03 Nov 2003 05:37: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 FAA26775 for ; Mon, 3 Nov 2003 05:37:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGc5J-0003Qs-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:37:21 -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 1AGc5I-0003Qp-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:37:20 -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; Mon, 03 Nov 2003 12:37:21 +0200 Date: Mon, 3 Nov 2003 12:37:21 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] Details about NSIS at IETF 58 In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Should we have one slide per draft for the background on the problem space people see? One slide with the main issues each "group" feels are the most important? Thath would make four slides? We could also have a preliminary discussion on the list. Regards, Jukka On Mon, 3 Nov 2003 john.loughney@nokia.com wrote: > Hannes, > > I want people to discuss it now, or speak-up on the mailing list that this > would be a good thing to discuss. So, resend your mail to the mailing list, > in a more positive light. I want to avoid a virtual mobility bof within > the NSIS meeting. > > John > > > -----Original Message----- > > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: 03 November, 2003 12:27 > > To: Loughney John (NRC/Helsinki); nsis@ietf.org > > Subject: RE: [NSIS] Details about NSIS at IETF 58 > > > > > > hi john, > > > > no discussion on the documents? we incorporated a number of > > comments based > > on discussions of the last few months into > > draft-fu-nsis-mobility-01.txt > > > > ciao > > hannes > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: Monday, November 03, 2003 10:55 AM > > > To: nsis@ietf.org > > > Subject: [NSIS] Details about NSIS at IETF 58 > > > > > > > > > Hi all, > > > > > > I've sent a preliminary agenda for NSIS 58. One open > > > discussion that the WG needs to consider is how to spend on > > > the mobility discussion. The following drafts have been > > > submitted, but there has been no discussion on the list about > > > this documents. > > > > > > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-01.txt > > > http://www.ietf.org/internet-drafts/draft-lee-nsis-mobility-ns > > > lp-00.txt > > > http://www.ietf.org/internet-drafts/draft-luu-ntlp-con-imp-00.txt > > > > > > br, > > > John > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 3 05:38:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26844 for ; Mon, 3 Nov 2003 05:38:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc61-000546-Mn for nsis-archive@odin.ietf.org; Mon, 03 Nov 2003 05:38:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Ac4MA019332 for nsis-archive@odin.ietf.org; Mon, 3 Nov 2003 05:38:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc5z-00050H-Mm; Mon, 03 Nov 2003 05:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc5k-0004tu-B6 for nsis@optimus.ietf.org; Mon, 03 Nov 2003 05:37:48 -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 FAA26800 for ; Mon, 3 Nov 2003 05:37:36 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGc5g-0003RV-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:37:44 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AGc5g-0003RS-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:37:44 -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 hA3AbiF20855 for ; Mon, 3 Nov 2003 12:37:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Nov 2003 12:37:44 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Nov 2003 12:37:43 +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] Details about NSIS at IETF 58 Date: Mon, 3 Nov 2003 12:37:42 +0200 Message-ID: Thread-Topic: [NSIS] Details about NSIS at IETF 58 Thread-Index: AcOh9jv6euThzUDOQt2PyUQ+EYTlyQAADtmw To: Cc: X-OriginalArrivalTime: 03 Nov 2003 10:37:43.0376 (UTC) FILETIME=[83529500:01C3A1F6] 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 Jukka, Thanks, I'll update the agenda. John > -----Original Message----- > From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: 03 November, 2003 12:35 > To: Loughney John (NRC/Helsinki) > Cc: nsis@ietf.org > Subject: Re: [NSIS] Details about NSIS at IETF 58 >=20 >=20 >=20 > Hi John, >=20 > We also had the following draft submitted about routing and mobility=20 > implications on NSIS work. >=20 > http://www.ietf.org/internet-drafts/draft-hancock-nsis-routing > -mobility-00.txt >=20 >=20 > Regards, > Jukka >=20 > On Mon, 3 Nov 2003 john.loughney@nokia.com wrote: >=20 > > Hi all, > >=20 > > I've sent a preliminary agenda for NSIS 58. One open=20 > discussion that the WG needs to consider is how to spend on=20 > the mobility discussion. The following drafts have been=20 > submitted, but there has been no discussion on the list about=20 > this documents. > >=20 > > http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-01.txt > >=20 http://www.ietf.org/internet-drafts/draft-lee-nsis-mobility-nslp-00.txt > http://www.ietf.org/internet-drafts/draft-luu-ntlp-con-imp-00.txt >=20 > br, > 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 Mon Nov 3 05:40:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26907 for ; Mon, 3 Nov 2003 05:40:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc7x-0005F6-KX for nsis-archive@odin.ietf.org; Mon, 03 Nov 2003 05:40:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Ae2bQ020059 for nsis-archive@odin.ietf.org; Mon, 3 Nov 2003 05:40:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc7u-0005DR-6G; Mon, 03 Nov 2003 05:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc7C-0005Bn-Q7 for nsis@optimus.ietf.org; Mon, 03 Nov 2003 05:39: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 FAA26884 for ; Mon, 3 Nov 2003 05:39:07 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGc79-0003TC-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:39:15 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AGc78-0003T7-00 for nsis@ietf.org; Mon, 03 Nov 2003 05:39:14 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA3AdFF22928 for ; Mon, 3 Nov 2003 12:39:15 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Nov 2003 12:39:15 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 3 Nov 2003 12:39:14 +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] Details about NSIS at IETF 58 Date: Mon, 3 Nov 2003 12:39:14 +0200 Message-ID: Thread-Topic: [NSIS] Details about NSIS at IETF 58 Thread-Index: AcOh9phbetElqeF3TxutfiXvHx/v6AAAAlIA To: , X-OriginalArrivalTime: 03 Nov 2003 10:39:15.0099 (UTC) FILETIME=[B9FE66B0:01C3A1F6] 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 Jukka, > Should we have one slide per draft for the background on the problem = space=20 > people see? One slide with the main issues each "group" feels are the=20 > most important? Thath would make four slides? >=20 > We could also have a preliminary discussion on the list. I'd like that we could discuss this on the list, a combined presentation would be one possible solution. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 4 04:02:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04669 for ; Tue, 4 Nov 2003 04:02: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 1AGx4p-00025j-QZ for nsis-archive@odin.ietf.org; Tue, 04 Nov 2003 04:02:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA492DG3007890 for nsis-archive@odin.ietf.org; Tue, 4 Nov 2003 04:02:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGx4e-00020r-P7; Tue, 04 Nov 2003 04:02:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGx4B-0001zk-Cp for nsis@optimus.ietf.org; Tue, 04 Nov 2003 04:01:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04608 for ; Tue, 4 Nov 2003 04:01:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGx48-0001FS-00 for nsis@ietf.org; Tue, 04 Nov 2003 04:01:32 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AGx48-0001FO-00 for nsis@ietf.org; Tue, 04 Nov 2003 04:01:32 -0500 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 04 Nov 2003 10:01:42 +0100 Message-ID: <3FA76A59.2050004@cs.uni-goettingen.de> Date: Tue, 04 Nov 2003 09:59:05 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: jmanner@cs.Helsinki.FI, nsis@ietf.org Subject: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, This sounds a good idea. One thing that has become clear to me is that although we all have some kind of idea on what mobility issues are, those ideas are not necessarily totally aligned (although a certain number of issues have been described in different ways and not particulalrly opposed in most cases since pre-&post-Vienna discussions). If NSIS is going to develop something interoperable with mobility protocols, I think it is probably necessary to come to some reasonable agreement on which issues are of common concern to all and which are of different view for each, before we go too far into presenting "seperate" issues but possibly repeating many issues several times. These can include, but not limit to, all the bullets that have come out of the existing discussions (e.g., host IP change, route change, IP-in-IP encapsulation, crossover router discovery, routing interface, etc.). For example, it seems to me more or less at least a consensus has been reached that working with mobility/route change is more of an NTLP concern rather than simply an NSLP issue. However, there are many other issues have not converged. For instance, there was a concern that flow ID should be able to used to route NSIS packets, but very likely, it can be problematic or inefficient in mobility and tunneling scenarios; we may instead rely on NTLP session ID together with the discovery functionality. Perhaps the outcome of the Minneapolis meeting would be not so much a direct solution, but to clarify a number of things. Best regards, Xiaoming john.loughney@nokia.com wrote: > Hi Jukka, > > >>Should we have one slide per draft for the background on the problem space >>people see? One slide with the main issues each "group" feels are the >>most important? Thath would make four slides? >> >>We could also have a preliminary discussion on the list. > > > I'd like that we could discuss this on the list, a combined presentation > would be one possible solution. > > br, > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 4 05:12:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06727 for ; Tue, 4 Nov 2003 05:12: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 1AGyAV-0007Q7-Fe for nsis-archive@odin.ietf.org; Tue, 04 Nov 2003 05:12:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4ACBNY028514 for nsis-archive@odin.ietf.org; Tue, 4 Nov 2003 05:12:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyAR-0007PP-Df; Tue, 04 Nov 2003 05:12:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyAE-0007OJ-7Q for nsis@optimus.ietf.org; Tue, 04 Nov 2003 05:11:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06681 for ; Tue, 4 Nov 2003 05:11:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGyAA-0002GI-00 for nsis@ietf.org; Tue, 04 Nov 2003 05:11:50 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AGyAA-0002Ff-00 for nsis@ietf.org; Tue, 04 Nov 2003 05:11:50 -0500 Received: from LocalHost (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA4ABIlr013224 for ; Tue, 4 Nov 2003 19:11:18 +0900 (KST) From: "Sung Hycuk Lee" To: Date: Tue, 4 Nov 2003 19:11:29 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Subject: [NSIS] Mobility-related issues in the NTLP/QoS-NSLP Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 DQpIaSBhbGwsDQoNCldlIHN1Ym1pdHRlZCB0aGUgZm9sbG93aW5nIGRyYWZ0cyBjb25jZXJuaW5n IA0KbW9iaWxpdHkgZnVuY3Rpb25zIGluIHRoZSBOVExQL1FvUy1OU0xQOg0KDQpodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sZWUtbnNpcy1tb2JpbGl0eS1uc2xwLTAw LnR4dA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamVvbmctbnNp cy1tb2JpbGl0eS1udGxwLTAwLnR4dA0KDQpCdXQsIHdlJ3ZlIHVwZGF0ZWQgdGhlIGRyYWZ0cyBy ZWNlbnRseSwgYW5kIHlvdSANCmNhbiBmaW5kIHRoZSB1cGRhdGVkIGRyYWZ0cyBhdCB0aGUgZm9s bG93aW5nIFVSTHM6DQogDQpodHRwOi8vd2lkZWNvbW0ua29yZWEuYWMua3IvfnN0YXJzdS9kcmFm dC1sZWUtbnNpcy1tb2JpbGl0eS1uc2xwLTAxLnR4dA0KaHR0cDovL3dpZGVjb21tLmtvcmVhLmFj LmtyL35zdGFyc3UvZHJhZnQtamVvbmctbnNpcy1tb2JpbGl0eS1udGxwLTAxLnR4dA0KIA0KVGhl c2UgZHJhZnRzIGRpc2N1c3NlZCB0aGUgZm9sbG93aW5nIChtb2JpbGl0eS1yZWxhdGVkKSBpc3N1 ZXMgYXQgZWFjaCBsYXllcjoNCg0KMS4gSW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlIE5UTFAgYW5k IHRoZSBOU0xQIGluIG1vYmlsaXR5IHN1cHBvcnQNCiAgIC0gU2luY2UgYW4gTU4gbWF5IGJlIGFu IE5SIG9yIE5JIGluIG1vYmlsaXR5IHNjZW5hcmlvcywgdGhlIE5UTFAgc2hvdWxkDQogICAgIGlu dGVyYWN0IHdpdGggdGhlIE5TTFAgYWNjb3JkaW5nIHRvIG1vYmlsaXR5IGV2ZW50cy4gU29tZSBy ZWxhdGVkIGlzc3VlcyBhcmUgYXMgZm9sbG93cy4NCg0KICAgQS4gSG93IGRvZXMgdGhlIE5UTFAg aW50ZXJhY3Qgd2l0aCB0aGUgTlNMUCBub3QgdG8gdHJpZ2dlciBhbiBlcnJvciBtZXNzYWdlIA0K ICAgICAgIGluZGljYXRpbmcgJ0Nhbi1Ob3QtQmUtRm9yd2FyZGVkLXRvLXRoZS1MQVNUX05PREUg KGUuZy4sIE1OKScgYWZ0ZXIgaGFuZG92ZXI/DQogICBCLiBIb3cgZG9lcyB0aGUgTlRMUCBpbnRl cmFjdCB3aXRoIHRoZSBOU0xQIHRvIGltbWVkaWF0ZWx5IHJlLWVzdGFibGlzaCBpdHMgc3RhdGVz IA0KICAgICAgIGFmdGVyIGhhbmRvdmVyPw0KICAgQy4gSG93IGRvZXMgdGhlIE5UTFAgaW50ZXJh Y3Qgd2l0aCB0aGUgTlNMUCB0byB0ZWFyZG93biBvbGQgc3RhdGVzIA0KICAgICAgIG9uIHRoZSBv YnNvbGV0ZSBwYXRoIGFmdGVyIGhhbmRvdmVyPw0KDQoyLiBDcm9zc292ZXIgTm9kZSBEaXNjb3Zl cnkNCiAgIC0gQXMgbWVudGlvbmVkIGluIHRoZSBOU0lTIGZyYW1ld29yayBkb2N1bWVudCwgdGhl IGRpc2NvdmVyeSBvZiB0aGUgY3Jvc3NvdmVyIG5vZGUNCiAgICAgaXMgaW1wb3J0YW50IGluIGxv Y2FsIHBhdGggcmVwYWlyLiBBIFNlc3Npb24gSUQgYW5kIGEgQnJhbmNoIElEIGFyZSBvbmx5IHVz ZWQgdG8gZmluZA0KICAgICB0aGUgY3Jvc3NvdmVyIG5vZGUgYWZ0ZXIgaGFuZG92ZXIsIGJ1dCBp biB0aGUgZm9sbG93aW5nIGNhc2UsIHRoZSBvbmx5IHR3byBJZGVudGlmaWVycw0KICAgIGFyZSBu b3QgZW5vdWdoIHRvIGZpbmQgdGhlIGNyb3Nzb3ZlciBub2RlLlNvbWUgcmVsYXRlZCBpc3N1ZXMg YXJlIGFzIGZvbGxvd3MuDQoNCiAgIEEuIElmIHRoZSBtZXJnaW5nIHBvaW50IG9mIHRoZSBvbGQg YW5kIG5ldyBwYXRocyBjYW4gbm90IHBlcmZvcm0gTlNJUyBmdW5jdGlvbmFsaXR5LCANCiAgICAg ICBob3cgZG9lcyB0aGUgTlRMUCBmaW5kIHRoZSBOU0lTLWF3YXJlIGNyb3Nzb3ZlciBOb2RlIA0K ICAgICAgIG9uIHRoZSBqb2ludGVkL2NvbW1vbiBwYXRoPw0KICAgQi4gSG93IGRvZXMgdGhlIE5U TFAgb2YgYSBDYW5kaWRhdGUgQWNjZXNzIFJvdXRlciAoQVIpIGZpbmQgdGhlIGNhbmRpZGF0ZSAg ICANCiAgICAgICBDcm9zc292ZXIgTm9kZSB0byBmYXN0IHJlLWVzdGFibGlzaCB0aGUgZXhpc3Rp bmcgTlNMUCBzdGF0ZSBkdXJpbmcgaGFuZG92ZXI/DQoNCjMuIERlYWQgUGVlciBEaXNjb3ZlcnkN CiAgIC0gQWx0aG91Z2ggdGhlIGNyb3Nzb3ZlciBub2RlIGhhcyBiZWVuIGRpc2NvdmVyZWQsIGl0 IG1heSBiZSBwb3NzaWJsZSB0aGF0IA0KICAgICB0aGUgY3Jvc3NvdmVyIG5vZGUgbWF5IG5vdCBm dW5jdGlvbiB3ZWxsIGZvciBzb21lIHJlYXNvbi4gQSBwb3NzaWJsZSANCiAgICAgaXNzdWUgaXMg YXMgZm9sbG93cy4NCg0KICAgQS4gSWYgdGhlIGNyb3Nzb3ZlciBub2RlIGZhaWxzLCBob3cgZG9l cyB0aGUgTlRMUCBkZXRlY3QgdGhlIGZhaWx1cmUgb2YgDQogICAgICAgdGhlIGNyb3Nzb3ZlciBu b2RlIGFuZCBmaW5kIGEgbmV3IGNyb3Nzb3ZlciBub2RlPw0KIA0KNC4gSW50ZXJ3b3JraW5nIHdp dGggTW9iaWxpdHkgcHJvdG9jb2xzDQogICAtIEFzIG1lbnRpb25lZCBpbiB0aGUgTlNJUyByZXF1 aXJlbWVudHMgZG9jdW1lbnQsIGFuIE5TSVMgcHJvdG9jb2wgc2hvdWxkIA0KICAgIHdvcmsgd2l0 aCBzZWFtbGVzcyBoYW5kb2ZmIHByb3RvY29scyBzdWNoIGFzIGNvbnRleHQgdHJhbnNmZXIgYW5k IA0KICAgIGNhbmRpZGF0ZSBhY2Nlc3Mgcm91dGVyIChDQVIpIGRpc2NvdmVyeS4gVGhlIGRvY3Vt ZW50IGFsc28gc3RhdGVzIA0KICAgIHRoYXQgTlNJUyBzaG91bGQgYWxsb3cgZWZmaWNpZW50IGFu ZCBxdWljayBzZXJ2aWNlIHJlLWVzdGFibGlzaG1lbnQgYWZ0ZXIgDQogICAgaGFuZG92ZXIuIFNv bWUgcmVsYXRlZCBpc3N1ZXMgYXJlIGFzIGZvbGxvd3MuDQoNCiAgQS4gSG93IGRvZXMgdGhlIE5U TFAgaW4gdGhlIGN1cnJlbnQgQVIgaW50ZXJhY3Qgd2l0aCBDQVJEDQogICAgIHRvIGZhc3QgcmUt ZXN0YWJsaXNoIGl0cyBhc3NvY2lhdGVkIE5TTFAgc3RhdGVzPw0KICBCLiBIb3cgZG9lcyB0aGUg TlRMUCBpbiBDdXJyZW50IEFSIGludGVyYWN0IHdpdGggQ1QNCiAgICAgdG8gc2VuZCBpdHMgYXNz b2NpYXRlZCBleGlzdGluZyBOU0xQIHN0YXRlcyB0byB0aGUgY2FuZGlkYXRlIEFSPw0KDQo1LiBT dGF0ZSBNYW5hZ2VtZW50DQogICAtIEFzIG1lbnRpb25lZCBpbiB0aGUgTlNJUyBmcmFtZXdvcmsg ZG9jdW1lbnQsIHN0YXRlIG1hbmFnZW1lbnQgaXMgcmVxdWlyZWQNCiAgICAgaW4gdGhlIE5UTFAg YW5kIHRoZSBOU0xQIGZvciBOU0lTIHNpZ25hbGluZy4gVGhlIHN0YXRlIG1hbmFnZW1lbnQgaW4g dGhlIG1vYmlsZQ0KICAgICBlbnZpcm9ubWVudCBzaG91bGQgYWxzbyBiZSBjb25zaWRlcmVkLiBT b21lIHJlbGF0ZWQgaXNzdWVzIGFyZSBhcyBmb2xsb3dzLg0KICAgICANCiAgQS4gSG93IChhbmQg d2hlbikgY2FuIHRoZSBRb1MtTlNMUCBhZGp1c3QgdGhlIHJlZnJlc2ggdGltZXIgdmFsdWUgYWNj b3JkaW5nDQogICAgIHRvIHRoZSBuZXR3b3JrIGVudmlyb25tZW50Pw0KICBCLiBJcyBpdCBuZWNl c3NhcnkgdG8gc2V0IHRoZSByZWZyZXNoIHRpbWVyIHZhbHVlIGluIGEgd2lyZWxlc3MgbmV0d29y ayB0byBhIHNtYWxsZXIgDQogICAgICB2YWx1ZSB0aGFuIHRoYXQgaW4gdGhlIGNvcmUgKHdpcmVk KSBuZXR3b3JrPw0KDQo2LiBRb1MtTlNMUCBzdGF0ZSBSZS1lc3RhYmxpc2htZW50DQogICAtIEFz IG1lbnRpb25lZCBpbiB0aGUgTlNJUyByZXF1aXJlbWVudHMgZG9jdW1lbnQsIHRoZSBOU0lTIHNp Z25hbGluZyANCiAgICAgbXVzdCBhbGxvdyBlZmZpY2llbnQgcmUtZXN0YWJsaXNobWVudCBhZnRl ciBoYW5kb3Zlci4gIFJlLWVzdGFibGlzaG1lbnQgDQogICAgIGFmdGVyIGhhbmRvdmVyIG11c3Qg YmUgYXMgcXVpY2sgYXMgcG9zc2libGUgc28gdGhhdCB0aGUgbW9iaWxlIG5vZGUgDQogICAgIGRv ZXMgbm90IGV4cGVyaWVuY2Ugc2VydmljZSBpbnRlcnJ1cHRpb24gb3Igc2VydmljZSBkZWdyYWRh dGlvbi4gDQogICAgIFRoZSByZS1lc3RhYmxpc2htZW50IHNob3VsZCBiZSBsb2NhbGl6ZWQsIGFu ZCBub3QgcmVxdWlyZSBlbmQtdG8tZW5kIA0KICAgICBzaWduYWxpbmcuIFNvbWUgcmVsYXRlZCBp c3N1ZXMgYXJlIGFzIGZvbGxvd3MuDQoNCiAgQS4gSG93IGRvZXMgdGhlIFFvUy1OU0xQIGludGVy YWN0IHdpdGggdGhlIE5UTFAgdG8gZmFzdCByZS1lc3RhYmxpc2ggdGhlIFFvUy1OU0xQIA0KICAg ICBzdGF0ZXMgYWZ0ZXIgaGFuZG92ZXI/DQogIEIuIEhvdyBjYW4gdGhlIGRlbGF5ZWQgc2lnbmFs aW5nIHByb2JsZW0gYmUgc29sdmVkIGluIGEgcmVjZWl2ZXItaW5pdGlhdGVkIGFwcHJvYWNoPw0K DQpXZSB3ZWxjb21lIGFueSBjb21tZW50cyBvciBzdWdnZXN0aW9ucy4NCg0KVGhhbmtzIGFuZCBS ZWdhcmRzLA0KDQpTdW5nLUh5dWNrIExlZS9TZW9uZy1IbyBKZW9uZw0KDQo= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 4 14:30:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29754 for ; Tue, 4 Nov 2003 14:30:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6sO-0006vI-PU for nsis-archive@odin.ietf.org; Tue, 04 Nov 2003 14:30:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4JU4P7026608 for nsis-archive@odin.ietf.org; Tue, 4 Nov 2003 14: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 1AH6sM-0006uW-8e; Tue, 04 Nov 2003 14:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6sD-0006u3-9u for nsis@optimus.ietf.org; Tue, 04 Nov 2003 14:29:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29679 for ; Tue, 4 Nov 2003 14:29:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6sA-0003Ta-00 for nsis@ietf.org; Tue, 04 Nov 2003 14:29:50 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AH6s9-0003T6-00 for nsis@ietf.org; Tue, 04 Nov 2003 14:29:50 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 19:29:13 -0000 Message-ID: From: "Hancock, Robert" To: Marcus Brunner , nsis@ietf.org Subject: RE: [NSIS] NTLP draft Date: Tue, 4 Nov 2003 19:29:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi marcus, all, > Robert, all, > > In general I think it is a good starting point for discussion. phew! to be serious: if this -00 version can help the WG to come to a consensus on whether to follow the approach described in section 3 or to do something different, it will IMHO have served its purpose. about the general approach described in 3... > > The view has been expressed that this is a good approach to > > investigate, but that there are some consequences which have > > to be worried over. We hope that the description now in the draft > > is clear enough to allow the WG to make its mind up on the > > matter. In particular, section 5.3 describes the problems > > and some possible cures (some people may find some of the > > cures worse than the problems). > > > > Section 5.3 was really the point were I got lost. I have seen > the several > options, but did not figure what the difference really is, > and why the raw > encapsulation is not sufficient. the best I can do is point to the example given in appendix C. the point is (using the terminology of that example), that the NSLPs at A and F really want the services of a messaging association between themselves, but the necessity of intermediate nodes to do some actions on the signalling messages means that if you use raw mode, the messaging association has to be broken into pieces. you then have to decide whether this breaking is a problem or not. > > > > > As a general point, this version is long (very long) on > > explanation and discussion, and short on actual specification. > > In fact, my impression is that GIMPS (or whatever we call it) > > is actually a rather simple protocol, which can behave > > in a number of very complicated ways and has a number of > > very complicated interactions with other protocols. So, > > in the longer term, we may need to think about how to structure > > the specification to reflect this (somewhat unusual) situation. > > The main problem I see is the flexibility which is still in > there. I think > we need to define quite a number of parameters in a static > way. There is a > lot of language saying "if you want to do that then configure > ....". In > many cases it is not clear who is deciding on the choices > (And I think we > already had some discussion on the topic). this is something that I think has to be handled case by case. we tried to pick out the major ones (where the impact is on more nodes than just the one making the choice) in section 8. this sort of flexibility has to be carefully justified. however, IMHO there are other sorts of flexibility (where there is implementation freedom in how to process messages at a node which doesn't change what's required of other nodes) which is much less dangerous. > > The other thing I did not get: > > 1) the GIMPS State (section 4.1). Why is the session id not > enough as index? two reasons: a) if multiple signalling applications were using the same session id (which is currently not ruled out), and if the GIMPS is bypassing NSLP-unaware nodes for some signalling applications, then the identity of the next/previous peer can depend on the signalling application. b) the flow id can change for a session (ip mobility) or there can be more than one (ip multihoming). it is probably the case that more discussion might allow us to restrict how session ids are allowed to map to application/flow ids (currently this is left pretty free). > > 2) For route change propagation I would assume a notification > per-application sitting on the node detecting the change > might work fine. > Would mean that the GIMPS keeps state for applications not > supported on the > specific node (which might be the case when only using raw > encapsulation.) this is a partial answer. but then there are two implications: a) GIMPS needs to store state for applications not supported on that node. This might well mean storing state for flows not otherwise interesting to that node. This might be happening anyway (you want connection mode and chose raw encapsulation) but would also even happen in datagram mode. This could lead to an explosion in flow storage requirements (think of all the middlebox application signalling state that core qos-nslp-only routers would end up with). b) even if the node stores state about the application it doesn't support, what does it then do with the notification? (i.e. the problem hasn't gone away.) > > Concerning the Open Issues > > 8.1) in GIMPS I don't like the word messaging in GIMPS. I > would vote for > GIST or any other choice (the field is open...) > > 8.2) + 8.3) I don't see why raw IP would not work for datagram mode. i think basically it would work, although I forsee some problems (mainly in some nat-traversal cases). are there actual advantages to raw IP? > > 8.4) I don't see why we need to care about letting signaling messages > travel on the fast path (no processing on the node). Putting too much > optimization into a design normally causes more problems than > gain, and we > optimize for todays technology, which might change as well. philosophically I agree, especially if we are talking about strictly 'protocol internal' functionality. when we are talking about the interface between NSIS and 'the rest of the Internet' I think the situation is slightly different. think about all those core nodes who want to do at most lightweight processing of some very specific qos-nslp having to do slow-path processing of some other signalling application which is really only interesting to edges. this could have a major effect on the network. > > 8.5) I propose to use 3 types of associations (unreliable, reliable, > secure), finer granular differentiation only complicates > without too much > gain. > this is a defensible position. i would like to see more views. > 8.7) I am in favor of raw mode. Seams to be the simplest one > without to > much impact. please see above. > > 8.10) scope should be a function for applications needing it, I don't > regard it as general functionality. this is a defensible position also. again i would like to see more views. > > 8.11) Reverse routing should be optional, it allows for > stateless operation > in the core an alternative view would be that the statelessness in the core could be supported by non-raw encapsulation and we lose the complexity of having to decide whether reverse state has been stored or not. (the problems come in error cases where reverse routing state is available on some parts of the path but not others). there is also some interaction here with whether we allow route recording (6.3). > > 8.12) additional discovery mechanisms are really nice in various > environments. Is there an impact on the protocol definition, > or is this > more an implementation issue? this is a good question. we have slightly underemphasised the issue (for fear of re-opening the on/off-path debate). some parts of the protocol are unaffected by how the routing state is set up (all of 4.2); some parts are affected (much of 4.3). The threat picture (threats against routing state integrity, 7.3) definitely changes, as do some aspects of the routing interactions (6.1). so, i would say it is definitely more than an implementation issue - or rather, we cannot promise it is only an implementation issue without doing more analysis work. However, the basic protocol design is in principle open to other mechanisms for filling in the routing state table, and some extensions may be useful even while we are restricted to the path-coupled case. > > Kind regrad, > > Marcus > & cheers, r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 4 15:03:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01641 for ; Tue, 4 Nov 2003 15:03:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7OH-00013P-PE for nsis-archive@odin.ietf.org; Tue, 04 Nov 2003 15:03:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4K31rJ004032 for nsis-archive@odin.ietf.org; Tue, 4 Nov 2003 15:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7OH-00012p-17; Tue, 04 Nov 2003 15:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7Nb-00011y-3x for nsis@optimus.ietf.org; Tue, 04 Nov 2003 15:02: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 PAA01604 for ; Tue, 4 Nov 2003 15:02:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7NY-0004DH-00 for nsis@ietf.org; Tue, 04 Nov 2003 15:02:16 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AH7NX-0004Cc-00 for nsis@ietf.org; Tue, 04 Nov 2003 15:02:15 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 20:01:45 -0000 Message-ID: From: "Hancock, Robert" To: Xiaoming Fu , john.loughney@nokia.com Cc: jmanner@cs.Helsinki.FI, nsis@ietf.org Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Tue, 4 Nov 2003 20:01:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi xiaoming, jukka, john, .... process-wise: i see some value in a 'what things group X/Y/Z cares about' discussion. i see much more value in a 'this is the complete issue list and here are the commonalities/divergences between different people' discussion (as I think we succeeded in doing with the 3 QoS drafts in Vienna). we should start that discussion on the list now and maybe we can do some further merging in Minneapolis (depending on what else is exciting to do on Monday). on a scoping point: between the lines I detect some concern that there is a danger that some of the mobility discussion may turn into some kind of 'Mobile-NSIS' project with a life of its own. it's my opinion that this shouldn't happen (and in fact isn't likely to happen). instead, what I think we are talking about here is analysis work which will feed into defining the functionality that is required in the basic NSIS protocols themselves (just like we have analysed security and so on). that protocol design work - which is going on now - is a potential eager consumer of this mobility work; at the moment, the mobility impact on protocol design has been driven mainly by instinct rather than solid thought, and it is time to put that instinct on a much firmer foundation. on the technical points: i have a pile of drafts to read... cheers, r. > -----Original Message----- > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > Sent: Tuesday, November 04, 2003 08:59 > To: john.loughney@nokia.com > Cc: jmanner@cs.Helsinki.FI; nsis@ietf.org > Subject: Issues splitting/consensus - Re: [NSIS] Details about NSIS at > IETF 58 > > > John, > > This sounds a good idea. One thing that has become clear to > me is that > although we all have some kind of idea on what mobility issues are, > those ideas are not necessarily totally aligned (although a certain > number of issues have been described in different ways and not > particulalrly opposed in most cases since pre-&post-Vienna > discussions). > > If NSIS is going to develop something interoperable with mobility > protocols, I think it is probably necessary to come to some > reasonable > agreement on which issues are of common concern to all and > which are of > different view for each, before we go too far into presenting > "seperate" > issues but possibly repeating many issues several times. These can > include, but not limit to, all the bullets that have come out of the > existing discussions (e.g., host IP change, route change, IP-in-IP > encapsulation, crossover router discovery, routing interface, > etc.). For > example, it seems to me more or less at least a consensus has been > reached that working with mobility/route change is more of an NTLP > concern rather than simply an NSLP issue. However, there are > many other > issues have not converged. For instance, there was a concern > that flow > ID should be able to used to route NSIS packets, but very > likely, it can > be problematic or inefficient in mobility and tunneling scenarios; we > may instead rely on NTLP session ID together with the discovery > functionality. Perhaps the outcome of the Minneapolis meeting > would be > not so much a direct solution, but to clarify a number of things. > > Best regards, > Xiaoming > > john.loughney@nokia.com wrote: > > Hi Jukka, > > > > > >>Should we have one slide per draft for the background on > the problem space > >>people see? One slide with the main issues each "group" > feels are the > >>most important? Thath would make four slides? > >> > >>We could also have a preliminary discussion on the list. > > > > > > I'd like that we could discuss this on the list, a combined > presentation > > would be one possible solution. > > > > br, > > John > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 5 16:47:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25766 for ; Wed, 5 Nov 2003 16:47:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVUY-0000XV-DD for nsis-archive@odin.ietf.org; Wed, 05 Nov 2003 16:47:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Ll60H002067 for nsis-archive@odin.ietf.org; Wed, 5 Nov 2003 16:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVUS-0000VA-Ma; Wed, 05 Nov 2003 16: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 1AHVU4-0000Tq-FB for nsis@optimus.ietf.org; Wed, 05 Nov 2003 16:46:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25752 for ; Wed, 5 Nov 2003 16:46:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVU2-00044b-00 for nsis@ietf.org; Wed, 05 Nov 2003 16:46:34 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AHVU1-000442-00 for nsis@ietf.org; Wed, 05 Nov 2003 16:46:33 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Nov 2003 21:46:03 -0000 Message-ID: From: "Hancock, Robert" To: Ling Kim Hui , nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt Date: Wed, 5 Nov 2003 21:46:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi again, > -----Original Message----- > From: Ling Kim Hui [mailto:lingkimhui@yahoo.com.sg] > Sent: Monday, November 03, 2003 03:31 > To: nsis@ietf.org > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt > > > Dear Mr Hancock, > > Thanks a lot for your timely reply. After checking the mailing list > archieve, I realized that the framework draft -04 has already gone > through the working group last call. Does it mean that the draft -05 > will go directly to AD/IESG for review? Sorry for asking, > since I am not that familiar with the review procedure. yes, basically -05 is now in ad/iesg hands. (this doesn't stop us talking about what it means, however.) > > I agree with most of your comments, though I have a few more thoughts > about them. > > > > > i consider this as coming under the broad heading of route changes. > > there are actually several different categories of route change anyway > > (different peer because of topology change, different peer because of > > NE failure but no rerouting, same peer but different ingress or egress > > interfaces, same peer but different intermediate routers, ...) > > > > exactly how each case is distinguished and handled will have to be > > done during protocol design. different protocol designs and indeed > > different implementations will be able to do different types of route > > change handling, so the framework can't really define this. > > This makes things clearer to me. But I think the case we listed out is > more of a detection of false route change. Largely in the draft, the > route change is defined as the change of route for data traffic. > > It is correct that details of handling the route change is a protocol > design issue, but my feeling is that in the framework, we should point > out different scenarios, so that protocol designer could be aware of > those issues. > > Therefore, it would be good to include some text to clearly identify the > route change cases (including the false route change) this could be done. it means referencing 3.2.5 from 5.1.2 and noting in particular that sometimes the next peer may change even though the topological route in the network has not. > > the information is the flow id (4.6.1). we specifically don't call > > this the flow classifier, since the NTLP isn't interested in packet > > classification; another name for the flow id would be 'flow routing > > information' (which is what the NTLP draft calls it). the NSLP might > > use the flow id as part of a packet classifier. > > Is the flow ID the only field that needs to be visible to the NTLP? How > would the NTLP uses information in the NSLP payload? Should it be > accessible by the NTLP? Shouldn't that be encrypted? > > I know this maybe depend on the implementation, but is it possible to > give me some guidance on any possible implementation method, since I am > really curious how it should be realized? > well (just for example): the NSLP would invoke the NTLP with - an opaque (maybe encrypted) payload (e.g. some QoS parameters) - addressing information about the flow being signalled for the NTLP formats the addressing information into a flow ID object, which is carried along with other NTLP objects (message sequence numbers and so on), and the NSLP payload. the NTLP doesn't interpret the NSLP payload, but the flow ID is not part of the NSLP payload. (the NSLP can find out about some NTLP objects, just like a UDP or TCP based programme can find out about what IP addresses are associated with a socket.) of course, other approaches are also possible. > > > formally, the f/w is not a standards track document, so it > > cannot define and manage identifier formats in this way. at > > the moment it seems likely that the session id will be an object in > > the NTLP, so the NTLP specification will pin this down and the sort > > of problems you indicate cannot arise. > > I am a bit confused here. Does this mean that the session ID instead of > Signaling Application ID would be used for demultiplexing the NSLPs? not "instead of", "possibly as well as". > Would the NTLP define how the Session ID be formatted? yes. the session ID would be another object in the NTLP, so the NTLP spec would have to define how it is formatted. > > As described also in your mail, the Session ID is not able to fully > replace the Signaling Application ID. Therefore, I think the SAID > format still has to be formally defined to achieve interoperability. If > the framework could not do it, would NTLP draft able to define it? I > feel maybe it is better to put a pointer in the framework > draft to that. i hope that is implied by the fact that these objects are assumed to be carried in the NTLP. maybe 4.6 should say this at the start if this is unclear. > > Also, I am not quite clear about the statement "it seems likely that the > session id will be an object in the NTLP". Does it mean the Session ID > would be generated and maintained in NTLP, and it would be carried at > NTLP headers? to answer the second question: yes (see above). to answer the first question: maybe, maybe not. this is a matter of NTLP design and also an implementation issue. a good comparison is the IPv6 flow label specification work (draft-ietf-ipv6-flow-label-08.txt section 3). the details can get even more complicated in the NSIS case. > > > > Thank you very much for your time and attention. > > Regards, > Kim Hui it's a pleasure, r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 5 17:06:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26608 for ; Wed, 5 Nov 2003 17:06:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVms-0001X0-HP for nsis-archive@odin.ietf.org; Wed, 05 Nov 2003 17:06:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5M627W005870 for nsis-archive@odin.ietf.org; Wed, 5 Nov 2003 17:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVms-0001WW-6a; Wed, 05 Nov 2003 17:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVmI-0001Vs-K2 for nsis@optimus.ietf.org; Wed, 05 Nov 2003 17:05:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26589 for ; Wed, 5 Nov 2003 17:05:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVmG-0004RD-00 for nsis@ietf.org; Wed, 05 Nov 2003 17:05:24 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHVmF-0004Qz-00 for nsis@ietf.org; Wed, 05 Nov 2003 17:05:24 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 05 Nov 2003 14:09:28 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA5M4mDd020106; Wed, 5 Nov 2003 14:04:49 -0800 (PST) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANX55076; Wed, 5 Nov 2003 14:04:47 -0800 (PST) Date: Wed, 5 Nov 2003 17:04:46 -0500 Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: nsis@ietf.org To: "Hancock, Robert" From: Melinda Shore In-Reply-To: Message-Id: <11533BC4-0FDC-11D8-A2D4-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, November 5, 2003, at 04:46 PM, Hancock, Robert wrote: > well (just for example): the NSLP would invoke the NTLP with > - an opaque (maybe encrypted) payload (e.g. some QoS parameters) > - addressing information about the flow being signalled for There are some issues here around NAT traversal that might lead one to conclude that the "NAT application" actually belongs in the NTLP. Having a firewall/NAT NSLP is fine if you aren't concerned about NAT interactions in other NSLPs, like QoS (or anything which uses addressing information as part of the reservation description). Obviously you want to avoid a situation in which the NTLP is peeking into, and parsing, NSLP payloads, and you want to avoid a situation in which random NSLPs must peek into a NAT NSLP (particularly if they're encrypted using different keys). Reimplementing NAT function in every NSLP that uses addresses is also unattractive. The first question, obviously, is how generalized you'd like your NAT traversal capabilities to be. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 5 18:29:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00836 for ; Wed, 5 Nov 2003 18:29:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX5C-0004te-Hh for nsis-archive@odin.ietf.org; Wed, 05 Nov 2003 18:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5NT2oZ018822 for nsis-archive@odin.ietf.org; Wed, 5 Nov 2003 18:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX5B-0004tN-K0; Wed, 05 Nov 2003 18:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX4q-0004s6-3W for nsis@optimus.ietf.org; Wed, 05 Nov 2003 18:28: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 SAA00816 for ; Wed, 5 Nov 2003 18:28:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHX4m-0005d0-00 for nsis@ietf.org; Wed, 05 Nov 2003 18:28:36 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AHX4m-0005cn-00 for nsis@ietf.org; Wed, 05 Nov 2003 18:28:36 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Nov 2003 23:28:06 -0000 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt Date: Wed, 5 Nov 2003 23:28:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi melinda, you raise an important point. i try to think of the NSIS NAT problems in coming in two levels. 1. a NAT has (somehow) established address and maybe port mappings for a flow. you want signalling packets to be treated by the NAT consistently with how the flow packets are treated (but you aren't trying to modify the mappings themselves). this includes as one example the SIIT case (where there is no explicit per-flow mapping state at all AFAIK). 2. you want to be able to inspect or control mappings in the NAT explicitly (e.g. to get an incoming flow through it, or discover what to put in an application layer payload). I think the direction we are going at the moment is that the functionality of (2) is to be handled by a special purpose signalling application. This can get pretty complex and involve non-trivial authorisation issues (especially where it fades into firewall traversal). For the nearly-orthogonal and quite restricted functionality to handle (1), at the moment we are trying to make it possible to do this in the NTLP (at least partly for the reasons you describe). We could have made a design decision that - the NAT should implement the functionality of (2), and - the signalling application should use it to fill out its payloads and this remains a possible approach, but I think it's overkill for a lot of scenarios. It might still be the right way in particularly paranoid security environments. Of course, we would have to be careful that nodes don't try to do things both ways at the same time. cheers, robert h. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, November 05, 2003 22:05 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt > > > On Wednesday, November 5, 2003, at 04:46 PM, Hancock, Robert wrote: > > well (just for example): the NSLP would invoke the NTLP with > > - an opaque (maybe encrypted) payload (e.g. some QoS parameters) > > - addressing information about the flow being signalled for > > There are some issues here around NAT traversal that might lead > one to conclude that the "NAT application" actually belongs in > the NTLP. Having a firewall/NAT NSLP is fine if you aren't > concerned about NAT interactions in other NSLPs, like QoS (or > anything which uses addressing information as part of the > reservation description). Obviously you want to avoid a > situation in which the NTLP is peeking into, and parsing, > NSLP payloads, and you want to avoid a situation in which > random NSLPs must peek into a NAT NSLP (particularly if > they're encrypted using different keys). Reimplementing NAT > function in every NSLP that uses addresses is also unattractive. > > The first question, obviously, is how generalized you'd like > your NAT traversal capabilities to be. > > Melinda > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 5 18:47:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01594 for ; Wed, 5 Nov 2003 18:47:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXMc-0007pb-AS for nsis-archive@odin.ietf.org; Wed, 05 Nov 2003 18:47:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Nl2Ir030084 for nsis-archive@odin.ietf.org; Wed, 5 Nov 2003 18: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 1AHXMb-0007p7-9y; Wed, 05 Nov 2003 18:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXLm-0007nd-6y for nsis@optimus.ietf.org; Wed, 05 Nov 2003 18:46:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01574 for ; Wed, 5 Nov 2003 18:45:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXLj-0005yk-00 for nsis@ietf.org; Wed, 05 Nov 2003 18:46:07 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHXLh-0005yI-00 for nsis@ietf.org; Wed, 05 Nov 2003 18:46:06 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2003 15:46:12 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA5NjWAv000508; Wed, 5 Nov 2003 15:45:34 -0800 (PST) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANX70325; Wed, 5 Nov 2003 15:45:30 -0800 (PST) Date: Wed, 5 Nov 2003 18:45:28 -0500 Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: nsis@ietf.org To: "Hancock, Robert" From: Melinda Shore In-Reply-To: Message-Id: <22E1FC0B-0FEA-11D8-A2D4-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, November 5, 2003, at 06:28 PM, Hancock, Robert wrote: > For the nearly-orthogonal and quite restricted functionality to > handle (1), at the moment we are trying to make it possible to do > this in the NTLP (at least partly for the reasons you describe). > We could have made a design decision that > - the NAT should implement the functionality of (2), and > - the signalling application should use it to fill out its payloads > and this remains a possible approach, but I think it's overkill for > a lot of scenarios. It might still be the right way in particularly > paranoid security environments. Of course, we would have to be careful > that nodes don't try to do things both ways at the same time. It's actually not very complex to tag addresses and put them in the NTLP with a "translate me" flag and put tags in the NSLP payloads. Another advantage of doing that, aside from providing optional support for translation of an address in any NSLP, is that you don't have to worry about application payload rewrites breaking integrity protection, and you don't have to deal with having an application do a credentials exchange with both its peers and whatever NATs may be along the path. I think it's a lot simpler and provides both better function and better security, but it's certainly not what's in the framework and you might not want to deviate at this late date. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 6 03:08:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27915 for ; Thu, 6 Nov 2003 03:08:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHfBU-0003fN-8O for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 03:08:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6883Q6014084 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 03:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHfBS-0003f3-Iv; Thu, 06 Nov 2003 03:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHfBE-0003d0-4S for nsis@optimus.ietf.org; Thu, 06 Nov 2003 03:07:48 -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 DAA27898 for ; Thu, 6 Nov 2003 03:07:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHfB9-0004T8-00 for nsis@ietf.org; Thu, 06 Nov 2003 03:07:43 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AHfB9-0004Sy-00 for nsis@ietf.org; Thu, 06 Nov 2003 03:07:43 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Nov 2003 08:07:08 -0000 Message-ID: From: "Hancock, Robert" To: Melinda Shore Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt Date: Thu, 6 Nov 2003 08:07:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi melinda, two points: > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, November 05, 2003 23:45 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt > > > On Wednesday, November 5, 2003, at 06:28 PM, Hancock, Robert wrote: > > For the nearly-orthogonal and quite restricted functionality to > > handle (1), at the moment we are trying to make it possible to do > > this in the NTLP (at least partly for the reasons you describe). > > We could have made a design decision that > > - the NAT should implement the functionality of (2), and > > - the signalling application should use it to fill out its payloads > > and this remains a possible approach, but I think it's overkill for > > a lot of scenarios. It might still be the right way in particularly > > paranoid security environments. Of course, we would have to > be careful > > that nodes don't try to do things both ways at the same time. > > It's actually not very complex to tag addresses and put them in the > NTLP with a "translate me" flag and put tags in the NSLP payloads. > Another advantage of doing that, aside from providing optional > support for translation of an address in any NSLP, is that you > don't have to worry about application payload rewrites breaking > integrity protection, and you don't have to deal with having > an application do a credentials exchange with both its peers and > whatever NATs may be along the path. I think it's a lot simpler > and provides both better function and better security, but it's > certainly not what's in the framework and you might not want to > deviate at this late date. on the framework front, please check the end of 4.6.1: " We've assumed here that the flow identification is not hidden within the NSLP, but is explicitly part of the NTLP. The justification for this is that it might be valuable to be able to do NSIS processing even at a node which was unaware of the specific signaling application (see section 3.2.3): an example scenario would be messages passing through an addressing boundary where the flow identification had to be re-written." i think this is saying something pretty close to what you are saying. what do you see as the main difference? (see also the mailing list on "Re: [NSIS] comments on NTLP design proposals" around 17/7/03 where this was discussed in a bit more detail.) on the security front, the issues are non-trivial. a basic problem is that an on-path adversary can re-write the flow id to make it refer to a different flow, hence stealing the reservation (or whatever the signalling is controlling); the fact that you can re-write the address fields without breaking integrity protection (as you mention) is both a benefit and a cost. this sort of issue needs more analysis in the NTLP design work (i don't think there is a perfect answer which satisfies the demands both of security and ease of deployment). cheers, r. > > Melinda > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 6 05:08:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02455 for ; Thu, 6 Nov 2003 05:08: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 1AHh3e-00049I-MH for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 05:08:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6A86cG015835 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 05:08:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh3Z-00046r-1U; Thu, 06 Nov 2003 05:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh3F-00042y-Cn for nsis@optimus.ietf.org; Thu, 06 Nov 2003 05:07:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02437 for ; Thu, 6 Nov 2003 05:07:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHh3B-0006K6-00 for nsis@ietf.org; Thu, 06 Nov 2003 05:07:37 -0500 Received: from [203.232.224.1] (helo=hufs.ac.kr) by ietf-mx with esmtp (Exim 4.12) id 1AHh3A-0006JP-00 for nsis@ietf.org; Thu, 06 Nov 2003 05:07:37 -0500 Received: from hufsshjeong ([203.253.71.65]) by hufs.ac.kr (8.11.7/8.11.7) with SMTP id hA6A0Wr20365; Thu, 6 Nov 2003 19:00:32 +0900 (KST) Message-ID: <039901c3a44c$d4c5fa00$491910ac@hufsshjeong> From: "Seong-Ho Jeong" To: "Hancock, Robert" , "Xiaoming Fu" , , Cc: , References: Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Thu, 6 Nov 2003 18:59:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LCBYaWFvbWluZywgSnVra2EsIFN1bmctSHl1Y2ssIGFuZCBKb2huLA0KDQpJTU8s IHRoZSBmb2xsb3dpbmcgY291bGQgYmUgKG1vYmlsaXR5LXJlbGF0ZWQpIGNvbW1vbiBpc3N1ZXMg DQooY29uY2VybmluZyB0aGUgTlRMUC9OU0xQKSB0aGF0IHRoZSBkcmFmdHMgc3VibWl0dGVkIGJ5 IGRpZmZlcmVudCANCnBlb3BsZSBoYXZlIGRpc2N1c3NlZC4NCg0KLSBEaWZmZXJlbmNlcyBiZXR3 ZWVuIHRoZSBnZW5lcmFsIHJvdXRlIGNoYW5nZSAobm90IHJlbGF0ZWQgdG8gbW9iaWxpdHkpIGFu ZCANCiAgIG1vYmlsaXR5LWNhdXNlZCByb3V0ZSBjaGFuZ2UNCi0gSG93IHRvIGRpc2NvdmVyIGNy b3Nzb3ZlciByb3V0ZXIgKG9yIGNyb3Nzb3ZlciBub2RlKSB1c2luZyBzb21lIGlkZW50aWZpZXJz DQogIChob3cgdG8gZGlzY292ZXIgdXBzdHJlYW0gYW5kIGRvd25zdHJlYW0gY3Jvc3NvdmVyIHJv dXRlcnMpDQotIEhvdyB0byBzZXR1cCBzdGF0ZXMgb24gdGhlIG5ldyBwYXRoIGFuZCB0ZWFyZG93 biBvbGQgc3RhdGVzIG9uIHRoZSBvYnNvbGV0ZSBwYXRoDQogIChhcyBxdWlja2x5IGFzIHBvc3Np YmxlLC4uLi4uLikNCi0gU3RhdGUgdXBkYXRlIG9uIHRoZSBqb2luZWQvY29tbW9uL3NoYXJlZC91 bmNoYW5nZWQgcGF0aCBhZnRlciBoYW5kb3Zlcg0KLSBJbnRlcmFjdGlvbnMgd2l0aCBtb2JpbGl0 eSBwcm90b2NvbHMgc3VjaCBhcyBDVCBhbmQgQ0FSRCAoaW4gYSBnZW5lcmFsIHdheSkNCi0gSW50 ZXJhY3Rpb25zIGJldHdlZW4gdGhlIE5UTFAgYW5kIE5TTFANCi0gU2VjdXJpdHkgaXNzdWVzIChh dXRob3JpemF0aW9uLC4uLikNCi0gZXRjLg0KDQpJIHRoaW5rIHRoYXQgKGF0IGxlYXN0KSB0aGUg YWJvdmUgaXNzdWVzIG1heSBuZWVkIHRvIGJlIGFkZHJlc3NlZCBpbiB0aGUgTlNJUyBXRy4uLi4g DQpBZGRpdGlvbmFsbHksIGl0IG1pZ2h0IGJlIGdvb2QgdG8gaW5jbHVkZSB0aGUgZm9sbG93aW5n IGlzc3VlcyB0aGF0IHdlcmUgZGlzY3Vzc2VkIA0Kc2VwYXJhdGVseSBieSB0aGUgZGlmZmVyZW50 IGRyYWZ0cy4NCg0KLSBJUC1pbi1JUCBlbmNhcHN1bGF0aW9uDQotIERlYWQgcGVlciAoY3Jvc3Nv dmVyIHJvdXRlcikgZGlzY292ZXJ5DQotIERpc2NvdmVyeSBvZiByZXNvdXJjZSBhdmFpbGFiaWxp dHkNCi0gU3RhdGUgbWFuZ2VtZW50IChyZWZyZXNoIHRpbWVyIHZhbHVlIG1hbmFnZW1lbnQsLi4u KQ0KLSBMYXN0IG5vZGUgZGV0ZWN0aW9uDQotIFByZS1yZXNlcnZhdGlvbg0KLSBldGMuLi4uDQoN ClJlZ2FyZHMsDQoNClNlb25nLUhvIEplb25nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQpGcm9tOiAiSGFuY29jaywgUm9iZXJ0IiA8cm9iZXJ0LmhhbmNvY2tAcm9rZS5jby51az4N ClRvOiAiWGlhb21pbmcgRnUiIDxmdUBjcy51bmktZ29ldHRpbmdlbi5kZT47IDxqb2huLmxvdWdo bmV5QG5va2lhLmNvbT4NCkNjOiA8am1hbm5lckBjcy5IZWxzaW5raS5GST47IDxuc2lzQGlldGYu b3JnPg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwNSwgMjAwMyA1OjAxIEFNDQpTdWJqZWN0 OiBSRTogSXNzdWVzIHNwbGl0dGluZy9jb25zZW5zdXMgLSBSZTogW05TSVNdIERldGFpbHMgYWJv dXQgTlNJUyBhdCBJRVRGIDU4DQoNCg0KPiBoaSB4aWFvbWluZywganVra2EsIGpvaG4sIC4uLi4N Cj4gDQo+IHByb2Nlc3Mtd2lzZToNCj4gaSBzZWUgc29tZSB2YWx1ZSBpbiBhICd3aGF0IHRoaW5n cyBncm91cCBYL1kvWiBjYXJlcyBhYm91dCcgZGlzY3Vzc2lvbi4NCj4gaSBzZWUgbXVjaCBtb3Jl IHZhbHVlIGluIGEgJ3RoaXMgaXMgdGhlIGNvbXBsZXRlIGlzc3VlIGxpc3QgYW5kIGhlcmUNCj4g YXJlIHRoZSBjb21tb25hbGl0aWVzL2RpdmVyZ2VuY2VzIGJldHdlZW4gZGlmZmVyZW50IHBlb3Bs ZScgZGlzY3Vzc2lvbg0KPiAoYXMgSSB0aGluayB3ZSBzdWNjZWVkZWQgaW4gZG9pbmcgd2l0aCB0 aGUgMyBRb1MgZHJhZnRzIGluIFZpZW5uYSkuDQo+IA0KPiB3ZSBzaG91bGQgc3RhcnQgdGhhdCBk aXNjdXNzaW9uIG9uIHRoZSBsaXN0IG5vdyBhbmQgbWF5YmUgd2UgY2FuIGRvDQo+IHNvbWUgZnVy dGhlciBtZXJnaW5nIGluIE1pbm5lYXBvbGlzIChkZXBlbmRpbmcgb24gd2hhdCBlbHNlIGlzIGV4 Y2l0aW5nDQo+IHRvIGRvIG9uIE1vbmRheSkuDQo+IA0KPiBvbiBhIHNjb3BpbmcgcG9pbnQ6DQo+ IGJldHdlZW4gdGhlIGxpbmVzIEkgZGV0ZWN0IHNvbWUgY29uY2VybiB0aGF0IHRoZXJlIGlzIGEg ZGFuZ2VyIHRoYXQNCj4gc29tZSBvZiB0aGUgbW9iaWxpdHkgZGlzY3Vzc2lvbiBtYXkgdHVybiBp bnRvIHNvbWUga2luZCBvZiAnTW9iaWxlLU5TSVMnDQo+IHByb2plY3Qgd2l0aCBhIGxpZmUgb2Yg aXRzIG93bi4gaXQncyBteSBvcGluaW9uIHRoYXQgdGhpcyBzaG91bGRuJ3QNCj4gaGFwcGVuIChh bmQgaW4gZmFjdCBpc24ndCBsaWtlbHkgdG8gaGFwcGVuKS4gaW5zdGVhZCwgd2hhdCBJIHRoaW5r IHdlDQo+IGFyZSB0YWxraW5nIGFib3V0IGhlcmUgaXMgYW5hbHlzaXMgd29yayB3aGljaCB3aWxs IGZlZWQgaW50byBkZWZpbmluZw0KPiB0aGUgZnVuY3Rpb25hbGl0eSB0aGF0IGlzIHJlcXVpcmVk IGluIHRoZSBiYXNpYyBOU0lTIHByb3RvY29scyB0aGVtc2VsdmVzDQo+IChqdXN0IGxpa2Ugd2Ug aGF2ZSBhbmFseXNlZCBzZWN1cml0eSBhbmQgc28gb24pLiB0aGF0IHByb3RvY29sIGRlc2lnbiAN Cj4gd29yayAtIHdoaWNoIGlzIGdvaW5nIG9uIG5vdyAtIGlzIGEgcG90ZW50aWFsIGVhZ2VyIGNv bnN1bWVyIG9mIHRoaXMgDQo+IG1vYmlsaXR5IHdvcms7IGF0IHRoZSBtb21lbnQsIHRoZSBtb2Jp bGl0eSBpbXBhY3Qgb24gcHJvdG9jb2wgZGVzaWduDQo+IGhhcyBiZWVuIGRyaXZlbiBtYWlubHkg YnkgaW5zdGluY3QgcmF0aGVyIHRoYW4gc29saWQgdGhvdWdodCwgYW5kIGl0DQo+IGlzIHRpbWUg dG8gcHV0IHRoYXQgaW5zdGluY3Qgb24gYSBtdWNoIGZpcm1lciBmb3VuZGF0aW9uLg0KPiANCj4g b24gdGhlIHRlY2huaWNhbCBwb2ludHM6DQo+IGkgaGF2ZSBhIHBpbGUgb2YgZHJhZnRzIHRvIHJl YWQuLi4NCj4gDQo+IGNoZWVycywNCj4gDQo+IHIuDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiBGcm9tOiBYaWFvbWluZyBGdSBbbWFpbHRvOmZ1QGNzLnVuaS1nb2V0dGluZ2Vu LmRlXQ0KPiA+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA0LCAyMDAzIDA4OjU5DQo+ID4gVG86 IGpvaG4ubG91Z2huZXlAbm9raWEuY29tDQo+ID4gQ2M6IGptYW5uZXJAY3MuSGVsc2lua2kuRkk7 IG5zaXNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBJc3N1ZXMgc3BsaXR0aW5nL2NvbnNlbnN1cyAt IFJlOiBbTlNJU10gRGV0YWlscyBhYm91dCBOU0lTIGF0DQo+ID4gSUVURiA1OA0KPiA+IA0KPiA+ IA0KPiA+IEpvaG4sDQo+ID4gDQo+ID4gVGhpcyBzb3VuZHMgYSBnb29kIGlkZWEuIE9uZSB0aGlu ZyB0aGF0IGhhcyBiZWNvbWUgY2xlYXIgdG8gDQo+ID4gbWUgaXMgdGhhdCANCj4gPiBhbHRob3Vn aCB3ZSBhbGwgaGF2ZSBzb21lIGtpbmQgb2YgaWRlYSBvbiB3aGF0IG1vYmlsaXR5IGlzc3VlcyBh cmUsIA0KPiA+IHRob3NlIGlkZWFzIGFyZSBub3QgbmVjZXNzYXJpbHkgdG90YWxseSBhbGlnbmVk IChhbHRob3VnaCBhIGNlcnRhaW4gDQo+ID4gbnVtYmVyIG9mIGlzc3VlcyBoYXZlIGJlZW4gZGVz Y3JpYmVkIGluIGRpZmZlcmVudCB3YXlzIGFuZCBub3QgDQo+ID4gcGFydGljdWxhbHJseSBvcHBv c2VkIGluIG1vc3QgY2FzZXMgc2luY2UgcHJlLSZwb3N0LVZpZW5uYSANCj4gPiBkaXNjdXNzaW9u cykuDQo+ID4gDQo+ID4gSWYgTlNJUyBpcyBnb2luZyB0byBkZXZlbG9wIHNvbWV0aGluZyBpbnRl cm9wZXJhYmxlIHdpdGggbW9iaWxpdHkgDQo+ID4gcHJvdG9jb2xzLCBJIHRoaW5rIGl0IGlzIHBy b2JhYmx5IG5lY2Vzc2FyeSB0byBjb21lIHRvIHNvbWUgDQo+ID4gcmVhc29uYWJsZSANCj4gPiBh Z3JlZW1lbnQgb24gd2hpY2ggaXNzdWVzIGFyZSBvZiBjb21tb24gY29uY2VybiB0byBhbGwgYW5k IA0KPiA+IHdoaWNoIGFyZSBvZiANCj4gPiBkaWZmZXJlbnQgdmlldyBmb3IgZWFjaCwgYmVmb3Jl IHdlIGdvIHRvbyBmYXIgaW50byBwcmVzZW50aW5nIA0KPiA+ICJzZXBlcmF0ZSIgDQo+ID4gaXNz dWVzIGJ1dCBwb3NzaWJseSByZXBlYXRpbmcgbWFueSBpc3N1ZXMgc2V2ZXJhbCB0aW1lcy4gVGhl c2UgY2FuIA0KPiA+IGluY2x1ZGUsIGJ1dCBub3QgbGltaXQgdG8sIGFsbCB0aGUgYnVsbGV0cyB0 aGF0IGhhdmUgY29tZSBvdXQgb2YgdGhlIA0KPiA+IGV4aXN0aW5nIGRpc2N1c3Npb25zIChlLmcu LCBob3N0IElQIGNoYW5nZSwgcm91dGUgY2hhbmdlLCBJUC1pbi1JUCANCj4gPiBlbmNhcHN1bGF0 aW9uLCBjcm9zc292ZXIgcm91dGVyIGRpc2NvdmVyeSwgcm91dGluZyBpbnRlcmZhY2UsIA0KPiA+ IGV0Yy4pLiBGb3IgDQo+ID4gZXhhbXBsZSwgaXQgc2VlbXMgdG8gbWUgbW9yZSBvciBsZXNzIGF0 IGxlYXN0IGEgY29uc2Vuc3VzIGhhcyBiZWVuIA0KPiA+IHJlYWNoZWQgdGhhdCB3b3JraW5nIHdp dGggbW9iaWxpdHkvcm91dGUgY2hhbmdlIGlzIG1vcmUgb2YgYW4gTlRMUCANCj4gPiBjb25jZXJu IHJhdGhlciB0aGFuIHNpbXBseSBhbiBOU0xQIGlzc3VlLiBIb3dldmVyLCB0aGVyZSBhcmUgDQo+ ID4gbWFueSBvdGhlciANCj4gPiBpc3N1ZXMgaGF2ZSBub3QgY29udmVyZ2VkLiBGb3IgaW5zdGFu Y2UsIHRoZXJlIHdhcyBhIGNvbmNlcm4gDQo+ID4gdGhhdCBmbG93IA0KPiA+IElEIHNob3VsZCBi ZSBhYmxlIHRvIHVzZWQgdG8gcm91dGUgTlNJUyBwYWNrZXRzLCBidXQgdmVyeSANCj4gPiBsaWtl bHksIGl0IGNhbiANCj4gPiBiZSBwcm9ibGVtYXRpYyBvciBpbmVmZmljaWVudCBpbiBtb2JpbGl0 eSBhbmQgdHVubmVsaW5nIHNjZW5hcmlvczsgd2UgDQo+ID4gbWF5IGluc3RlYWQgcmVseSBvbiBO VExQIHNlc3Npb24gSUQgdG9nZXRoZXIgd2l0aCB0aGUgZGlzY292ZXJ5IA0KPiA+IGZ1bmN0aW9u YWxpdHkuIFBlcmhhcHMgdGhlIG91dGNvbWUgb2YgdGhlIE1pbm5lYXBvbGlzIG1lZXRpbmcgDQo+ ID4gd291bGQgYmUgDQo+ID4gbm90IHNvIG11Y2ggYSBkaXJlY3Qgc29sdXRpb24sIGJ1dCB0byBj bGFyaWZ5IGEgbnVtYmVyIG9mIHRoaW5ncy4NCj4gPiANCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4g WGlhb21pbmcNCj4gPiANCj4gPiBqb2huLmxvdWdobmV5QG5va2lhLmNvbSB3cm90ZToNCj4gPiA+ IEhpIEp1a2thLA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+PlNob3VsZCB3ZSBoYXZlIG9uZSBzbGlk ZSBwZXIgZHJhZnQgZm9yIHRoZSBiYWNrZ3JvdW5kIG9uIA0KPiA+IHRoZSBwcm9ibGVtIHNwYWNl IA0KPiA+ID4+cGVvcGxlIHNlZT8gT25lIHNsaWRlIHdpdGggdGhlIG1haW4gaXNzdWVzIGVhY2gg Imdyb3VwIiANCj4gPiBmZWVscyBhcmUgdGhlIA0KPiA+ID4+bW9zdCBpbXBvcnRhbnQ/IFRoYXRo IHdvdWxkIG1ha2UgZm91ciBzbGlkZXM/DQo+ID4gPj4NCj4gPiA+PldlIGNvdWxkIGFsc28gaGF2 ZSBhIHByZWxpbWluYXJ5IGRpc2N1c3Npb24gb24gdGhlIGxpc3QuDQo+ID4gPiANCj4gPiA+IA0K PiA+ID4gSSdkIGxpa2UgdGhhdCB3ZSBjb3VsZCBkaXNjdXNzIHRoaXMgb24gdGhlIGxpc3QsIGEg Y29tYmluZWQgDQo+ID4gcHJlc2VudGF0aW9uDQo+ID4gPiB3b3VsZCBiZSBvbmUgcG9zc2libGUg c29sdXRpb24uDQo+ID4gPiANCj4gPiA+IGJyLA0KPiA+ID4gSm9obg0KPiA+ID4gDQo+ID4gDQo+ ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBuc2lzIG1haWxpbmcgbGlzdA0KPiA+IG5zaXNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2lzDQo+ID4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuc2lzIG1haWxpbmcgbGlz dA0KPiBuc2lzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25zaXMNCj4= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 6 07:21:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05831 for ; Thu, 6 Nov 2003 07:21: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 1AHj8O-0002oC-IX for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 07:21:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6CL882010777 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 07:21:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHj8J-0002nF-3f; Thu, 06 Nov 2003 07:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHj7T-0002md-3y for nsis@optimus.ietf.org; Thu, 06 Nov 2003 07:20: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 HAA05796 for ; Thu, 6 Nov 2003 07:20:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHj7S-00006A-00 for nsis@ietf.org; Thu, 06 Nov 2003 07:20:10 -0500 Received: from smtp2.libero.it ([193.70.192.52]) by ietf-mx with esmtp (Exim 4.12) id 1AHj7S-000064-00 for nsis@ietf.org; Thu, 06 Nov 2003 07:20:10 -0500 Received: from libero.it (193.70.192.46) by smtp2.libero.it (7.0.020-DD01) id 3F6F0DA00056004D for nsis@ietf.org; Thu, 6 Nov 2003 13:20:16 +0100 Date: Thu, 6 Nov 2003 13:19:38 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "scel\@inwind\.it" To: "nsis" X-XaM3-API-Version: 4.1 (B16) X-type: 0 X-SenderIP: 193.204.86.212 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RSVPv2 Sender: nsis-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'm Elena Scialpi. I am beginning the NSIS study and I hav= e one question in order to the following drafts: =A003-Nov-2002=A0=A0=A0= draft-westberg-proposal-for-rsvpv2-01.txt (00, 00) -> expired. 19-Apr-2= 003=A0=A0=A0draft-westberg-proposal-for-rsvpv2-nslp-00.tx RSVPv2 i= dea has been abandoned in front of NSISv1. Why? 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 Thu Nov 6 08:22:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07731 for ; Thu, 6 Nov 2003 08:22:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHk5P-000638-JH for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 08:22:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6DM7HQ023254 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 08:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHk5J-00062s-HB; Thu, 06 Nov 2003 08: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 1AHk4a-0005x5-AO for nsis@optimus.ietf.org; Thu, 06 Nov 2003 08:21:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07694 for ; Thu, 6 Nov 2003 08:21:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHk4Z-0000tO-00 for nsis@ietf.org; Thu, 06 Nov 2003 08:21:15 -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 1AHk4Y-0000tD-00 for nsis@ietf.org; Thu, 06 Nov 2003 08:21:14 -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, 06 Nov 2003 15:21:02 +0200 Date: Thu, 6 Nov 2003 15:21:02 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 In-Reply-To: <039901c3a44c$d4c5fa00$491910ac@hufsshjeong> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 went through all mobility-related drafts and I basically agree with you= =20 about the common issues. To me it seems that we have pretty much identified the main issues, and it is time to move on now. I would suggest that we gather one single draft about the implications of mobility, routing, multi-homing and routing changes/repair into one single WG draft. This draft would be used as a "requirements"-type of document as the design of NTLP continues, to check that the design fits specific environments (mobile, routing changes, multi-homing). The document would also include the backgrounds for certain issues, not just repeat requirements already mentioned in the requirements draft. In addition, the document would be a reference for the current and future NSLP documents: what you need to take into account when you design an NSLP? I would include in this document the issues Seong-Ho already mentioned, and, the issue with refresh timers, and encapsulation issues because many LMM protocols do this. I would leave out resource discovery (since, at least in a mobile environment, CARD is doing this), and pre-reservations, because these are more of a trick and very special scheme to deal with mobility and resources. Moreover, I wouldn't want the document to have discussions on how to implement things - the NTLP and NSLP documents will do this eventually, if not already. Thus, it would be a draft that documents the current understanding of the issues between mobility/routing/multi-homing and resource signaling. The authors of the various mobility drafts listed by John could meet in Minneapolis, e.g. on Sunday, after the reception, to discuss these issues before the actual NSIS WG meetings. We could, for example, try to agree on= =20 an initial set of issues to discuss in the draft, and assign responsible=20 section editors, and an overall editor. Any comments? Regards, Jukka On Thu, 6 Nov 2003, Seong-Ho Jeong wrote: > Hi Robert, Xiaoming, Jukka, Sung-Hyuck, and John, >=20 > IMO, the following could be (mobility-related) common issues=20 > (concerning the NTLP/NSLP) that the drafts submitted by different=20 > people have discussed. >=20 > - Differences between the general route change (not related to mobility) = and=20 > mobility-caused route change > - How to discover crossover router (or crossover node) using some identif= iers > (how to discover upstream and downstream crossover routers) > - How to setup states on the new path and teardown old states on the obso= lete path > (as quickly as possible,......) > - State update on the joined/common/shared/unchanged path after handover > - Interactions with mobility protocols such as CT and CARD (in a general = way) > - Interactions between the NTLP and NSLP > - Security issues (authorization,...) > - etc. >=20 > I think that (at least) the above issues may need to be addressed in the = NSIS WG....=20 > Additionally, it might be good to include the following issues that were = discussed=20 > separately by the different drafts. >=20 > - IP-in-IP encapsulation > - Dead peer (crossover router) discovery > - Discovery of resource availability > - State mangement (refresh timer value management,...) > - Last node detection > - Pre-reservation > - etc.... >=20 > Regards, >=20 > Seong-Ho Jeong >=20 > ----- Original Message -----=20 > From: "Hancock, Robert" > To: "Xiaoming Fu" ; > Cc: ; > Sent: Wednesday, November 05, 2003 5:01 AM > Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS a= t IETF 58 >=20 >=20 > > hi xiaoming, jukka, john, .... > >=20 > > process-wise: > > i see some value in a 'what things group X/Y/Z cares about' discussion. > > i see much more value in a 'this is the complete issue list and here > > are the commonalities/divergences between different people' discussion > > (as I think we succeeded in doing with the 3 QoS drafts in Vienna). > >=20 > > we should start that discussion on the list now and maybe we can do > > some further merging in Minneapolis (depending on what else is exciting > > to do on Monday). > >=20 > > on a scoping point: > > between the lines I detect some concern that there is a danger that > > some of the mobility discussion may turn into some kind of 'Mobile-NSIS= ' > > project with a life of its own. it's my opinion that this shouldn't > > happen (and in fact isn't likely to happen). instead, what I think we > > are talking about here is analysis work which will feed into defining > > the functionality that is required in the basic NSIS protocols themselv= es > > (just like we have analysed security and so on). that protocol design= =20 > > work - which is going on now - is a potential eager consumer of this=20 > > mobility work; at the moment, the mobility impact on protocol design > > has been driven mainly by instinct rather than solid thought, and it > > is time to put that instinct on a much firmer foundation. > >=20 > > on the technical points: > > i have a pile of drafts to read... > >=20 > > cheers, > >=20 > > r. > > > -----Original Message----- > > > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > > > Sent: Tuesday, November 04, 2003 08:59 > > > To: john.loughney@nokia.com > > > Cc: jmanner@cs.Helsinki.FI; nsis@ietf.org > > > Subject: Issues splitting/consensus - Re: [NSIS] Details about NSIS a= t > > > IETF 58 > > >=20 > > >=20 > > > John, > > >=20 > > > This sounds a good idea. One thing that has become clear to=20 > > > me is that=20 > > > although we all have some kind of idea on what mobility issues are,= =20 > > > those ideas are not necessarily totally aligned (although a certain= =20 > > > number of issues have been described in different ways and not=20 > > > particulalrly opposed in most cases since pre-&post-Vienna=20 > > > discussions). > > >=20 > > > If NSIS is going to develop something interoperable with mobility=20 > > > protocols, I think it is probably necessary to come to some=20 > > > reasonable=20 > > > agreement on which issues are of common concern to all and=20 > > > which are of=20 > > > different view for each, before we go too far into presenting=20 > > > "seperate"=20 > > > issues but possibly repeating many issues several times. These can=20 > > > include, but not limit to, all the bullets that have come out of the= =20 > > > existing discussions (e.g., host IP change, route change, IP-in-IP=20 > > > encapsulation, crossover router discovery, routing interface,=20 > > > etc.). For=20 > > > example, it seems to me more or less at least a consensus has been=20 > > > reached that working with mobility/route change is more of an NTLP=20 > > > concern rather than simply an NSLP issue. However, there are=20 > > > many other=20 > > > issues have not converged. For instance, there was a concern=20 > > > that flow=20 > > > ID should be able to used to route NSIS packets, but very=20 > > > likely, it can=20 > > > be problematic or inefficient in mobility and tunneling scenarios; we= =20 > > > may instead rely on NTLP session ID together with the discovery=20 > > > functionality. Perhaps the outcome of the Minneapolis meeting=20 > > > would be=20 > > > not so much a direct solution, but to clarify a number of things. > > >=20 > > > Best regards, > > > Xiaoming > > >=20 > > > john.loughney@nokia.com wrote: > > > > Hi Jukka, > > > >=20 > > > >=20 > > > >>Should we have one slide per draft for the background on=20 > > > the problem space=20 > > > >>people see? One slide with the main issues each "group"=20 > > > feels are the=20 > > > >>most important? Thath would make four slides? > > > >> > > > >>We could also have a preliminary discussion on the list. > > > >=20 > > > >=20 > > > > I'd like that we could discuss this on the list, a combined=20 > > > presentation > > > > would be one possible solution. > > > >=20 > > > > br, > > > > John > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=9E=C8=AC=99=A8=A5=8Ax%=8A=CBg=B2+"z=D7=E8=AE=08m=B6=9B>=FF=FC0=C3X=9E= =B5=FA+=83=F9=9A=8AY=9A=9F=F9b=B2=D8=A7~=8F=E7=B2+ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 6 08:25:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07790 for ; Thu, 6 Nov 2003 08:25:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHk8F-0006CI-U6 for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 08:25:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6DP3Bl023671 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 08:25:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHk8D-00069K-GO; Thu, 06 Nov 2003 08:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHk7H-00068r-NJ for nsis@optimus.ietf.org; Thu, 06 Nov 2003 08:24:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07764 for ; Thu, 6 Nov 2003 08:23:52 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHk7G-0000v5-00 for nsis@ietf.org; Thu, 06 Nov 2003 08:24:02 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHk7F-0000v1-00 for nsis@ietf.org; Thu, 06 Nov 2003 08:24:02 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA6DNxF20887 for ; Thu, 6 Nov 2003 15:23:59 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Nov 2003 15:23:59 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Nov 2003 15:23:59 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Nov 2003 15:23:59 +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: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Thu, 6 Nov 2003 15:23:58 +0200 Message-ID: Thread-Topic: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Thread-Index: AcOkaQJeKO+mv88MReOqPASRx2waDgAABACA To: , X-OriginalArrivalTime: 06 Nov 2003 13:23:59.0166 (UTC) FILETIME=[3C9895E0:01C3A469] 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 Jukka, > The authors of the various mobility drafts listed by John could meet = in > Minneapolis, e.g. on Sunday, after the reception, to discuss these = issues > before the actual NSIS WG meetings. We could, for example, try to = agree on=20 > an initial set of issues to discuss in the draft, and assign = responsible=20 > section editors, and an overall editor. I fully support this. If this is acceptable, then the results could be discussed at the NSIS meeting. I think this is a much better use of time, then presenting overlapping individual documents. Does anyone else have any comments on this? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 6 09:18:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09659 for ; Thu, 6 Nov 2003 09:18:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHkxW-0000k6-Ia for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 09:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6EI2HW002835 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 09:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHkxV-0000jc-S9; Thu, 06 Nov 2003 09:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHkwh-0000gf-RV for nsis@optimus.ietf.org; Thu, 06 Nov 2003 09:17:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09604 for ; Thu, 6 Nov 2003 09:16:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHkwg-0001bW-00 for nsis@ietf.org; Thu, 06 Nov 2003 09:17:10 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AHkwf-0001bT-00 for nsis@ietf.org; Thu, 06 Nov 2003 09:17:09 -0500 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Thu, 06 Nov 2003 15:17:17 +0100 Message-ID: <3FAA5747.402@cs.uni-goettingen.de> Date: Thu, 06 Nov 2003 15:14:31 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com, jmanner@cs.Helsinki.FI, nsis@ietf.org Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John, Jukka, It would be nice that we work together a single document regarding mobility and move things on. I also agree that mobility concerns with route change and tunneling; is it a little too overloaded for this document to cover general routing, multi-homing or general tunnel issues as well? (Unfortunately I will be not able to attend the Minneapolis meeting due to personal reasons. However, I am interested in this work and would like to participate in the discussions through emails.) Best regards, Xiaoming john.loughney@nokia.com wrote: > Hi Jukka, > > >>The authors of the various mobility drafts listed by John could meet in >>Minneapolis, e.g. on Sunday, after the reception, to discuss these issues >>before the actual NSIS WG meetings. We could, for example, try to agree on >>an initial set of issues to discuss in the draft, and assign responsible >>section editors, and an overall editor. > > > I fully support this. If this is acceptable, then the results could > be discussed at the NSIS meeting. I think this is a much better > use of time, then presenting overlapping individual documents. > > Does anyone else have any comments on this? > > 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 Nov 6 09:25:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10002 for ; Thu, 6 Nov 2003 09:25:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHl4J-00014H-Kl for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 09:25:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6EP3V9004101 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 09:25:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHl4I-00013v-Pj; Thu, 06 Nov 2003 09:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHl3Z-00012q-P4 for nsis@optimus.ietf.org; Thu, 06 Nov 2003 09:24: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 JAA09907 for ; Thu, 6 Nov 2003 09:24:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHl3Y-0001g3-00 for nsis@ietf.org; Thu, 06 Nov 2003 09:24: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 1AHl3X-0001g0-00 for nsis@ietf.org; Thu, 06 Nov 2003 09:24:15 -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, 06 Nov 2003 16:24:13 +0200 Date: Thu, 6 Nov 2003 16:24:13 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 In-Reply-To: <3FAA5747.402@cs.uni-goettingen.de> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I basically try to look at things with the KISS principle, and my initial assumptions are that mobility, routing, and multi-homing have much in common once we think about them properly and with an open mind. I wouldn't want to have several different documents discussing NTLP+NSLP and specific scenarios. Of course, it might happen that we end up realizing that certain issues are too complex and need their own documents. Still, I would start with the mentioned issues and see from there. Regards, Jukka On Thu, 6 Nov 2003, Xiaoming Fu wrote: > Hi John, Jukka, > > It would be nice that we work together a single document regarding > mobility and move things on. I also agree that mobility concerns with > route change and tunneling; is it a little too overloaded for this > document to cover general routing, multi-homing or general tunnel issues > as well? > > (Unfortunately I will be not able to attend the Minneapolis meeting due > to personal reasons. However, I am interested in this work and would > like to participate in the discussions through emails.) > > Best regards, > Xiaoming > > john.loughney@nokia.com wrote: > > Hi Jukka, > > > > > >>The authors of the various mobility drafts listed by John could meet in > >>Minneapolis, e.g. on Sunday, after the reception, to discuss these issues > >>before the actual NSIS WG meetings. We could, for example, try to agree on > >>an initial set of issues to discuss in the draft, and assign responsible > >>section editors, and an overall editor. > > > > > > I fully support this. If this is acceptable, then the results could > > be discussed at the NSIS meeting. I think this is a much better > > use of time, then presenting overlapping individual documents. > > > > Does anyone else have any comments on this? > > > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 6 09:30:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10368 for ; Thu, 6 Nov 2003 09:30:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHl99-0001TT-FE for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 09:30:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6EU39w005648 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 09:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHl98-0001Sz-L0; Thu, 06 Nov 2003 09:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHl8n-0001SK-Vi for nsis@optimus.ietf.org; Thu, 06 Nov 2003 09:29:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10359 for ; Thu, 6 Nov 2003 09:29:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHl8m-0001nX-00 for nsis@ietf.org; Thu, 06 Nov 2003 09:29:40 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AHl8l-0001nM-00 for nsis@ietf.org; Thu, 06 Nov 2003 09:29:39 -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 hA6ETVpn002490; Thu, 6 Nov 2003 15:29:32 +0100 (MET) Message-ID: <001f01c3a472$6576fe30$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , "nsis" References: Subject: Re: [NSIS] RSVPv2 Date: Thu, 6 Nov 2003 15:29:33 +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 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Elena Please note that some ideas and concepts that were included in the listed drafts are included in the QoS-NSLP draft, see: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-01.txt Thus the main concept discussed in the listed drafts is not abandoned. Best Regards, Georgios ----- Original Message ----- From: To: "nsis" Sent: Thursday, November 06, 2003 1:19 PM Subject: [NSIS] RSVPv2 > Hi all, > > I'm Elena Scialpi. > > I am beginning the NSIS study and I have one question in order to the following drafts: > > 03-Nov-2002 draft-westberg-proposal-for-rsvpv2-01.txt (00, 00) -> expired. > 19-Apr-2003 draft-westberg-proposal-for-rsvpv2-nslp-00.tx > > > RSVPv2 idea has been abandoned in front of NSISv1. Why? > > Hoping in your answers. > Best regards > Elena > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 6 10:18:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12949 for ; Thu, 6 Nov 2003 10:18:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlta-0004Ek-Nx for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 10:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6FI2PD016280 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 10:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHltY-0004ET-7t; Thu, 06 Nov 2003 10:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlsv-0004DU-G9 for nsis@optimus.ietf.org; Thu, 06 Nov 2003 10:17: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 KAA12908 for ; Thu, 6 Nov 2003 10:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlst-0002Ni-00 for nsis@ietf.org; Thu, 06 Nov 2003 10:17:19 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 1AHlss-0002Lk-00 for nsis@ietf.org; Thu, 06 Nov 2003 10:17:18 -0500 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Thu, 06 Nov 2003 16:16:42 +0100 Received: from docomolab-euro.com ([192.168.0.138]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 6 Nov 2003 16:16:41 +0100 Message-ID: <3FAA64A0.30601@docomolab-euro.com> Date: Thu, 06 Nov 2003 16:11:28 +0100 From: Paulo Mendes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner CC: nsis@ietf.org Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-b3863204-8257-41ba-a7e1-9486e4d9881b" X-OriginalArrivalTime: 06 Nov 2003 15:16:41.0663 (UTC) FILETIME=[FB5BBCF0:01C3A478] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-b3863204-8257-41ba-a7e1-9486e4d9881b Content-Type: multipart/alternative; boundary="------------010003010804040403040903" --------------010003010804040403040903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jukka, I also agree that something has to be done about the mobility-related drafts, since they have overlapping issues. However, I'm not convinced right now that analyzing mobility, multihoming and routing changes in the draft will lead us to a simpler document, complying with the KISS principle. To start from, because IMO the mobility issue by itself is already very complex, as we tried to show in our analysis draft. However, I think that we need to start working on the mobility issues that overlap in the presented drafts to achieve the goal of understanding how can NSIS be extended to mobile environments. For instance, I saw that your draft as a more general definition of crossover router. Hence, I agree with Robert when he says "I think we are talking about here is analysis work which will feed into defining the functionality that is required in the basic NSIS protocols themselves". This is, I agree that we must not include by now any discussion about how to implement any particular solution. I don't see why shouldn't we work in a mobility analysis draft and a multihoming analysis draft (by nature these are two different things). If after this analysis (divide to conquer principle :)), we realize that a common solution can be achieved, than we should work in a common solution draft. If not, just continue in separate ways. In what concerns routing changes, if they are due to the movement of end-hosts, this topic is naturally included in the mobility analysis. However, IMO routing changes "in the interior of the network", for instance due to load balancing and link failure, should be considered in the basic NSIS, since they do not happen only in mobile environments. I tend to disagree with you in what concerns the open issues. If you do not identify open issues by now you will have to do it late. Besides, an efficient solution for mobility within NSIS needs to be aware of open issues if it wants to be the next step in signaling. From the issues mentioned, resource discovery has to do also with the e2e new path and not only with the new access network. Only the latter is done by CARD. In what concerns pre-reservations, you have to deal with this sooner or latter if you want to get good quality levels for multimedia applications while moving. I'm not saying that this is easy or not, or that it should be included in NSIS. I'm just saying that this is an open issue. In what concerns Minneapolis: - Agree that the authors of the different drafts should meet in Minneapolis for further discussion (unfortunately I cannot attend this IETF meeting). This discussion should be extended to this mailing list. - About the presentations, probably it is a little late to get a consensus among authors in order to make a efficient join presentation, but I think that if this could be done, it would be most profitable. Cheers, Paulo Jukka MJ Manner wrote: >Hi, > >I basically try to look at things with the KISS principle, and my initial >assumptions are that mobility, routing, and multi-homing have much in >common once we think about them properly and with an open mind. I wouldn't >want to have several different documents discussing NTLP+NSLP and specific >scenarios. Of course, it might happen that we end up realizing that >certain issues are too complex and need their own documents. Still, I >would start with the mentioned issues and see from there. > >Regards, >Jukka > > >On Thu, 6 Nov 2003, Xiaoming Fu wrote: > > > >>Hi John, Jukka, >> >>It would be nice that we work together a single document regarding >>mobility and move things on. I also agree that mobility concerns with >>route change and tunneling; is it a little too overloaded for this >>document to cover general routing, multi-homing or general tunnel issues >>as well? >> >>(Unfortunately I will be not able to attend the Minneapolis meeting due >>to personal reasons. However, I am interested in this work and would >>like to participate in the discussions through emails.) >> >>Best regards, >>Xiaoming >> >>john.loughney@nokia.com wrote: >> >> >>>Hi Jukka, >>> >>> >>> >>> >>>>The authors of the various mobility drafts listed by John could meet in >>>>Minneapolis, e.g. on Sunday, after the reception, to discuss these issues >>>>before the actual NSIS WG meetings. We could, for example, try to agree on >>>>an initial set of issues to discuss in the draft, and assign responsible >>>>section editors, and an overall editor. >>>> >>>> >>>I fully support this. If this is acceptable, then the results could >>>be discussed at the NSIS meeting. I think this is a much better >>>use of time, then presenting overlapping individual documents. >>> >>>Does anyone else have any comments on this? >>> >>>John >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >> >> > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > > -- Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ --------------010003010804040403040903 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jukka,

I also agree that something has to be done about the mobility-related drafts, since they have overlapping issues. However, I'm not convinced right now that analyzing mobility, multihoming and routing changes in the draft will lead us to a simpler document, complying with the KISS principle. To start from, because IMO the mobility issue by itself is already very complex, as we tried to show in our analysis draft.
However, I think that we need to start working on the mobility issues that overlap in the presented drafts to achieve the goal of understanding how can NSIS be extended to mobile environments. For instance, I saw that your draft as a more general definition of crossover router.
Hence, I agree with Robert when he says "I think we are talking about here is analysis work which will feed into defining the functionality that is required in the basic NSIS protocols themselves". This is, I agree that we must not include by now any discussion about how to implement any particular solution.

I don't see why shouldn't we work in a mobility analysis draft and a multihoming analysis draft (by nature these are two different things). If after this analysis (divide to conquer principle :)), we realize that a common solution can be achieved, than we should work in a common solution draft. If not, just continue in separate ways.
In what concerns routing changes, if they are due to the movement of end-hosts, this topic is naturally included in the mobility analysis. However, IMO routing changes "in the interior of the network", for instance due to load balancing and link failure, should be considered in the basic NSIS, since they do not happen only in mobile environments.

I tend to disagree with you in what concerns the open issues. If you do not identify open issues by now you will have to do it late. Besides, an efficient solution for mobility within NSIS needs to be aware of open issues if it wants to be the next step in signaling. From the issues mentioned, resource discovery has to do also with the e2e new path and not only with the new access network. Only the latter is done by CARD. In what concerns pre-reservations, you have to deal with this sooner or latter if you want to get good quality levels for multimedia applications while moving. I'm not saying that this is easy or not, or that it should be included in NSIS. I'm just saying that this is an open issue.

In what concerns Minneapolis:
- Agree that the authors of the different drafts should meet in Minneapolis for further discussion (unfortunately I cannot attend this IETF meeting). This discussion should be extended to this mailing list.
- About the presentations, probably it is a little late to get a consensus among authors in order to make a efficient join presentation, but I think that if this could be done, it would be most profitable.

Cheers,
Paulo

Jukka MJ Manner wrote:
Hi,

I basically try to look at things with the KISS principle, and my initial
assumptions are that mobility, routing, and multi-homing have much in
common once we think about them properly and with an open mind. I wouldn't
want to have several different documents discussing NTLP+NSLP and specific
scenarios. Of course, it might happen that we end up realizing that
certain issues are too complex and need their own documents. Still, I
would start with the mentioned issues and see from there.

Regards,
Jukka


On Thu, 6 Nov 2003, Xiaoming Fu wrote:

  
Hi John, Jukka,

It would be nice that we work together a single document regarding 
mobility and move things on. I also agree that mobility concerns with 
route change and tunneling; is it a little too overloaded for this 
document to cover general routing, multi-homing or general tunnel issues 
as well?

(Unfortunately I will be not able to attend the Minneapolis meeting due 
to personal reasons. However, I am interested in this work and would 
like to participate in the discussions through emails.)

Best regards,
Xiaoming

john.loughney@nokia.com wrote:
    
Hi Jukka,


      
The authors of the various mobility drafts listed by John could meet in
Minneapolis, e.g. on Sunday, after the reception, to discuss these issues
before the actual NSIS WG meetings. We could, for example, try to agree on 
an initial set of issues to discuss in the draft, and assign responsible 
section editors, and an overall editor.
        
I fully support this.  If this is acceptable, then the results could
be discussed at the NSIS meeting.  I think this is a much better
use of time, then presenting overlapping individual documents.

Does anyone else have any comments on this?

John

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

    


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

  


-- 
Paulo Mendes
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany
Tel. +49-89-56824-226
Fax. +49-89-56824-300
E-mail: mendes@docomolab-euro.com
http://www.docomoeurolabs.de/
--------------010003010804040403040903-- ------=_NextPartTM-000-b3863204-8257-41ba-a7e1-9486e4d9881b-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 6 19:43:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10379 for ; Thu, 6 Nov 2003 19:43:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHuiM-00016r-A0 for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 19:43:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA70h2OX004261 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 19:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHuiL-00016C-2w; Thu, 06 Nov 2003 19:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHuiJ-000161-O0 for nsis@optimus.ietf.org; Thu, 06 Nov 2003 19:42: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 TAA10373 for ; Thu, 6 Nov 2003 19:42:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHuiH-0003b4-00 for nsis@ietf.org; Thu, 06 Nov 2003 19:42:57 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AHuiG-0003as-00 for nsis@ietf.org; Thu, 06 Nov 2003 19:42:56 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Nov 2003 00:42:24 -0000 Message-ID: From: "Hancock, Robert" To: Jukka MJ Manner , nsis@ietf.org Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Fri, 7 Nov 2003 00:42:34 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA10374 Sender: nsis-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, yes, let's do it like this and see how we get on. my preference=20 would be to get a single coherent document with the broad scope=20 that jukka mentions (route change, mobility, multihoming) and=20 maybe a bit more (see later reply to paulo, to come), which=20 explains what signalling messages have to be sent around and=20 when to handle these problems. deciding which layer is responsible for which bit of this should come later. one thing which we discovered doing our mobility work is that=20 there are still decisions about complexity/performance tradeoffs to be made in this work. for example, in the general case, to=20 achieve a rapid teardown on the old path may be quite difficult; so, there is a choice between 'we try to make this possible always' and 'if you want to have this function, do it with=20 card/ct/whatever'. to make these decisions sensibly, we need some concrete analysis in a form which everyone can absorb and come to a view on. (the result can then go into the protocol design documents.) r. PS. i'm all for meeting at the reception, although I may be fit to collapse asleep by the end of it. we can at least find out who is around and when people are free monday. > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Thursday, November 06, 2003 13:21 > To: nsis@ietf.org > Subject: Re: Issues splitting/consensus - Re: [NSIS] Details=20 > about NSIS > at IETF 58 >=20 >=20 >=20 > Hi all, >=20 > I went through all mobility-related drafts and I basically=20 > agree with you=20 > about the common issues. >=20 > To me it seems that we have pretty much identified the main=20 > issues, and it > is time to move on now. I would suggest that we gather one=20 > single draft > about the implications of mobility, routing, multi-homing and routing > changes/repair into one single WG draft. This draft would be used as a > "requirements"-type of document as the design of NTLP=20 > continues, to check > that the design fits specific environments (mobile, routing changes, > multi-homing). The document would also include the=20 > backgrounds for certain > issues, not just repeat requirements already mentioned in the=20 > requirements > draft. In addition, the document would be a reference for the=20 > current and > future NSLP documents: what you need to take into account=20 > when you design > an NSLP? >=20 > I would include in this document the issues Seong-Ho already=20 > mentioned, > and, the issue with refresh timers, and encapsulation issues=20 > because many > LMM protocols do this. I would leave out resource discovery (since, at > least in a mobile environment, CARD is doing this), and=20 > pre-reservations, > because these are more of a trick and very special scheme to deal with > mobility and resources. Moreover, I wouldn't want the document to have > discussions on how to implement things - the NTLP and NSLP=20 > documents will > do this eventually, if not already. >=20 > Thus, it would be a draft that documents the current=20 > understanding of the > issues between mobility/routing/multi-homing and resource signaling. >=20 > The authors of the various mobility drafts listed by John=20 > could meet in > Minneapolis, e.g. on Sunday, after the reception, to discuss=20 > these issues > before the actual NSIS WG meetings. We could, for example,=20 > try to agree on=20 > an initial set of issues to discuss in the draft, and assign=20 > responsible=20 > section editors, and an overall editor. >=20 > Any comments? >=20 > Regards, > Jukka >=20 >=20 > On Thu, 6 Nov 2003, Seong-Ho Jeong wrote: >=20 > > Hi Robert, Xiaoming, Jukka, Sung-Hyuck, and John, > >=20 > > IMO, the following could be (mobility-related) common issues=20 > > (concerning the NTLP/NSLP) that the drafts submitted by different=20 > > people have discussed. > >=20 > > - Differences between the general route change (not related=20 > to mobility) and=20 > > mobility-caused route change > > - How to discover crossover router (or crossover node)=20 > using some identifiers > > (how to discover upstream and downstream crossover routers) > > - How to setup states on the new path and teardown old=20 > states on the obsolete path > > (as quickly as possible,......) > > - State update on the joined/common/shared/unchanged path=20 > after handover > > - Interactions with mobility protocols such as CT and CARD=20 > (in a general way) > > - Interactions between the NTLP and NSLP > > - Security issues (authorization,...) > > - etc. > >=20 > > I think that (at least) the above issues may need to be=20 > addressed in the NSIS WG....=20 > > Additionally, it might be good to include the following=20 > issues that were discussed=20 > > separately by the different drafts. > >=20 > > - IP-in-IP encapsulation > > - Dead peer (crossover router) discovery > > - Discovery of resource availability > > - State mangement (refresh timer value management,...) > > - Last node detection > > - Pre-reservation > > - etc.... > >=20 > > Regards, > >=20 > > Seong-Ho Jeong > >=20 > > ----- Original Message -----=20 > > From: "Hancock, Robert" > > To: "Xiaoming Fu" ;=20 > > > Cc: ; > > Sent: Wednesday, November 05, 2003 5:01 AM > > Subject: RE: Issues splitting/consensus - Re: [NSIS]=20 > Details about NSIS at IETF 58 > >=20 > >=20 > > > hi xiaoming, jukka, john, .... > > >=20 > > > process-wise: > > > i see some value in a 'what things group X/Y/Z cares=20 > about' discussion. > > > i see much more value in a 'this is the complete issue=20 > list and here > > > are the commonalities/divergences between different=20 > people' discussion > > > (as I think we succeeded in doing with the 3 QoS drafts=20 > in Vienna). > > >=20 > > > we should start that discussion on the list now and maybe=20 > we can do > > > some further merging in Minneapolis (depending on what=20 > else is exciting > > > to do on Monday). > > >=20 > > > on a scoping point: > > > between the lines I detect some concern that there is a=20 > danger that > > > some of the mobility discussion may turn into some kind=20 > of 'Mobile-NSIS' > > > project with a life of its own. it's my opinion that this=20 > shouldn't > > > happen (and in fact isn't likely to happen). instead,=20 > what I think we > > > are talking about here is analysis work which will feed=20 > into defining > > > the functionality that is required in the basic NSIS=20 > protocols themselves > > > (just like we have analysed security and so on). that=20 > protocol design=20 > > > work - which is going on now - is a potential eager=20 > consumer of this=20 > > > mobility work; at the moment, the mobility impact on=20 > protocol design > > > has been driven mainly by instinct rather than solid=20 > thought, and it > > > is time to put that instinct on a much firmer foundation. > > >=20 > > > on the technical points: > > > i have a pile of drafts to read... > > >=20 > > > cheers, > > >=20 > > > r. > > > > -----Original Message----- > > > > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > > > > Sent: Tuesday, November 04, 2003 08:59 > > > > To: john.loughney@nokia.com > > > > Cc: jmanner@cs.Helsinki.FI; nsis@ietf.org > > > > Subject: Issues splitting/consensus - Re: [NSIS]=20 > Details about NSIS at > > > > IETF 58 > > > >=20 > > > >=20 > > > > John, > > > >=20 > > > > This sounds a good idea. One thing that has become clear to=20 > > > > me is that=20 > > > > although we all have some kind of idea on what mobility=20 > issues are,=20 > > > > those ideas are not necessarily totally aligned=20 > (although a certain=20 > > > > number of issues have been described in different ways and not=20 > > > > particulalrly opposed in most cases since pre-&post-Vienna=20 > > > > discussions). > > > >=20 > > > > If NSIS is going to develop something interoperable=20 > with mobility=20 > > > > protocols, I think it is probably necessary to come to some=20 > > > > reasonable=20 > > > > agreement on which issues are of common concern to all and=20 > > > > which are of=20 > > > > different view for each, before we go too far into presenting=20 > > > > "seperate"=20 > > > > issues but possibly repeating many issues several=20 > times. These can=20 > > > > include, but not limit to, all the bullets that have=20 > come out of the=20 > > > > existing discussions (e.g., host IP change, route=20 > change, IP-in-IP=20 > > > > encapsulation, crossover router discovery, routing interface,=20 > > > > etc.). For=20 > > > > example, it seems to me more or less at least a=20 > consensus has been=20 > > > > reached that working with mobility/route change is more=20 > of an NTLP=20 > > > > concern rather than simply an NSLP issue. However, there are=20 > > > > many other=20 > > > > issues have not converged. For instance, there was a concern=20 > > > > that flow=20 > > > > ID should be able to used to route NSIS packets, but very=20 > > > > likely, it can=20 > > > > be problematic or inefficient in mobility and tunneling=20 > scenarios; we=20 > > > > may instead rely on NTLP session ID together with the discovery=20 > > > > functionality. Perhaps the outcome of the Minneapolis meeting=20 > > > > would be=20 > > > > not so much a direct solution, but to clarify a number=20 > of things. > > > >=20 > > > > Best regards, > > > > Xiaoming > > > >=20 > > > > john.loughney@nokia.com wrote: > > > > > Hi Jukka, > > > > >=20 > > > > >=20 > > > > >>Should we have one slide per draft for the background on=20 > > > > the problem space=20 > > > > >>people see? One slide with the main issues each "group"=20 > > > > feels are the=20 > > > > >>most important? Thath would make four slides? > > > > >> > > > > >>We could also have a preliminary discussion on the list. > > > > >=20 > > > > >=20 > > > > > I'd like that we could discuss this on the list, a combined=20 > > > > presentation > > > > > would be one possible solution. > > > > >=20 > > > > > br, > > > > > John > > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >z=C8=AC(tm)=A8=A5Sx%S=CBg=B2+"z=D7=E8=AE=08m=B6>>=FF=FC0=C3Xz=B5=FA+= f=F9sSYsY=F9b=B2=D8=A7~=8F=E7=B2+ >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 6 19:44:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10420 for ; Thu, 6 Nov 2003 19:44:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHujJ-0001Hd-4K for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 19:44:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA70i0wY004853 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 19:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHujI-0001G3-LL; Thu, 06 Nov 2003 19:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHuiL-00016D-3h for nsis@optimus.ietf.org; Thu, 06 Nov 2003 19:43:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10376 for ; Thu, 6 Nov 2003 19:42:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHuiJ-0003b9-00 for nsis@ietf.org; Thu, 06 Nov 2003 19:42:59 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AHuiI-0003at-00 for nsis@ietf.org; Thu, 06 Nov 2003 19:42:58 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Nov 2003 00:42:29 -0000 Message-ID: From: "Hancock, Robert" To: Paulo Mendes , Jukka MJ Manner Cc: nsis@ietf.org Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Fri, 7 Nov 2003 00:42:39 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi paulo, jukka, IMHO we have to consider routing, mobility and multihoming together. the overlap between any two is (in undefined units, of course) about 75%; doing them separately will not help consistency in the long run. (and after all, we want this work to feed into protocol design. we should avoid feeding the protocol designers requirements which are similar but subtly different just because they have been developed independently.) i do agree that the CT/CARD/pre-reservation issues have to be covered as part of the same work, for the reasons given below. as i've written in another mail, at least partly this is to allow us to make sensible consistent decisions about where to optimise (after all, of this work is about optimisation). cheers, r. PS I keep seeing stuff saying 'we have to handle tunnels in a special way when they are used for mobility support'. does anyone have a worked example of normal tunnel handling failing to work here? -----Original Message----- From: Paulo Mendes [mailto:mendes@docomolab-euro.com] Sent: Thursday, November 06, 2003 15:11 To: Jukka MJ Manner Cc: nsis@ietf.org Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Hi Jukka, I also agree that something has to be done about the mobility-related drafts, since they have overlapping issues. However, I'm not convinced right now that analyzing mobility, multihoming and routing changes in the draft will lead us to a simpler document, complying with the KISS principle. To start from, because IMO the mobility issue by itself is already very complex, as we tried to show in our analysis draft. However, I think that we need to start working on the mobility issues that overlap in the presented drafts to achieve the goal of understanding how can NSIS be extended to mobile environments. For instance, I saw that your draft as a more general definition of crossover router. Hence, I agree with Robert when he says "I think we are talking about here is analysis work which will feed into defining the functionality that is required in the basic NSIS protocols themselves". This is, I agree that we must not include by now any discussion about how to implement any particular solution. I don't see why shouldn't we work in a mobility analysis draft and a multihoming analysis draft (by nature these are two different things). If after this analysis (divide to conquer principle :)), we realize that a common solution can be achieved, than we should work in a common solution draft. If not, just continue in separate ways. In what concerns routing changes, if they are due to the movement of end-hosts, this topic is naturally included in the mobility analysis. However, IMO routing changes "in the interior of the network", for instance due to load balancing and link failure, should be considered in the basic NSIS, since they do not happen only in mobile environments. I tend to disagree with you in what concerns the open issues. If you do not identify open issues by now you will have to do it late. Besides, an efficient solution for mobility within NSIS needs to be aware of open issues if it wants to be the next step in signaling. From the issues mentioned, resource discovery has to do also with the e2e new path and not only with the new access network. Only the latter is done by CARD. In what concerns pre-reservations, you have to deal with this sooner or latter if you want to get good quality levels for multimedia applications while moving. I'm not saying that this is easy or not, or that it should be included in NSIS. I'm just saying that this is an open issue. In what concerns Minneapolis: - Agree that the authors of the different drafts should meet in Minneapolis for further discussion (unfortunately I cannot attend this IETF meeting). This discussion should be extended to this mailing list. - About the presentations, probably it is a little late to get a consensus among authors in order to make a efficient join presentation, but I think that if this could be done, it would be most profitable. Cheers, Paulo Jukka MJ Manner wrote: Hi, I basically try to look at things with the KISS principle, and my initial assumptions are that mobility, routing, and multi-homing have much in common once we think about them properly and with an open mind. I wouldn't want to have several different documents discussing NTLP+NSLP and specific scenarios. Of course, it might happen that we end up realizing that certain issues are too complex and need their own documents. Still, I would start with the mentioned issues and see from there. Regards, Jukka On Thu, 6 Nov 2003, Xiaoming Fu wrote: Hi John, Jukka, It would be nice that we work together a single document regarding mobility and move things on. I also agree that mobility concerns with route change and tunneling; is it a little too overloaded for this document to cover general routing, multi-homing or general tunnel issues as well? (Unfortunately I will be not able to attend the Minneapolis meeting due to personal reasons. However, I am interested in this work and would like to participate in the discussions through emails.) Best regards, Xiaoming john.loughney@nokia.com wrote: Hi Jukka, The authors of the various mobility drafts listed by John could meet in Minneapolis, e.g. on Sunday, after the reception, to discuss these issues before the actual NSIS WG meetings. We could, for example, try to agree on an initial set of issues to discuss in the draft, and assign responsible section editors, and an overall editor. I fully support this. If this is acceptable, then the results could be discussed at the NSIS meeting. I think this is a much better use of time, then presenting overlapping individual documents. Does anyone else have any comments on this? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis -- Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 6 21:36:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13505 for ; Thu, 6 Nov 2003 21:36:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwTj-0006EC-4J for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 21:36:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA72a3I3023934 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 21:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwTh-0006DX-Qg; Thu, 06 Nov 2003 21:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwSz-0006BX-3y for nsis@optimus.ietf.org; Thu, 06 Nov 2003 21:35: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 VAA13458 for ; Thu, 6 Nov 2003 21:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHwSw-0004yK-00 for nsis@ietf.org; Thu, 06 Nov 2003 21:35:14 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHwSv-0004yD-00 for nsis@ietf.org; Thu, 06 Nov 2003 21:35:13 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA72ZBUC012208 for ; Fri, 7 Nov 2003 11:35:11 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA72ZBpo015458 for ; Fri, 7 Nov 2003 11:35:11 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA72ZB8H019914 for ; Fri, 7 Nov 2003 11:35:11 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id LAA26330 for ; Fri, 7 Nov 2003 11:35:10 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id LAA17706 for ; Fri, 7 Nov 2003 11:35:10 +0900 (JST) Message-Id: <5.1.1.11.2.20031107113026.0452a380@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Fri, 07 Nov 2003 11:35:15 +0900 To: nsis@ietf.org From: "MORITA, Naotaka" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] PPS and MF-PHB Sender: nsis-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 would like to draw QoS experts attention to the following three documents. http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfphb-00.txt http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt I am going to make a presentation on Monday morning at TSV WG. Naotaka ---- Title : Framework of Priority Promotion Scheme Author(s) : N. Morita, G. Karlsson Filename : draft-morita-tsvwg-pps-01.txt Pages : 18 Date : 2003-10-27 This document describes a framework of a new scheme for traffic control to achieve end-to-end QoS for interactive multimedia services. The scheme is based on end-to-end measurement of network resources by end systems. The network is assumed to fully support the priority control scheme specified in the Diffserv architecture for QoS and SIP [1] for session control. Since the scheme relies on the behavior of the end systems, this document also touches on mechanisms for monitoring end-system behavior. ------ Title : Measurable Forwarding: A New per-Hop Behavior (PHB) Author(s) : N. Morita Filename : draft-morita-tsvwg-mfphb-00.txt Pages : 19 Date : 2003-11-2 The Priority Promotion Scheme (PPS) is a new scheme for traffic control; specifically, the PPS achieves end-to-end QoS for interactive multimedia services by exercising admission control for a series of packets on a packet-based network. The scheme is based on the end-to-end measurement of network resources by end systems. The destination end system notifies the conditions of receipt for a limited set of packets sent from the source end. If this is acceptable, the source end system then promotes the priority of the succeeding IP packets to firmly establish the session. The network is only assumed to support a per-class form of priority control, since this allows the end systems to measure remaining resources without affecting the existing streams. If all end systems behave in the above way, we can achieve specific levels of end-to-end QoS without maintaining per-flow states in each item of network equipment. ------ Title : Verification scenarios for Measurable Forwarding PHB (Per-Hop Behavior) Author(s) : N. Morita Filename : draft-morita-tsvwg-mfverify-00.txt Pages : 7 Date : 2003-10-31 The Priority Promotion Scheme (PPS) is a new scheme for traffic control; specifically, the PPS achieves end-to-end QoS for interactive multimedia services by exercising admission control for series of packets on a packet-based network. The scheme is based on the end-to-end measurement of network resources by end systems. The destination end system notifies the conditions of receipt for a limited set of packets sent from the source end. If this is acceptable, the source end system then promotes the priority of the succeeding IP packets to firmly establish the session. The network is only assumed to support a per-class form of priority control, since this allows the end systems to measure remaining resources without affecting the existing streams. If all end systems behave in the above way, we can achieve specific levels of end-to-end QoS without maintaining per-flow states in each item of network equipment. The PPS is based on a new per-hop forwarding behavior, called measurable forwarding (MF-PHB), which will use the DiffServ architecture. In this document, we propose a way to verify whether MF-PHB is realizable by elaborating configurations of existing equipment. ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 6 23:07:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15575 for ; Thu, 6 Nov 2003 23:07:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHxtr-0001s3-4b for nsis-archive@odin.ietf.org; Thu, 06 Nov 2003 23:07:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7476Ir007126 for nsis-archive@odin.ietf.org; Thu, 6 Nov 2003 23:07:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHxto-0001qb-DS; Thu, 06 Nov 2003 23:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHucH-0000gx-5a for nsis@optimus.ietf.org; Thu, 06 Nov 2003 19:36:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10212 for ; Thu, 6 Nov 2003 19:36:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHucF-0003Wz-00 for nsis@ietf.org; Thu, 06 Nov 2003 19:36:43 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHucE-0003Ww-00 for nsis@ietf.org; Thu, 06 Nov 2003 19:36:42 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA70afUC019251 for ; Fri, 7 Nov 2003 09:36:41 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA70afpo024436 for ; Fri, 7 Nov 2003 09:36:41 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA70ae8H016038 for ; Fri, 7 Nov 2003 09:36:40 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA14994 for ; Fri, 7 Nov 2003 09:36:40 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA08355 for ; Fri, 7 Nov 2003 09:36:39 +0900 (JST) Message-Id: <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Fri, 07 Nov 2003 09:36:44 +0900 To: nsis@ietf.org From: "MORITA, Naotaka" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] PPS and MF-PHB Sender: nsis-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 would like to draw QoS experts attention to the following three documents. http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfphb-00.txt http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt I am going to make a presentation on Monday morning at TSV WG. ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Nov 7 01:26:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18901 for ; Fri, 7 Nov 2003 01:26:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI04I-0007BL-AW for nsis-archive@odin.ietf.org; Fri, 07 Nov 2003 01:26:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA76Q2HY027604 for nsis-archive@odin.ietf.org; Fri, 7 Nov 2003 01:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI04H-0007Am-1Z; Fri, 07 Nov 2003 01: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 1AI03m-0007AL-0s for nsis@optimus.ietf.org; Fri, 07 Nov 2003 01:25: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 BAA18782 for ; Fri, 7 Nov 2003 01:25:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI03i-0007M1-00 for nsis@ietf.org; Fri, 07 Nov 2003 01:25:26 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AI03d-0007Li-00 for nsis@ietf.org; Fri, 07 Nov 2003 01:25:25 -0500 Received: from LocalHost (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA76NZls017749; Fri, 7 Nov 2003 15:23:58 +0900 (KST) From: "Sung Hycuk Lee" To: "Hancock, Robert" , "Paulo Mendes" , "Jukka MJ Manner" , "Seong-Ho Jeong" Cc: , , Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Fri, 7 Nov 2003 15:23:47 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_01C3A543.239E13A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-MS-TNEF-Correlator: Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C3A543.239E13A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpIaSBSb2JlcnQsIFBhdWxvLCBKdWtrYSwgYW5kIFNlb25nLUhvLA0KDQpJIGFncmVlIHRoYXQg d2Ugc2hvdWxkIGZpcnN0IGRpc2N1c3MgdGhlIGFuYWx5c2lzIG9mIHRoZSBtb2JpbGl0eSBpc3N1 ZXMNCm92ZXJsYXBwZWQgDQphbmQgbmV3bHkgcmFpc2VkIGluIHRoZSBzdWJtaXR0ZWQgZHJhZnRz IGF0IHRoZSBtZWV0aW5nIGluIE1pbm5lYXBvbGlzIGFzDQp3ZWxsIGFzIG9uIA0KdGhlIG1haWxp bmcgbGlzdCwgc28gd2UgY291bGQgZmVlZCBpbnRvIGRlZmluaW5nIHRoZSBmdW5jdGlvbmFsaXR5 IHRoYXQgaXMNCnJlcXVpcmVkIGluIHRoZSANCmJhc2ljIE5TSVMgcHJvdG9jb2xzLg0KDQpJTUhP LCBJIHRoaW5rIHRoYXQgdGhlIG1vYmlsaXR5IGV2ZW50IGRldGVjdGlvbiwgc3RhdGUgbWFuYWdl bWVudCAocmVmcmVzaA0KdGltZXIpLCANCmludGVyYWN0aW9ucyB3aXRoIENBUkQvQ1QsIGFuZCBw cmUtcmVzZXJ2YXRpb24gaXNzdWVzIGNhbiBiZSB0YWtlbiBpbnRvDQpjb25zaWRlcmF0aW9uIA0K d2hpY2ggbWF5IGJlIHVzZWQgYXMgcmVmZXJlbmNlcyBmb3IgdGhlIE5TTFAgZG9jdW1lbnQuIEVz cGVjaWFsbHksDQphbHRob3VnaCANCnRoZSBwcmUtcmVzZXJ2YXRpb24gcmVsYXRlZCB3b3JrIGlz IGFuIG9wZW4gaXNzdWUsIGFzIFJvYmVydCwgU2VvbmctSG8sDQphbmQgUGF1bG8gbWVudGlvbmVk IGFuZCBJJ3ZlIGFkZHJlc3NlZCBpbiBteSBwcmV2aW91cyBlbWFpbCBzaW5jZSB0aGUNClZpZW5u YSBtZWV0aW5nLCBJIGFsc28gdGhpbmsgdGhhdCB0aGUgcHJlLXJlc2VydmF0aW9uIHJlbGF0ZWQg aXNzdWUgaXMNCmltcG9ydGFudCB0byBzdXBwb3J0IHNlYW1sZXNzIHNlcnZpY2VzIGZvciByZWFs LXRpbWUgDQoobXVsdGltZWRpYSkgYXBwbGljYXRpb25zICh5b3UgY2FuIHNlZSBhbiBleGFtcGxl IHJlbGF0ZWQgdG8NCkNBUkQvQ1QvcHJlLXJlc2VydmF0aW9uIA0KaW4gZHJhZnQtbGVlLW5zaXMt bW9iaWxpdHktbnNscC0wMC8wMS50eHQNCihodHRwOi8vd2lkZWNvbW0ua29yZWEuYWMua3IvfnN0 YXJzdS9kcmFmdC1sZWUtbnNpcy1tb2JpbGl0eS1uc2xwLTAxLnR4dCkuDQoNCkkgd29uZGVyIGlm ICB0aGUgd29yayBvbiBhIGNvbW1vbiBzb2x1dGlvbiBkcmFmdCBpcyBzdWl0YWJsZSBmb3IgdGhl IE5TSVMNCmNoYXJ0ZXIvbWlsZXN0b25lcy4gDQpCdXQgIGlmIGl0IGlzIGFjY2VwdGFibGUsIEkg aG9wZSB0aGF0IHdlJ2xsIHdvcmsgZm9yIGEgY29tbW9uIHNvbHV0aW9uDQpkcmF0IGFmdGVyIGNv bXBsZXRpbmcgDQp0aGUgbW9iaWxpdHkgYW5hbHlzaXMgZHJhZnQuIA0KDQpDb25jZXJuaW5nIHRo ZSBwcmVzZW50YXRpb24gaW4gTWlubmVhcG9saXMsIGFsdGhvdWdoIHRoZXJlIG1heSBub3QgYmUN CmVub3VnaCB0aW1lIHRvIHJlYWNoIGEgY29uc2Vuc3VzIGFtb25nIGF1dGhvcnMgYmVmb3JlIHRo ZSBOU0lTIHNlc3Npb24sIEkNCmFsc28gdGhpbmsgdGhhdCBpdCBpcyBwcm9maXRhYmxlIGlmIHRo ZSBhdXRob3JzIGNhbiBnZXQgdG9nZXRoZXIgb24gU3VuZGF5DQphbmQgaWRlbnRpZnkgdGhlIG1v YmlsaXR5LXJlbGF0ZWQgY29tbW9uIGlzc3VlcyBhbmQgbmV3IG9wZW4gaXNzdWVzIGZvcg0KcHJl c2VudGF0aW9uLiANCg0KUmVnYXJkcywNCg0KU3VuZy1IeXVjaw0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IG5zaXMtYWRtaW5AaWV0Zi5vcmcgW21haWx0bzpuc2lzLWFk bWluQGlldGYub3JnXU9uIEJlaGFsZiANCj4gT2YgSGFuY29jaywgUm9iZXJ0DQo+IFNlbnQ6IEZy aWRheSwgTm92ZW1iZXIgMDcsIDIwMDMgOTo0MyBBTQ0KPiBUbzogUGF1bG8gTWVuZGVzOyBKdWtr YSBNSiBNYW5uZXINCj4gQ2M6IG5zaXNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IElzc3VlcyBz cGxpdHRpbmcvY29uc2Vuc3VzIC0gUmU6IFtOU0lTXSBEZXRhaWxzIA0KPiBhYm91dCBOU0lTIGF0 IElFVEYgNTgNCj4gDQo+IA0KPiBoaSBwYXVsbywganVra2EsDQo+IA0KPiBJTUhPIHdlIGhhdmUg dG8gY29uc2lkZXIgcm91dGluZywgbW9iaWxpdHkgYW5kIG11bHRpaG9taW5nIHRvZ2V0aGVyLg0K PiB0aGUgb3ZlcmxhcCBiZXR3ZWVuIGFueSB0d28gaXMgKGluIHVuZGVmaW5lZCB1bml0cywgb2Yg Y291cnNlKSANCj4gYWJvdXQgNzUlOyBkb2luZyB0aGVtIHNlcGFyYXRlbHkgd2lsbCBub3QgaGVs cCBjb25zaXN0ZW5jeSBpbiB0aGUNCj4gbG9uZyBydW4uDQo+IA0KPiAoYW5kIGFmdGVyIGFsbCwg d2Ugd2FudCB0aGlzIHdvcmsgdG8gZmVlZCBpbnRvIHByb3RvY29sIGRlc2lnbi4NCj4gd2Ugc2hv dWxkIGF2b2lkIGZlZWRpbmcgdGhlIHByb3RvY29sIGRlc2lnbmVycyByZXF1aXJlbWVudHMgd2hp Y2ggYXJlIA0KPiBzaW1pbGFyIGJ1dCBzdWJ0bHkgZGlmZmVyZW50IGp1c3QgYmVjYXVzZSB0aGV5 IGhhdmUgYmVlbiBkZXZlbG9wZWQNCj4gaW5kZXBlbmRlbnRseS4pDQo+IA0KPiBpIGRvIGFncmVl IHRoYXQgdGhlIENUL0NBUkQvcHJlLXJlc2VydmF0aW9uIGlzc3VlcyBoYXZlIHRvIGJlIGNvdmVy ZWQNCj4gYXMgcGFydCBvZiB0aGUgc2FtZSB3b3JrLCBmb3IgdGhlIHJlYXNvbnMgZ2l2ZW4gYmVs b3cuIGFzIGkndmUgd3JpdHRlbiANCj4gaW4gYW5vdGhlciBtYWlsLCBhdCBsZWFzdCBwYXJ0bHkg dGhpcyBpcyB0byBhbGxvdyB1cyB0byBtYWtlIHNlbnNpYmxlIA0KPiBjb25zaXN0ZW50IGRlY2lz aW9ucyBhYm91dCB3aGVyZSB0byBvcHRpbWlzZSAoYWZ0ZXIgYWxsLCBvZiB0aGlzIHdvcmsgDQo+ IGlzIGFib3V0IG9wdGltaXNhdGlvbikuDQo+IA0KPiBjaGVlcnMsDQo+IA0KPiByLg0KPiANCj4g UFMgSSBrZWVwIHNlZWluZyBzdHVmZiBzYXlpbmcgJ3dlIGhhdmUgdG8gaGFuZGxlIHR1bm5lbHMg aW4gYSBzcGVjaWFsDQo+IHdheSB3aGVuIHRoZXkgYXJlIHVzZWQgZm9yIG1vYmlsaXR5IHN1cHBv cnQnLiBkb2VzIGFueW9uZSBoYXZlIGEgd29ya2VkDQo+IGV4YW1wbGUgb2Ygbm9ybWFsIHR1bm5l bCBoYW5kbGluZyBmYWlsaW5nIHRvIHdvcmsgaGVyZT8NCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFBhdWxvIE1lbmRlcyBbbWFpbHRvOm1lbmRlc0Bkb2NvbW9sYWIt ZXVyby5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwNiwgMjAwMyAxNToxMQ0KPiBU bzogSnVra2EgTUogTWFubmVyDQo+IENjOiBuc2lzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBJ c3N1ZXMgc3BsaXR0aW5nL2NvbnNlbnN1cyAtIFJlOiBbTlNJU10gRGV0YWlscyANCj4gYWJvdXQg TlNJUyBhdCBJRVRGIDU4DQo+IA0KPiANCj4gSGkgSnVra2EsDQo+IA0KPiBJIGFsc28gYWdyZWUg dGhhdCBzb21ldGhpbmcgaGFzIHRvIGJlIGRvbmUgYWJvdXQgdGhlIA0KPiBtb2JpbGl0eS1yZWxh dGVkIGRyYWZ0cywgc2luY2UgdGhleSBoYXZlIG92ZXJsYXBwaW5nIGlzc3Vlcy4gDQo+IEhvd2V2 ZXIsIEknbSBub3QgY29udmluY2VkIHJpZ2h0IG5vdyB0aGF0IGFuYWx5emluZyBtb2JpbGl0eSwg DQo+IG11bHRpaG9taW5nIGFuZCByb3V0aW5nIGNoYW5nZXMgaW4gdGhlIGRyYWZ0IHdpbGwgbGVh ZCB1cyB0byBhIA0KPiBzaW1wbGVyIGRvY3VtZW50LCBjb21wbHlpbmcgd2l0aCB0aGUgS0lTUyBw cmluY2lwbGUuIFRvIHN0YXJ0IA0KPiBmcm9tLCBiZWNhdXNlIElNTyB0aGUgbW9iaWxpdHkgaXNz dWUgYnkgaXRzZWxmIGlzIGFscmVhZHkgdmVyeSANCj4gY29tcGxleCwgYXMgd2UgdHJpZWQgdG8g c2hvdyBpbiBvdXIgYW5hbHlzaXMgZHJhZnQuDQo+IEhvd2V2ZXIsIEkgdGhpbmsgdGhhdCB3ZSBu ZWVkIHRvIHN0YXJ0IHdvcmtpbmcgb24gdGhlIG1vYmlsaXR5IA0KPiBpc3N1ZXMgdGhhdCBvdmVy bGFwIGluIHRoZSBwcmVzZW50ZWQgZHJhZnRzIHRvIGFjaGlldmUgdGhlIGdvYWwgDQo+IG9mIHVu ZGVyc3RhbmRpbmcgaG93IGNhbiBOU0lTIGJlIGV4dGVuZGVkIHRvIG1vYmlsZSBlbnZpcm9ubWVu dHMuIA0KPiBGb3IgaW5zdGFuY2UsIEkgc2F3IHRoYXQgeW91ciBkcmFmdCBhcyBhIG1vcmUgZ2Vu ZXJhbCBkZWZpbml0aW9uIA0KPiBvZiBjcm9zc292ZXIgcm91dGVyLg0KPiBIZW5jZSwgSSBhZ3Jl ZSB3aXRoIFJvYmVydCB3aGVuIGhlIHNheXMgIkkgdGhpbmsgd2UgYXJlIHRhbGtpbmcgDQo+IGFi b3V0IGhlcmUgaXMgYW5hbHlzaXMgd29yayB3aGljaCB3aWxsIGZlZWQgaW50byBkZWZpbmluZyB0 aGUgDQo+IGZ1bmN0aW9uYWxpdHkgdGhhdCBpcyByZXF1aXJlZCBpbiB0aGUgYmFzaWMgTlNJUyBw cm90b2NvbHMgDQo+IHRoZW1zZWx2ZXMiLiBUaGlzIGlzLCBJIGFncmVlIHRoYXQgd2UgbXVzdCBu b3QgaW5jbHVkZSBieSBub3cgYW55IA0KPiBkaXNjdXNzaW9uIGFib3V0IGhvdyB0byBpbXBsZW1l bnQgYW55IHBhcnRpY3VsYXIgc29sdXRpb24uDQo+IA0KPiBJIGRvbid0IHNlZSB3aHkgc2hvdWxk bid0IHdlIHdvcmsgaW4gYSBtb2JpbGl0eSBhbmFseXNpcyBkcmFmdCANCj4gYW5kIGEgbXVsdGlo b21pbmcgYW5hbHlzaXMgZHJhZnQgKGJ5IG5hdHVyZSB0aGVzZSBhcmUgdHdvIA0KPiBkaWZmZXJl bnQgdGhpbmdzKS4gSWYgYWZ0ZXIgdGhpcyBhbmFseXNpcyAoZGl2aWRlIHRvIGNvbnF1ZXIgDQo+ IHByaW5jaXBsZSA6KSksIHdlIHJlYWxpemUgdGhhdCBhIGNvbW1vbiBzb2x1dGlvbiBjYW4gYmUg YWNoaWV2ZWQsIA0KPiB0aGFuIHdlIHNob3VsZCB3b3JrIGluIGEgY29tbW9uIHNvbHV0aW9uIGRy YWZ0LiBJZiBub3QsIGp1c3QgDQo+IGNvbnRpbnVlIGluIHNlcGFyYXRlIHdheXMuDQo+IEluIHdo YXQgY29uY2VybnMgcm91dGluZyBjaGFuZ2VzLCBpZiB0aGV5IGFyZSBkdWUgdG8gdGhlIG1vdmVt ZW50IA0KPiBvZiBlbmQtaG9zdHMsIHRoaXMgdG9waWMgaXMgbmF0dXJhbGx5IGluY2x1ZGVkIGlu IHRoZSBtb2JpbGl0eSANCj4gYW5hbHlzaXMuIEhvd2V2ZXIsIElNTyByb3V0aW5nIGNoYW5nZXMg ImluIHRoZSBpbnRlcmlvciBvZiB0aGUgDQo+IG5ldHdvcmsiLCBmb3IgaW5zdGFuY2UgZHVlIHRv IGxvYWQgYmFsYW5jaW5nIGFuZCBsaW5rIGZhaWx1cmUsIA0KPiBzaG91bGQgYmUgY29uc2lkZXJl ZCBpbiB0aGUgYmFzaWMgTlNJUywgc2luY2UgdGhleSBkbyBub3QgaGFwcGVuIA0KPiBvbmx5IGlu IG1vYmlsZSBlbnZpcm9ubWVudHMuDQo+IA0KPiBJIHRlbmQgdG8gZGlzYWdyZWUgd2l0aCB5b3Ug aW4gd2hhdCBjb25jZXJucyB0aGUgb3BlbiBpc3N1ZXMuIElmIA0KPiB5b3UgZG8gbm90IGlkZW50 aWZ5IG9wZW4gaXNzdWVzIGJ5IG5vdyB5b3Ugd2lsbCBoYXZlIHRvIGRvIGl0IA0KPiBsYXRlLiBC ZXNpZGVzLCBhbiBlZmZpY2llbnQgc29sdXRpb24gZm9yIG1vYmlsaXR5IHdpdGhpbiBOU0lTIA0K PiBuZWVkcyB0byBiZSBhd2FyZSBvZiBvcGVuIGlzc3VlcyBpZiBpdCB3YW50cyB0byBiZSB0aGUg bmV4dCBzdGVwIA0KPiBpbiBzaWduYWxpbmcuIEZyb20gdGhlIGlzc3VlcyBtZW50aW9uZWQsIHJl c291cmNlIGRpc2NvdmVyeSBoYXMgDQo+IHRvIGRvIGFsc28gd2l0aCB0aGUgZTJlIG5ldyBwYXRo IGFuZCBub3Qgb25seSB3aXRoIHRoZSBuZXcgYWNjZXNzIA0KPiBuZXR3b3JrLiBPbmx5IHRoZSBs YXR0ZXIgaXMgZG9uZSBieSBDQVJELiBJbiB3aGF0IGNvbmNlcm5zIA0KPiBwcmUtcmVzZXJ2YXRp b25zLCB5b3UgaGF2ZSB0byBkZWFsIHdpdGggdGhpcyBzb29uZXIgb3IgbGF0dGVyIGlmIA0KPiB5 b3Ugd2FudCB0byBnZXQgZ29vZCBxdWFsaXR5IGxldmVscyBmb3IgbXVsdGltZWRpYSBhcHBsaWNh dGlvbnMgDQo+IHdoaWxlIG1vdmluZy4gSSdtIG5vdCBzYXlpbmcgdGhhdCB0aGlzIGlzIGVhc3kg b3Igbm90LCBvciB0aGF0IGl0IA0KPiBzaG91bGQgYmUgaW5jbHVkZWQgaW4gTlNJUy4gSSdtIGp1 c3Qgc2F5aW5nIHRoYXQgdGhpcyBpcyBhbiBvcGVuIGlzc3VlLg0KPiANCj4gSW4gd2hhdCBjb25j ZXJucyBNaW5uZWFwb2xpczoNCj4gLSBBZ3JlZSB0aGF0IHRoZSBhdXRob3JzIG9mIHRoZSBkaWZm ZXJlbnQgZHJhZnRzIHNob3VsZCBtZWV0IGluIA0KPiBNaW5uZWFwb2xpcyBmb3IgZnVydGhlciBk aXNjdXNzaW9uICh1bmZvcnR1bmF0ZWx5IEkgY2Fubm90IGF0dGVuZCANCj4gdGhpcyBJRVRGIG1l ZXRpbmcpLiBUaGlzIGRpc2N1c3Npb24gc2hvdWxkIGJlIGV4dGVuZGVkIHRvIHRoaXMgDQo+IG1h aWxpbmcgbGlzdC4NCj4gLSBBYm91dCB0aGUgcHJlc2VudGF0aW9ucywgcHJvYmFibHkgaXQgaXMg YSBsaXR0bGUgbGF0ZSB0byBnZXQgYSANCj4gY29uc2Vuc3VzIGFtb25nIGF1dGhvcnMgaW4gb3Jk ZXIgdG8gbWFrZSBhIGVmZmljaWVudCBqb2luIA0KPiBwcmVzZW50YXRpb24sIGJ1dCBJIHRoaW5r IHRoYXQgaWYgdGhpcyBjb3VsZCBiZSBkb25lLCBpdCB3b3VsZCBiZSANCj4gbW9zdCBwcm9maXRh YmxlLg0KPiANCj4gQ2hlZXJzLA0KPiBQYXVsbw0KPiANCj4gSnVra2EgTUogTWFubmVyIHdyb3Rl Og0KPiANCj4gSGksDQo+IA0KPiBJIGJhc2ljYWxseSB0cnkgdG8gbG9vayBhdCB0aGluZ3Mgd2l0 aCB0aGUgS0lTUyBwcmluY2lwbGUsIGFuZCBteQ0KaW5pdGlhbA0KPiBhc3N1bXB0aW9ucyBhcmUg dGhhdCBtb2JpbGl0eSwgcm91dGluZywgYW5kIG11bHRpLWhvbWluZyBoYXZlIG11Y2ggaW4NCj4g Y29tbW9uIG9uY2Ugd2UgdGhpbmsgYWJvdXQgdGhlbSBwcm9wZXJseSBhbmQgd2l0aCBhbiBvcGVu IG1pbmQuIEkNCndvdWxkbid0DQo+IHdhbnQgdG8gaGF2ZSBzZXZlcmFsIGRpZmZlcmVudCBkb2N1 bWVudHMgZGlzY3Vzc2luZyBOVExQK05TTFAgYW5kDQpzcGVjaWZpYw0KPiBzY2VuYXJpb3MuIE9m IGNvdXJzZSwgaXQgbWlnaHQgaGFwcGVuIHRoYXQgd2UgZW5kIHVwIHJlYWxpemluZyB0aGF0DQo+ IGNlcnRhaW4gaXNzdWVzIGFyZSB0b28gY29tcGxleCBhbmQgbmVlZCB0aGVpciBvd24gZG9jdW1l bnRzLiBTdGlsbCwgSQ0KPiB3b3VsZCBzdGFydCB3aXRoIHRoZSBtZW50aW9uZWQgaXNzdWVzIGFu ZCBzZWUgZnJvbSB0aGVyZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IEp1a2thDQo+IA0KPiANCj4gT24g VGh1LCA2IE5vdiAyMDAzLCBYaWFvbWluZyBGdSB3cm90ZToNCj4gDQo+ICAgDQo+IEhpIEpvaG4s IEp1a2thLA0KPiANCj4gSXQgd291bGQgYmUgbmljZSB0aGF0IHdlIHdvcmsgdG9nZXRoZXIgYSBz aW5nbGUgZG9jdW1lbnQgcmVnYXJkaW5nIA0KPiBtb2JpbGl0eSBhbmQgbW92ZSB0aGluZ3Mgb24u IEkgYWxzbyBhZ3JlZSB0aGF0IG1vYmlsaXR5IGNvbmNlcm5zIHdpdGggDQo+IHJvdXRlIGNoYW5n ZSBhbmQgdHVubmVsaW5nOyBpcyBpdCBhIGxpdHRsZSB0b28gb3ZlcmxvYWRlZCBmb3IgdGhpcyAN Cj4gZG9jdW1lbnQgdG8gY292ZXIgZ2VuZXJhbCByb3V0aW5nLCBtdWx0aS1ob21pbmcgb3IgZ2Vu ZXJhbCB0dW5uZWwgaXNzdWVzDQoNCj4gYXMgd2VsbD8NCj4gDQo+IChVbmZvcnR1bmF0ZWx5IEkg d2lsbCBiZSBub3QgYWJsZSB0byBhdHRlbmQgdGhlIE1pbm5lYXBvbGlzIG1lZXRpbmcgZHVlIA0K PiB0byBwZXJzb25hbCByZWFzb25zLiBIb3dldmVyLCBJIGFtIGludGVyZXN0ZWQgaW4gdGhpcyB3 b3JrIGFuZCB3b3VsZCANCj4gbGlrZSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGlzY3Vzc2lvbnMg dGhyb3VnaCBlbWFpbHMuKQ0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBYaWFvbWluZw0KPiANCj4g am9obi5sb3VnaG5leUBub2tpYS5jb20gd3JvdGU6DQo+ICAgICANCj4gSGkgSnVra2EsDQo+IA0K PiAgICAgICAgDQo+IFRoZSBhdXRob3JzIG9mIHRoZSB2YXJpb3VzIG1vYmlsaXR5IGRyYWZ0cyBs aXN0ZWQgYnkgSm9obiBjb3VsZCBtZWV0IGluDQo+IE1pbm5lYXBvbGlzLCBlLmcuIG9uIFN1bmRh eSwgYWZ0ZXIgdGhlIHJlY2VwdGlvbiwgdG8gZGlzY3VzcyB0aGVzZQ0KaXNzdWVzDQo+IGJlZm9y ZSB0aGUgYWN0dWFsIE5TSVMgV0cgbWVldGluZ3MuIFdlIGNvdWxkLCBmb3IgZXhhbXBsZSwgdHJ5 IHRvIA0KPiBhZ3JlZSBvbiANCj4gYW4gaW5pdGlhbCBzZXQgb2YgaXNzdWVzIHRvIGRpc2N1c3Mg aW4gdGhlIGRyYWZ0LCBhbmQgYXNzaWduIHJlc3BvbnNpYmxlDQoNCj4gc2VjdGlvbiBlZGl0b3Jz LCBhbmQgYW4gb3ZlcmFsbCBlZGl0b3IuDQo+ICAgICAgICAgDQo+IEkgZnVsbHkgc3VwcG9ydCB0 aGlzLiAgSWYgdGhpcyBpcyBhY2NlcHRhYmxlLCB0aGVuIHRoZSByZXN1bHRzIGNvdWxkDQo+IGJl IGRpc2N1c3NlZCBhdCB0aGUgTlNJUyBtZWV0aW5nLiAgSSB0aGluayB0aGlzIGlzIGEgbXVjaCBi ZXR0ZXINCj4gdXNlIG9mIHRpbWUsIHRoZW4gcHJlc2VudGluZyBvdmVybGFwcGluZyBpbmRpdmlk dWFsIGRvY3VtZW50cy4NCj4gDQo+IERvZXMgYW55b25lIGVsc2UgaGF2ZSBhbnkgY29tbWVudHMg b24gdGhpcz8NCj4gDQo+IEpvaG4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IG5zaXMgbWFpbGluZyBsaXN0DQo+IG5zaXNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNpcw0KPiAgICAgICAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbnNp cyBtYWlsaW5nIGxpc3QNCj4gbnNpc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uc2lzDQo+IA0KPiAgICAgDQo+IA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbnNpcyBtYWlsaW5nIGxpc3QN Cj4gbnNpc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uc2lzDQo+IA0KPiAgIA0KPiANCj4gDQo+IA0KPiAtLSANCj4gUGF1bG8gTWVuZGVzDQo+IERv Q29NbyBDb21tdW5pY2F0aW9ucyBMYWJvcmF0b3JpZXMgRXVyb3BlIEdtYkgNCj4gTGFuZHNiZXJn ZXIgU3RyLiAzMTINCj4gODA2ODcgTXVuaWNoLCBHZXJtYW55DQo+IFRlbC4gKzQ5LTg5LTU2ODI0 LTIyNg0KPiBGYXguICs0OS04OS01NjgyNC0zMDANCj4gRS1tYWlsOiBtZW5kZXNAZG9jb21vbGFi LWV1cm8uY29tDQo+IGh0dHA6Ly93d3cuZG9jb21vZXVyb2xhYnMuZGUvDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuc2lzIG1haWxpbmcg bGlzdA0KPiBuc2lzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25zaXMNCj4gDQo= ------=_NextPart_000_0008_01C3A543.239E13A0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ii8GAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAAtQMAAAAAAAC4AAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHCwAHAA8AFwAAAAUAFwEB A5AGAPQWAAAkAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAABGAAAASXNzdWVzIHNwbGl0dGluZy9jb25zZW5zdXMgLSBSZTogW05TSVNdIERl dGFpbHMgYWJvdXQgTlNJUyBhdCBJRVRGIDU4AAAAAgFxAAEAAAAWAAAAAcOk96e3MlwCLB93S/mQ 19uxX2eW7QAAAgEdDAEAAAAfAAAAU01UUDpTVEFSU1VAU0FJVC5TQU1TVU5HLkNPLktSAAALAAEO AAAAAEAABg4Ael+X96TDAQIBCg4BAAAAGAAAAAAAAACmbdeE8xePT5tku88CLyjfwoAAAAsAHw4B AAAAAgEJEAEAAABxEgAAbRIAAJ4nAABMWkZ1bGWkJgMACgByY3BnMTI18jIA+zM2AegCpAPkBxOP AoMAUAPUAgBwcnEOUAhmY2gKwHNldDCVEKZ9CoF2CJB3awuAdGQ0DGBjAFALAwtgbvkOEDA0EiEL xQqxCoEAQCggSGkH8WIEkHQsMCBQYXUJABbwSnXYa2thFvAAcGQGUQIguGctSBdQFcUV00kX4FkJ wiB0EmAFQHcZ4HPKaAhgbBgQZmkSgAVA8mQEAGN1BBEaABngAHDNB0B5AJAEIG9mG8MEYMJiAxBp dHkgBAEKUM0cgXYEkAtgcHAJgArjmwqAF/JuB9AcQCByC3CfEpAYEAuAG8MdwGJtHWD6dB6RZB/A AYAEIBohHNPVCeB0C4BnICJNC4AfYLceYAbwHHFhBCAaUGwDIP8jkQIgHrUc0wtwHVAicSNR+Rbh c28aQgWgGrMJ4CASPnQmAAEBC4AiYhvSZnX8bmMiUAIgB0AdYhoDHHG5CXBxdRsAIAgVxGIjkLMN 4AewU0kF8BHwbycgiQjhcy4Yy01ITxbwtxmAGgALgGsZ9BzbZR4g/wIwJ0EhAChTJdEBkCEAJQHZ HCBnZQeALyEoCXADUM0HkGgZ8AdxcikW8BXEfycBBJAA0ChiI6EdYDGAQ8BBUkQvQ1QX1BHw7GUt MVEEkHYaIChxHZbOYwORFrAZ8GFrCfAm9N8FoACBBIE1FBXEdy2AElD/JQEdgDYhG5AekSORMSEE kH0J8GMHkQIQBcAb0itATBZQG0Ar0HUwwi4gRbpzHoBjBzEcQBfRbBoA/QhgZzGAJHg0fglwC2Ah At53BbAtsCNiA6BvHoA1Vf8X0QQgFpYYNxfjFxMiEQIwZyhxOTIYAUknHiAX4GT3IUAHkB/1bR2A NHETkAhgfwQgMLAlIRpwC4A6ABvDVvsIkCLwYSIWLTIHQCXxLX3/Pa8+tR2jKUIHcCMwACAAcH8h wSYAHcAecAkRGnAjEG3+bEPxS/E08A3gOhUJcAdA5i0xoh61KG0XMDGiG1B8YSkX4B5wHVA14DL0 KL55CGA10xKQG/Iu4HhMIN8LUBngPqYnITOlLzR+MiadITQtTEA0kACBcy0dFgFU0WxwLTAwLzAs MS4M0DDxaAJAcDoMLy8D8AWCbW0uaxsFsCMQLgDQV7ByL35zMAESgHUvVE9VW1ZTKf8sLD8RE/AE kB2QHLAbwz8j/yRBRpBXciRBJfAKQDUjIUP/KUIdwB1gAaBRUTpIK2ESUv0yoS8g0ExBJyAfYCwQ HrW+Ql5gXMBcoR1gP2NjOgC/BTBfki0yGpAegBn2JyPh/z8jOkJdryEyBUAhYVxxV3H/UUEiUyR5 HSYcFyFDYdYVxP8IUDnxBKAnpjRxEpACMDUV3yK7PFkb0QlwOJNuK7A2Ev8J8G4UTcInIU1hOHFl ogCA/wnwHcAhkV3xIoAXIDyREoD/NhE6QUXkK0MSkAQQL7NHT/9ixSuRGvBfhFyhG9Nx9TXiXzCg SzJ3UW5xJDJTKDBk7zixF/I3QUKhZijiHPg0of8+xGXFHaUfJT/JOiRsCmo8+FJlZwsRbaAYynhR GHEaeRQwawKyGNk+IC31gdJPBRBnC4AHQAXQQ/HXMJGB04FWRgNhOh9QWbKzQ7Ag0G5ACJAAMC4F sG0igFslEicgOoRfhWBd0k8DoEJlEmBsHLCBVvpPHLBIAHAFoICgFvAWlP+BVgZgAjCEMIPwN0A4 sBbwzk4eEQbQXHEwNxbwAdBAMDMgOTo0i/BBek2BVlSF8EIVgrBcUXN2Oxd0BdBKBdAAcB9gcnmB VkNjhDSE94mXILBq0y+BhDBSRYQwSR20O8CrHVEiUi9w6C0H8GWEMOJbK0JdIEQSoCUhBCE/gWUB oAhgBUArQxohSUXgVEYgNTiBVpbOLYD7K4AXJGoXk5bOLPIaQhJg/0OBNtkfsJWRRvNoyRgQTnP/ GpCEwSfBd6UsJYGwG9IeFf02EXQaUDaBAHAo4T8gKUL+KCAxeGEnYh6RKDAdYG2hHxyhJlESgU8Q lPw3NSX3jgA7ECelbUvxCrEwIR+R/wPwI+FvAhvgVeA29BsgOeHfHYEgQ4FWCQAicXIoMJ53fYFW KBfyZxQ8ERbwGlF3/0sTLYAjoT8yJyEmuCuWJ0H9AJBnqHgaWJrQpDAmlGuI/6yrBJApZzDCI6E4 UwrAKmZvgbAAkGExCsFiYmEgoXT/H5EbUAEgOcIFQJjgGyEWsP814DkRG8IdgJrDFrA2gQEA/x4g CQAegYFWE+FjYI2yAjD5HEAuKZbOFnA7EBmaG9L/UoEzozR/HbSaxjYhBaAeIf+26CORCrEFQByl guBN0T8i/xbwOkZNYSXwBjGCUC8BNhGtCQB3O5AjkWlDcncFEP8g8SRWt2IX4Suwd+IlEhfR/wVA TEAjkAVAvnIfkasTHHH/JyE8EcFwOQFLQgDANnBL8f8AgV+igVamZy8yO/BzkiGR/5WDOEBugich P9AxoR/hqYH/qfgco6s2twfJRspVNRNbNn+XKBJQCeASgJk/nmiBVlB/BfAZgDZwY2BQgiJiGyB1 6wEgvyF5ImInmpkSYBPw/1FR0xAi8ZTBwzKSUTvjrYf/OLHJwSBDaTFukTkTOkIdF/1LhSc7kDsQ e5NQEB9gmrS/RpA/IrboUQYcoW8AcgDA7wMg1QTUhCJiZiUlJyE/I/1ucj+WzoHfgu+D9I1KhYd7 MMGN0UA7EQNwBvABoC1SZQhwby5XcV2JnFQWaKKRiq02i6UxNTr+MRRTjMaOL48/kE+RVZPR/5H/ kw+UH5Uvlj/x7hZhF4T/mU90BBmpJfAHgC1yIoASYP/FozYhOxDaMfCUKkjgAHnf/yFEJdFFtrW1 HhYiYx2zYdbX80HBcC7xci0xJ6SwbwL/NwETkDnxGBDggVbAbvEH4PsaAxwTeiJiHRYyBvihnUn/ F/Kb1WCiFOAHkSA1XsSlg//EcaGxxaSyWlFBCtA7Fhbw72dz04MzUxvSSytgK3JFsf5pUUE7kOkA L/JL0d+mMUD/9iAW8LUGLPCacBzftgEdga8hgCPQYrEhkWxNYWRpMG8eIWkwx5hRMnhAcxpRdP/C QFHUGoF8ICAxooFpTvyf/y1bGlEfYA/VCXM/IiJiJEH/C2vMeB3DGgOfRiA1bAUhGJ/FwmCwhQCa 4hvhZ2/g0f/fphyhoTJyMEsBrzMQQjXi/ytDb0JWgI2yUePYc29S/lDtrJBusWP8eEZlceCwG9L/ OgAtMuEw/0VQEQZBXtMjkf9GkXKSMKDqAeDRJ1Q3mRszvmOskExg+1Kbw55ZSDnif3PTudMzU0DE 1vS/A2mQIN4iLVYPcbIiX4BsFQPwHP9ucz9zaXU/IzhEpYOr6CNU/2uVCcd4YDLj1iDYwnTEsNf7 RDN2UmLAgE9wcwSshu/456SCDOH7YHMiCRHFVCaY/xN2TnDEoW8CRbFeUKFQDILv/yKgQt+mTuBz BoBzgyq2//8yoKFRMgaioDO+ck9wmJDfszFeNtDv9PD3USdL4l0B/mjY4a5DPNKqkl0y1YNoz99e tfAXqbIBbT+7KDbCZID/5RBF47VRKYOgkTd4tDb2U35zzkAS4L7QZxSrE2lXKP9O4P5QNpGbFLEQ XHHfpgiHMCA6KSmqc01iaXrfZEVlr3cDvSEZxWQA2GRh/8KQrgg+aGXPafRGUW8BmML/xKHHmZwB DGGnIaTW1rJhwP+Zx05BZHKmYWtCsNECjIkQ+3Yk14RkDGGrsQtkixG0cvsa2Y2xLRBAxKBtoasT q7D/+8AxwKDBQ1PLUacCNmMw978Vz2lWNAASaAsxAn4iA3X/rDFrUMkQeAG+1N+mbTCggf2rgCK/ xCA2V1bGEASxMYD/n4AIsQIF3gETUN3SQ4EA2P+uNb0jm2Qw73Mh+ju5kaXT//uhwon+MFtTHh8f IjufISD/jbEFAjfxJtkhgacSVLyfA/98WEYz36ZvQmmleQd8SjbF/29CLOOaxrmR2MCpB3qCNAD/ h4CbclZxTjGhYCNwCMC0cv9QF9g7JzKnIfDzYYi9oPbW/yEAsiK+wXOaVqF2AarC9tb/MUKhkB1w 0vHSYcK5rTIvof8DIDQAg/JgNO0kBqLJEU1S/7txooFjQjgB+1K1sjK5dbPz9RMHp2UyE9L/QKTw J1H/qaL94msDB6eFohnA+oDhIPthfjQAT2sSMUL5cUaiEVL/92IMkbriRjFUnkj4u1tWcf9vQnVX SqEHlqDBUBD3YWDxf8swieZxvKrE3mCeERpxb/+pwLEQL6THYLaR7/DYM51C/79QrzA+4Puh2LAK wI2jqQf/LIHHYVgRgDP9ptNluiXFZP/AcXNxyzBRQ7/zMCIJqGZ4/1uK8PKWxLSzl28rc3DJbL99 i29N4LCB4Pug5LAMMDr536cgQbncCtAnUGKw7/D/vsW0GBklrjW/UJJRb4GpFr+hKWKTLyDE8MOi N/koG4D/YqHVAfmBxRH08Byh/eKJ8v9k4TLYzPHxc6Xi+9FGITQj/zf5ZngdasVD+Efd5aGhEcj/ omH3txiFjZYyMTGAx1AMov/M42UBwmDHYflykgYFSO4o39vQ/jBCAaOFEIJyZ2HGd/M+4HfYam+m ObIKCoHwwf8S+1ajzPGC8Gal91JWgRSy/2al+EjEojJAI3DvsMdRnw/+Q8984qPfLulND2AyQezg /fJvafPv9PAxg1szD6Av4f1jwm8TUJf0RfEHnwild4L/pcFbYiOh1iiYsO0wOYCVJP8pgyFCAFgC dcn1QXJZgUHT/45TNbAsseCwDjlP0lUSD2P/EyP3p/3AMjFqQPuAP3JO4fcnQp42QdFkRjG9dDzR 1kj/keSOUz0Q+2EjIqR4BnWs+MEqEU5UTFAr8PDYwP9kw+2A7IBFMDGwBWf6gODA+2DBH0FPJJEQ sT0QvTNB0O/+4moVNTZt8nUX8EqUnSb/DjcnsbAAfJcpg4/QDqaGJO8UAzFQHsAbQHdQgddmNAD+ U+3QBGAS0ZWHZpMUdciW/4GH36fZUqKxCkIxMvWAv4/97NBnOtB7QMVX85Px76H1a4lQNBF1ANA2 8OD7UCDQMjAwMwDQWJSAAdQ+RnThw++iIu6w8upvaP+6ofOfn8S9aSOQ+oM1VE8D/5IQkkGoIsMQ 2FIeYQZmSoH/6LIqCj8JpcH7UcgGO2Emov+EkjTZeUdVByczoeYlU19172TDqXGB4IAiOw0idgGz 5//gYheTY/EY8WKiryv0V0hD/yUSItbNZ847YrEi1vv0FsaXyvgPYeMwP7+eKFWpPf8s4/HiqmK/ URmDqqQxQqbq/6wlY2ODqdJxUBCAAUqCC4H/Xgu2YWB03/AY4mATLAbS0/tmk3Y3abgxCyI6Y0nA U3L/YBU3+BciJVHcMB1Qr/IfQP4pv553EfTGwOjspr+euSCd77AuY+ASoYHgeUBp0Pkp8GEu0EHt XRmC7urwD/8ZVu65NCCjX42AYMG2QXlH/6UFsHL+UYrR75K8VaXlpm+vNHLncIBROHFTqSBknQD/ d4FGlUpy0NDLw1nhbkM4Iv9DtXEkoea8wGKhfiRM8Klws9aBMeNXR6wWXgFXZvL/ZqFihH6QtnDJ w8clXReik/84cV0YynY9AYaRfTF8xCTp/xE2ULLJ9Mtxf+GCIqdAZzH/CAKaJ9mgUFOUYZIQwNFA 9P+eQdZTdTAyFLC3G97GYKfg/1tCcUCUwKlRq3Mo8EZCnbf/h+HLwL9CWeLcs0pycUBBgP+8RSZY rQb+UaMFekOsJTbC/7snndXPRLzAigKh5pywfBP/lDI4RbIFAlP94pSx9ULT8c9H4iey4li/nkRv 5jNyUP+KoZOBfiCOU0PxT5PXo0xR76uCBR/vkr+eX0ifSa9Kei9hh13hr+tLikC40HRmTi5isBYn 3EB0cKHAL6Qvd09gMS5N5i+v8rmv8G4vsHJ6EGKgL0wC/xtsSB9Tf1SPS09MX01vTn//T49Qnxr/ 7shHn16/X89VL/9WP1dPWF9Zb1p/W4/ubmjff6H2omDBC6bQrpImR0OgQ3xvTZIgbODQYKkglPdM 39GR1nAzwbjQr1BF24Bw0eAgR21iSKHmbiCuoD5zvMBkYPOR4wAz4CAzBDEyoeY4MDY4N2um0G1y aCNwR/nAZqF5BxxX/DAo8Cs0OS04BXQgNXIAMjQtMjKiNqHmRmF4c+0z7FBpoeZFLa/yOoFybBFA z9dR7NCnUNGQLWVvARhi+2SKZVQueER44nihEzC3oP4vXb98v33PYO9h/2MPZB+vZS9mP2dPogJ9 oiAAhtAAAAAeAEIQAQAAAD0AAAA8RUE5NDNDRDMwQkNCMTA0RTlEMzhGNUI1REMyRDlBNzA4QUM1 RURAcnN5czAwNGEucm9rZS5jby51az4AAAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAA AAADAAOACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAA AFKFAAB9bgEAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsADYAIIAYA AAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwA6gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAAD ADyACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAPYAIIAYAAAAAAMAAAAAAAABGAAAAABiF AAAAAAAAAwBjgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAI6ACCAGAAAAAADAAAAAAAAA RgAAAAAGhQAAAAAAAAIB+A8BAAAAEAAAAKZt14TzF49Pm2S7zwIvKN8CAfoPAQAAABAAAACmbdeE 8xePT5tku88CLyjfAgH7DwEAAACYAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwA AAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcRG9jdW1lbnRzIGFuZCBTZXR0aW5nc1zAzLy6x/Vc TG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xvdXRsb29r LnBzdAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAA5AAAAPElQRVBKTEdFQk5LQ05GS0xOTE1JRUVQ Q0NGQUEuc3RhcnN1QHNhaXQuc2Ftc3VuZy5jby5rcj4AAAAAAwAGEBGZ/9sDAAcQbBoAAAMAEBAA AAAAAwAREAEAAAAeAAgQAQAAAGUAAABISVJPQkVSVCxQQVVMTyxKVUtLQSxBTkRTRU9ORy1ITyxJ QUdSRUVUSEFUV0VTSE9VTERGSVJTVERJU0NVU1NUSEVBTkFMWVNJU09GVEhFTU9CSUxJVFlJU1NV RVNPVkVSTEFQAAAAACXn ------=_NextPart_000_0008_01C3A543.239E13A0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Nov 7 02:48:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03864 for ; Fri, 7 Nov 2003 02:48: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 1AI1Lp-0004GI-HH for nsis-archive@odin.ietf.org; Fri, 07 Nov 2003 02:48:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA77mDRK016380 for nsis-archive@odin.ietf.org; Fri, 7 Nov 2003 02:48:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1Ld-0004FW-RI; Fri, 07 Nov 2003 02:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1Ku-0004EY-A9 for nsis@optimus.ietf.org; Fri, 07 Nov 2003 02:47:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03849 for ; Fri, 7 Nov 2003 02:47:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1Kq-0000ap-00 for nsis@ietf.org; Fri, 07 Nov 2003 02:47:12 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AI1Kp-0000am-00 for nsis@ietf.org; Fri, 07 Nov 2003 02:47:11 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Fri, 7 Nov 2003 08:46:19 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Nov 2003 08:46:29 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6B2@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: morita.naotaka@lab.ntt.co.jp Cc: nsis@ietf.org Subject: RE: [NSIS] PPS and MF-PHB Date: Fri, 7 Nov 2003 08:46:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-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: , Naotaka, thanks for informing NSIS about your work. Those of you interested in end-to-end QoS with stateless core service management should read the documents and attend the TSV WG meeting. The documents aren't perfect yet, but I'm convinced the basic idea is worth more attention. Regards, Rudiger |-----Original Message----- |From: MORITA, Naotaka [mailto:morita.naotaka@lab.ntt.co.jp] |Sent: Friday, November 07, 2003 3:35 AM |To: nsis@ietf.org |Subject: [NSIS] PPS and MF-PHB | | |I would like to draw QoS experts attention to the following |three documents. | |http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt |http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfphb-00.txt |http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt | |I am going to make a presentation on Monday morning at TSV WG. | |Naotaka |---- | Title : Framework of Priority Promotion Scheme | Author(s) : N. Morita, G. Karlsson | Filename : draft-morita-tsvwg-pps-01.txt | Pages : 18 | Date : 2003-10-27 | |This document describes a framework of a new scheme for traffic |control to achieve end-to-end QoS for interactive multimedia |services. The scheme is based on end-to-end measurement of network |resources by end systems. The network is assumed to fully support |the priority control scheme specified in the Diffserv architecture |for QoS and SIP [1] for session control. Since the scheme relies on |the behavior of the end systems, this document also touches on |mechanisms for monitoring end-system behavior. | |------ | Title : Measurable Forwarding: A New |per-Hop Behavior (PHB) | Author(s) : N. Morita | Filename : draft-morita-tsvwg-mfphb-00.txt | Pages : 19 | Date : 2003-11-2 | |The Priority Promotion Scheme (PPS) is a new scheme for traffic |control; specifically, the PPS achieves end-to-end QoS for |interactive multimedia services by exercising admission control for a |series of packets on a packet-based network. The scheme is based on |the end-to-end measurement of network resources by end systems. The |destination end system notifies the conditions of receipt for a |limited set of packets sent from the source end. If this is |acceptable, the source end system then promotes the priority of the |succeeding IP packets to firmly establish the session. The network |is only assumed to support a per-class form of priority control, |since this allows the end systems to measure remaining resources |without affecting the existing streams. If all end systems behave in |the above way, we can achieve specific levels of end-to-end QoS |without maintaining per-flow states in each item of network equipment. | |------ | Title : Verification scenarios for |Measurable Forwarding |PHB (Per-Hop Behavior) | Author(s) : N. Morita | Filename : draft-morita-tsvwg-mfverify-00.txt | Pages : 7 | Date : 2003-10-31 | |The Priority Promotion Scheme (PPS) is a new scheme for traffic |control; specifically, the PPS achieves end-to-end QoS for |interactive multimedia services by exercising admission control for |series of packets on a packet-based network. The scheme is based on |the end-to-end measurement of network resources by end systems. The |destination end system notifies the conditions of receipt for a |limited set of packets sent from the source end. If this is |acceptable, the source end system then promotes the priority of the |succeeding IP packets to firmly establish the session. The network |is only assumed to support a per-class form of priority control, |since this allows the end systems to measure remaining resources |without affecting the existing streams. If all end systems behave in |the above way, we can achieve specific levels of end-to-end QoS |without maintaining per-flow states in each item of network equipment. |The PPS is based on a new per-hop forwarding behavior, called |measurable forwarding (MF-PHB), which will use the DiffServ |architecture. |In this document, we propose a way to verify whether MF-PHB is |realizable by elaborating configurations of existing equipment. | |---------------------------------- |Naotaka MORITA, Senior Research Engineer, Supervisor |Network Service Systems Laboratories |Information Sharing Laboratory Group |NTT |3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN |Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 |E-mail: morita.naotaka@lab.ntt.co.jp |MSN messenger: moritanaotaka@hotmail.com |NTT home page: http://www.ntt.co.jp/about/e/index.html | | | |_______________________________________________ |nsis mailing list |nsis@ietf.org |https://www1.ietf.org/mailman/listinfo/nsis | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Nov 7 03:16:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04840 for ; Fri, 7 Nov 2003 03:16:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1ml-0006Cr-C1 for nsis-archive@odin.ietf.org; Fri, 07 Nov 2003 03:16:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA78G3l0023856 for nsis-archive@odin.ietf.org; Fri, 7 Nov 2003 03:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1mk-0006Cc-K0; Fri, 07 Nov 2003 03:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1lq-0006Ah-LH for nsis@optimus.ietf.org; Fri, 07 Nov 2003 03:15: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 DAA04815 for ; Fri, 7 Nov 2003 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 1AI1lo-0000uz-00 for nsis@ietf.org; Fri, 07 Nov 2003 03:15:04 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1AI1ld-0000uk-00 for nsis@ietf.org; Fri, 07 Nov 2003 03:15:03 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA78ED214210 for ; Fri, 7 Nov 2003 10:14:43 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Nov 2003 10:13:08 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 7 Nov 2003 10:13:08 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Nov 2003 10:13:08 +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: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Fri, 7 Nov 2003 10:13:08 +0200 Message-ID: Thread-Topic: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Thread-Index: AcOkeTcIe45cdTC6QN22WrYOGi6kcwAjNycA To: , Cc: X-OriginalArrivalTime: 07 Nov 2003 08:13:08.0611 (UTC) FILETIME=[FA697D30:01C3A506] 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, Just a point of procedure. Currently, NSIS does not have an explicit = charter item about handling mobility. The charter does discuss mobility to some extent, and it is assumed that the NSIS work needs to be mobility = friendly. However, if you are interested in going beyond that, we will need to get approval for this from our ADs. Ultimately, I'd like to split mobility into two pieces: 1) Ensuring mobility does not break the NSLPs & NTLP. This means that = our initial solution may not be completely optimized for mobility, but it won't break in the presence of mobility. 2) Longer term mobility optimization & support. This would be a = possible new item for NSIS to consider, which would explicitly deal with how we = could deal with mobility extentions, etc. This work is currently outside = of the charter, but if there is enough support in the WG, it is possible to = ask for an extension to the NSIS charter to handle this. What I am looking for at the Minneapolis meeting is to have a general = discussion along the lines of the 2 points above and gage if there is interest in = this work. If there is, then I'd suggest that the interested parties get together = after Minneapolis and work out a combined analysis/discussion/approach wrt to = mobilty submit and individual submission. After this is done, we can see if = extending the charter would be reasonable or not. Please note that the NTLP, NSLP protocols are already underway so I = don't want to insert a new dependency on completing these protocols. thanks, John -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of ext = Paulo Mendes Sent: 06 November, 2003 17:11 To: Jukka MJ Manner Cc: nsis@ietf.org Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS = at IETF 58 Hi Jukka, I also agree that something has to be done about the mobility-related = drafts, since they have overlapping issues. However, I'm not convinced = right now that analyzing mobility, multihoming and routing changes in = the draft will lead us to a simpler document, complying with the KISS = principle. To start from, because IMO the mobility issue by itself is = already very complex, as we tried to show in our analysis draft. However, I think that we need to start working on the mobility issues = that overlap in the presented drafts to achieve the goal of = understanding how can NSIS be extended to mobile environments. For = instance, I saw that your draft as a more general definition of = crossover router. Hence, I agree with Robert when he says "I think we are talking about = here is analysis work which will feed into defining the functionality = that is required in the basic NSIS protocols themselves". This is, I = agree that we must not include by now any discussion about how to = implement any particular solution. I don't see why shouldn't we work in a mobility analysis draft and a = multihoming analysis draft (by nature these are two different things). = If after this analysis (divide to conquer principle :)), we realize that = a common solution can be achieved, than we should work in a common = solution draft. If not, just continue in separate ways. In what concerns routing changes, if they are due to the movement of = end-hosts, this topic is naturally included in the mobility analysis. = However, IMO routing changes "in the interior of the network", for = instance due to load balancing and link failure, should be considered in = the basic NSIS, since they do not happen only in mobile environments. I tend to disagree with you in what concerns the open issues. If you do = not identify open issues by now you will have to do it late. Besides, an = efficient solution for mobility within NSIS needs to be aware of open = issues if it wants to be the next step in signaling. From the issues = mentioned, resource discovery has to do also with the e2e new path and = not only with the new access network. Only the latter is done by CARD. = In what concerns pre-reservations, you have to deal with this sooner or = latter if you want to get good quality levels for multimedia = applications while moving. I'm not saying that this is easy or not, or = that it should be included in NSIS. I'm just saying that this is an open = issue. In what concerns Minneapolis: - Agree that the authors of the different drafts should meet in = Minneapolis for further discussion (unfortunately I cannot attend this = IETF meeting). This discussion should be extended to this mailing list. - About the presentations, probably it is a little late to get a = consensus among authors in order to make a efficient join presentation, = but I think that if this could be done, it would be most profitable. Cheers, Paulo Jukka MJ Manner wrote: Hi, I basically try to look at things with the KISS principle, and my = initial assumptions are that mobility, routing, and multi-homing have much in common once we think about them properly and with an open mind. I = wouldn't want to have several different documents discussing NTLP+NSLP and = specific scenarios. Of course, it might happen that we end up realizing that certain issues are too complex and need their own documents. Still, I would start with the mentioned issues and see from there. Regards, Jukka On Thu, 6 Nov 2003, Xiaoming Fu wrote: =20 Hi John, Jukka, It would be nice that we work together a single document regarding=20 mobility and move things on. I also agree that mobility concerns with=20 route change and tunneling; is it a little too overloaded for this=20 document to cover general routing, multi-homing or general tunnel issues = as well? (Unfortunately I will be not able to attend the Minneapolis meeting due=20 to personal reasons. However, I am interested in this work and would=20 like to participate in the discussions through emails.) Best regards, Xiaoming john.loughney@nokia.com wrote: =20 Hi Jukka, =20 The authors of the various mobility drafts listed by John could meet in Minneapolis, e.g. on Sunday, after the reception, to discuss these = issues before the actual NSIS WG meetings. We could, for example, try to agree = on=20 an initial set of issues to discuss in the draft, and assign responsible = section editors, and an overall editor. =20 I fully support this. If this is acceptable, then the results could be discussed at the NSIS meeting. I think this is a much better use of time, then presenting overlapping individual documents. Does anyone else have any comments on this? John _______________________________________________ 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 =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis =20 --=20 Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Nov 7 03:27:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05113 for ; Fri, 7 Nov 2003 03:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1xP-0006yy-EV for nsis-archive@odin.ietf.org; Fri, 07 Nov 2003 03:27:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA78R37L026800 for nsis-archive@odin.ietf.org; Fri, 7 Nov 2003 03:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1xN-0006y1-Va; Fri, 07 Nov 2003 03:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1wo-0006tA-LY for nsis@optimus.ietf.org; Fri, 07 Nov 2003 03:26:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05102 for ; Fri, 7 Nov 2003 03:26:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1wm-00011s-00 for nsis@ietf.org; Fri, 07 Nov 2003 03:26:24 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AI1wl-00011p-00 for nsis@ietf.org; Fri, 07 Nov 2003 03:26:23 -0500 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Fri, 07 Nov 2003 09:26:28 +0100 Message-ID: <3FAB5727.8080000@cs.uni-goettingen.de> Date: Fri, 07 Nov 2003 09:26:15 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: Paulo Mendes , Jukka MJ Manner , nsis@ietf.org Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, Paulo, Jukka, and all, Hancock, Robert wrote: > hi paulo, jukka, > > IMHO we have to consider routing, mobility and multihoming together. > the overlap between any two is (in undefined units, of course) > about 75%; doing them separately will not help consistency in the long run. Seeking an accurate corelation factor might go for mathematical models :-) I do see the relationship between routing, mobility and multihome is incoherent in some sense. However, if we look at IP mobility protocols (which is suggested by the current charter), this relationship might be less strong as you expected. - Generally, a soft state signaling protocol needs to react to route change and node failures in "best-effort" IP networks (in this sense RSVP which precedes NSIS have presented a good way in regards that; infrequent route change can be discerned by RSVP/routing interface and repaired by local repair anyway). - Typical IP mobility protocols do not mandate a multi-homed support, but suggest this can be an optimal case when the old and new CoAs are at the same still valid for data transmission. - What is the in the long run - IMHO - is that IP mobility protocols in principle change the Internet way of forwarding data by (much more) frequent _route change and adding/removal/change of encapsulations_ in the middle _in co-located with host IP address change_, which is "MUST-be-supported" for IP mobility. This might be the real difficulty behind a rational NSIS-mobility interop work. - I guess NSIS at the first step might want something that is interoperable with basic mobility approaches, where we look for > i do agree that the CT/CARD/pre-reservation issues have to be covered > as part of the same work, for the reasons given below. as i've written > in another mail, at least partly this is to allow us to make sensible > consistent decisions about where to optimise (after all, of this work > is about optimisation). I also agree that CT/CARD/pre-res. is part of the mobility consideration, as this is the useful scenarios in presence of mobility; even if something is not mandatory for IP mobility, they can be a long run to pursue. Cheers, Xiaoming > cheers, > > r. > > PS I keep seeing stuff saying 'we have to handle tunnels in a special > way when they are used for mobility support'. does anyone have a worked > example of normal tunnel handling failing to work here? > > -----Original Message----- > From: Paulo Mendes [mailto:mendes@docomolab-euro.com] > Sent: Thursday, November 06, 2003 15:11 > To: Jukka MJ Manner > Cc: nsis@ietf.org > Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 > > > Hi Jukka, > > I also agree that something has to be done about the mobility-related drafts, since they have overlapping issues. However, I'm not convinced right now that analyzing mobility, multihoming and routing changes in the draft will lead us to a simpler document, complying with the KISS principle. To start from, because IMO the mobility issue by itself is already very complex, as we tried to show in our analysis draft. > However, I think that we need to start working on the mobility issues that overlap in the presented drafts to achieve the goal of understanding how can NSIS be extended to mobile environments. For instance, I saw that your draft as a more general definition of crossover router. > Hence, I agree with Robert when he says "I think we are talking about here is analysis work which will feed into defining the functionality that is required in the basic NSIS protocols themselves". This is, I agree that we must not include by now any discussion about how to implement any particular solution. > > I don't see why shouldn't we work in a mobility analysis draft and a multihoming analysis draft (by nature these are two different things). If after this analysis (divide to conquer principle :)), we realize that a common solution can be achieved, than we should work in a common solution draft. If not, just continue in separate ways. > In what concerns routing changes, if they are due to the movement of end-hosts, this topic is naturally included in the mobility analysis. However, IMO routing changes "in the interior of the network", for instance due to load balancing and link failure, should be considered in the basic NSIS, since they do not happen only in mobile environments. > > I tend to disagree with you in what concerns the open issues. If you do not identify open issues by now you will have to do it late. Besides, an efficient solution for mobility within NSIS needs to be aware of open issues if it wants to be the next step in signaling. From the issues mentioned, resource discovery has to do also with the e2e new path and not only with the new access network. Only the latter is done by CARD. In what concerns pre-reservations, you have to deal with this sooner or latter if you want to get good quality levels for multimedia applications while moving. I'm not saying that this is easy or not, or that it should be included in NSIS. I'm just saying that this is an open issue. > > In what concerns Minneapolis: > - Agree that the authors of the different drafts should meet in Minneapolis for further discussion (unfortunately I cannot attend this IETF meeting). This discussion should be extended to this mailing list. > - About the presentations, probably it is a little late to get a consensus among authors in order to make a efficient join presentation, but I think that if this could be done, it would be most profitable. > > Cheers, > Paulo > > Jukka MJ Manner wrote: > > Hi, > > I basically try to look at things with the KISS principle, and my initial > assumptions are that mobility, routing, and multi-homing have much in > common once we think about them properly and with an open mind. I wouldn't > want to have several different documents discussing NTLP+NSLP and specific > scenarios. Of course, it might happen that we end up realizing that > certain issues are too complex and need their own documents. Still, I > would start with the mentioned issues and see from there. > > Regards, > Jukka > > > On Thu, 6 Nov 2003, Xiaoming Fu wrote: > > > Hi John, Jukka, > > It would be nice that we work together a single document regarding > mobility and move things on. I also agree that mobility concerns with > route change and tunneling; is it a little too overloaded for this > document to cover general routing, multi-homing or general tunnel issues > as well? > > (Unfortunately I will be not able to attend the Minneapolis meeting due > to personal reasons. However, I am interested in this work and would > like to participate in the discussions through emails.) > > Best regards, > Xiaoming > > john.loughney@nokia.com wrote: > > Hi Jukka, > > > > The authors of the various mobility drafts listed by John could meet in > Minneapolis, e.g. on Sunday, after the reception, to discuss these issues > before the actual NSIS WG meetings. We could, for example, try to agree on > an initial set of issues to discuss in the draft, and assign responsible > section editors, and an overall editor. > > I fully support this. If this is acceptable, then the results could > be discussed at the NSIS meeting. I think this is a much better > use of time, then presenting overlapping individual documents. > > Does anyone else have any comments on this? > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Nov 7 03:29:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05184 for ; Fri, 7 Nov 2003 03:29:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1zK-00074o-TA for nsis-archive@odin.ietf.org; Fri, 07 Nov 2003 03:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA78T2X1027177 for nsis-archive@odin.ietf.org; Fri, 7 Nov 2003 03:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1zJ-000749-TM; Fri, 07 Nov 2003 03:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1yb-00073a-Pu for nsis@optimus.ietf.org; Fri, 07 Nov 2003 03:28: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 DAA05153 for ; Fri, 7 Nov 2003 03:28:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1yZ-00012y-00 for nsis@ietf.org; Fri, 07 Nov 2003 03:28:15 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AI1yY-00012v-00 for nsis@ietf.org; Fri, 07 Nov 2003 03:28:14 -0500 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Fri, 07 Nov 2003 09:28:22 +0100 Message-ID: <3FAB5798.4080303@cs.uni-goettingen.de> Date: Fri, 07 Nov 2003 09:28:08 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: mendes@docomolab-euro.com, jmanner@cs.Helsinki.FI, nsis@ietf.org Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, I fully agree with your suggestion. Cheers, Xiaoming john.loughney@nokia.com wrote: > Hi all, > > Just a point of procedure. Currently, NSIS does not have an explicit charter > item about handling mobility. The charter does discuss mobility to some > extent, and it is assumed that the NSIS work needs to be mobility friendly. > However, if you are interested in going beyond that, we will need to get > approval for this from our ADs. > > Ultimately, I'd like to split mobility into two pieces: > > 1) Ensuring mobility does not break the NSLPs & NTLP. This means that our > initial solution may not be completely optimized for mobility, but > it won't break in the presence of mobility. > > 2) Longer term mobility optimization & support. This would be a possible new > item for NSIS to consider, which would explicitly deal with how we could > deal with mobility extentions, etc. This work is currently outside of the > charter, but if there is enough support in the WG, it is possible to ask > for an extension to the NSIS charter to handle this. > > What I am looking for at the Minneapolis meeting is to have a general discussion > along the lines of the 2 points above and gage if there is interest in this work. > If there is, then I'd suggest that the interested parties get together after > Minneapolis and work out a combined analysis/discussion/approach wrt to mobilty > submit and individual submission. After this is done, we can see if extending > the charter would be reasonable or not. > > Please note that the NTLP, NSLP protocols are already underway so I don't want > to insert a new dependency on completing these protocols. > > thanks, > John > > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of ext Paulo Mendes > Sent: 06 November, 2003 17:11 > To: Jukka MJ Manner > Cc: nsis@ietf.org > Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 > > > Hi Jukka, > > I also agree that something has to be done about the mobility-related drafts, since they have overlapping issues. However, I'm not convinced right now that analyzing mobility, multihoming and routing changes in the draft will lead us to a simpler document, complying with the KISS principle. To start from, because IMO the mobility issue by itself is already very complex, as we tried to show in our analysis draft. > However, I think that we need to start working on the mobility issues that overlap in the presented drafts to achieve the goal of understanding how can NSIS be extended to mobile environments. For instance, I saw that your draft as a more general definition of crossover router. > Hence, I agree with Robert when he says "I think we are talking about here is analysis work which will feed into defining the functionality that is required in the basic NSIS protocols themselves". This is, I agree that we must not include by now any discussion about how to implement any particular solution. > > I don't see why shouldn't we work in a mobility analysis draft and a multihoming analysis draft (by nature these are two different things). If after this analysis (divide to conquer principle :)), we realize that a common solution can be achieved, than we should work in a common solution draft. If not, just continue in separate ways. > In what concerns routing changes, if they are due to the movement of end-hosts, this topic is naturally included in the mobility analysis. However, IMO routing changes "in the interior of the network", for instance due to load balancing and link failure, should be considered in the basic NSIS, since they do not happen only in mobile environments. > > I tend to disagree with you in what concerns the open issues. If you do not identify open issues by now you will have to do it late. Besides, an efficient solution for mobility within NSIS needs to be aware of open issues if it wants to be the next step in signaling. From the issues mentioned, resource discovery has to do also with the e2e new path and not only with the new access network. Only the latter is done by CARD. In what concerns pre-reservations, you have to deal with this sooner or latter if you want to get good quality levels for multimedia applications while moving. I'm not saying that this is easy or not, or that it should be included in NSIS. I'm just saying that this is an open issue. > > In what concerns Minneapolis: > - Agree that the authors of the different drafts should meet in Minneapolis for further discussion (unfortunately I cannot attend this IETF meeting). This discussion should be extended to this mailing list. > - About the presentations, probably it is a little late to get a consensus among authors in order to make a efficient join presentation, but I think that if this could be done, it would be most profitable. > > Cheers, > Paulo > > Jukka MJ Manner wrote: > > Hi, > > I basically try to look at things with the KISS principle, and my initial > assumptions are that mobility, routing, and multi-homing have much in > common once we think about them properly and with an open mind. I wouldn't > want to have several different documents discussing NTLP+NSLP and specific > scenarios. Of course, it might happen that we end up realizing that > certain issues are too complex and need their own documents. Still, I > would start with the mentioned issues and see from there. > > Regards, > Jukka > > > On Thu, 6 Nov 2003, Xiaoming Fu wrote: > > > Hi John, Jukka, > > It would be nice that we work together a single document regarding > mobility and move things on. I also agree that mobility concerns with > route change and tunneling; is it a little too overloaded for this > document to cover general routing, multi-homing or general tunnel issues > as well? > > (Unfortunately I will be not able to attend the Minneapolis meeting due > to personal reasons. However, I am interested in this work and would > like to participate in the discussions through emails.) > > Best regards, > Xiaoming > > john.loughney@nokia.com wrote: > > Hi Jukka, > > > > The authors of the various mobility drafts listed by John could meet in > Minneapolis, e.g. on Sunday, after the reception, to discuss these issues > before the actual NSIS WG meetings. We could, for example, try to agree on > an initial set of issues to discuss in the draft, and assign responsible > section editors, and an overall editor. > > I fully support this. If this is acceptable, then the results could > be discussed at the NSIS meeting. I think this is a much better > use of time, then presenting overlapping individual documents. > > Does anyone else have any comments on this? > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Nov 7 03:45:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05644 for ; Fri, 7 Nov 2003 03:45:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2Eq-0007wT-9S for nsis-archive@odin.ietf.org; Fri, 07 Nov 2003 03:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA78j4sv030526 for nsis-archive@odin.ietf.org; Fri, 7 Nov 2003 03:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2Eo-0007vf-0Q; Fri, 07 Nov 2003 03: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 1AI2EJ-0007um-GG for nsis@optimus.ietf.org; Fri, 07 Nov 2003 03:44: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 DAA05623 for ; Fri, 7 Nov 2003 03:44:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2EG-0001FF-00 for nsis@ietf.org; Fri, 07 Nov 2003 03:44:28 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AI2EF-0001Ev-00 for nsis@ietf.org; Fri, 07 Nov 2003 03:44:28 -0500 Received: from netpronote3 (netpronote3.psl.com.sg [10.81.113.71]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with SMTP id hA78ZxRn001247; Fri, 7 Nov 2003 16:36:00 +0800 (SGT) From: "Cheng Hong" To: "Xiaoming Fu" , , Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Fri, 7 Nov 2003 16:47:31 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3FAB5727.8080000@cs.uni-goettingen.de> Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Xiaming and all, > - Typical IP mobility protocols do not mandate a multi-homed support, > but suggest this can be an optimal case when the old and new CoAs are at > the same still valid for data transmission. Although multi-homing is not mandated by mobility protocols, it is something that happens in a moblity event. I guess it falls into the catagory 1) of John's classification. It is something the NSIS has too support in the initial solution. best regards Cheng > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Xiaoming Fu > Sent: Friday, November 07, 2003 4:26 PM > To: Hancock, Robert > Cc: Paulo Mendes; Jukka MJ Manner; nsis@ietf.org > Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS > at IETF 58 > > > Robert, Paulo, Jukka, and all, > > Hancock, Robert wrote: > > hi paulo, jukka, > > > > IMHO we have to consider routing, mobility and multihoming together. > > the overlap between any two is (in undefined units, of course) > > about 75%; doing them separately will not help consistency in > the long run. > > Seeking an accurate corelation factor might go for mathematical models > :-) I do see the relationship between routing, mobility and multihome is > incoherent in some sense. However, if we look at IP mobility protocols > (which is suggested by the current charter), this relationship might be > less strong as you expected. > > - Generally, a soft state signaling protocol needs to react to route > change and node failures in "best-effort" IP networks (in this sense > RSVP which precedes NSIS have presented a good way in regards that; > infrequent route change can be discerned by RSVP/routing interface and > repaired by local repair anyway). > > - Typical IP mobility protocols do not mandate a multi-homed support, > but suggest this can be an optimal case when the old and new CoAs are at > the same still valid for data transmission. > > - What is the in the long run - IMHO - is that IP mobility protocols in > principle change the Internet way of forwarding data by (much more) > frequent _route change and adding/removal/change of encapsulations_ in > the middle _in co-located with host IP address change_, which is > "MUST-be-supported" for IP mobility. This might be the real difficulty > behind a rational NSIS-mobility interop work. > > - I guess NSIS at the first step might want something that is > interoperable with basic mobility approaches, where we look for > > > i do agree that the CT/CARD/pre-reservation issues have to be covered > > as part of the same work, for the reasons given below. as i've written > > in another mail, at least partly this is to allow us to make sensible > > consistent decisions about where to optimise (after all, of this work > > is about optimisation). > > I also agree that CT/CARD/pre-res. is part of the mobility > consideration, as this is the useful scenarios in presence of mobility; > even if something is not mandatory for IP mobility, they can be a long > run to pursue. > > Cheers, > Xiaoming > > cheers, > > > > r. > > > > PS I keep seeing stuff saying 'we have to handle tunnels in a special > > way when they are used for mobility support'. does anyone have a worked > > example of normal tunnel handling failing to work here? > > > > -----Original Message----- > > From: Paulo Mendes [mailto:mendes@docomolab-euro.com] > > Sent: Thursday, November 06, 2003 15:11 > > To: Jukka MJ Manner > > Cc: nsis@ietf.org > > Subject: Re: Issues splitting/consensus - Re: [NSIS] Details > about NSIS at IETF 58 > > > > > > Hi Jukka, > > > > I also agree that something has to be done about the > mobility-related drafts, since they have overlapping issues. > However, I'm not convinced right now that analyzing mobility, > multihoming and routing changes in the draft will lead us to a > simpler document, complying with the KISS principle. To start > from, because IMO the mobility issue by itself is already very > complex, as we tried to show in our analysis draft. > > However, I think that we need to start working on the mobility > issues that overlap in the presented drafts to achieve the goal > of understanding how can NSIS be extended to mobile environments. > For instance, I saw that your draft as a more general definition > of crossover router. > > Hence, I agree with Robert when he says "I think we are talking > about here is analysis work which will feed into defining the > functionality that is required in the basic NSIS protocols > themselves". This is, I agree that we must not include by now any > discussion about how to implement any particular solution. > > > > I don't see why shouldn't we work in a mobility analysis draft > and a multihoming analysis draft (by nature these are two > different things). If after this analysis (divide to conquer > principle :)), we realize that a common solution can be achieved, > than we should work in a common solution draft. If not, just > continue in separate ways. > > In what concerns routing changes, if they are due to the > movement of end-hosts, this topic is naturally included in the > mobility analysis. However, IMO routing changes "in the interior > of the network", for instance due to load balancing and link > failure, should be considered in the basic NSIS, since they do > not happen only in mobile environments. > > > > I tend to disagree with you in what concerns the open issues. > If you do not identify open issues by now you will have to do it > late. Besides, an efficient solution for mobility within NSIS > needs to be aware of open issues if it wants to be the next step > in signaling. From the issues mentioned, resource discovery has > to do also with the e2e new path and not only with the new access > network. Only the latter is done by CARD. In what concerns > pre-reservations, you have to deal with this sooner or latter if > you want to get good quality levels for multimedia applications > while moving. I'm not saying that this is easy or not, or that it > should be included in NSIS. I'm just saying that this is an open issue. > > > > In what concerns Minneapolis: > > - Agree that the authors of the different drafts should meet in > Minneapolis for further discussion (unfortunately I cannot attend > this IETF meeting). This discussion should be extended to this > mailing list. > > - About the presentations, probably it is a little late to get > a consensus among authors in order to make a efficient join > presentation, but I think that if this could be done, it would be > most profitable. > > > > Cheers, > > Paulo > > > > Jukka MJ Manner wrote: > > > > Hi, > > > > I basically try to look at things with the KISS principle, and > my initial > > assumptions are that mobility, routing, and multi-homing have much in > > common once we think about them properly and with an open mind. > I wouldn't > > want to have several different documents discussing NTLP+NSLP > and specific > > scenarios. Of course, it might happen that we end up realizing that > > certain issues are too complex and need their own documents. Still, I > > would start with the mentioned issues and see from there. > > > > Regards, > > Jukka > > > > > > On Thu, 6 Nov 2003, Xiaoming Fu wrote: > > > > > > Hi John, Jukka, > > > > It would be nice that we work together a single document regarding > > mobility and move things on. I also agree that mobility concerns with > > route change and tunneling; is it a little too overloaded for this > > document to cover general routing, multi-homing or general > tunnel issues > > as well? > > > > (Unfortunately I will be not able to attend the Minneapolis meeting due > > to personal reasons. However, I am interested in this work and would > > like to participate in the discussions through emails.) > > > > Best regards, > > Xiaoming > > > > john.loughney@nokia.com wrote: > > > > Hi Jukka, > > > > > > > > The authors of the various mobility drafts listed by John could meet in > > Minneapolis, e.g. on Sunday, after the reception, to discuss > these issues > > before the actual NSIS WG meetings. We could, for example, try > to agree on > > an initial set of issues to discuss in the draft, and assign > responsible > > section editors, and an overall editor. > > > > I fully support this. If this is acceptable, then the results could > > be discussed at the NSIS meeting. I think this is a much better > > use of time, then presenting overlapping individual documents. > > > > Does anyone else have any comments on this? > > > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Nov 7 03:51:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05765 for ; Fri, 7 Nov 2003 03:51:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2Kb-0008DM-RR for nsis-archive@odin.ietf.org; Fri, 07 Nov 2003 03:51:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA78p193031555 for nsis-archive@odin.ietf.org; Fri, 7 Nov 2003 03:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2Ka-0008Cd-8b; Fri, 07 Nov 2003 03:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2K7-0008BP-Cy for nsis@optimus.ietf.org; Fri, 07 Nov 2003 03:50: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 DAA05714 for ; Fri, 7 Nov 2003 03:50:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2K4-0001J3-00 for nsis@ietf.org; Fri, 07 Nov 2003 03:50:28 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AI2K3-0001Iv-00 for nsis@ietf.org; Fri, 07 Nov 2003 03:50:27 -0500 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Fri, 07 Nov 2003 09:50:31 +0100 Message-ID: <3FAB5CC9.6060506@cs.uni-goettingen.de> Date: Fri, 07 Nov 2003 09:50:17 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable To: "Hancock, Robert" CC: Jukka MJ Manner , nsis@ietf.org Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 References: In-Reply-To: X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.39.1 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, Short comments inline: > for example, in the general case, to > achieve a rapid teardown on the old path may be quite difficult; > so, there is a choice between 'we try to make this possible > always' and 'if you want to have this function, do it with > card/ct/whatever'. Probably this is desirable for many access networks - recall how bulk, real-time traffic have evolved the QoS necessity - in (rather frequent) movement of a number of mobile nodes, (mostly, access network) routers may come up overloaded within bottleneck resources (which can be pretiou= s). > to make these decisions sensibly, we need some > concrete analysis in a form which everyone can absorb and come > to a view on. (the result can then go into the protocol design > documents.) I agree. Best regards, Xiaoming > r. > > PS. i'm all for meeting at the reception, although I may be > fit to collapse asleep by the end of it. we can at least find > out who is around and when people are free monday. > > > >>-----Original Message----- >>From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >>Sent: Thursday, November 06, 2003 13:21 >>To: nsis@ietf.org >>Subject: Re: Issues splitting/consensus - Re: [NSIS] Details >>about NSIS >>at IETF 58 >> >> >> >>Hi all, >> >>I went through all mobility-related drafts and I basically >>agree with you >>about the common issues. >> >>To me it seems that we have pretty much identified the main >>issues, and it >>is time to move on now. I would suggest that we gather one >>single draft >>about the implications of mobility, routing, multi-homing and routing >>changes/repair into one single WG draft. This draft would be used as a >>"requirements"-type of document as the design of NTLP >>continues, to check >>that the design fits specific environments (mobile, routing changes, >>multi-homing). The document would also include the >>backgrounds for certain >>issues, not just repeat requirements already mentioned in the >>requirements >>draft. In addition, the document would be a reference for the >>current and >>future NSLP documents: what you need to take into account >>when you design >>an NSLP? >> >>I would include in this document the issues Seong-Ho already >>mentioned, >>and, the issue with refresh timers, and encapsulation issues >>because many >>LMM protocols do this. I would leave out resource discovery (since, at >>least in a mobile environment, CARD is doing this), and >>pre-reservations, >>because these are more of a trick and very special scheme to deal with >>mobility and resources. Moreover, I wouldn't want the document to have >>discussions on how to implement things - the NTLP and NSLP >>documents will >>do this eventually, if not already. >> >>Thus, it would be a draft that documents the current >>understanding of the >>issues between mobility/routing/multi-homing and resource signaling. >> >>The authors of the various mobility drafts listed by John >>could meet in >>Minneapolis, e.g. on Sunday, after the reception, to discuss >>these issues >>before the actual NSIS WG meetings. We could, for example, >>try to agree on >>an initial set of issues to discuss in the draft, and assign >>responsible >>section editors, and an overall editor. >> >>Any comments? >> >>Regards, >>Jukka >> >> >>On Thu, 6 Nov 2003, Seong-Ho Jeong wrote: >> >> >>>Hi Robert, Xiaoming, Jukka, Sung-Hyuck, and John, >>> >>>IMO, the following could be (mobility-related) common issues >>>(concerning the NTLP/NSLP) that the drafts submitted by different >>>people have discussed. >>> >>>- Differences between the general route change (not related >> >>to mobility) and >> >>> mobility-caused route change >>>- How to discover crossover router (or crossover node) >> >>using some identifiers >> >>> (how to discover upstream and downstream crossover routers) >>>- How to setup states on the new path and teardown old >> >>states on the obsolete path >> >>> (as quickly as possible,......) >>>- State update on the joined/common/shared/unchanged path >> >>after handover >> >>>- Interactions with mobility protocols such as CT and CARD >> >>(in a general way) >> >>>- Interactions between the NTLP and NSLP >>>- Security issues (authorization,...) >>>- etc. >>> >>>I think that (at least) the above issues may need to be >> >>addressed in the NSIS WG.... >> >>>Additionally, it might be good to include the following >> >>issues that were discussed >> >>>separately by the different drafts. >>> >>>- IP-in-IP encapsulation >>>- Dead peer (crossover router) discovery >>>- Discovery of resource availability >>>- State mangement (refresh timer value management,...) >>>- Last node detection >>>- Pre-reservation >>>- etc.... >>> >>>Regards, >>> >>>Seong-Ho Jeong >>> >>>----- Original Message ----- >>>From: "Hancock, Robert" >>>To: "Xiaoming Fu" ; >> >> >> >>>Cc: ; >>>Sent: Wednesday, November 05, 2003 5:01 AM >>>Subject: RE: Issues splitting/consensus - Re: [NSIS] >> >>Details about NSIS at IETF 58 >> >>> >>>>hi xiaoming, jukka, john, .... >>>> >>>>process-wise: >>>>i see some value in a 'what things group X/Y/Z cares >> >>about' discussion. >> >>>>i see much more value in a 'this is the complete issue >> >>list and here >> >>>>are the commonalities/divergences between different >> >>people' discussion >> >>>>(as I think we succeeded in doing with the 3 QoS drafts >> >>in Vienna). >> >>>>we should start that discussion on the list now and maybe >> >>we can do >> >>>>some further merging in Minneapolis (depending on what >> >>else is exciting >> >>>>to do on Monday). >>>> >>>>on a scoping point: >>>>between the lines I detect some concern that there is a >> >>danger that >> >>>>some of the mobility discussion may turn into some kind >> >>of 'Mobile-NSIS' >> >>>>project with a life of its own. it's my opinion that this >> >>shouldn't >> >>>>happen (and in fact isn't likely to happen). instead, >> >>what I think we >> >>>>are talking about here is analysis work which will feed >> >>into defining >> >>>>the functionality that is required in the basic NSIS >> >>protocols themselves >> >>>>(just like we have analysed security and so on). that >> >>protocol design >> >>>>work - which is going on now - is a potential eager >> >>consumer of this >> >>>>mobility work; at the moment, the mobility impact on >> >>protocol design >> >>>>has been driven mainly by instinct rather than solid >> >>thought, and it >> >>>>is time to put that instinct on a much firmer foundation. >>>> >>>>on the technical points: >>>>i have a pile of drafts to read... >>>> >>>>cheers, >>>> >>>>r. >>>> >>>>>-----Original Message----- >>>>>From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] >>>>>Sent: Tuesday, November 04, 2003 08:59 >>>>>To: john.loughney@nokia.com >>>>>Cc: jmanner@cs.Helsinki.FI; nsis@ietf.org >>>>>Subject: Issues splitting/consensus - Re: [NSIS] >> >>Details about NSIS at >> >>>>>IETF 58 >>>>> >>>>> >>>>>John, >>>>> >>>>>This sounds a good idea. One thing that has become clear to >>>>>me is that >>>>>although we all have some kind of idea on what mobility >> >>issues are, >> >>>>>those ideas are not necessarily totally aligned >> >>(although a certain >> >>>>>number of issues have been described in different ways and not >>>>>particulalrly opposed in most cases since pre-&post-Vienna >>>>>discussions). >>>>> >>>>>If NSIS is going to develop something interoperable >> >>with mobility >> >>>>>protocols, I think it is probably necessary to come to some >>>>>reasonable >>>>>agreement on which issues are of common concern to all and >>>>>which are of >>>>>different view for each, before we go too far into presenting >>>>>"seperate" >>>>>issues but possibly repeating many issues several >> >>times. These can >> >>>>>include, but not limit to, all the bullets that have >> >>come out of the >> >>>>>existing discussions (e.g., host IP change, route >> >>change, IP-in-IP >> >>>>>encapsulation, crossover router discovery, routing interface, >>>>>etc.). For >>>>>example, it seems to me more or less at least a >> >>consensus has been >> >>>>>reached that working with mobility/route change is more >> >>of an NTLP >> >>>>>concern rather than simply an NSLP issue. However, there are >>>>>many other >>>>>issues have not converged. For instance, there was a concern >>>>>that flow >>>>>ID should be able to used to route NSIS packets, but very >>>>>likely, it can >>>>>be problematic or inefficient in mobility and tunneling >> >>scenarios; we >> >>>>>may instead rely on NTLP session ID together with the discovery >>>>>functionality. Perhaps the outcome of the Minneapolis meeting >>>>>would be >>>>>not so much a direct solution, but to clarify a number >> >>of things. >> >>>>>Best regards, >>>>>Xiaoming >>>>> >>>>>john.loughney@nokia.com wrote: >>>>> >>>>>>Hi Jukka, >>>>>> >>>>>> >>>>>> >>>>>>>Should we have one slide per draft for the background on >>>>> >>>>>the problem space >>>>> >>>>>>>people see? One slide with the main issues each "group" >>>>> >>>>>feels are the >>>>> >>>>>>>most important? Thath would make four slides? >>>>>>> >>>>>>>We could also have a preliminary discussion on the list. >>>>>> >>>>>> >>>>>>I'd like that we could discuss this on the list, a combined >>>>> >>>>>presentation >>>>> >>>>>>would be one possible solution. >>>>>> >>>>>>br, >>>>>>John >>>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>nsis mailing list >>>>>nsis@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>> >>>> >>>>_______________________________________________ >>>>nsis mailing list >>>>nsis@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>z=C8=AC(tm)=A8=A5Sx%S=CBg=B2+"z=D7=E8=AE=08m=B6>>=FF=FC0=C3Xz=B5=FA+= f=F9sSYsY=F9b=B2=D8=A7~=8F=E7=B2+ >> >> >> >> >>_______________________________________________ >>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 Fri Nov 7 09:04:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14958 for ; Fri, 7 Nov 2003 09:04:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7DW-0007Cz-Nw for nsis-archive@odin.ietf.org; Fri, 07 Nov 2003 09:04:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7E42p1027703 for nsis-archive@odin.ietf.org; Fri, 7 Nov 2003 09:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7DV-0007CM-EC; Fri, 07 Nov 2003 09:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7Cf-0007Aw-Eo for nsis@optimus.ietf.org; Fri, 07 Nov 2003 09:03:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14884; Fri, 7 Nov 2003 09:02: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 1AI7Cc-0005RA-00; Fri, 07 Nov 2003 09:03:06 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AI7Cc-0005R3-00; Fri, 07 Nov 2003 09:03:06 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA7E34A09520; Fri, 7 Nov 2003 16:03:04 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Nov 2003 16:03:04 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Nov 2003 16:03:04 +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="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Nov 2003 16:03:03 +0200 Message-ID: Thread-Topic: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Thread-Index: AcOlDFX/o8EgpLdlSKupFDSuTuFUCgAKzt3g To: Cc: X-OriginalArrivalTime: 07 Nov 2003 14:03:04.0181 (UTC) FILETIME=[DCBF3A50:01C3A537] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] NSIS Agenda Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Here is the updated agenda. I may still need to bash it somewhat still. thanks, John Next Steps in Signaling Agenda IETF 58 TUESDAY, November 11, 2003 1415-1515 Afternoon Sessions II =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Agenda bashing & WG Update 15 min Milestones Requirements Doc update Framework Doc update GIMPS: General Internet Messaging Protocol for Signaling=20 - Robert Hancock - 30 min Analysis document update=20 - Jukka Manner - 5 min Security Threats for NSIS doc update=20 - Hannes Tschofenig - 5 min RSVP Security Properties doc update=20 - Hannes Tschofenig - 5 min THURSDAY, November 13, 2003 0900-1130 Morning Sessions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Agenda bashing & WG Update=20 - chair - 10 min NSLP for Quality-of-Service signaling=20 - Sven van den Bosch - 30 min A NAT/Firewall NSIS Signaling Layer Protocol=20 - Hannes Tschofenig or Martin Stiemerling - 30 min NATFW NSLP security issues and solution - Martin/Miquel Martin or Hannes Tschofenig - 10 min NATFW NSLP migration considerations - Cedric Aoun - 10 min NSIS Mobility discussion=20 - Open - 30 min Closing & discussion=20 - chair - 10 min Reading Material WG drafts http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-0= 3.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-0= 3.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-03.txt Individual submissions http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw-migration-= 00.txt=20 http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-01.txt http://www.ietf.org/internet-drafts/draft-lee-nsis-mobility-nslp-00.txt http://www.ietf.org/internet-drafts/draft-luu-ntlp-con-imp-00.txt http://www.ietf.org/internet-drafts/draft-jeong-nsis-mobility-ntlp-00.txt= http://www.ietf.org/internet-drafts/draft-martin-nsis-nslp-security-00.tx= t http://www.ietf.org/internet-drafts/draft-martin-nsis-nslp-natfw-security= -00.txt http://www.ietf.org/internet-drafts/draft-tschofenig-rsvp-doi-01.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Nov 7 11:39:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21346 for ; Fri, 7 Nov 2003 11:39:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9dW-0007mi-DJ for nsis-archive@odin.ietf.org; Fri, 07 Nov 2003 11:39:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Gd2Me029920 for nsis-archive@odin.ietf.org; Fri, 7 Nov 2003 11:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9dV-0007m8-TM; Fri, 07 Nov 2003 11:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9dM-0007lo-Qh for nsis@optimus.ietf.org; Fri, 07 Nov 2003 11:38:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21317 for ; Fri, 7 Nov 2003 11:38:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9dL-0007IL-00 for nsis@ietf.org; Fri, 07 Nov 2003 11:38:51 -0500 Received: from ponyexpress.ee.columbia.edu ([128.59.64.61] ident=[pmqk9gUtdZXcllzJ5iWBq35i8Zn2wdZH]) by ietf-mx with esmtp (Exim 4.12) id 1AI9dL-0007IH-00 for nsis@ietf.org; Fri, 07 Nov 2003 11:38:51 -0500 Received: from president (bus84-091.gsb.columbia.edu [128.59.84.91]) (authenticated bits=0) by ponyexpress.ee.columbia.edu (8.12.8/8.12.1) with ESMTP id hA7GbtaU018517 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 7 Nov 2003 11:37:59 -0500 From: "Charles Q. Shen" To: "'Xiaoming Fu'" , "'Hancock, Robert'" Cc: "'Paulo Mendes'" , "'Jukka MJ Manner'" , Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Fri, 7 Nov 2003 11:38:36 -0500 Organization: Columbia University Message-ID: <000101c3a54d$9b4549a0$5b543b80@president> 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.2616 Importance: Normal In-Reply-To: <3FAB5727.8080000@cs.uni-goettingen.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Xiaoming, > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > Behalf Of Xiaoming Fu ... > > > Robert, Paulo, Jukka, and all, > > Hancock, Robert wrote: > > hi paulo, jukka, > > > > IMHO we have to consider routing, mobility and multihoming > together. > > the overlap between any two is (in undefined units, of > course) about > > 75%; doing them separately will not help consistency in the > long run. > > Seeking an accurate corelation factor might go for > mathematical models > :-) I do see the relationship between routing, mobility and > multihome is > incoherent in some sense. However, if we look at IP mobility > protocols > (which is suggested by the current charter), this > relationship might be > less strong as you expected. > > - Generally, a soft state signaling protocol needs to react to route > change and node failures in "best-effort" IP networks (in this sense > RSVP which precedes NSIS have presented a good way in regards that; > infrequent route change can be discerned by RSVP/routing > interface and > repaired by local repair anyway). > Without the need for a strict mathematical model, we can still see a relationship that IMHO deserves a coherent approach to these three mechanisms (routing, mobility and multihoming). The most notable difference among them is probably whether the flow identity has changed. But whatever is the case, a common result is a changed session path. This makes it neat to analyze them together, especially when considering the topology and the downstream/upstream cross-over routers. Even in the pure route change case, there could still be tricky issues about identification of the right cross-over router. Best regards, Charles _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Nov 7 12:13:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23099 for ; Fri, 7 Nov 2003 12:13:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAAQ-0001DC-43 for nsis-archive@odin.ietf.org; Fri, 07 Nov 2003 12:13:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7HD2wi004637 for nsis-archive@odin.ietf.org; Fri, 7 Nov 2003 12:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAAP-0001Cd-E2; Fri, 07 Nov 2003 12:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIA9V-0001AX-T6 for nsis@optimus.ietf.org; Fri, 07 Nov 2003 12:12: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 MAA22755 for ; Fri, 7 Nov 2003 12:11:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIA9U-0007gF-00 for nsis@ietf.org; Fri, 07 Nov 2003 12:12:04 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AIA9U-0007gC-00 for nsis@ietf.org; Fri, 07 Nov 2003 12:12:04 -0500 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Fri, 07 Nov 2003 18:12:12 +0100 Message-ID: <3FABD25C.60501@cs.uni-goettingen.de> Date: Fri, 07 Nov 2003 18:11:56 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles Q. Shen" CC: "'Hancock, Robert'" , "'Paulo Mendes'" , "'Jukka MJ Manner'" , nsis@ietf.org Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 References: <000101c3a54d$9b4549a0$5b543b80@president> In-Reply-To: <000101c3a54d$9b4549a0$5b543b80@president> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Charles, > Without the need for a strict mathematical model, we can still see a > relationship that IMHO deserves a coherent approach to these three > mechanisms (routing, mobility and multihoming). The most notable > difference among them is probably whether the flow identity has changed. > But whatever is the case, a common result is a changed session path. > This makes it neat to analyze them together, especially when considering > the topology and the downstream/upstream cross-over routers. Even in the > pure route change case, there could still be tricky issues about > identification of the right cross-over router. > I don't know whether a universal flow id is necessary at NTLP level for routing of NSIS packets. Essentially, if one node has NTLP state table (which can include session ID, Previous NE, Next NE and possibly, src. & dest. info. - not necessary details regarding the data flow), it should enough for NTLP to route any NSIS packets matching an item in this table, if not, discovery component should be able to find out Next NE. Identifying a crossover router can be based on a matching of session ID as well. Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Nov 8 06:23:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13197 for ; Sat, 8 Nov 2003 06:23:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIRBK-0001GY-K5 for nsis-archive@odin.ietf.org; Sat, 08 Nov 2003 06:23:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8BN62R004862 for nsis-archive@odin.ietf.org; Sat, 8 Nov 2003 06:23:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIRBF-0001Fy-0t; Sat, 08 Nov 2003 06:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIRAo-0001FH-3o for nsis@optimus.ietf.org; Sat, 08 Nov 2003 06:22: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 GAA13187 for ; Sat, 8 Nov 2003 06:22:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIRAk-0005WX-00 for nsis@ietf.org; Sat, 08 Nov 2003 06:22:30 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AIRAj-0005WU-00 for nsis@ietf.org; Sat, 08 Nov 2003 06:22:29 -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 hA8BMRpn013206; Sat, 8 Nov 2003 12:22:27 +0100 (MET) Message-ID: <013f01c3a5ea$9862fbe0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: Cc: References: Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Sat, 8 Nov 2003 12:22:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 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 Mobility is handled in other IETF working groups. I think that this WG should not try to find mobility solutions, but indeed it should look to ways of how the NSIS protocols could interoperate with existing (under development by other working groups) mobility approaches. Best Regards, Georgios ----- Original Message ----- From: To: ; Cc: Sent: Friday, November 07, 2003 9:13 AM Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 > Hi all, > > Just a point of procedure. Currently, NSIS does not have an explicit charter > item about handling mobility. The charter does discuss mobility to some > extent, and it is assumed that the NSIS work needs to be mobility friendly. > However, if you are interested in going beyond that, we will need to get > approval for this from our ADs. > > Ultimately, I'd like to split mobility into two pieces: > > 1) Ensuring mobility does not break the NSLPs & NTLP. This means that our > initial solution may not be completely optimized for mobility, but > it won't break in the presence of mobility. > > 2) Longer term mobility optimization & support. This would be a possible new > item for NSIS to consider, which would explicitly deal with how we could > deal with mobility extentions, etc. This work is currently outside of the > charter, but if there is enough support in the WG, it is possible to ask > for an extension to the NSIS charter to handle this. > > What I am looking for at the Minneapolis meeting is to have a general discussion > along the lines of the 2 points above and gage if there is interest in this work. > If there is, then I'd suggest that the interested parties get together after > Minneapolis and work out a combined analysis/discussion/approach wrt to mobilty > submit and individual submission. After this is done, we can see if extending > the charter would be reasonable or not. > > Please note that the NTLP, NSLP protocols are already underway so I don't want > to insert a new dependency on completing these protocols. > > thanks, > John > > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of ext Paulo Mendes > Sent: 06 November, 2003 17:11 > To: Jukka MJ Manner > Cc: nsis@ietf.org > Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 > > > Hi Jukka, > > I also agree that something has to be done about the mobility-related drafts, since they have overlapping issues. However, I'm not convinced right now that analyzing mobility, multihoming and routing changes in the draft will lead us to a simpler document, complying with the KISS principle. To start from, because IMO the mobility issue by itself is already very complex, as we tried to show in our analysis draft. > However, I think that we need to start working on the mobility issues that overlap in the presented drafts to achieve the goal of understanding how can NSIS be extended to mobile environments. For instance, I saw that your draft as a more general definition of crossover router. > Hence, I agree with Robert when he says "I think we are talking about here is analysis work which will feed into defining the functionality that is required in the basic NSIS protocols themselves". This is, I agree that we must not include by now any discussion about how to implement any particular solution. > > I don't see why shouldn't we work in a mobility analysis draft and a multihoming analysis draft (by nature these are two different things). If after this analysis (divide to conquer principle :)), we realize that a common solution can be achieved, than we should work in a common solution draft. If not, just continue in separate ways. > In what concerns routing changes, if they are due to the movement of end-hosts, this topic is naturally included in the mobility analysis. However, IMO routing changes "in the interior of the network", for instance due to load balancing and link failure, should be considered in the basic NSIS, since they do not happen only in mobile environments. > > I tend to disagree with you in what concerns the open issues. If you do not identify open issues by now you will have to do it late. Besides, an efficient solution for mobility within NSIS needs to be aware of open issues if it wants to be the next step in signaling. From the issues mentioned, resource discovery has to do also with the e2e new path and not only with the new access network. Only the latter is done by CARD. In what concerns pre-reservations, you have to deal with this sooner or latter if you want to get good quality levels for multimedia applications while moving. I'm not saying that this is easy or not, or that it should be included in NSIS. I'm just saying that this is an open issue. > > In what concerns Minneapolis: > - Agree that the authors of the different drafts should meet in Minneapolis for further discussion (unfortunately I cannot attend this IETF meeting). This discussion should be extended to this mailing list. > - About the presentations, probably it is a little late to get a consensus among authors in order to make a efficient join presentation, but I think that if this could be done, it would be most profitable. > > Cheers, > Paulo > > Jukka MJ Manner wrote: > > Hi, > > I basically try to look at things with the KISS principle, and my initial > assumptions are that mobility, routing, and multi-homing have much in > common once we think about them properly and with an open mind. I wouldn't > want to have several different documents discussing NTLP+NSLP and specific > scenarios. Of course, it might happen that we end up realizing that > certain issues are too complex and need their own documents. Still, I > would start with the mentioned issues and see from there. > > Regards, > Jukka > > > On Thu, 6 Nov 2003, Xiaoming Fu wrote: > > > Hi John, Jukka, > > It would be nice that we work together a single document regarding > mobility and move things on. I also agree that mobility concerns with > route change and tunneling; is it a little too overloaded for this > document to cover general routing, multi-homing or general tunnel issues > as well? > > (Unfortunately I will be not able to attend the Minneapolis meeting due > to personal reasons. However, I am interested in this work and would > like to participate in the discussions through emails.) > > Best regards, > Xiaoming > > john.loughney@nokia.com wrote: > > Hi Jukka, > > > > The authors of the various mobility drafts listed by John could meet in > Minneapolis, e.g. on Sunday, after the reception, to discuss these issues > before the actual NSIS WG meetings. We could, for example, try to agree on > an initial set of issues to discuss in the draft, and assign responsible > section editors, and an overall editor. > > I fully support this. If this is acceptable, then the results could > be discussed at the NSIS meeting. I think this is a much better > use of time, then presenting overlapping individual documents. > > Does anyone else have any comments on this? > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > -- > Paulo Mendes > DoCoMo Communications Laboratories Europe GmbH > Landsberger Str. 312 > 80687 Munich, Germany > Tel. +49-89-56824-226 > Fax. +49-89-56824-300 > E-mail: mendes@docomolab-euro.com > http://www.docomoeurolabs.de/ > > _______________________________________________ > 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 Sat Nov 8 19:25:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02429 for ; Sat, 8 Nov 2003 19:25:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIdO4-0005jg-5m for nsis-archive@odin.ietf.org; Sat, 08 Nov 2003 19:25:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA90P40Y022008 for nsis-archive@odin.ietf.org; Sat, 8 Nov 2003 19:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIdO2-0005id-Qk; Sat, 08 Nov 2003 19:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIdNB-0005ho-Ah for nsis@optimus.ietf.org; Sat, 08 Nov 2003 19:24:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02378 for ; Sat, 8 Nov 2003 19:23: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 1AIdN9-0007G9-00 for nsis@ietf.org; Sat, 08 Nov 2003 19:24:07 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AIdN8-0007G5-00 for nsis@ietf.org; Sat, 08 Nov 2003 19:24:06 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA90O6A12739 for ; Sun, 9 Nov 2003 02:24:06 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 9 Nov 2003 02:24:02 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 02:24:06 +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: Sun, 9 Nov 2003 02:24:06 +0200 Message-ID: Thread-Topic: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Thread-Index: AcOlC3MA++dshZQIS1mh57FInloUZQBB39KA To: X-OriginalArrivalTime: 09 Nov 2003 00:24:06.0838 (UTC) FILETIME=[C96F3560:01C3A657] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] WG Secretary Sender: nsis-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, Hannes Tschofenig has volunteered to be the WG Secretary. I need to = check the formalities with the relevant area directors, but I wanted to = announce this already. Thanks Hannes! John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Nov 8 20:36:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02428 for ; Sat, 8 Nov 2003 19:25:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIdO4-0005jf-5V for nsis-archive@odin.ietf.org; Sat, 08 Nov 2003 19:25:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA90P4kk022011 for nsis-archive@odin.ietf.org; Sat, 8 Nov 2003 19:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIdO3-0005io-8t; Sat, 08 Nov 2003 19:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIdNB-0005ht-Gl for nsis@optimus.ietf.org; Sat, 08 Nov 2003 19:24:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02381 for ; Sat, 8 Nov 2003 19:23: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 1AIdN9-0007GC-00 for nsis@ietf.org; Sat, 08 Nov 2003 19:24:07 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AIdN9-0007G6-00 for nsis@ietf.org; Sat, 08 Nov 2003 19:24:07 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by manatick with esmtp (Exim 4.24) id 1AIdNA-0001VX-FU for nsis@ietf.org; Sat, 08 Nov 2003 19:24:08 -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 hA90O5e02423 for ; Sun, 9 Nov 2003 02:24:05 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 9 Nov 2003 02:24:05 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 02:24:05 +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: Sun, 9 Nov 2003 02:24:05 +0200 Message-ID: Thread-Topic: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Thread-Index: AcOlC3MA++dshZQIS1mh57FInloUZQBB2Gjw X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 09 Nov 2003 00:24:05.0443 (UTC) FILETIME=[C89A5930:01C3A657] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] ATTN all presenters Sender: nsis-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, Could you send me your slidesets asap. I would like to post them before = the meeting. thanks John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Nov 8 21:27:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04366 for ; Sat, 8 Nov 2003 21:27:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfIB-0001WS-Cp for nsis-archive@odin.ietf.org; Sat, 08 Nov 2003 21:27:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA92R7gI005849 for nsis-archive@odin.ietf.org; Sat, 8 Nov 2003 21:27:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfI5-0001Va-Np; Sat, 08 Nov 2003 21:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfHW-0001Uc-Go for nsis@optimus.ietf.org; Sat, 08 Nov 2003 21:26:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04333 for ; Sat, 8 Nov 2003 21:26:14 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIfHT-0000p8-00 for nsis@ietf.org; Sat, 08 Nov 2003 21:26:23 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AIfHS-0000p0-00 for nsis@ietf.org; Sat, 08 Nov 2003 21:26:23 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA92QKA28071 for ; Sun, 9 Nov 2003 04:26:20 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 04:26:19 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 9 Nov 2003 04:26:19 +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: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Sun, 9 Nov 2003 04:26:19 +0200 Message-ID: Thread-Topic: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Thread-Index: AcOl6pqbx1T9xtPXRD6KcGijxbb7uQAffK3Q To: Cc: X-OriginalArrivalTime: 09 Nov 2003 02:26:19.0480 (UTC) FILETIME=[DC079580:01C3A668] 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 Georgios, > Mobility is handled in other IETF working groups. > I think that this WG should not try to find mobility solutions,=20 Noone is suggesting that NSIS work on mobility solutions. In fact, it is explicitly out of scope for NSIS to work on mobility solutions. > but indeed it should look to ways of how the NSIS protocols > could interoperate with existing (under development by other=20 > working groups) mobility approaches. I believe that is what I said we should do. I am unsure if you are trying to say anything more. John > Best Regards, > Georgios >=20 >=20 > ----- Original Message ----- > From: > To: ; > Cc: > Sent: Friday, November 07, 2003 9:13 AM > Subject: RE: Issues splitting/consensus - Re: [NSIS] Details=20 > about NSIS at > IETF 58 >=20 >=20 > > Hi all, > > > > Just a point of procedure. Currently, NSIS does not have=20 > an explicit > charter > > item about handling mobility. The charter does discuss=20 > mobility to some > > extent, and it is assumed that the NSIS work needs to be mobility > friendly. > > However, if you are interested in going beyond that, we=20 > will need to get > > approval for this from our ADs. > > > > Ultimately, I'd like to split mobility into two pieces: > > > > 1) Ensuring mobility does not break the NSLPs & NTLP. This=20 > means that our > > initial solution may not be completely optimized for=20 > mobility, but > > it won't break in the presence of mobility. > > > > 2) Longer term mobility optimization & support. This would=20 > be a possible > new > > item for NSIS to consider, which would explicitly deal=20 > with how we > could > > deal with mobility extentions, etc. This work is=20 > currently outside of > the > > charter, but if there is enough support in the WG, it is=20 > possible to > ask > > for an extension to the NSIS charter to handle this. > > > > What I am looking for at the Minneapolis meeting is to have=20 > a general > discussion > > along the lines of the 2 points above and gage if there is=20 > interest in > this work. > > If there is, then I'd suggest that the interested parties=20 > get together > after > > Minneapolis and work out a combined=20 > analysis/discussion/approach wrt to > mobilty > > submit and individual submission. After this is done, we can see if > extending > > the charter would be reasonable or not. > > > > Please note that the NTLP, NSLP protocols are already=20 > underway so I don't > want > > to insert a new dependency on completing these protocols. > > > > thanks, > > John > > > > -----Original Message----- > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On=20 > Behalf Of ext > Paulo Mendes > > Sent: 06 November, 2003 17:11 > > To: Jukka MJ Manner > > Cc: nsis@ietf.org > > Subject: Re: Issues splitting/consensus - Re: [NSIS]=20 > Details about NSIS at > IETF 58 > > > > > > Hi Jukka, > > > > I also agree that something has to be done about the=20 > mobility-related > drafts, since they have overlapping issues. However, I'm not=20 > convinced right > now that analyzing mobility, multihoming and routing changes=20 > in the draft > will lead us to a simpler document, complying with the KISS=20 > principle. To > start from, because IMO the mobility issue by itself is already very > complex, as we tried to show in our analysis draft. > > However, I think that we need to start working on the=20 > mobility issues that > overlap in the presented drafts to achieve the goal of=20 > understanding how can > NSIS be extended to mobile environments. For instance, I saw=20 > that your draft > as a more general definition of crossover router. > > Hence, I agree with Robert when he says "I think we are=20 > talking about here > is analysis work which will feed into defining the=20 > functionality that is > required in the basic NSIS protocols themselves". This is, I=20 > agree that we > must not include by now any discussion about how to implement=20 > any particular > solution. > > > > I don't see why shouldn't we work in a mobility analysis draft and a > multihoming analysis draft (by nature these are two different=20 > things). If > after this analysis (divide to conquer principle :)), we=20 > realize that a > common solution can be achieved, than we should work in a=20 > common solution > draft. If not, just continue in separate ways. > > In what concerns routing changes, if they are due to the movement of > end-hosts, this topic is naturally included in the mobility analysis. > However, IMO routing changes "in the interior of the=20 > network", for instance > due to load balancing and link failure, should be considered=20 > in the basic > NSIS, since they do not happen only in mobile environments. > > > > I tend to disagree with you in what concerns the open=20 > issues. If you do > not identify open issues by now you will have to do it late.=20 > Besides, an > efficient solution for mobility within NSIS needs to be aware=20 > of open issues > if it wants to be the next step in signaling. From the issues=20 > mentioned, > resource discovery has to do also with the e2e new path and=20 > not only with > the new access network. Only the latter is done by CARD. In=20 > what concerns > pre-reservations, you have to deal with this sooner or latter=20 > if you want to > get good quality levels for multimedia applications while=20 > moving. I'm not > saying that this is easy or not, or that it should be=20 > included in NSIS. I'm > just saying that this is an open issue. > > > > In what concerns Minneapolis: > > - Agree that the authors of the different drafts should meet in > Minneapolis for further discussion (unfortunately I cannot=20 > attend this IETF > meeting). This discussion should be extended to this mailing list. > > - About the presentations, probably it is a little late to=20 > get a consensus > among authors in order to make a efficient join presentation,=20 > but I think > that if this could be done, it would be most profitable. > > > > Cheers, > > Paulo > > > > Jukka MJ Manner wrote: > > > > Hi, > > > > I basically try to look at things with the KISS principle,=20 > and my initial > > assumptions are that mobility, routing, and multi-homing=20 > have much in > > common once we think about them properly and with an open=20 > mind. I wouldn't > > want to have several different documents discussing=20 > NTLP+NSLP and specific > > scenarios. Of course, it might happen that we end up realizing that > > certain issues are too complex and need their own=20 > documents. Still, I > > would start with the mentioned issues and see from there. > > > > Regards, > > Jukka > > > > > > On Thu, 6 Nov 2003, Xiaoming Fu wrote: > > > > > > Hi John, Jukka, > > > > It would be nice that we work together a single document regarding > > mobility and move things on. I also agree that mobility=20 > concerns with > > route change and tunneling; is it a little too overloaded for this > > document to cover general routing, multi-homing or general=20 > tunnel issues > > as well? > > > > (Unfortunately I will be not able to attend the Minneapolis=20 > meeting due > > to personal reasons. However, I am interested in this work and would > > like to participate in the discussions through emails.) > > > > Best regards, > > Xiaoming > > > > john.loughney@nokia.com wrote: > > > > Hi Jukka, > > > > > > > > The authors of the various mobility drafts listed by John=20 > could meet in > > Minneapolis, e.g. on Sunday, after the reception, to=20 > discuss these issues > > before the actual NSIS WG meetings. We could, for example,=20 > try to agree on > > an initial set of issues to discuss in the draft, and=20 > assign responsible > > section editors, and an overall editor. > > > > I fully support this. If this is acceptable, then the results could > > be discussed at the NSIS meeting. I think this is a much better > > use of time, then presenting overlapping individual documents. > > > > Does anyone else have any comments on this? > > > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > -- > > Paulo Mendes > > DoCoMo Communications Laboratories Europe GmbH > > Landsberger Str. 312 > > 80687 Munich, Germany > > Tel. +49-89-56824-226 > > Fax. +49-89-56824-300 > > E-mail: mendes@docomolab-euro.com > > http://www.docomoeurolabs.de/ > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Nov 9 09:37:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29361 for ; Sun, 9 Nov 2003 09:37: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 1AIqgg-0004rt-H1 for nsis-archive@odin.ietf.org; Sun, 09 Nov 2003 09:37:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9EbA6W018694 for nsis-archive@odin.ietf.org; Sun, 9 Nov 2003 09:37:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqgZ-0004o4-Bo; Sun, 09 Nov 2003 09:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqgF-0004mM-94 for nsis@optimus.ietf.org; Sun, 09 Nov 2003 09:36:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29330 for ; Sun, 9 Nov 2003 09:36:29 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqgD-0001sw-00 for nsis@ietf.org; Sun, 09 Nov 2003 09:36:41 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AIqgC-0001ss-00 for nsis@ietf.org; Sun, 09 Nov 2003 09:36:40 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9EacA22980 for ; Sun, 9 Nov 2003 16:36:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 9 Nov 2003 16:36:38 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 9 Nov 2003 16:36:37 +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: Sun, 9 Nov 2003 16:36:36 +0200 Message-ID: Thread-Topic: ID Tracker State Update Notice: draft-ietf-nsis-req Thread-Index: AcOmlf+33bUL47hrRAmMAfGWPpr08QAONueA To: X-OriginalArrivalTime: 09 Nov 2003 14:36:37.0445 (UTC) FILETIME=[E1926F50:01C3A6CE] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] FW: ID Tracker State Update Notice: draft-ietf-nsis-req Sender: nsis-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 FYI: 'State Changes to IESG Evaluation::AD Followup from IESG = Evaluation::Revised ID Needed by Allison Mankin' ID Tracker URL: = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D8432&rfc_flag=3D0 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Nov 9 13:29:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05572 for ; Sun, 9 Nov 2003 13:29:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuJ5-0005UQ-Gu for nsis-archive@odin.ietf.org; Sun, 09 Nov 2003 13:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9IT30d021098 for nsis-archive@odin.ietf.org; Sun, 9 Nov 2003 13:29:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuJ3-0005Ty-JR; Sun, 09 Nov 2003 13:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuIM-0005TR-Ci for nsis@optimus.ietf.org; Sun, 09 Nov 2003 13:28: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 NAA05532 for ; Sun, 9 Nov 2003 13:28:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuIK-00050D-00 for nsis@ietf.org; Sun, 09 Nov 2003 13:28:16 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AIuIJ-000508-00 for nsis@ietf.org; Sun, 09 Nov 2003 13:28:15 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AIuIC-0001JK-00; Sun, 09 Nov 2003 19:28:08 +0100 Received: from i72ms1.tm.uni-karlsruhe.de ([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 1AIuIB-00031d-00; Sun, 09 Nov 2003 19:28:07 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=i72mn12.tm.uka.de ident=3010) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1AIuI9-00043a-00; Sun, 09 Nov 2003 19:28:05 +0100 Date: Sun, 9 Nov 2003 19:28:26 +0100 From: Roland Bless To: john.loughney@nokia.com Cc: , , Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Message-Id: <20031109192826.24c0f82a.bless@tm.uka.de> In-Reply-To: References: Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John, On Fri, 7 Nov 2003 10:13:08 +0200 john.loughney@nokia.com wrote: > Just a point of procedure. Currently, NSIS does not have an explicit charter > item about handling mobility. The charter does discuss mobility to some > extent, and it is assumed that the NSIS work needs to be mobility friendly. > However, if you are interested in going beyond that, we will need to get > approval for this from our ADs. > > Ultimately, I'd like to split mobility into two pieces: > > 1) Ensuring mobility does not break the NSLPs & NTLP. This means that our > initial solution may not be completely optimized for mobility, but > it won't break in the presence of mobility. > 2) Longer term mobility optimization & support. This would be a possible new > item for NSIS to consider, which would explicitly deal with how we could > deal with mobility extentions, etc. This work is currently outside of the > charter, but if there is enough support in the WG, it is possible to ask > for an extension to the NSIS charter to handle this. Both points sound very reasonable, IMHO. While there is a whole bunch of optimizations possible, ensuring that things will not break should be easier. > Please note that the NTLP, NSLP protocols are already underway so I don't want > to insert a new dependency on completing these protocols. Sure, however, mobility issues should be considered to the necessary extent you mentioned in 1). Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Nov 9 15:02:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07859 for ; Sun, 9 Nov 2003 15:02:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIvl6-0001qD-Jg for nsis-archive@odin.ietf.org; Sun, 09 Nov 2003 15:02:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9K248Q007058 for nsis-archive@odin.ietf.org; Sun, 9 Nov 2003 15:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIvl4-0001pO-2a; Sun, 09 Nov 2003 15:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIvkL-0001p3-Ca for nsis@optimus.ietf.org; Sun, 09 Nov 2003 15:01: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 PAA07851 for ; Sun, 9 Nov 2003 15:01:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIvkI-0006KH-00 for nsis@ietf.org; Sun, 09 Nov 2003 15:01:14 -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 1AIvkH-0006KE-00 for nsis@ietf.org; Sun, 09 Nov 2003 15:01:13 -0500 Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Sun, 09 Nov 2003 22:01:10 +0200 Date: Sun, 9 Nov 2003 22:01:09 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Next Steps in NSIS Mobility Discussions Sender: nsis-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 here in Minneapolis, I would suggest that people interested in discussing issues and dependencies related to mobility/routing/multihoming management with NSIS could gather after the reception at 7PM at the Registration desk. We could try to see what we all have in common and what would be the next steps in getting the NSIS protocols ready to do mobility in the "right" way. Initially, we could try to continue e.g. on with breakfast meeting on Tuesday? Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Nov 9 15:41:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09929 for ; Sun, 9 Nov 2003 15:41:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwMo-0003wX-Gm for nsis-archive@odin.ietf.org; Sun, 09 Nov 2003 15:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9Kf23H015145 for nsis-archive@odin.ietf.org; Sun, 9 Nov 2003 15:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwMn-0003wA-UM; Sun, 09 Nov 2003 15:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwMU-0003vc-Pd for nsis@optimus.ietf.org; Sun, 09 Nov 2003 15:40:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09910 for ; Sun, 9 Nov 2003 15:40:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIwMT-0006lQ-00 for nsis@ietf.org; Sun, 09 Nov 2003 15:40:41 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AIwMS-0006lI-00 for nsis@ietf.org; Sun, 09 Nov 2003 15:40:40 -0500 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with ESMTP id hA9KeZpn007365; Sun, 9 Nov 2003 21:40:35 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.9) with ESMTP id hA9KeYFx003381; Sun, 9 Nov 2003 21:40:34 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7+Sun/8.10.2) id hA9KeYJ03337; Sun, 9 Nov 2003 21:40:34 +0100 (MET) Date: Sun, 9 Nov 2003 21:40:34 +0100 (MET) Message-Id: <200311092040.hA9KeYJ03337@janus.cs.utwente.nl> X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian using -f To: john.loughney@nokia.com Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Received: from 130.129.80.6 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 09 Nov 2003 20:40:34 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.10 (On: webmail.cs.utwente.nl) In-Reply-To: From: karagiannis Bounce-To: karagiannis CC: "nsis@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John Thus your proposal for "Long term mobility optimization and support" it does not imply mobility support. Best Regards, Georgios On 11/9/2003, "john.loughney@nokia.com" wrote: >Georgios, > >> Mobility is handled in other IETF working groups. >> I think that this WG should not try to find mobility solutions, > >Noone is suggesting that NSIS work on mobility solutions. In fact, >it is explicitly out of scope for NSIS to work on mobility solutions. > >> but indeed it should look to ways of how the NSIS protocols >> could interoperate with existing (under development by other >> working groups) mobility approaches. > >I believe that is what I said we should do. I am unsure if you >are trying to say anything more. > >John > >> Best Regards, >> Georgios >> >> >> ----- Original Message ----- >> From: >> To: ; >> Cc: >> Sent: Friday, November 07, 2003 9:13 AM >> Subject: RE: Issues splitting/consensus - Re: [NSIS] Details >> about NSIS at >> IETF 58 >> >> >> > Hi all, >> > >> > Just a point of procedure. Currently, NSIS does not have >> an explicit >> charter >> > item about handling mobility. The charter does discuss >> mobility to some >> > extent, and it is assumed that the NSIS work needs to be mobility >> friendly. >> > However, if you are interested in going beyond that, we >> will need to get >> > approval for this from our ADs. >> > >> > Ultimately, I'd like to split mobility into two pieces: >> > >> > 1) Ensuring mobility does not break the NSLPs & NTLP. This >> means that our >> > initial solution may not be completely optimized for >> mobility, but >> > it won't break in the presence of mobility. >> > >> > 2) Longer term mobility optimization & support. This would >> be a possible >> new >> > item for NSIS to consider, which would explicitly deal >> with how we >> could >> > deal with mobility extentions, etc. This work is >> currently outside of >> the >> > charter, but if there is enough support in the WG, it is >> possible to >> ask >> > for an extension to the NSIS charter to handle this. >> > >> > What I am looking for at the Minneapolis meeting is to have >> a general >> discussion >> > along the lines of the 2 points above and gage if there is >> interest in >> this work. >> > If there is, then I'd suggest that the interested parties >> get together >> after >> > Minneapolis and work out a combined >> analysis/discussion/approach wrt to >> mobilty >> > submit and individual submission. After this is done, we can see if >> extending >> > the charter would be reasonable or not. >> > >> > Please note that the NTLP, NSLP protocols are already >> underway so I don't >> want >> > to insert a new dependency on completing these protocols. >> > >> > thanks, >> > John >> > >> > -----Original Message----- >> > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On >> Behalf Of ext >> Paulo Mendes >> > Sent: 06 November, 2003 17:11 >> > To: Jukka MJ Manner >> > Cc: nsis@ietf.org >> > Subject: Re: Issues splitting/consensus - Re: [NSIS] >> Details about NSIS at >> IETF 58 >> > >> > >> > Hi Jukka, >> > >> > I also agree that something has to be done about the >> mobility-related >> drafts, since they have overlapping issues. However, I'm not >> convinced right >> now that analyzing mobility, multihoming and routing changes >> in the draft >> will lead us to a simpler document, complying with the KISS >> principle. To >> start from, because IMO the mobility issue by itself is already very >> complex, as we tried to show in our analysis draft. >> > However, I think that we need to start working on the >> mobility issues that >> overlap in the presented drafts to achieve the goal of >> understanding how can >> NSIS be extended to mobile environments. For instance, I saw >> that your draft >> as a more general definition of crossover router. >> > Hence, I agree with Robert when he says "I think we are >> talking about here >> is analysis work which will feed into defining the >> functionality that is >> required in the basic NSIS protocols themselves". This is, I >> agree that we >> must not include by now any discussion about how to implement >> any particular >> solution. >> > >> > I don't see why shouldn't we work in a mobility analysis draft and a >> multihoming analysis draft (by nature these are two different >> things). If >> after this analysis (divide to conquer principle :)), we >> realize that a >> common solution can be achieved, than we should work in a >> common solution >> draft. If not, just continue in separate ways. >> > In what concerns routing changes, if they are due to the movement of >> end-hosts, this topic is naturally included in the mobility analysis. >> However, IMO routing changes "in the interior of the >> network", for instance >> due to load balancing and link failure, should be considered >> in the basic >> NSIS, since they do not happen only in mobile environments. >> > >> > I tend to disagree with you in what concerns the open >> issues. If you do >> not identify open issues by now you will have to do it late. >> Besides, an >> efficient solution for mobility within NSIS needs to be aware >> of open issues >> if it wants to be the next step in signaling. From the issues >> mentioned, >> resource discovery has to do also with the e2e new path and >> not only with >> the new access network. Only the latter is done by CARD. In >> what concerns >> pre-reservations, you have to deal with this sooner or latter >> if you want to >> get good quality levels for multimedia applications while >> moving. I'm not >> saying that this is easy or not, or that it should be >> included in NSIS. I'm >> just saying that this is an open issue. >> > >> > In what concerns Minneapolis: >> > - Agree that the authors of the different drafts should meet in >> Minneapolis for further discussion (unfortunately I cannot >> attend this IETF >> meeting). This discussion should be extended to this mailing list. >> > - About the presentations, probably it is a little late to >> get a consensus >> among authors in order to make a efficient join presentation, >> but I think >> that if this could be done, it would be most profitable. >> > >> > Cheers, >> > Paulo >> > >> > Jukka MJ Manner wrote: >> > >> > Hi, >> > >> > I basically try to look at things with the KISS principle, >> and my initial >> > assumptions are that mobility, routing, and multi-homing >> have much in >> > common once we think about them properly and with an open >> mind. I wouldn't >> > want to have several different documents discussing >> NTLP+NSLP and specific >> > scenarios. Of course, it might happen that we end up realizing that >> > certain issues are too complex and need their own >> documents. Still, I >> > would start with the mentioned issues and see from there. >> > >> > Regards, >> > Jukka >> > >> > >> > On Thu, 6 Nov 2003, Xiaoming Fu wrote: >> > >> > >> > Hi John, Jukka, >> > >> > It would be nice that we work together a single document regarding >> > mobility and move things on. I also agree that mobility >> concerns with >> > route change and tunneling; is it a little too overloaded for this >> > document to cover general routing, multi-homing or general >> tunnel issues >> > as well? >> > >> > (Unfortunately I will be not able to attend the Minneapolis >> meeting due >> > to personal reasons. However, I am interested in this work and would >> > like to participate in the discussions through emails.) >> > >> > Best regards, >> > Xiaoming >> > >> > john.loughney@nokia.com wrote: >> > >> > Hi Jukka, >> > >> > >> > >> > The authors of the various mobility drafts listed by John >> could meet in >> > Minneapolis, e.g. on Sunday, after the reception, to >> discuss these issues >> > before the actual NSIS WG meetings. We could, for example, >> try to agree on >> > an initial set of issues to discuss in the draft, and >> assign responsible >> > section editors, and an overall editor. >> > >> > I fully support this. If this is acceptable, then the results could >> > be discussed at the NSIS meeting. I think this is a much better >> > use of time, then presenting overlapping individual documents. >> > >> > Does anyone else have any comments on this? >> > >> > John >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> > >> > >> > >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> > >> > >> > >> > >> > >> > -- >> > Paulo Mendes >> > DoCoMo Communications Laboratories Europe GmbH >> > Landsberger Str. 312 >> > 80687 Munich, Germany >> > Tel. +49-89-56824-226 >> > Fax. +49-89-56824-300 >> > E-mail: mendes@docomolab-euro.com >> > http://www.docomoeurolabs.de/ >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> > >> >> Dr. ir. Georgios Karagiannis Group: Design and Analysis of Communication Systems (DACS) University of Twente The Netherlands _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Nov 9 16:46:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11624 for ; Sun, 9 Nov 2003 16:46:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxNi-0007ls-VD for nsis-archive@odin.ietf.org; Sun, 09 Nov 2003 16:46:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9Lk2EF029866 for nsis-archive@odin.ietf.org; Sun, 9 Nov 2003 16:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxNi-0007lb-CS; Sun, 09 Nov 2003 16:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxNG-0007kv-7G for nsis@optimus.ietf.org; Sun, 09 Nov 2003 16:45: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 QAA11605 for ; Sun, 9 Nov 2003 16:45:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxNE-0007hb-00 for nsis@ietf.org; Sun, 09 Nov 2003 16:45:32 -0500 Received: from delicious.ietf58.ietf.org ([130.129.16.24]) by ietf-mx with esmtp (Exim 4.12) id 1AIxND-0007hY-00 for nsis@ietf.org; Sun, 09 Nov 2003 16:45:31 -0500 Received: from starsu (starsu.ietf58.ietf.org [130.129.133.225]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hA9LjTKg028142; Sun, 9 Nov 2003 15:45:30 -0600 (CST) Message-ID: <000801c3a642$2e58f4e0$e1858182@starsu> From: "Sung-Hyuck Lee" To: Cc: Subject: RE: [NSIS] Next Steps in NSIS Mobility Discussions Date: Sat, 8 Nov 2003 15:49:25 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C3A60F.E2F345A0" 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 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C3A60F.E2F345A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgSnVra2EsDQoNClNvdW5kcyBsaWtlIGdvb2QgaWRlYS4NCg0KUmVnYXJkcywNCg0KU3VuZy1I eXVjaw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpKdWtrYSB3cm90ZToNCg0KSGkg YWxsIGhlcmUgaW4gTWlubmVhcG9saXMsDQoNCkkgd291bGQgc3VnZ2VzdCB0aGF0IHBlb3BsZSBp bnRlcmVzdGVkIGluIGRpc2N1c3NpbmcgaXNzdWVzIGFuZA0KZGVwZW5kZW5jaWVzIHJlbGF0ZWQg dG8gbW9iaWxpdHkvcm91dGluZy9tdWx0aWhvbWluZyBtYW5hZ2VtZW50IHdpdGggTlNJUw0KY291 bGQgZ2F0aGVyIGFmdGVyIHRoZSByZWNlcHRpb24gYXQgN1BNIGF0IHRoZSBSZWdpc3RyYXRpb24g ZGVzay4gV2UgY291bGQNCnRyeSB0byBzZWUgd2hhdCB3ZSBhbGwgaGF2ZSBpbiBjb21tb24gYW5k IHdoYXQgd291bGQgYmUgdGhlIG5leHQgc3RlcHMgaW4NCmdldHRpbmcgdGhlIE5TSVMgcHJvdG9j b2xzIHJlYWR5IHRvIGRvIG1vYmlsaXR5IGluIHRoZSAicmlnaHQiIHdheS4NCg0KSW5pdGlhbGx5 LCB3ZSBjb3VsZCB0cnkgdG8gY29udGludWUgZS5nLiBvbiB3aXRoIGJyZWFrZmFzdCBtZWV0aW5n IG9uDQpUdWVzZGF5Pw0KDQoNClJlZ2FyZHMsDQpKdWtrYQ0K ------=_NextPart_000_0005_01C3A60F.E2F345A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMTA2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SGkgSnVra2EsPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+U291bmRzIGxpa2UgZ29vZCBpZGVhLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlJlZ2FyZHMs PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+U3VuZy1IeXVjazwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgDQpzaXplPTI+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+SnVra2Egd3JvdGU6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj5IaSBhbGwgaGVyZSBpbiBNaW5uZWFwb2xpcyw8QlI+PEJSPkkg d291bGQgc3VnZ2VzdCB0aGF0IHBlb3BsZSBpbnRlcmVzdGVkIA0KaW4gZGlzY3Vzc2luZyBpc3N1 ZXMgYW5kPEJSPmRlcGVuZGVuY2llcyByZWxhdGVkIHRvIG1vYmlsaXR5L3JvdXRpbmcvbXVsdGlo b21pbmcgDQptYW5hZ2VtZW50IHdpdGggTlNJUzxCUj5jb3VsZCBnYXRoZXIgYWZ0ZXIgdGhlIHJl Y2VwdGlvbiBhdCA3UE0gYXQgdGhlIA0KUmVnaXN0cmF0aW9uIGRlc2suIFdlIGNvdWxkPEJSPnRy eSB0byBzZWUgd2hhdCB3ZSBhbGwgaGF2ZSBpbiBjb21tb24gYW5kIHdoYXQgDQp3b3VsZCBiZSB0 aGUgbmV4dCBzdGVwcyBpbjxCUj5nZXR0aW5nIHRoZSBOU0lTIHByb3RvY29scyByZWFkeSB0byBk byBtb2JpbGl0eSBpbiANCnRoZSAicmlnaHQiIHdheS48QlI+PEJSPkluaXRpYWxseSwgd2UgY291 bGQgdHJ5IHRvIGNvbnRpbnVlIGUuZy4gb24gd2l0aCANCmJyZWFrZmFzdCBtZWV0aW5nIA0Kb248 QlI+VHVlc2RheT88QlI+PEJSPjxCUj5SZWdhcmRzLDxCUj5KdWtrYTxCUj48L0RJVj48L0JPRFk+ PC9IVE1MPg0K ------=_NextPart_000_0005_01C3A60F.E2F345A0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Nov 9 18:01:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16659 for ; Sun, 9 Nov 2003 18:01:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyYK-0005JS-09 for nsis-archive@odin.ietf.org; Sun, 09 Nov 2003 18:01:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9N13rr020403 for nsis-archive@odin.ietf.org; Sun, 9 Nov 2003 18:01:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyYI-0005In-RC; Sun, 09 Nov 2003 18:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyXh-0005Hu-NG for nsis@optimus.ietf.org; Sun, 09 Nov 2003 18:00: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 SAA16580 for ; Sun, 9 Nov 2003 18:00:10 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyXe-0001UV-00 for nsis@ietf.org; Sun, 09 Nov 2003 18:00:22 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AIyXe-0001UQ-00 for nsis@ietf.org; Sun, 09 Nov 2003 18:00:22 -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 hA9N0Le27007 for ; Mon, 10 Nov 2003 01:00:22 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 01:00:21 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 01:00:21 +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: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Date: Mon, 10 Nov 2003 01:00:21 +0200 Message-ID: Thread-Topic: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58 Thread-Index: AcOnAb7DLnU1fkZgQFSMb0KPX/qPWQAE2tUQ To: Cc: X-OriginalArrivalTime: 09 Nov 2003 23:00:21.0404 (UTC) FILETIME=[407495C0:01C3A715] 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 Georgios, > Thus your proposal for > "Long term mobility optimization and support" it does not imply > mobility support. I'm sorry, but I still don't understand your point. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 10 09:54:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21675 for ; Mon, 10 Nov 2003 09:54:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDQb-0008Ef-Eo for nsis-archive@odin.ietf.org; Mon, 10 Nov 2003 09:54:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAEs5X1031653 for nsis-archive@odin.ietf.org; Mon, 10 Nov 2003 09:54:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDQX-0008E3-8o; Mon, 10 Nov 2003 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 1AJDPk-0008DL-CX for nsis@optimus.ietf.org; Mon, 10 Nov 2003 09:53:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21618 for ; Mon, 10 Nov 2003 09:52:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJDPi-0005Sn-00 for nsis@ietf.org; Mon, 10 Nov 2003 09:53:10 -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 1AJDPh-0005Sj-00 for nsis@ietf.org; Mon, 10 Nov 2003 09:53:09 -0500 Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 10 Nov 2003 16:53:03 +0200 Date: Mon, 10 Nov 2003 16:53:03 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Feedback from the "mobility in NSIS" meeting Sender: nsis-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, Here a list of issues that I collected from the various NSIS+mobility drafts, and which we agreed on during our meeting on Sunday evening. There were roughly ten people present. This list IS NOT a) an extensive list of all issues, b) a table of contents for a future working group draft, c) a proposal for a new protocol to be designed and/or to compete with the NSIS NTLP/NSLP work, and d) a proposal to split the work done in NSIS into some basic functions and mobility-specific functions. The list MAY be used to write a draft that a) analysis the implications of mobility/routing/multihoming (MoRoMu) on the work within NSIS, b) gives guidelines on how to include support for the MoRoMu issues into NTLP/NSLPs, c) helps in deciding how functions should be split between NTLP and NSLPs, d) documents the current understanding of the interactions of mobility and resource signaling, and e) gives guidelines for designers of new NSLP protocols. Now that the background for the list is made clear (?), here is the list. This could be used as a list of items to discuss during the timeslot on Thursday. The people present during the Sunday evening meeting agreed to meet Wednesday morning at 8.30 AM around the registration desk and see what have been the comments on the NSIS mailing list and what should be done for the Thursday NSIS meeting. Regards, Jukka -------------------------------------------------------------------------------- Basic Issues ------------ - Differences between the general route change (not related to mobility) and mobility-caused route change, when a) when IP addresses change (end host or next peer) b) when IP addresses do not change - How to discover crossover router, when a) the cross-over router exists by the definition in RSVP, that is, the same session is identified on a new interface b) the cross-over router does not exist in the previous way, that is, new messages for an existing session arrive from a new peer through the old interface c) other nodes than the cross-over router affect the signaling (The cross-over router discovery is most important when the mobile node is receiver) - How to set up states on the new path and teardown old states on the obsolete path? When is the "old" path not needed? - State update on the common path after handover - Interactions with mobility protocols such as MIP and LMM protocols - Interactions with CT and CARD, e.g. a) to perform a make-before-break handover with resource set up b) to query (not reserve) for resources on a possible new path from a CAR - Dependencies between the NTLP and NSLP and split of functionality between layers - Security issues: implications of the authorization model - Dead peer and dead cross-over router discovery Not in the initial scope aka. "Grey area" ----------------------------------------- - Refresh timer decisions hop-by-hop? Are these any different from individual "ordinary" hop-by-hop timers? - Issues with mobility protocols using tunneling? Is this any different from "common" tunneling elsewhere in the network? - Multicast: (single) source-specific with homogeneous receivers? Is this so much different from multi-homing support? - Optimized support for specific topologies, e.g. symmetric routes and bi-directional reservations? - Support for mobile networks? This sounds like a specific optimization? - Session modifications caused by changes in the network, e.g. pre-emptive QoS allocation, re-routing leading to charging issues? Out of scope of this work ------------------------- - Specific implementation details (generic guidelines for making something work would be in scope) - Mobility (routing) management - Handover management (NTLP/NSLP state management in scope) - Evaluating the movement of end hosts and finding candidate access routers/access points - Multicast without limits (this is why RSVP is so complex) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 10 18:01:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19403 for ; Mon, 10 Nov 2003 18:01:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJL1r-0004FY-QT for nsis-archive@odin.ietf.org; Mon, 10 Nov 2003 18:01:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAN13eZ016282 for nsis-archive@odin.ietf.org; Mon, 10 Nov 2003 18:01:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJL1p-0004Dj-LN; Mon, 10 Nov 2003 18: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 1AJL1U-0004Cw-Cx for nsis@optimus.ietf.org; Mon, 10 Nov 2003 18:00: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 SAA19356 for ; Mon, 10 Nov 2003 18:00:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJL1R-0006n2-00 for nsis@ietf.org; Mon, 10 Nov 2003 18:00:37 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AJL1Q-0006mv-00 for nsis@ietf.org; Mon, 10 Nov 2003 18:00:36 -0500 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 11 Nov 2003 00:00:46 +0100 Message-ID: <3FB01887.40400@cs.uni-goettingen.de> Date: Tue, 11 Nov 2003 00:00:23 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'nsis@ietf.org '" CC: Dieter Hogrefe , Sebastian Willert , Fabian Meyer Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] CASP implementation Sender: nsis-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, We made version 0.1.0 of our experimental CASP implementation available for public. Current version supports messaging most layer functionalities, both static and active next-peer discovery (scout). Constraints and open issues of this version are given in the README. If somebody is interested, have a look at: http://user.informatik.uni-goettingen.de/~casp/ Your feedbacks, suggestions are very appreciated. Best regards, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 10 18:50:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23938 for ; Mon, 10 Nov 2003 18:50:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLnH-0007u2-F8 for nsis-archive@odin.ietf.org; Mon, 10 Nov 2003 18:50:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAANo332030347 for nsis-archive@odin.ietf.org; Mon, 10 Nov 2003 18:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLnH-0007tM-56; Mon, 10 Nov 2003 18:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLn4-0007su-4c for nsis@optimus.ietf.org; Mon, 10 Nov 2003 18:49:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23867 for ; Mon, 10 Nov 2003 18:49:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLn0-00009S-00 for nsis@ietf.org; Mon, 10 Nov 2003 18:49: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 1AJLn0-00009L-00 for nsis@ietf.org; Mon, 10 Nov 2003 18:49:46 -0500 Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 11 Nov 2003 01:49:46 +0200 Date: Tue, 11 Nov 2003 01:49:46 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Open issue 1 in NTLP draft: Protocol Naming Sender: nsis-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, Keeping with typical naming within the IETF, how about "Signaling Transport Protocol (STP)" Short and simple. Cheers, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 10 21:56:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01577 for ; Mon, 10 Nov 2003 21:56:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOhH-0001R9-Px for nsis-archive@odin.ietf.org; Mon, 10 Nov 2003 21:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB2u302005499 for nsis-archive@odin.ietf.org; Mon, 10 Nov 2003 21: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 1AJOhH-0001QK-21; Mon, 10 Nov 2003 21:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOhA-0001P5-58 for nsis@optimus.ietf.org; Mon, 10 Nov 2003 21:55: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 VAA01551 for ; Mon, 10 Nov 2003 21:55:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOh7-0003KI-00 for nsis@ietf.org; Mon, 10 Nov 2003 21:55:53 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AJOh6-0003KF-00 for nsis@ietf.org; Mon, 10 Nov 2003 21:55:52 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAB2sxme028108; Mon, 10 Nov 2003 21:55:00 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hAB2swf25958; Mon, 10 Nov 2003 21:54:59 -0500 Message-ID: <3FB04F88.60906@cs.columbia.edu> Date: Mon, 10 Nov 2003 21:55:04 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner CC: nsis@ietf.org Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Already taken in the SS7 context (signaling transfer point). Jukka MJ Manner wrote: > Hi, > > Keeping with typical naming within the IETF, how about > > "Signaling Transport Protocol (STP)" > > Short and simple. > > Cheers, > Jukka > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 10 22:50:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03261 for ; Mon, 10 Nov 2003 22:50:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPXX-0004u9-0D for nsis-archive@odin.ietf.org; Mon, 10 Nov 2003 22:50:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB3o2xG018850 for nsis-archive@odin.ietf.org; Mon, 10 Nov 2003 22:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPXW-0004tt-L9; Mon, 10 Nov 2003 22:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPX5-0004tN-Fc for nsis@optimus.ietf.org; Mon, 10 Nov 2003 22:49:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03239 for ; Mon, 10 Nov 2003 22:49:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPX1-0003xJ-00 for nsis@ietf.org; Mon, 10 Nov 2003 22:49:31 -0500 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AJPX1-0003xG-00 for nsis@ietf.org; Mon, 10 Nov 2003 22:49:31 -0500 Received: from n-pool-3.office (dyn134-139.ietf58.ietf.org [130.129.134.139]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 9C8E710378 for ; Tue, 11 Nov 2003 04:53:55 +0100 (CET) Date: Mon, 10 Nov 2003 21:49:28 -0600 From: Marcus Brunner Reply-To: Marcus Brunner To: nsis@ietf.org Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting Message-ID: <59304575.1068500968@dyn134-139.ietf58.ietf.org> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 > Basic Issues > ------------ > > - Differences between the general route change (not related to mobility) > and mobility-caused route change, when > a) when IP addresses change (end host or next peer) > b) when IP addresses do not change > So what is the difference? > - How to discover crossover router, when First question: what do you need the crossover router for? What functionality is special on the crossover router? > a) the cross-over router exists by the definition in RSVP, that is, the > same session is identified on a new interface > b) the cross-over router does not exist in the previous way, that is, > new messages for an existing session arrive from a new peer through > the old interface > c) other nodes than the cross-over router affect the signaling > (The cross-over router discovery is most important when the mobile node > is receiver) > > - State update on the common path after handover > I would assume this is NSLP dependent > - Interactions with mobility protocols such as MIP and LMM protocols > IMHO there is no interworking needed with MIP except that MIP might want to use NSIS. [...] > - Dependencies between the NTLP and NSLP and split of functionality > between layers > Can you an example where the split might be different when looking into mobile versus static networks. > - Security issues: implications of the authorization model > What is different in the mobility case. > - Dead peer and dead cross-over router discovery > again why do you need to discover these? I assume peer maintance is part of the NTLP anyway. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 00:50:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07180 for ; Tue, 11 Nov 2003 00:50:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJRPg-0003S1-9c for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 00:50:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB5o48b013265 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 00:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJRPd-0003RV-Ow; Tue, 11 Nov 2003 00:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJRP5-0003Qm-Ul for nsis@optimus.ietf.org; Tue, 11 Nov 2003 00:49: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 AAA07174 for ; Tue, 11 Nov 2003 00:49:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJRP3-0005Ro-00 for nsis@ietf.org; Tue, 11 Nov 2003 00:49:25 -0500 Received: from ponyexpress.ee.columbia.edu ([128.59.64.61] ident=[Sb++/5K+1wzJjG4qwHB7zr22TsynTHTg]) by ietf-mx with esmtp (Exim 4.12) id 1AJRP2-0005Rl-00 for nsis@ietf.org; Tue, 11 Nov 2003 00:49:24 -0500 Received: from president (dyn-fair-240-205.dyn.columbia.edu [160.39.240.205]) (authenticated bits=0) by ponyexpress.ee.columbia.edu (8.12.8/8.12.1) with ESMTP id hAB5l2aU020362 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 11 Nov 2003 00:47:14 -0500 From: "Charles Q. Shen" To: "'Marcus Brunner'" , Subject: RE: [NSIS] Feedback from the "mobility in NSIS" meeting Date: Tue, 11 Nov 2003 00:47:58 -0500 Organization: Columbia University Message-ID: <000001c3a817$72feef10$cdf027a0@president> 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.2616 Importance: Normal In-Reply-To: <59304575.1068500968@dyn134-139.ietf58.ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Marcus, a few brief comments inline (marked with [cs]): > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > Behalf Of Marcus Brunner > Sent: Monday, November 10, 2003 10:49 PM > To: nsis@ietf.org > Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting > > > > > Basic Issues > > ------------ > > > > - Differences between the general route change (not related > to mobility) > > and mobility-caused route change, when > > a) when IP addresses change (end host or next peer) > > b) when IP addresses do not change > > > > So what is the difference? [cs] My understanding of the difference is: 1) the different causes of route change (eg. routing adaptation or mobility) 2) whether IP address change is associated with the route change or not > > > - How to discover crossover router, when > > First question: what do you need the crossover router for? What > functionality is special on the crossover router? > [cs] IMHO crossover router may at least help in optimizing the handling of route change events, e.g. certain local repair messages may initiate from or terminate at crossover routers. > > a) the cross-over router exists by the definition in > RSVP, that is, the > > same session is identified on a new interface > > b) the cross-over router does not exist in the previous > way, that is, > > new messages for an existing session arrive from a > new peer through > > the old interface > > c) other nodes than the cross-over router affect the > signaling (The > > cross-over router discovery is most important when the > mobile node is > > receiver) > > > > - State update on the common path after handover > > > > I would assume this is NSLP dependent > [cs] It could be helpful to define cross-over router as NSLP dependent. (instead of a pure topology-wise cross-over router) > > - Interactions with mobility protocols such as MIP and LMM protocols > > > > IMHO there is no interworking needed with MIP except that MIP > might want to > use NSIS. > > [...] > [cs] I suppose it is still a good idea to analyze the scenarios of MIP-NSIS working together, at least to ensure " NSIS won't break in the presence of mobility". > > - Dependencies between the NTLP and NSLP and split of functionality > > between layers > > > > Can you an example where the split might be different when > looking into > mobile versus static networks. > [cs] IMHO this is one potential area we might want to examine further. Thanks and regards, Charles > > - Security issues: implications of the authorization model > > > > What is different in the mobility case. > > > - Dead peer and dead cross-over router discovery > > > > again why do you need to discover these? I assume peer > maintance is part of > the NTLP anyway. > > Marcus > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/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 Tue Nov 11 09:17:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01839 for ; Tue, 11 Nov 2003 09:17:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZKM-0003VD-DS for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 09:17:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABEH6oA013460 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 09:17:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZKH-0003Ue-1s; Tue, 11 Nov 2003 09:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZJV-0003P8-DW for nsis@optimus.ietf.org; Tue, 11 Nov 2003 09:16:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01800 for ; Tue, 11 Nov 2003 09:15:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJZJS-0003aA-00 for nsis@ietf.org; Tue, 11 Nov 2003 09:16:10 -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 1AJZJR-0003a7-00 for nsis@ietf.org; Tue, 11 Nov 2003 09:16:09 -0500 Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 11 Nov 2003 16:16:08 +0200 Date: Tue, 11 Nov 2003 16:16:08 +0200 (EET) From: Jukka MJ Manner To: Marcus Brunner cc: nsis@ietf.org Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting In-Reply-To: <59304575.1068500968@dyn134-139.ietf58.ietf.org> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Marcus, replies inline. Jukka On Mon, 10 Nov 2003, Marcus Brunner wrote: > > > Basic Issues > > ------------ > > > > - Differences between the general route change (not related to mobility) > > and mobility-caused route change, when > > a) when IP addresses change (end host or next peer) > > b) when IP addresses do not change > > > > So what is the difference? [JM] Nothing, if you do things right, e.g. the session states are not identified with IP addresses (as in RSVP), but a generic ID as seems to be the case in the NTLP and NSLP design already. > > > - How to discover crossover router, when > > First question: what do you need the crossover router for? What > functionality is special on the crossover router? [JM] Read the line in paranthesis... when you are the receiver and you move, the new path starts at the cross-over router. This is where the local repair starts. > > > a) the cross-over router exists by the definition in RSVP, that is, the > > same session is identified on a new interface > > b) the cross-over router does not exist in the previous way, that is, > > new messages for an existing session arrive from a new peer through > > the old interface > > c) other nodes than the cross-over router affect the signaling > > (The cross-over router discovery is most important when the mobile node > > is receiver) > > > > - State update on the common path after handover > > > > I would assume this is NSLP dependent [JM] May be, may be not... don't know the clear answer, yet > > > - Interactions with mobility protocols such as MIP and LMM protocols > > > > IMHO there is no interworking needed with MIP except that MIP might want to > use NSIS. [JM] To me NSIS and MIPv6 and Fast Handovers have something in common, as CARD and CT have. Also, how would MIPv4 work with NSIS with CoAs and CCoAs, tunneling, and possible triangular routing. What if CN and MN are actually in the same network? Any changes to make things more efficient aka. optimize? (yes, I know, someone will soon tell not to focus on optimizations at this stage... but it might we worthwhile to at least document some ideas?) > > - Dependencies between the NTLP and NSLP and split of functionality > > between layers > > > > Can you an example where the split might be different when looking into > mobile versus static networks. [JM] No, not yet. Probably some issues related to who triggers who and when and why and what messages are then send, when a mobility event occurs and states need to be managed. > > > - Security issues: implications of the authorization model > > > > What is different in the mobility case. [JM] A more dynamic environment, not all peers remain, who is who, who is the signaling initiator? > > > - Dead peer and dead cross-over router discovery > > > > again why do you need to discover these? I assume peer maintance is part of > the NTLP anyway. [JM] Already answered to the cross-over router issue, discovery of dead peers is also related to mobility and path changes. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 09:25:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02036 for ; Tue, 11 Nov 2003 09:25:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZS2-0003jP-Lh for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 09:25:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABEP25o014319 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 09:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZS1-0003in-TA; Tue, 11 Nov 2003 09:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZRW-0003gZ-Ak for nsis@optimus.ietf.org; Tue, 11 Nov 2003 09:24: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 JAA02033 for ; Tue, 11 Nov 2003 09:24:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJZRU-0003fE-00 for nsis@ietf.org; Tue, 11 Nov 2003 09:24:28 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AJZRT-0003f7-00 for nsis@ietf.org; Tue, 11 Nov 2003 09:24:27 -0500 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 11 Nov 2003 15:24:36 +0100 Message-ID: <3FB0F113.9000400@cs.uni-goettingen.de> Date: Tue, 11 Nov 2003 15:24:19 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles Q. Shen" CC: "'Marcus Brunner'" , nsis@ietf.org Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting References: <000001c3a817$72feef10$cdf027a0@president> In-Reply-To: <000001c3a817$72feef10$cdf027a0@president> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, A few comments inline: Charles Q. Shen wrote: > Hi Marcus, a few brief comments inline (marked with [cs]): > >>>- Differences between the general route change (not related to mobility) >>> and mobility-caused route change, when >>> a) when IP addresses change (end host or next peer) >>> b) when IP addresses do not change >> >>So what is the difference? > > [cs] My understanding of the difference is: > 1) the different causes of route change (eg. routing adaptation or > mobility) > 2) whether IP address change is associated with the route change or not > Note there are some topology change cases, even with mobility, the IP address does not change. For example, in HMIP, it is possible the source address of a packet sent from the MN to the CN can be RCoA, even its LCoA is changed. >>>- State update on the common path after handover >>> >>I would assume this is NSLP dependent >> > [cs] It could be helpful to define cross-over router as NSLP dependent. > (instead of a pure topology-wise cross-over router) > Basically, if one wants to refresh the NSLP state in the common path, for example from the cross-over router to the CN (for the upstreaming direction), there are two possibilities: either the cross-over router is NSLP aware, and let its NSLP to refresh along the path; or let NTLP to refresh along the path, while triggering associated NSLP(s) in each NSIS hop while the NTLP refresh. However, the implication needs to be further studied. One issue concern with the first way is possible multiple NSLPs, then it may need several times of NSLP refresh upon a mobility event; the second way needs a clear NTLP/NSLP interface. Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 09:49:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02803 for ; Tue, 11 Nov 2003 09:49:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZpF-00057O-9F for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 09:49:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABEn1um019655 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 09:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZpE-00056u-So; Tue, 11 Nov 2003 09: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 1AJZoG-00051D-O9 for nsis@optimus.ietf.org; Tue, 11 Nov 2003 09:48:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02735 for ; Tue, 11 Nov 2003 09:47:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJZoE-0003yn-00 for nsis@ietf.org; Tue, 11 Nov 2003 09:47:58 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AJZoD-0003yg-00 for nsis@ietf.org; Tue, 11 Nov 2003 09:47:58 -0500 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 11 Nov 2003 15:48:06 +0100 Message-ID: <3FB0F694.3090804@cs.uni-goettingen.de> Date: Tue, 11 Nov 2003 15:47:48 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner CC: nsis@ietf.org Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Jukka, Great we have something going on. Nice work! These issues IMO is quite well summarized in the list (actually most, if not all, issues we've discussed in various ocassions: NSIS-list, I-Ds, etc.:-); it is now a good time for the WG to decide whether/how to have a working group document on these issues), and I do think this list would be helpful for studying the implications of mobility on the work within NSIS. Can you tell how mobility matters from normal handling of general routing/multihoming elsewhere in the sense of NSIS? Cheers, Xiaoming Jukka MJ Manner wrote: > Dear all, > > Here a list of issues that I collected from the various NSIS+mobility > drafts, and which we agreed on during our meeting on Sunday evening. > There were roughly ten people present. > > This list IS NOT > a) an extensive list of all issues, > b) a table of contents for a future working group draft, > c) a proposal for a new protocol to be designed and/or to compete with > the NSIS NTLP/NSLP work, and > d) a proposal to split the work done in NSIS into some basic functions > and mobility-specific functions. > > The list MAY be used to write a draft that > > a) analysis the implications of mobility/routing/multihoming (MoRoMu) on the > work within NSIS, > b) gives guidelines on how to include support for the MoRoMu issues into > NTLP/NSLPs, > c) helps in deciding how functions should be split between NTLP and NSLPs, > d) documents the current understanding of the interactions of mobility and > resource signaling, and > e) gives guidelines for designers of new NSLP protocols. > > > Now that the background for the list is made clear (?), here is the > list. This could be used as a list of items to discuss during the > timeslot on Thursday. The people present during the Sunday evening > meeting agreed to meet Wednesday morning at 8.30 AM around the > registration desk and see what have been the comments on the NSIS > mailing list and what should be done for the Thursday NSIS meeting. > > Regards, > Jukka > > > -------------------------------------------------------------------------------- > > Basic Issues > ------------ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 10:00:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03225 for ; Tue, 11 Nov 2003 10:00: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 1AJa03-0005hx-FD for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:00:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABF0BiX021920 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:00:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZzw-0005gV-EF; Tue, 11 Nov 2003 10:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZzk-0005ay-O6 for nsis@optimus.ietf.org; Tue, 11 Nov 2003 09:59:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03163 for ; Tue, 11 Nov 2003 09:59:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJZzi-00047U-00 for nsis@ietf.org; Tue, 11 Nov 2003 09:59:50 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AJZzi-00047R-00 for nsis@ietf.org; Tue, 11 Nov 2003 09:59:50 -0500 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 11 Nov 2003 15:59:58 +0100 Message-ID: <3FB0F95C.2050709@cs.uni-goettingen.de> Date: Tue, 11 Nov 2003 15:59:40 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Jukka MJ Manner , nsis@ietf.org Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming References: <3FB04F88.60906@cs.columbia.edu> In-Reply-To: <3FB04F88.60906@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, or CSMP - Common State Management/Messaging Protocol? Regards, Xiaoming Henning Schulzrinne wrote: > Already taken in the SS7 context (signaling transfer point). > > Jukka MJ Manner wrote: > >> Hi, >> >> Keeping with typical naming within the IETF, how about >> >> "Signaling Transport Protocol (STP)" >> >> Short and simple. >> >> Cheers, >> Jukka >> >> >> _______________________________________________ >> 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 -- Xiaoming Fu University of Goettingen, Telematics Group Lotzestr. 16-18, 37083 Goettingen, Germany Tel.+49-551-39 14411, Fax.+49-551-39 14403 http://www.ifi.informatik.uni-goettingen.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 10:21:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05208 for ; Tue, 11 Nov 2003 10:21:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaKH-0007H2-SQ for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:21:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABFL5hk027941 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:21:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaKE-0007Fq-3k; Tue, 11 Nov 2003 10:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaJU-0007Em-PD for nsis@optimus.ietf.org; Tue, 11 Nov 2003 10:20: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 KAA05158 for ; Tue, 11 Nov 2003 10:20:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJaJS-0004TX-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:20:14 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AJaJR-0004Sy-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:20:14 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Nov 2003 15:19:35 -0000 Message-ID: From: "Hancock, Robert" To: Xiaoming Fu , Henning Schulzrinne Cc: Jukka MJ Manner , nsis@ietf.org Subject: RE: [NSIS] Open issue 1 in NTLP draft: Protocol Naming Date: Tue, 11 Nov 2003 15:19:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , but: it doesn't do state management! (except for itself, which you could say about any protocol). r. > -----Original Message----- > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > Sent: Tuesday, November 11, 2003 09:00 > To: Henning Schulzrinne > Cc: Jukka MJ Manner; nsis@ietf.org > Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming > > > Hi, > > or CSMP - Common State Management/Messaging Protocol? > > Regards, > Xiaoming > Henning Schulzrinne wrote: > > Already taken in the SS7 context (signaling transfer point). > > > > Jukka MJ Manner wrote: > > > >> Hi, > >> > >> Keeping with typical naming within the IETF, how about > >> > >> "Signaling Transport Protocol (STP)" > >> > >> Short and simple. > >> > >> Cheers, > >> Jukka > >> > >> > >> _______________________________________________ > >> 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 > > -- > Xiaoming Fu > University of Goettingen, Telematics Group > Lotzestr. 16-18, 37083 Goettingen, Germany > Tel.+49-551-39 14411, Fax.+49-551-39 14403 > http://www.ifi.informatik.uni-goettingen.de > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 10:34:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06088 for ; Tue, 11 Nov 2003 10:34:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaWn-00086X-VK for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABFY13L031122 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaWn-00085i-EI; Tue, 11 Nov 2003 10:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaWj-00085P-4j for nsis@optimus.ietf.org; Tue, 11 Nov 2003 10:33: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 KAA06024 for ; Tue, 11 Nov 2003 10:33:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJaWg-0004lp-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:33:54 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AJaWg-0004lk-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:33:54 -0500 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 11 Nov 2003 16:34:02 +0100 Message-ID: <3FB10158.2030806@cs.uni-goettingen.de> Date: Tue, 11 Nov 2003 16:33:44 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: Henning Schulzrinne , Jukka MJ Manner , nsis@ietf.org Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yes, but if you don't have this common state, it falls into a flat arch - all state management protocols will have to do their own. It is just this common state & its management matters to serve for the common purposes for all signaling BTW - signaling is to establish certain soft or half-soft or hard state anyway. Reference: - R. Braden and B. Lindell, "A Two-Level Architecture for Internet Signaling", Internet draft, work in progress, Nov 2002. Xiaoming Hancock, Robert wrote: > but: > it doesn't do state management! > (except for itself, which you could say about any protocol). > > r. > > >>-----Original Message----- >>From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] >>Sent: Tuesday, November 11, 2003 09:00 >>To: Henning Schulzrinne >>Cc: Jukka MJ Manner; nsis@ietf.org >>Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming >> >> >>Hi, >> >>or CSMP - Common State Management/Messaging Protocol? >> >>Regards, >>Xiaoming >>Henning Schulzrinne wrote: >> >>>Already taken in the SS7 context (signaling transfer point). >>> >>>Jukka MJ Manner wrote: >>> >>> >>>>Hi, >>>> >>>>Keeping with typical naming within the IETF, how about >>>> >>>>"Signaling Transport Protocol (STP)" >>>> >>>>Short and simple. >>>> >>>>Cheers, >>>>Jukka >>>> >>>> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 10:47:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06499 for ; Tue, 11 Nov 2003 10:47:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJajN-0000ae-Qv for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:47:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABFl1N0002247 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJajN-0000a5-8f; Tue, 11 Nov 2003 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaiV-0000Yz-Mi for nsis@optimus.ietf.org; Tue, 11 Nov 2003 10:46: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 KAA06447 for ; Tue, 11 Nov 2003 10:45:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJaiT-0004ue-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:46:05 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AJaiS-0004rw-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:46:04 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Nov 2003 15:45:28 -0000 Message-ID: From: "Hancock, Robert" To: Xiaoming Fu Cc: nsis@ietf.org Subject: RE: [NSIS] Open issue 1 in NTLP draft: Protocol Naming Date: Tue, 11 Nov 2003 15:45:39 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , xiaoming, please say if you think the f/w section 3.2.5 (based in part on the content of a pair of 50 email threads earlier this year) is technically incorrect for some reason. i don't want to repeat all those arguments again. at the moment, we have a (provisional) decision on this, which we should use as the basis for our protocol work (unless there was some critical argument that got missed during the earlier discussion). thanks, r. > -----Original Message----- > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > Sent: Tuesday, November 11, 2003 09:34 > To: Hancock, Robert > Cc: Henning Schulzrinne; Jukka MJ Manner; nsis@ietf.org > Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming > > > Yes, but if you don't have this common state, it falls into a > flat arch > - all state management protocols will have to do their own. > > It is just this common state & its management matters to > serve for the > common purposes for all signaling > > BTW - signaling is to establish certain soft or half-soft or > hard state > anyway. > > Reference: > - R. Braden and B. Lindell, "A Two-Level Architecture for Internet > Signaling", Internet draft, work in progress, Nov 2002. > > Xiaoming > > Hancock, Robert wrote: > > but: > > it doesn't do state management! > > (except for itself, which you could say about any protocol). > > > > r. > > > > > >>-----Original Message----- > >>From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > >>Sent: Tuesday, November 11, 2003 09:00 > >>To: Henning Schulzrinne > >>Cc: Jukka MJ Manner; nsis@ietf.org > >>Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming > >> > >> > >>Hi, > >> > >>or CSMP - Common State Management/Messaging Protocol? > >> > >>Regards, > >>Xiaoming > >>Henning Schulzrinne wrote: > >> > >>>Already taken in the SS7 context (signaling transfer point). > >>> > >>>Jukka MJ Manner wrote: > >>> > >>> > >>>>Hi, > >>>> > >>>>Keeping with typical naming within the IETF, how about > >>>> > >>>>"Signaling Transport Protocol (STP)" > >>>> > >>>>Short and simple. > >>>> > >>>>Cheers, > >>>>Jukka > >>>> > >>>> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 10:51:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06660 for ; Tue, 11 Nov 2003 10:51:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJanI-0000pY-4S for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:51:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABFp4at003173 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:51:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJanH-0000oz-J1; Tue, 11 Nov 2003 10:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJamz-0000nD-Br for nsis@optimus.ietf.org; Tue, 11 Nov 2003 10:50:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06627 for ; Tue, 11 Nov 2003 10:50:31 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJamw-0004xg-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:50:42 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJamv-0004xY-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:50:42 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABFods09486 for ; Tue, 11 Nov 2003 17:50:39 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 17:50:39 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 17:50:39 +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] Open issue 1 in NTLP draft: Protocol Naming Date: Tue, 11 Nov 2003 17:50:39 +0200 Message-ID: Thread-Topic: [NSIS] Open issue 1 in NTLP draft: Protocol Naming Thread-Index: AcOoayBIDQfuNnz5Ssm5bSDRazUxWQAAGU6g To: , Cc: X-OriginalArrivalTime: 11 Nov 2003 15:50:39.0722 (UTC) FILETIME=[8E339CA0:01C3A86B] 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 agree with Robert on this. > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of ext > Hancock, Robert > Sent: 11 November, 2003 17:46 > To: Xiaoming Fu > Cc: nsis@ietf.org > Subject: RE: [NSIS] Open issue 1 in NTLP draft: Protocol Naming >=20 >=20 > xiaoming, >=20 > please say if you think the f/w section 3.2.5 (based in part > on the content of a pair of 50 email threads earlier this > year) is technically incorrect for some reason. >=20 > i don't want to repeat all those arguments again. at the > moment, we have a (provisional) decision on this, which we > should use as the basis for our protocol work (unless there > was some critical argument that got missed during the earlier > discussion). >=20 > thanks, >=20 > r. >=20 > > -----Original Message----- > > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > > Sent: Tuesday, November 11, 2003 09:34 > > To: Hancock, Robert > > Cc: Henning Schulzrinne; Jukka MJ Manner; nsis@ietf.org > > Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming > >=20 > >=20 > > Yes, but if you don't have this common state, it falls into a=20 > > flat arch=20 > > - all state management protocols will have to do their own. > >=20 > > It is just this common state & its management matters to=20 > > serve for the=20 > > common purposes for all signaling > >=20 > > BTW - signaling is to establish certain soft or half-soft or=20 > > hard state=20 > > anyway. > >=20 > > Reference: > > - R. Braden and B. Lindell, "A Two-Level Architecture for Internet=20 > > Signaling", Internet draft, work in progress, Nov 2002. > >=20 > > Xiaoming > >=20 > > Hancock, Robert wrote: > > > but:=20 > > > it doesn't do state management! > > > (except for itself, which you could say about any protocol). > > >=20 > > > r. > > >=20 > > >=20 > > >>-----Original Message----- > > >>From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > > >>Sent: Tuesday, November 11, 2003 09:00 > > >>To: Henning Schulzrinne > > >>Cc: Jukka MJ Manner; nsis@ietf.org > > >>Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming > > >> > > >> > > >>Hi, > > >> > > >>or CSMP - Common State Management/Messaging Protocol? > > >> > > >>Regards, > > >>Xiaoming > > >>Henning Schulzrinne wrote: > > >> > > >>>Already taken in the SS7 context (signaling transfer point). > > >>> > > >>>Jukka MJ Manner wrote: > > >>> > > >>> > > >>>>Hi, > > >>>> > > >>>>Keeping with typical naming within the IETF, how about > > >>>> > > >>>>"Signaling Transport Protocol (STP)" > > >>>> > > >>>>Short and simple. > > >>>> > > >>>>Cheers, > > >>>>Jukka > > >>>> > > >>>> > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 10:56:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06947 for ; Tue, 11 Nov 2003 10:56:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJas6-0001Jy-TI for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:56:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABFu2VW005032 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJas6-0001J1-D7; Tue, 11 Nov 2003 10: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 1AJarQ-0001G0-GJ for nsis@optimus.ietf.org; Tue, 11 Nov 2003 10:55:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06900 for ; Tue, 11 Nov 2003 10:55:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJarN-000517-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:55:18 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AJarN-000513-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:55:17 -0500 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 11 Nov 2003 16:55:26 +0100 Message-ID: <3FB1065B.10609@cs.uni-goettingen.de> Date: Tue, 11 Nov 2003 16:55:07 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, I fully agree to the statement there and have no objection to use framework as basis for protocols. On the contrary, if I understand it correctly, we're talking about the same technical point and the same conclusion. Cheers, Xiaoming Hancock, Robert wrote: > xiaoming, > > please say if you think the f/w section 3.2.5 (based in part > on the content of a pair of 50 email threads earlier this > year) is technically incorrect for some reason. > > i don't want to repeat all those arguments again. at the > moment, we have a (provisional) decision on this, which we > should use as the basis for our protocol work (unless there > was some critical argument that got missed during the earlier > discussion). > > thanks, > > r. > > >>-----Original Message----- >>From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] >>Sent: Tuesday, November 11, 2003 09:34 >>To: Hancock, Robert >>Cc: Henning Schulzrinne; Jukka MJ Manner; nsis@ietf.org >>Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming >> >> >>Yes, but if you don't have this common state, it falls into a >>flat arch >>- all state management protocols will have to do their own. >> >>It is just this common state & its management matters to >>serve for the >>common purposes for all signaling >> >>BTW - signaling is to establish certain soft or half-soft or >>hard state >>anyway. >> >>Reference: >>- R. Braden and B. Lindell, "A Two-Level Architecture for Internet >>Signaling", Internet draft, work in progress, Nov 2002. >> >>Xiaoming >> >>Hancock, Robert wrote: >> >>>but: >>>it doesn't do state management! >>>(except for itself, which you could say about any protocol). >>> >>>r. >>> >>> >>> >>>>-----Original Message----- >>>>From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] >>>>Sent: Tuesday, November 11, 2003 09:00 >>>>To: Henning Schulzrinne >>>>Cc: Jukka MJ Manner; nsis@ietf.org >>>>Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming >>>> >>>> >>>>Hi, >>>> >>>>or CSMP - Common State Management/Messaging Protocol? >>>> >>>>Regards, >>>>Xiaoming >>>>Henning Schulzrinne wrote: >>>> >>>> >>>>>Already taken in the SS7 context (signaling transfer point). >>>>> >>>>>Jukka MJ Manner wrote: >>>>> >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>>Keeping with typical naming within the IETF, how about >>>>>> >>>>>>"Signaling Transport Protocol (STP)" >>>>>> >>>>>>Short and simple. >>>>>> >>>>>>Cheers, >>>>>>Jukka >>>>>> >>>>>> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Xiaoming Fu University of Goettingen, Telematics Group Lotzestr. 16-18, 37083 Goettingen, Germany Tel.+49-551-39 14411, Fax.+49-551-39 14403 http://www.ifi.informatik.uni-goettingen.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 11:00:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07175 for ; Tue, 11 Nov 2003 11:00:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJavy-0001hJ-37 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 11:00:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABG019q006504 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 11:00:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJavx-0001go-Kb; Tue, 11 Nov 2003 11:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJav6-0001XX-77 for nsis@optimus.ietf.org; Tue, 11 Nov 2003 10:59: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 KAA07053 for ; Tue, 11 Nov 2003 10:58:54 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJav3-000545-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:59:05 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJav2-000542-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:59:04 -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 hABFx3s18604 for ; Tue, 11 Nov 2003 17:59:03 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 17:59:02 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Nov 2003 17:59:02 +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] NTLP draft Date: Tue, 11 Nov 2003 17:59:02 +0200 Message-ID: Thread-Topic: [NSIS] NTLP draft Thread-Index: AcOobF1mjkaJldXTRGybtovbZRuFCAAAC0ZA To: , , X-OriginalArrivalTime: 11 Nov 2003 15:59:02.0851 (UTC) FILETIME=[BA170130:01C3A86C] 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 Georgios, > 1) Is it possible to separate the datagram mode (unreliable mode) and > connection mode (reliable mode) > specifications in two separate protocol specifications (two RFCs)? No. We are making 1 NTLP RFC. > 2) Is it possible to use (in some scenarios) the datagram mode > end to end (without supporting the connection mode)? Please note that > this mode selection procedure > might be different than the one that you have described in the draft. > Of course, if a NSIS node along the path will not support > this mode then an error message might be reported to the=20 > signaling sender. > > 3) Why have you chosen in the datagram mode for UDP encapsulation > and not for "raw IP" encapsulation? >=20 > 4) It will be interesting if the Peer-Peer Tunelled Encapsulation > (Section 5.3.3) could be applied upstream and the "End-to-End = Tunnelled > Encapsulation" could be applied downstream. Is that possible? Perhaps Robert or Henning could address these technical issues. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 11:22:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07978 for ; Tue, 11 Nov 2003 11:22:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbHH-0003aY-P4 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 11:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGM3WJ013793 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 11: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 1AJbHF-0003a1-Ee; Tue, 11 Nov 2003 11: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 1AJbGu-0003ZH-MM for nsis@optimus.ietf.org; Tue, 11 Nov 2003 11:21:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07940 for ; Tue, 11 Nov 2003 11:21:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbGt-0005Me-00 for nsis@ietf.org; Tue, 11 Nov 2003 11:21:39 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AJbGt-0005MV-00 for nsis@ietf.org; Tue, 11 Nov 2003 11:21:39 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Nov 2003 16:21:07 -0000 Message-ID: From: "Hancock, Robert" To: john.loughney@nokia.com, karagian@cs.utwente.nl, nsis@ietf.org Subject: RE: [NSIS] NTLP draft Date: Tue, 11 Nov 2003 16:21:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi john, georgios, > > 1) Is it possible to separate the datagram mode (unreliable > mode) and > > connection mode (reliable mode) > > specifications in two separate protocol specifications (two RFCs)? > > No. We are making 1 NTLP RFC. even technically, it would IMHO not be a good idea. big chunks of the specification are common (e.g. message formats, routing state integrity threats, v4/v6 transition, tunnel interactions...) and connection mode requires datagram mode anyway. however, probably the (near lack of) interaction between these two modes could be better explained. > > > 2) Is it possible to use (in some scenarios) the datagram mode > > end to end (without supporting the connection mode)? Please note that > > this mode selection procedure > > might be different than the one that you have described in the draft. > > Of course, if a NSIS node along the path will not support > > this mode then an error message might be reported to the > > signaling sender. functionally, if no NTLP node along the path decides to use connection mode, then the datagram mode has been used end to end. i think we have to make hard decisions about deciding to make functionality optional which would then lead to more error conditions having to be signalled around. to take a specific example: only supporting datagram mode implies imposing a maximum NSLP message size. if that maximum size is imposed in the middle of the network, how is an NSLP at one edge (a) supposed to find out and (b) get messages through it? it would mean that every NSLP would have to be able to work in case connection mode was never present, in which case there probably isn't much point in having it (which may be what you are aiming at, of course!) > > > > 3) Why have you chosen in the datagram mode for UDP encapsulation > > and not for "raw IP" encapsulation? in broad functionality, i don't think there is much difference here between the two. the differences are in details: *) raw IP can allow interception on protocol number (or do we assume RAO anyway) *) UDP has a checksum which is nice (it's the same if you include the RSVPv1 header, of course) *) UDP will be easier to get through NSIS-unaware NATs (if we want to do this) *) some hosts can't easily do raw IP i/o (why RSVP allows UDP) *) some hosts can't access the IP TTL *unless* you do raw i/o (if we need to do this) *) and so on. i think we should aim to choose one option at this stage. on balance, the arguments for UDP seem stronger at the moment. there is minimal impact on the rest of the protocol high level design. > > > > 4) It will be interesting if the Peer-Peer Tunelled Encapsulation > > (Section 5.3.3) could be applied upstream and the > "End-to-End Tunnelled > > Encapsulation" could be applied downstream. Is that possible? that is possible. you don't have to use the same approach both directions (the 'return path' could also be raw). the e2e version can only be used downstream anyway. some people don't like either tunnel encapsulation anyway - this is all very open (and views are sought). > > Perhaps Robert or Henning could address these technical issues. we aim to please! r. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 11:26:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08257 for ; Tue, 11 Nov 2003 11:26:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbL9-0004AA-K3 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 11:26:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGQ3OI015963 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 11: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 1AJbL9-00049N-9l; Tue, 11 Nov 2003 11:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbKS-000426-FI for nsis@optimus.ietf.org; Tue, 11 Nov 2003 11:25:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08152 for ; Tue, 11 Nov 2003 11:25:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbKR-0005PW-00 for nsis@ietf.org; Tue, 11 Nov 2003 11:25:19 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AJbKQ-0005Oy-00 for nsis@ietf.org; Tue, 11 Nov 2003 11:25:18 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Nov 2003 16:24:47 -0000 Message-ID: From: "Hancock, Robert" To: Marcus Brunner , nsis@ietf.org Subject: RE: [NSIS] Feedback from the "mobility in NSIS" meeting Date: Tue, 11 Nov 2003 16:24:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Marcus, All your questions are reasonable, and I would say come into the category of "that's exactly what I would like a consensus draft to answer". Regardless of whether people want to use nsis protocols in a "mobile environment" (whatever that means) or not, we I think should have a broader expectation that the nsis protocols will get used in ways we haven't thought of yet. (That is, if they get used at all. If they don't, it doesn't really matter what we do right now.) Thinking about how we would attempt to use the protocols in stressful environments is one way to avoid building restrictive assumptions into the protocol design, and mobility etc. is a very good hothouse for doing this. I don't actually expect significant extra functionality is needed to handle any of these issues, certainly not in the NTLP anyway; indeed, the analysis might be a method for trimming down the set of possible designs (which we should all be grateful for). Exactly how this work should get managed, officially or otherwise, is another question. But the situation we have at the moment - where we have several drafts, which all have to be read very closely to determine whether they are asking for roughly the same thing or completely different things from the protocols - is not optimised for making best use of WG energy (or causing least confusion to the protocol design work). r. > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Monday, November 10, 2003 21:49 > To: nsis@ietf.org > Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting > > > > > Basic Issues > > ------------ > > > > - Differences between the general route change (not related > to mobility) > > and mobility-caused route change, when > > a) when IP addresses change (end host or next peer) > > b) when IP addresses do not change > > > > So what is the difference? > > > - How to discover crossover router, when > > First question: what do you need the crossover router for? What > functionality is special on the crossover router? > > > a) the cross-over router exists by the definition in > RSVP, that is, the > > same session is identified on a new interface > > b) the cross-over router does not exist in the previous > way, that is, > > new messages for an existing session arrive from a > new peer through > > the old interface > > c) other nodes than the cross-over router affect the signaling > > (The cross-over router discovery is most important when the > mobile node > > is receiver) > > > > - State update on the common path after handover > > > > I would assume this is NSLP dependent > > > - Interactions with mobility protocols such as MIP and LMM protocols > > > > IMHO there is no interworking needed with MIP except that MIP > might want to > use NSIS. > > [...] > > > - Dependencies between the NTLP and NSLP and split of functionality > > between layers > > > > Can you an example where the split might be different when > looking into > mobile versus static networks. > > > - Security issues: implications of the authorization model > > > > What is different in the mobility case. > > > - Dead peer and dead cross-over router discovery > > > > again why do you need to discover these? I assume peer > maintance is part of > the NTLP anyway. > > Marcus > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/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 Tue Nov 11 12:00:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06954 for ; Tue, 11 Nov 2003 10:56:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJas7-0001L3-Fn for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10:56:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABFu3x5005103 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 10: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 1AJas7-0001KA-6p; Tue, 11 Nov 2003 10:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJarl-0001Hz-7I for nsis@optimus.ietf.org; Tue, 11 Nov 2003 10:55: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 KAA06927 for ; Tue, 11 Nov 2003 10:55:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJari-00051N-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:55:38 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AJarh-00051K-00 for nsis@ietf.org; Tue, 11 Nov 2003 10:55:37 -0500 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with ESMTP id hABFtXpn028427; Tue, 11 Nov 2003 16:55:33 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.9) with ESMTP id hABFtWFx018859; Tue, 11 Nov 2003 16:55:32 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7+Sun/8.10.2) id hABFtWN10969; Tue, 11 Nov 2003 16:55:32 +0100 (MET) Date: Tue, 11 Nov 2003 16:55:32 +0100 (MET) Message-Id: <200311111555.hABFtWN10969@janus.cs.utwente.nl> X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian using -f To: robert.hancock@roke.co.uk, nsis@ietf.org Subject: Re: [NSIS] NTLP draft Received: from 130.129.80.7 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 11 Nov 2003 15:55:32 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.10 (On: webmail.cs.utwente.nl) In-Reply-To: From: karagiannis Bounce-To: karagiannis MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: nsis-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 and Henning Thank you very much for the hard work! I have some questions related to the draft: 1) Is it possible to separate the datagram mode (unreliable mode) and connection mode (reliable mode) specifications in two separate protocol specifications (two RFCs)? 2) Is it possible to use (in some scenarios) the datagram mode end to end (without supporting the connection mode)? Please note that this mode selection procedure might be different than the one that you have described in the draft. Of course, if a NSIS node along the path will not support this mode then an error message might be reported to the signaling sender. 3) Why have you chosen in the datagram mode for UDP encapsulation and not for "raw IP" encapsulation? 4) It will be interesting if the Peer-Peer Tunelled Encapsulation (Section 5.3.3) could be applied upstream and the "End-to-End Tunnelled Encapsulation" could be applied downstream. Is that possible? Best Regards, Georgios On 10/23/2003, "Hancock, Robert" wrote: >Dear all, > >You will (I hope) be pleased to know that there is now a >wg -00 NTLP draft. While it works through the i-d editor >queue, you can find a copy at > >http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-00.txt > >This can be seen as a development of the ideas in the drafts >that were presented in Vienna and the subsequent discussion >(actually, it is still called GIMPS but the name is actually >the first in the list of open issues). > >The main point is that the protocol is (hopefully now very >clearly) structured as >- something RFC2205-like, which also supports >- use of existing transport&security protocols to achieve > the functionality that RSVP has in 2747 & 2961 > >The view has been expressed that this is a good approach to >investigate, but that there are some consequences which have >to be worried over. We hope that the description now in the draft >is clear enough to allow the WG to make its mind up on the >matter. In particular, section 5.3 describes the problems >and some possible cures (some people may find some of the >cures worse than the problems). > >There is also more discussion of other aspects of operation >as requested (e.g. v4/v6 stuff and supporting material) and >some examples for clarification. There is also a bit more >on routing interactions (although I believe this needs more >analysis before we can decide exactly what we want the >protocol to do). > >As a general point, this version is long (very long) on >explanation and discussion, and short on actual specification. >In fact, my impression is that GIMPS (or whatever we call it) >is actually a rather simple protocol, which can behave >in a number of very complicated ways and has a number of >very complicated interactions with other protocols. So, >in the longer term, we may need to think about how to structure >the specification to reflect this (somewhat unusual) situation. > >enjoy, > >robert h. > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis Dr. ir. Georgios Karagiannis Group: Design and Analysis of Communication Systems (DACS) University of Twente The Netherlands _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 12:12:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10722 for ; Tue, 11 Nov 2003 12:12:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc3d-0002I6-Pp for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 12:12:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHC1ER008798 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 12:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc3c-0002HN-UI; Tue, 11 Nov 2003 12:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc2v-0002G8-LI for nsis@optimus.ietf.org; Tue, 11 Nov 2003 12:11: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 MAA10645 for ; Tue, 11 Nov 2003 12:11:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJc2u-0006Hn-00 for nsis@ietf.org; Tue, 11 Nov 2003 12:11:16 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AJc2s-0006Gq-00 for nsis@ietf.org; Tue, 11 Nov 2003 12:11:15 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hABH9qme004370; Tue, 11 Nov 2003 12:09:53 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hABH7of08438; Tue, 11 Nov 2003 12:07:52 -0500 Message-ID: <3FB1176D.2030407@cs.columbia.edu> Date: Tue, 11 Nov 2003 12:07:57 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: john.loughney@nokia.com, karagian@cs.utwente.nl, nsis@ietf.org Subject: Re: [NSIS] NTLP draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hancock, Robert wrote: > functionally, if no NTLP node along the path decides to use connection > mode, then the datagram mode has been used end to end. i think we > have to make hard decisions about deciding to make functionality optional > which would then lead to more error conditions having to be signalled > around. > > to take a specific example: only supporting datagram mode implies > imposing a maximum NSLP message size. if that maximum size is imposed > in the middle of the network, how is an NSLP at one edge (a) supposed to > find out and (b) get messages through it? it would mean that every > NSLP would have to be able to work in case connection mode was never > present, in which case there probably isn't much point in having it > (which may be what you are aiming at, of course!) There are other reasons beyond fragmentation to have connection mode, but I agree that MTU discovery in mixed mode is something we may need to consider or explicitly rule out. (It's basically the same as in IP - send until it hits boundary and get error message "message too large".) I suspect that most NSLP messages have a natural size - you can't just cut the certificate in half if it exceeds the MTU. However, I think this is essentially the wrong question. We should require *support* of connection mode, but allow messages to *request* datagram mode. This avoids the problem Robert mentions - every message gets through, but applications can choose datagram mode if that fits their need. > > >>>3) Why have you chosen in the datagram mode for UDP encapsulation >>>and not for "raw IP" encapsulation? > > i think we should aim to choose one option at this stage. on balance, > the arguments for UDP seem stronger at the moment. there is minimal > impact on the rest of the protocol high level design. In addition, firewalls may or may not be configurable for non-UDP/TCP protocols. Every firewalls seems to have the notion of port-based filtering. > that is possible. you don't have to use the same approach both directions > (the 'return path' could also be raw). the e2e version can only be used > downstream anyway. some people don't like either tunnel encapsulation > anyway - this is all very open (and views are sought). We should definitely discuss this at the NSIS meeting. My current thinking is that encapsulation imposes complexity, makes implementation in certain circumstances rather tedious and it addresses somewhat ill-defined problems, so I'd love to hear arguments as to what can't be done in other ways. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 12:13:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10760 for ; Tue, 11 Nov 2003 12:13:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc4b-0002V7-AU for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 12:13:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHD0NQ009555 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 12:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc4a-0002Tz-R5; Tue, 11 Nov 2003 12:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc3j-0002Jv-PJ for nsis@optimus.ietf.org; Tue, 11 Nov 2003 12:12: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 MAA10713 for ; Tue, 11 Nov 2003 12:11:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJc3i-0006In-00 for nsis@ietf.org; Tue, 11 Nov 2003 12:12:06 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AJc3h-0006Ig-00 for nsis@ietf.org; Tue, 11 Nov 2003 12:12:06 -0500 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 11 Nov 2003 18:05:55 +0100 Message-ID: <3FB116DF.9000500@cs.uni-goettingen.de> Date: Tue, 11 Nov 2003 18:05:35 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: Henning Schulzrinne , nsis@ietf.org Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, To avoid misleading "state", how about "Common Service Messaging (or Management) Protocol"? Xiaoming Hancock, Robert wrote: > but: > it doesn't do state management! > (except for itself, which you could say about any protocol). > > r. > > >>-----Original Message----- >>From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] >>Sent: Tuesday, November 11, 2003 09:00 >>To: Henning Schulzrinne >>Cc: Jukka MJ Manner; nsis@ietf.org >>Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming >> >> >>Hi, >> >>or CSMP - Common State Management/Messaging Protocol? >> >>Regards, >>Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 14:17:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16121 for ; Tue, 11 Nov 2003 14:17:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe0b-0004Bd-EN for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14:17:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJH1TE016089 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe0a-0004BN-OX; Tue, 11 Nov 2003 14:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe0X-0004Az-PQ for nsis@optimus.ietf.org; Tue, 11 Nov 2003 14:16:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16116 for ; Tue, 11 Nov 2003 14:16:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe0V-0000Pb-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:16:55 -0500 Received: from delicious.ietf58.ietf.org ([130.129.16.24]) by ietf-mx with esmtp (Exim 4.12) id 1AJe0U-0000PY-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:16:54 -0500 Received: from starsu (dyn135-133.ietf58.ietf.org [130.129.135.133]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hABJGrKg013836; Tue, 11 Nov 2003 13:16:53 -0600 (CST) Message-ID: <000801c3a7bf$bd8ccfa0$85878182@starsu> From: "Sung-Hyuck Lee" To: , Cc: Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting Date: Mon, 10 Nov 2003 13:20:44 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C3A78D.728F09F0" 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 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C3A78D.728F09F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgIEp1a2thIGFuZCBNYXJjdXMsDQoNCm15IGNvbW1lbnRzIGlubGluZToNCg0KUmVncmFkcywN Cg0KU3VuZy1IeXVjaw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpKdWtrYSB3cm90ZToN Cg0KIA0KPj4gPiBCYXNpYyBJc3N1ZXMNCj4+ID4gLS0tLS0tLS0tLS0tDQo+PiANCj4+ID4gLSBI b3cgdG8gZGlzY292ZXIgY3Jvc3NvdmVyIHJvdXRlciwgd2hlbg0KPj4gDQo+PiBGaXJzdCBxdWVz dGlvbjogd2hhdCBkbyB5b3UgbmVlZCB0aGUgY3Jvc3NvdmVyIHJvdXRlciBmb3I/IFdoYXQgDQo+ PiBmdW5jdGlvbmFsaXR5IGlzIHNwZWNpYWwgb24gdGhlIGNyb3Nzb3ZlciByb3V0ZXI/DQoNCj5b Sk1dIFJlYWQgdGhlIGxpbmUgaW4gcGFyYW50aGVzaXMuLi4gd2hlbiB5b3UgYXJlIHRoZSByZWNl aXZlciBhbmQgeW91IA0KPm1vdmUsIHRoZSBuZXcgcGF0aCBzdGFydHMgYXQgdGhlIGNyb3NzLW92 ZXIgcm91dGVyLiBUaGlzIGlzIHdoZXJlIHRoZSANCj5sb2NhbCByZXBhaXIgc3RhcnRzLg0KDQpb Uy1IXSBZZXMsIGluIGFkZGl0aW9uIHRvIHRoZSBpbml0aWF0aW9uIG9mIHRoZSBzdGF0ZSB1cGRh dGUgb24gdGhlIGNvbW1vbiBwYXRoIA0KYWZ0aGVyIGhhbmRvdmVyLCAgdGhlIGNyb3Nzb3ZlciBy b3V0ZXIgbWF5IG5lZWQgdG8gaGF2ZSB0aGUgZnVuY3Rpb25hbGl0eSBvZiANCnRoZSBOSSwgTlIs IGFuZCBORi4NCg0KPj4gPiAgIGEpIHRoZSBjcm9zcy1vdmVyIHJvdXRlciBleGlzdHMgYnkgdGhl IGRlZmluaXRpb24gaW4gUlNWUCwgdGhhdCBpcywgdGhlDQo+PiA+IHNhbWUgICAgICAgc2Vzc2lv biBpcyBpZGVudGlmaWVkIG9uIGEgbmV3IGludGVyZmFjZQ0KPj4gPiAgIGIpIHRoZSBjcm9zcy1v dmVyIHJvdXRlciBkb2VzIG5vdCBleGlzdCBpbiB0aGUgcHJldmlvdXMgd2F5LCB0aGF0IGlzLA0K Pj4gPiBuZXcgICAgICAgbWVzc2FnZXMgZm9yIGFuIGV4aXN0aW5nIHNlc3Npb24gYXJyaXZlIGZy b20gYSBuZXcgcGVlciB0aHJvdWdoDQo+PiA+IHRoZSBvbGQgICAgICAgaW50ZXJmYWNlDQo+PiA+ ICAgYykgb3RoZXIgbm9kZXMgdGhhbiB0aGUgY3Jvc3Mtb3ZlciByb3V0ZXIgYWZmZWN0IHRoZSBz aWduYWxpbmcNCj4+ID4gKFRoZSBjcm9zcy1vdmVyIHJvdXRlciBkaXNjb3ZlcnkgaXMgbW9zdCBp bXBvcnRhbnQgd2hlbiB0aGUgbW9iaWxlIG5vZGUNCj4+ID4gaXMgcmVjZWl2ZXIpDQo+PiA+DQo+ PiA+IC0gU3RhdGUgdXBkYXRlIG9uIHRoZSBjb21tb24gcGF0aCBhZnRlciBoYW5kb3Zlcg0KPj4g Pg0KPj4gDQo+PiBJIHdvdWxkIGFzc3VtZSB0aGlzIGlzIE5TTFAgZGVwZW5kZW50DQoNCj5bSk1d IE1heSBiZSwgbWF5IGJlIG5vdC4uLiBkb24ndCBrbm93IHRoZSBjbGVhciBhbnN3ZXIsIHlldA0K DQo+PiANCj4+ID4gLSBJbnRlcmFjdGlvbnMgd2l0aCBtb2JpbGl0eSBwcm90b2NvbHMgc3VjaCBh cyBNSVAgYW5kIExNTSBwcm90b2NvbHMNCj4+ID4NCj4+IA0KPj4gSU1ITyB0aGVyZSBpcyBubyBp bnRlcndvcmtpbmcgbmVlZGVkIHdpdGggTUlQIGV4Y2VwdCB0aGF0IE1JUCBtaWdodCB3YW50IHRv IA0KPj4gdXNlIE5TSVMuDQoNCj5bSk1dIFRvIG1lIE5TSVMgYW5kIE1JUHY2IGFuZCBGYXN0IEhh bmRvdmVycyBoYXZlIHNvbWV0aGluZyBpbiBjb21tb24sIGFzIA0KPkNBUkQgYW5kIENUIGhhdmUu IEFsc28sIGhvdyB3b3VsZCBNSVB2NCB3b3JrIHdpdGggTlNJUyB3aXRoIENvQXMgYW5kIA0KPkND b0FzLCB0dW5uZWxpbmcsIGFuZCBwb3NzaWJsZSB0cmlhbmd1bGFyIHJvdXRpbmcuIFdoYXQgaWYg Q04gYW5kIE1OIGFyZSANCj5hY3R1YWxseSBpbiB0aGUgc2FtZSBuZXR3b3JrPyBBbnkgY2hhbmdl cyB0byBtYWtlIHRoaW5ncyBtb3JlIGVmZmljaWVudCANCj5ha2EuIG9wdGltaXplPyAoeWVzLCBJ IGtub3csIHNvbWVvbmUgd2lsbCBzb29uIHRlbGwgbm90IHRvIGZvY3VzIG9uIA0KPm9wdGltaXph dGlvbnMgYXQgdGhpcyBzdGFnZS4uLiBidXQgaXQgbWlnaHQgd2Ugd29ydGh3aGlsZSB0byBhdCBs ZWFzdCANCj5kb2N1bWVudCBzb21lIA0KPmlkZWFzPykNCg0KW1MtSF0gSU1ITywgaXQgbWF5IGJl IG9uZSBvZiB0aGUgaW1wb3J0YW50IGlzc3VlcyB0aGF0IHdlIG5lZWQgdG8gZGlzY3VzcyBhdCB0 aGUgDQphbmFseXNpcyBzdGF0Z2UgYXMgd2VsbCBhcyBhdCB0aGUgZnV0dXJlIG9wdGltaXphdGlv biBzdGFnZSB0byBzdXBwb3J0IGZhc3QgDQpyZS1lc3RhYmxpc2htZW50IGFmdGVyIGhhbmRvdmVy LiBGb3IgZXhhbXBsZSwgYW4gTU4gKGFzIGEgc2VuZGVyKSBvciBhIGNyb3Nzb3ZlciANCnJvdXRl ciAod2hlbiBhbiBNTiBpcyBhIHJlY2VpdmVyKSBtYXkgYmUgYWJsZSB0byBpbml0aWF0ZSB0aGUg cmUtZXN0YWJsaXNobWVudCBvZiB0aGUgDQpRb1MtTlNMUCBzdGF0ZSBpbiBhIGZhc3QgbWFubmVy IGFzIHNvb24gYXMgdGhlIE1OIG9yIGNyb3Nzb3ZlciByb3V0ZXIgcmVjZWl2ZXMgDQphIG1vYmls aXR5IGluZm9ybWF0aW9uIG1lc3NhZ2UgKGUuZy4sIEJpbmRpbmcgVXBkYXRlIG1lc3NhZ2UpLiAN Cg0KPj4gPiAtIERlcGVuZGVuY2llcyBiZXR3ZWVuIHRoZSBOVExQIGFuZCBOU0xQIGFuZCBzcGxp dCBvZiBmdW5jdGlvbmFsaXR5DQo+PiA+IGJldHdlZW4gICAgbGF5ZXJzDQo+PiA+DQo+PiANCj4+ IENhbiB5b3UgYW4gZXhhbXBsZSB3aGVyZSB0aGUgc3BsaXQgbWlnaHQgYmUgZGlmZmVyZW50IHdo ZW4gbG9va2luZyBpbnRvIA0KPj4gbW9iaWxlIHZlcnN1cyBzdGF0aWMgbmV0d29ya3MuDQoNCj5b Sk1dIE5vLCBub3QgeWV0LiBQcm9iYWJseSBzb21lIGlzc3VlcyByZWxhdGVkIHRvIHdobyB0cmln Z2VycyB3aG8gYW5kDQo+d2hlbiBhbmQgd2h5IGFuZCB3aGF0IG1lc3NhZ2VzIGFyZSB0aGVuIHNl bmQsIHdoZW4gYSBtb2JpbGl0eSBldmVudCBvY2N1cnMNCj5hbmQgc3RhdGVzIG5lZWQgdG8gYmUg bWFuYWdlZC4NCiANCltTLUhdIEJhc2ljYWxseSwgdGhlcmUgbWF5IG5vdCBiZSBhIGJpZyBkaWZm ZXJlbmNlLiBCdXQsIGF0IGxlYXN0IHdlIGNhbg0KaWRlbnRpdHkgdGhhdCBjZXJ0YWluIHRyaWdn ZXJpbmcgZXZlbnRzIGFyZSByZWxhdGVkIHRvIG1vYmlsaXR5IG9yIG5vbi1tb2JpbGl0eS4NCk9u ZSBleGFtcGxlIGNvdWxkIGJlICdsYXN0IG5vZGUgZGV0ZWN0aW9uJy4gU3BlY2lmaWNhbGx5LCB3 aGVuIGEgcm91dGUgY2hhbmdlIA0Kb2NjdXJzIGR1ZSB0byBoYW5kb3ZlciwgdGhlIE5UTFAgb2Yg dGhlIG9sZCBBUiB3aWxsIGZpbmQgdGhhdCBpdHMgcGVlciAoaS5lLiwgTU4pIA0KaXMgbm90IGFs aXZlIGFueSBsb25nZXIgc2luY2UgaXQgd2lsbCBub3QgcmVjZWl2ZSBhbnkgYWNrbm93bGVkZ2Vt ZW50IGZyb20gdGhlIE1OIA0KaW4gcmVzcG9uc2UgdG8gYSBwZWVyIGRpc2NvdmVyeSByZXF1ZXN0 IG1lc3NhZ2UuIEhvd2V2ZXIsIGluIHRoaXMgY2FzZSwgdGhlIA0KTlNMUCBvZiB0aGUgb2xkIEFS IHNob3VsZCBub3QgZ2VuZXJhdGUgYW55IGVycm9yIG1lc3NhZ2UgdG8gYXZvaWQgdGVhcmRvd24g b2YgDQpleGlzdGluZyBzdGF0ZXMgYmVmb3JlIHRoZSBjcm9zc292ZXIgcm91dGVyIGluaXRpYXRl cyBhIHRlYXJkb3duIG1lc3NhZ2Ugb24gdGhlIA0Kb2Jzb2xldGUgcGF0aC4gVGhpcyBjYXNlIG1h eSBhbHNvIGJlIGNvbnNpZGVyZWQgYXMgYSBzcGVjaWFsIGNhc2Ugb2YgZGVhZA0KcGVlciBkaXNj b3Zlcnkgb2YgdGhlIE5UTFAuDQo= ------=_NextPart_000_0005_01C3A78D.728F09F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMjY0IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SGkmbmJzcDsgSnVr a2EgYW5kIE1hcmN1cyw8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+bXkgY29tbWVudHMgaW5saW5lOjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5SZWdyYWRzLDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIA0Kc2l6ZT0yPlN1bmctSHl1Y2s8QlI+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5KdWtrYSB3cm90ZTo8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+Jm5ic3A7PEJSPiZndDsmZ3Q7ICZndDsgQmFzaWMgSXNzdWVzPEJSPiZndDsm Z3Q7ICZndDsgDQotLS0tLS0tLS0tLS08QlI+PC9GT05UPjxGT05UIHNpemU9Mj4mZ3Q7Jmd0OyA8 QlI+Jmd0OyZndDsgJmd0OyAtIEhvdyB0byBkaXNjb3ZlciANCmNyb3Nzb3ZlciByb3V0ZXIsIHdo ZW48QlI+Jmd0OyZndDsgPEJSPiZndDsmZ3Q7IEZpcnN0IHF1ZXN0aW9uOiB3aGF0IGRvIHlvdSBu ZWVkIA0KdGhlIGNyb3Nzb3ZlciByb3V0ZXIgZm9yPyBXaGF0IDxCUj4mZ3Q7Jmd0OyBmdW5jdGlv bmFsaXR5IGlzIHNwZWNpYWwgb24gdGhlIA0KY3Jvc3NvdmVyIHJvdXRlcj88L0ZPTlQ+PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jmd0O1tKTV0gUmVhZCB0aGUg bGluZSBpbiBwYXJhbnRoZXNpcy4uLiB3aGVuIHlvdSBhcmUgdGhlIA0KcmVjZWl2ZXIgYW5kIHlv dSA8QlI+Jmd0O21vdmUsIHRoZSBuZXcgcGF0aCBzdGFydHMgYXQgdGhlIGNyb3NzLW92ZXIgcm91 dGVyLiANClRoaXMgaXMgd2hlcmUgdGhlIDxCUj4mZ3Q7bG9jYWwgcmVwYWlyIHN0YXJ0cy48L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+W1MtSF0gWWVz LCBpbiBhZGRpdGlvbiB0byB0aGUgaW5pdGlhdGlvbiBvZiB0aGUgc3RhdGUgdXBkYXRlIA0Kb24g dGhlIGNvbW1vbiBwYXRoIDxCUj5hZnRoZXIgaGFuZG92ZXIsJm5ic3A7IHRoZSBjcm9zc292ZXIg cm91dGVyIG1heSBuZWVkIHRvIA0KaGF2ZSB0aGUgZnVuY3Rpb25hbGl0eSBvZiA8QlI+dGhlIE5J LCBOUiwgYW5kIE5GLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj4mZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7IGEpIHRoZSBjcm9zcy1vdmVyIHJvdXRl ciBleGlzdHMgYnkgDQp0aGUgZGVmaW5pdGlvbiBpbiBSU1ZQLCB0aGF0IGlzLCB0aGU8QlI+Jmd0 OyZndDsgJmd0OyANCnNhbWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vz c2lvbiBpcyBpZGVudGlmaWVkIG9uIGEgbmV3IA0KaW50ZXJmYWNlPEJSPiZndDsmZ3Q7ICZndDsm bmJzcDsmbmJzcDsgYikgdGhlIGNyb3NzLW92ZXIgcm91dGVyIGRvZXMgbm90IGV4aXN0IA0KaW4g dGhlIHByZXZpb3VzIHdheSwgdGhhdCBpcyw8QlI+Jmd0OyZndDsgJmd0OyANCm5ldyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtZXNzYWdlcyBmb3IgYW4gZXhpc3Rpbmcgc2Vz c2lvbiBhcnJpdmUgDQpmcm9tIGEgbmV3IHBlZXIgdGhyb3VnaDxCUj4mZ3Q7Jmd0OyAmZ3Q7IHRo ZSANCm9sZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnRlcmZhY2U8QlI+ Jmd0OyZndDsgJmd0OyZuYnNwOyZuYnNwOyANCmMpIG90aGVyIG5vZGVzIHRoYW4gdGhlIGNyb3Nz LW92ZXIgcm91dGVyIGFmZmVjdCB0aGUgc2lnbmFsaW5nPEJSPiZndDsmZ3Q7ICZndDsgDQooVGhl IGNyb3NzLW92ZXIgcm91dGVyIGRpc2NvdmVyeSBpcyBtb3N0IGltcG9ydGFudCB3aGVuIHRoZSBt b2JpbGUgDQpub2RlPEJSPiZndDsmZ3Q7ICZndDsgaXMgcmVjZWl2ZXIpPEJSPiZndDsmZ3Q7ICZn dDs8QlI+Jmd0OyZndDsgJmd0OyAtIFN0YXRlIA0KdXBkYXRlIG9uIHRoZSBjb21tb24gcGF0aCBh ZnRlciBoYW5kb3ZlcjxCUj4mZ3Q7Jmd0OyAmZ3Q7PEJSPiZndDsmZ3Q7IA0KPEJSPiZndDsmZ3Q7 IEkgd291bGQgYXNzdW1lIHRoaXMgaXMgTlNMUCBkZXBlbmRlbnQ8L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jmd0O1tKTV0gTWF5IGJlLCBtYXkgYmUg bm90Li4uIGRvbid0IGtub3cgdGhlIGNsZWFyIGFuc3dlciwgDQp5ZXQ8L0ZPTlQ+PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jmd0OyZndDsgPEJSPiZndDsmZ3Q7 ICZndDsgLSBJbnRlcmFjdGlvbnMgd2l0aCBtb2JpbGl0eSANCnByb3RvY29scyBzdWNoIGFzIE1J UCBhbmQgTE1NIHByb3RvY29sczxCUj4mZ3Q7Jmd0OyAmZ3Q7PEJSPiZndDsmZ3Q7IA0KPEJSPiZn dDsmZ3Q7IElNSE8gdGhlcmUgaXMgbm8gaW50ZXJ3b3JraW5nIG5lZWRlZCB3aXRoIE1JUCBleGNl cHQgdGhhdCBNSVAgbWlnaHQgDQp3YW50IHRvIDxCUj4mZ3Q7Jmd0OyB1c2UgTlNJUy48L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jmd0O1tKTV0gVG8g bWUgTlNJUyBhbmQgTUlQdjYgYW5kIEZhc3QgSGFuZG92ZXJzIGhhdmUgDQpzb21ldGhpbmcgaW4g Y29tbW9uLCBhcyA8QlI+Jmd0O0NBUkQgYW5kIENUIGhhdmUuIEFsc28sIGhvdyB3b3VsZCBNSVB2 NCB3b3JrIA0Kd2l0aCBOU0lTIHdpdGggQ29BcyBhbmQgPEJSPiZndDtDQ29BcywgdHVubmVsaW5n LCBhbmQgcG9zc2libGUgdHJpYW5ndWxhciANCnJvdXRpbmcuIFdoYXQgaWYgQ04gYW5kIE1OIGFy ZSA8QlI+Jmd0O2FjdHVhbGx5IGluIHRoZSBzYW1lIG5ldHdvcms/IEFueSBjaGFuZ2VzIA0KdG8g bWFrZSB0aGluZ3MgbW9yZSBlZmZpY2llbnQgPEJSPiZndDtha2EuIG9wdGltaXplPyAoeWVzLCBJ IGtub3csIHNvbWVvbmUgd2lsbCANCnNvb24gdGVsbCBub3QgdG8gZm9jdXMgb24gPEJSPiZndDtv cHRpbWl6YXRpb25zIGF0IHRoaXMgc3RhZ2UuLi4gYnV0IGl0IG1pZ2h0IHdlIA0Kd29ydGh3aGls ZSB0byBhdCBsZWFzdCA8QlI+Jmd0O2RvY3VtZW50IHNvbWUgPEJSPiZndDtpZGVhcz8pPC9GT05U PjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPltTLUhdIElNSE8s IGl0IG1heSBiZSBvbmUgb2YgdGhlIGltcG9ydGFudCBpc3N1ZXMgdGhhdCB3ZSBuZWVkIA0KdG8g ZGlzY3VzcyBhdCB0aGUgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YW5hbHlzaXMg c3RhdGdlIGFzIHdlbGwgYXMgYXQgdGhlIGZ1dHVyZSBvcHRpbWl6YXRpb24gc3RhZ2UgdG8gDQpz dXBwb3J0IGZhc3QgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+cmUtZXN0YWJsaXNo bWVudCBhZnRlciBoYW5kb3Zlci4gRm9yIGV4YW1wbGUsIGFuIE1OIChhcyBhIA0Kc2VuZGVyKSBv ciBhIGNyb3Nzb3ZlciA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5yb3V0ZXIgKHdo ZW4gYW4gTU4gaXMgYSByZWNlaXZlcikgbWF5IGJlIGFibGUgdG8gaW5pdGlhdGUgdGhlIA0KcmUt ZXN0YWJsaXNobWVudCBvZiB0aGUgPEJSPlFvUy1OU0xQIHN0YXRlIGluIGEgZmFzdCBtYW5uZXIg YXMgc29vbiBhcyB0aGUgTU4gb3IgDQpjcm9zc292ZXIgcm91dGVyIHJlY2VpdmVzIDxCUj5hIG1v YmlsaXR5IGluZm9ybWF0aW9uIG1lc3NhZ2UgKGUuZy4sIEJpbmRpbmcgDQpVcGRhdGUgbWVzc2Fn ZSkuIDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4m Z3Q7Jmd0OyAmZ3Q7IC0gRGVwZW5kZW5jaWVzIGJldHdlZW4gdGhlIE5UTFAgYW5kIE5TTFAgYW5k IA0Kc3BsaXQgb2YgZnVuY3Rpb25hbGl0eTxCUj4mZ3Q7Jmd0OyAmZ3Q7IGJldHdlZW4mbmJzcDsm bmJzcDsmbmJzcDsgDQpsYXllcnM8QlI+Jmd0OyZndDsgJmd0OzxCUj4mZ3Q7Jmd0OyA8QlI+Jmd0 OyZndDsgQ2FuIHlvdSBhbiBleGFtcGxlIHdoZXJlIHRoZSANCnNwbGl0IG1pZ2h0IGJlIGRpZmZl cmVudCB3aGVuIGxvb2tpbmcgaW50byA8QlI+Jmd0OyZndDsgbW9iaWxlIHZlcnN1cyBzdGF0aWMg DQpuZXR3b3Jrcy48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+Jmd0O1tKTV0gTm8sIG5vdCB5ZXQuIFByb2JhYmx5IHNvbWUgaXNzdWVzIHJlbGF0ZWQg dG8gd2hvIA0KdHJpZ2dlcnMgd2hvIGFuZDxCUj4mZ3Q7d2hlbiBhbmQgd2h5IGFuZCB3aGF0IG1l c3NhZ2VzIGFyZSB0aGVuIHNlbmQsIHdoZW4gYSANCm1vYmlsaXR5IGV2ZW50IG9jY3VyczxCUj4m Z3Q7YW5kIHN0YXRlcyBuZWVkIHRvIGJlIG1hbmFnZWQuPEJSPiZuYnNwOzxCUj5bUy1IXSANCkJh c2ljYWxseSwgdGhlcmUgbWF5IG5vdCBiZSBhIGJpZyBkaWZmZXJlbmNlLiBCdXQsIGF0IGxlYXN0 IHdlIGNhbjxCUj5pZGVudGl0eSANCnRoYXQgY2VydGFpbiB0cmlnZ2VyaW5nIGV2ZW50cyBhcmUg cmVsYXRlZCB0byBtb2JpbGl0eSBvciBub24tbW9iaWxpdHkuPEJSPk9uZSANCmV4YW1wbGUgY291 bGQgYmUgJ2xhc3Qgbm9kZSBkZXRlY3Rpb24nLiBTcGVjaWZpY2FsbHksIHdoZW4gYSByb3V0ZSBj aGFuZ2UgDQo8QlI+b2NjdXJzIGR1ZSB0byBoYW5kb3ZlciwgdGhlIE5UTFAgb2YgdGhlIG9sZCBB UiB3aWxsIGZpbmQgdGhhdCBpdHMgcGVlciANCihpLmUuLCBNTikgPEJSPmlzIG5vdCBhbGl2ZSBh bnkgbG9uZ2VyIHNpbmNlIGl0IHdpbGwgbm90IHJlY2VpdmUgYW55IA0KYWNrbm93bGVkZ2VtZW50 IGZyb20gdGhlIE1OIDxCUj5pbiByZXNwb25zZSB0byBhIHBlZXIgZGlzY292ZXJ5IHJlcXVlc3Qg bWVzc2FnZS4gDQpIb3dldmVyLCBpbiB0aGlzIGNhc2UsIHRoZSA8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj5OU0xQIG9mIHRoZSBvbGQgQVIgc2hvdWxkIG5vdCBnZW5lcmF0ZSBhbnkg ZXJyb3IgbWVzc2FnZSB0byANCmF2b2lkIHRlYXJkb3duIG9mIDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPmV4aXN0aW5nIHN0YXRlcyBiZWZvcmUgdGhlIGNyb3Nzb3ZlciByb3V0ZXIg aW5pdGlhdGVzIGEgDQp0ZWFyZG93biBtZXNzYWdlIG9uIHRoZSA8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj5vYnNvbGV0ZSBwYXRoLiBUaGlzIGNhc2UgbWF5IGFsc28gYmUgY29uc2lk ZXJlZCBhcyBhIHNwZWNpYWwgDQpjYXNlIG9mIGRlYWQ8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5wZWVyIGRpc2NvdmVyeSBvZiB0aGUgTlRMUC48QlI+PC9ESVY+PC9GT05UPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_000_0005_01C3A78D.728F09F0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 14:19:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16176 for ; Tue, 11 Nov 2003 14:19:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe2Y-0004Hx-5s for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14:19:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJJ1Ak016428 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe2X-0004Gs-QO; Tue, 11 Nov 2003 14:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe21-0004GS-O7 for nsis@optimus.ietf.org; Tue, 11 Nov 2003 14:18:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16166 for ; Tue, 11 Nov 2003 14:18:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe1z-0000Qi-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:18:27 -0500 Received: from delicious.ietf58.ietf.org ([130.129.16.24]) by ietf-mx with esmtp (Exim 4.12) id 1AJe1y-0000Qf-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:18:26 -0500 Received: from hufsshjeong (dyn128-227.ietf58.ietf.org [130.129.128.227]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hABJIPKg013921; Tue, 11 Nov 2003 13:18:26 -0600 (CST) Message-ID: <002b01c3a888$8ddf34e0$e3808182@hufsshjeong> From: "Seong-Ho Jeong" To: "Marcus Brunner" Cc: , References: Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting Date: Wed, 12 Nov 2003 04:18:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgTWFyY3VzLCANCg0KQSBmZXcgbW9yZSBjb21tZW50cyBpbmxpbmUgW1NISl0NCg0KUmVnYXJk cywNClNlb25nLUhvDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSnVr a2EgTUogTWFubmVyIiA8am1hbm5lckBjcy5IZWxzaW5raS5GST4NClRvOiAiTWFyY3VzIEJydW5u ZXIiIDxicnVubmVyQGNjcmxlLm5lYy5kZT4NCkNjOiA8bnNpc0BpZXRmLm9yZz4NClNlbnQ6IFR1 ZXNkYXksIE5vdmVtYmVyIDExLCAyMDAzIDExOjE2IFBNDQpTdWJqZWN0OiBSZTogW05TSVNdIEZl ZWRiYWNrIGZyb20gdGhlICJtb2JpbGl0eSBpbiBOU0lTIiBtZWV0aW5nDQoNCg0KPiANCj4gSGkg TWFyY3VzLCByZXBsaWVzIGlubGluZS4NCj4gDQo+IEp1a2thDQo+IA0KPiBPbiBNb24sIDEwIE5v diAyMDAzLCBNYXJjdXMgQnJ1bm5lciB3cm90ZToNCj4gDQo+ID4gDQo+ID4gPiBCYXNpYyBJc3N1 ZXMNCj4gPiA+IC0tLS0tLS0tLS0tLQ0KPiA+ID4NCj4gPiA+IC0gRGlmZmVyZW5jZXMgYmV0d2Vl biB0aGUgZ2VuZXJhbCByb3V0ZSBjaGFuZ2UgKG5vdCByZWxhdGVkIHRvIG1vYmlsaXR5KQ0KPiA+ ID4gICBhbmQgbW9iaWxpdHktY2F1c2VkIHJvdXRlIGNoYW5nZSwgd2hlbg0KPiA+ID4gICBhKSB3 aGVuIElQIGFkZHJlc3NlcyBjaGFuZ2UgKGVuZCBob3N0IG9yIG5leHQgcGVlcikNCj4gPiA+ICAg Yikgd2hlbiBJUCBhZGRyZXNzZXMgZG8gbm90IGNoYW5nZQ0KPiA+ID4NCj4gPiANCj4gPiBTbyB3 aGF0IGlzIHRoZSBkaWZmZXJlbmNlPw0KPiANCj4gW0pNXSBOb3RoaW5nLCBpZiB5b3UgZG8gdGhp bmdzIHJpZ2h0LCBlLmcuIHRoZSBzZXNzaW9uIHN0YXRlcyBhcmUgbm90IA0KPiBpZGVudGlmaWVk IHdpdGggSVAgYWRkcmVzc2VzIChhcyBpbiBSU1ZQKSwgYnV0IGEgZ2VuZXJpYyBJRCBhcyBzZWVt cyB0byBiZSANCj4gdGhlIGNhc2UgaW4gdGhlIE5UTFAgYW5kIE5TTFAgZGVzaWduIGFscmVhZHku DQoNCltTSEpdT25lIG9mIHRoZSBtYWluIHJlYXNvbnMgd2h5IHdlIGluY2x1ZGVkIHRoZSBkaWZm ZXJlbmNlcyBpbiB0aGUgbGlzdCBpcyB0aGUgZmFjdCANCnRoYXQgdGhlIG1vYmlsaXR5LWNhdXNl ZCByb3V0ZSBjaGFuZ2UgbWF5IGhhdmUgc29tZSBpbXBhY3Qgb24gdGhlIGZsb3cgaWRlbnRpZmll ciAoYWx0aG91Z2gNCml0IG1heSBiZSBwb3NzaWJsZSB0aGF0IHRoZSBmbG93IGlkZW50aWZpZXIg ZG9lcyBub3QgY2hhbmdlIGluIHRoZSBtaWNyby1tb2JpbGl0eSBjYXNlKS4gDQpUaGUgY2hhbmdl IGluIHRoZSBmbG93IGlkZW50aWZpZXIgbWF5IGNhdXNlIHN0YXRlIHVwZGF0ZS4NCg0KPiANCj4g PiANCj4gPiA+IC0gSG93IHRvIGRpc2NvdmVyIGNyb3Nzb3ZlciByb3V0ZXIsIHdoZW4NCj4gPiAN Cj4gPiBGaXJzdCBxdWVzdGlvbjogd2hhdCBkbyB5b3UgbmVlZCB0aGUgY3Jvc3NvdmVyIHJvdXRl ciBmb3I/IFdoYXQgDQo+ID4gZnVuY3Rpb25hbGl0eSBpcyBzcGVjaWFsIG9uIHRoZSBjcm9zc292 ZXIgcm91dGVyPw0KPiANCj4gW0pNXSBSZWFkIHRoZSBsaW5lIGluIHBhcmFudGhlc2lzLi4uIHdo ZW4geW91IGFyZSB0aGUgcmVjZWl2ZXIgYW5kIHlvdSANCj4gbW92ZSwgdGhlIG5ldyBwYXRoIHN0 YXJ0cyBhdCB0aGUgY3Jvc3Mtb3ZlciByb3V0ZXIuIFRoaXMgaXMgd2hlcmUgdGhlIA0KPiBsb2Nh bCByZXBhaXIgc3RhcnRzLg0KDQpbU0hKXVRvIG1pbmltemUgdGhlIGltcGFjdCBvZiBtb2JpbGl0 eS1jYXVzZWQgcm91dGUgY2hhbmdlLCBpdCBpcyBkZXNpcmVkDQp0byBsaW1pdCB0aGUgc3RhdGUg cmUtZXN0YWJsaXNobWVudCBhbmQgb2xkIHN0YXRlIHJlbW92YWwgdG8gdGhlIGFmZmVjdGVkIHBh dGggc2VnbWVudC4gDQpJbiB0aGlzIGNhc2UsIHRoZSBjcm9zc292ZXIgcm91dGVyIGlzIGFuIGFw cHJvcHJpYXRlIG5vZGUgdG8gaW5pdGlhdGUgdGhpcyBsb2NhbCBwYXRoIHJlcGFpci4gDQpUaGlz IGlzIHBhcnRpY3VsYXJseSBpbXBvcnRhbnQgd2hlbiB0aGUgbW9iaWxlIG5vZGUgYWN0cyBhcyBh IHJlY2VpdmVyIHRvIGF2b2lkIA0KYSBsb25nIGRlbGF5IGZvciBzdGF0ZSByZS1lc3RhYmxpc2ht ZW50Lg0KDQo+IA0KPiA+IA0KPiA+ID4gICBhKSB0aGUgY3Jvc3Mtb3ZlciByb3V0ZXIgZXhpc3Rz IGJ5IHRoZSBkZWZpbml0aW9uIGluIFJTVlAsIHRoYXQgaXMsIHRoZQ0KPiA+ID4gc2FtZSAgICAg ICBzZXNzaW9uIGlzIGlkZW50aWZpZWQgb24gYSBuZXcgaW50ZXJmYWNlDQo+ID4gPiAgIGIpIHRo ZSBjcm9zcy1vdmVyIHJvdXRlciBkb2VzIG5vdCBleGlzdCBpbiB0aGUgcHJldmlvdXMgd2F5LCB0 aGF0IGlzLA0KPiA+ID4gbmV3ICAgICAgIG1lc3NhZ2VzIGZvciBhbiBleGlzdGluZyBzZXNzaW9u IGFycml2ZSBmcm9tIGEgbmV3IHBlZXIgdGhyb3VnaA0KPiA+ID4gdGhlIG9sZCAgICAgICBpbnRl cmZhY2UNCj4gPiA+ICAgYykgb3RoZXIgbm9kZXMgdGhhbiB0aGUgY3Jvc3Mtb3ZlciByb3V0ZXIg YWZmZWN0IHRoZSBzaWduYWxpbmcNCj4gPiA+IChUaGUgY3Jvc3Mtb3ZlciByb3V0ZXIgZGlzY292 ZXJ5IGlzIG1vc3QgaW1wb3J0YW50IHdoZW4gdGhlIG1vYmlsZSBub2RlDQo+ID4gPiBpcyByZWNl aXZlcikNCj4gPiA+DQo+ID4gPiAtIFN0YXRlIHVwZGF0ZSBvbiB0aGUgY29tbW9uIHBhdGggYWZ0 ZXIgaGFuZG92ZXINCj4gPiA+DQo+ID4gDQo+ID4gSSB3b3VsZCBhc3N1bWUgdGhpcyBpcyBOU0xQ IGRlcGVuZGVudA0KPiANCj4gW0pNXSBNYXkgYmUsIG1heSBiZSBub3QuLi4gZG9uJ3Qga25vdyB0 aGUgY2xlYXIgYW5zd2VyLCB5ZXQNCg0KW1NISl0gSU1ITywgIGl0IG1heSBiZSBOU0xQIGRlcGVu ZGVudCwgYnV0IHRoZXJlIGNvdWxkIGJlIE5UTFAgc3RhdGVzIGludm9sdmVkLiANCkkgdGhpbmsg aUl0IGRlcGVuZHMgb24gIGhvdyB0byBkZWZpbmUgc3RhdGVzIGluIHRoZSBOVExQIGFuZCBOU0xQ Lg0KDQo+IA0KPiA+IA0KPiA+ID4gLSBJbnRlcmFjdGlvbnMgd2l0aCBtb2JpbGl0eSBwcm90b2Nv bHMgc3VjaCBhcyBNSVAgYW5kIExNTSBwcm90b2NvbHMNCj4gPiA+DQo+ID4gDQo+ID4gSU1ITyB0 aGVyZSBpcyBubyBpbnRlcndvcmtpbmcgbmVlZGVkIHdpdGggTUlQIGV4Y2VwdCB0aGF0IE1JUCBt aWdodCB3YW50IHRvIA0KPiA+IHVzZSBOU0lTLg0KPiANCj4gW0pNXSBUbyBtZSBOU0lTIGFuZCBN SVB2NiBhbmQgRmFzdCBIYW5kb3ZlcnMgaGF2ZSBzb21ldGhpbmcgaW4gY29tbW9uLCBhcyANCj4g Q0FSRCBhbmQgQ1QgaGF2ZS4gQWxzbywgaG93IHdvdWxkIE1JUHY0IHdvcmsgd2l0aCBOU0lTIHdp dGggQ29BcyBhbmQgDQo+IENDb0FzLCB0dW5uZWxpbmcsIGFuZCBwb3NzaWJsZSB0cmlhbmd1bGFy IHJvdXRpbmcuIFdoYXQgaWYgQ04gYW5kIE1OIGFyZSANCj4gYWN0dWFsbHkgaW4gdGhlIHNhbWUg bmV0d29yaz8gQW55IGNoYW5nZXMgdG8gbWFrZSB0aGluZ3MgbW9yZSBlZmZpY2llbnQgDQo+IGFr YS4gb3B0aW1pemU/ICh5ZXMsIEkga25vdywgc29tZW9uZSB3aWxsIHNvb24gdGVsbCBub3QgdG8g Zm9jdXMgb24gDQo+IG9wdGltaXphdGlvbnMgYXQgdGhpcyBzdGFnZS4uLiBidXQgaXQgbWlnaHQg d2Ugd29ydGh3aGlsZSB0byBhdCBsZWFzdCANCj4gZG9jdW1lbnQgc29tZSANCj4gaWRlYXM/KQ0K PiANCj4gPiA+IC0gRGVwZW5kZW5jaWVzIGJldHdlZW4gdGhlIE5UTFAgYW5kIE5TTFAgYW5kIHNw bGl0IG9mIGZ1bmN0aW9uYWxpdHkNCj4gPiA+IGJldHdlZW4gICAgbGF5ZXJzDQo+ID4gPg0KPiA+ IA0KPiA+IENhbiB5b3UgYW4gZXhhbXBsZSB3aGVyZSB0aGUgc3BsaXQgbWlnaHQgYmUgZGlmZmVy ZW50IHdoZW4gbG9va2luZyBpbnRvIA0KPiA+IG1vYmlsZSB2ZXJzdXMgc3RhdGljIG5ldHdvcmtz Lg0KPiANCj4gW0pNXSBObywgbm90IHlldC4gUHJvYmFibHkgc29tZSBpc3N1ZXMgcmVsYXRlZCB0 byB3aG8gdHJpZ2dlcnMgd2hvIGFuZA0KPiB3aGVuIGFuZCB3aHkgYW5kIHdoYXQgbWVzc2FnZXMg YXJlIHRoZW4gc2VuZCwgd2hlbiBhIG1vYmlsaXR5IGV2ZW50IG9jY3Vycw0KPiBhbmQgc3RhdGVz IG5lZWQgdG8gYmUgbWFuYWdlZC4NCj4gDQo+ID4gDQo+ID4gPiAtIFNlY3VyaXR5IGlzc3Vlczog aW1wbGljYXRpb25zIG9mIHRoZSBhdXRob3JpemF0aW9uIG1vZGVsDQo+ID4gPg0KPiA+IA0KPiA+ IFdoYXQgaXMgZGlmZmVyZW50IGluIHRoZSBtb2JpbGl0eSBjYXNlLg0KPiANCj4gW0pNXSBBIG1v cmUgZHluYW1pYyBlbnZpcm9ubWVudCwgbm90IGFsbCBwZWVycyByZW1haW4sIHdobyBpcyB3aG8s IHdobyBpcyANCj4gdGhlIHNpZ25hbGluZyBpbml0aWF0b3I/DQo+IA0KPiA+IA0KPiA+ID4gLSBE ZWFkIHBlZXIgYW5kIGRlYWQgY3Jvc3Mtb3ZlciByb3V0ZXIgZGlzY292ZXJ5DQo+ID4gPg0KPiA+ IA0KPiA+IGFnYWluIHdoeSBkbyB5b3UgbmVlZCB0byBkaXNjb3ZlciB0aGVzZT8gSSBhc3N1bWUg cGVlciBtYWludGFuY2UgaXMgcGFydCBvZiANCj4gPiB0aGUgTlRMUCBhbnl3YXkuDQo+IA0KPiBb Sk1dIEFscmVhZHkgYW5zd2VyZWQgdG8gdGhlIGNyb3NzLW92ZXIgcm91dGVyIGlzc3VlLCBkaXNj b3Zlcnkgb2YgZGVhZA0KPiBwZWVycyBpcyBhbHNvIHJlbGF0ZWQgdG8gbW9iaWxpdHkgYW5kIHBh dGggY2hhbmdlcy4NCg0KW1NISl0gVGhpcyB3aWxsIGJlIHBhcnRpY3VsYXJseSBpbXBvcnRhbnQg d2hlbiBvbmUgb2YgdGhlIHBlZXJzIGlzIHRoZSBjcm9zc292ZXIgcm91dGVyDQpiZWNhdXNlIHRo ZSBjcm9zc292ZXIgcm91dGVyIGlzIG9uZSBvZiB0aGUga2V5IGNvbXBvbmVudHMgaW4gc3RhdGUg cmUtZXN0YWJsaXNobWVudCBhbmQNCm9sZCBzdGF0ZSByZW1vdmFsLiBJZiB0aGUgY3Jvc3NvdmVy IHJvdXRlciBpcyBmb3VuZCB0byBiZSBkZWFkIGZvciBzb21lIHJlYXNvbiBiZWZvcmUgDQp0aGUg c3RhdGUgcmUtZXN0YWJsaXNobWVudCBhbmQgb2xkIHN0YXRlIHJlbW92YWwsIGEgbmV3IGNyb3Nz b3ZlciByb3V0ZXIgc2hvdWxkIGJlIA0KZGlzY292ZXJlZCBpbiBhIGZhc3QgbWFubmVyLg0KPiAN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IG5zaXMgbWFpbGluZyBsaXN0DQo+IG5zaXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbnNpcw0KPg== _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 14:22:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16288 for ; Tue, 11 Nov 2003 14:22:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe5Q-0004PY-TI for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14:22:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJM0BB016915 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14:22:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe5Q-0004Og-Fx; Tue, 11 Nov 2003 14: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 1AJe5O-0004OV-HV for nsis@optimus.ietf.org; Tue, 11 Nov 2003 14:21:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16269 for ; Tue, 11 Nov 2003 14:21:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe5L-0000Sf-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:21:56 -0500 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AJe5L-0000Sc-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:21:55 -0500 Received: from dyn134-139.ietf58.ietf.org (dyn134-139.ietf58.ietf.org [130.129.134.139]) by ftp.ccrle.nec.de (Postfix) with ESMTP id DB3351037F; Tue, 11 Nov 2003 20:26:18 +0100 (CET) Date: Tue, 11 Nov 2003 13:20:53 -0600 From: Marcus Brunner Reply-To: Marcus Brunner To: Xiaoming Fu Cc: nsis@ietf.org Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting Message-ID: <115186559.1068556850@dyn134-139.ietf58.ietf.org> In-Reply-To: <3FB0F694.3090804@cs.uni-goettingen.de> References: <3FB0F694.3090804@cs.uni-goettingen.de> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 > it is now a good time for the WG to decide whether/how to have a > working group document on these issues), and I do think this list would > be helpful for studying the implications of mobility on the work within > NSIS. I think it is far to early to talk about mobility (even when interesting from a research point of view.) Let's first get the work on the table done. I do not have problem when the directions of NTLP and NSLPs are carefully reviewed checking the impact on mobility. And I think John already mentioned mobility is not part of the charter. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 14:24:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16397 for ; Tue, 11 Nov 2003 14:24:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe7N-0004aY-St for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14:24:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJO1Z4017595 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe7N-0004Zb-Dq; Tue, 11 Nov 2003 14:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe6v-0004Z2-8f for nsis@optimus.ietf.org; Tue, 11 Nov 2003 14:23: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 OAA16351 for ; Tue, 11 Nov 2003 14:23:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe6s-0000Tr-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:23:30 -0500 Received: from ponyexpress.ee.columbia.edu ([128.59.64.61] ident=[RcXJtB9wL/lnjKaUmEr7VatZYHY+KBLP]) by ietf-mx with esmtp (Exim 4.12) id 1AJe6s-0000To-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:23:30 -0500 Received: from president (dyn-fair-240-205.dyn.columbia.edu [160.39.240.205]) (authenticated bits=0) by ponyexpress.ee.columbia.edu (8.12.8/8.12.1) with ESMTP id hABJMLaU028514 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 11 Nov 2003 14:22:22 -0500 From: "Charles Q. Shen" To: "'Xiaoming Fu'" Cc: "'Marcus Brunner'" , Subject: RE: [NSIS] Feedback from the "mobility in NSIS" meeting Date: Tue, 11 Nov 2003 14:23:21 -0500 Organization: Columbia University Message-ID: <001b01c3a889$459c8f60$cdf027a0@president> 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.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3FB0F113.9000400@cs.uni-goettingen.de> Importance: Normal 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 Xiaoming, > > > > [cs] My understanding of the difference is: > > 1) the different causes of route change (eg. routing adaptation or > > mobility) > > 2) whether IP address change is associated with the route > change or not > > > > Note there are some topology change cases, even with mobility, the IP > address does not change. For example, in HMIP, it is possible > the source > address of a packet sent from the MN to the CN can be RCoA, even its > LCoA is changed. > That's correct. I did not mean one case in point (1) is tied with one specific case in point (2). These two points should be examined in parallel. Regards, Charles _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 14:28:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16630 for ; Tue, 11 Nov 2003 14:28:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeBF-00059v-TY for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJS1v7019792 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14: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 1AJeBF-000592-Jt; Tue, 11 Nov 2003 14: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 1AJeAw-00058a-TJ for nsis@optimus.ietf.org; Tue, 11 Nov 2003 14:27:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16599 for ; Tue, 11 Nov 2003 14:27:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJeAu-0000Yk-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:27:40 -0500 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AJeAt-0000Yh-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:27:39 -0500 Received: from dyn134-139.ietf58.ietf.org (dyn134-139.ietf58.ietf.org [130.129.134.139]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 55BA41037F; Tue, 11 Nov 2003 20:32:03 +0100 (CET) Date: Tue, 11 Nov 2003 13:27:36 -0600 From: Marcus Brunner Reply-To: Marcus Brunner To: "Hancock, Robert" Cc: nsis@ietf.org Subject: RE: [NSIS] Feedback from the "mobility in NSIS" meeting Message-ID: <115592032.1068557255@dyn134-139.ietf58.ietf.org> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 > Thinking about how we would attempt to use the protocols > in stressful environments is one way to avoid building > restrictive assumptions into the protocol design, and > mobility etc. is a very good hothouse for doing this. I > don't actually expect significant extra functionality is > needed to handle any of these issues, certainly not in the > NTLP anyway; indeed, the analysis might be a method for > trimming down the set of possible designs (which we should > all be grateful for). yes, sure, but I have too often heard the word "optimize" in the context of the mobility discussion. The best optimization is IMO the make it simple and lean > > Exactly how this work should get managed, officially or > otherwise, is another question. But the situation we have > at the moment - where we have several drafts, which all have > to be read very closely to determine whether they are > asking for roughly the same thing or completely different > things from the protocols - is not optimised for making > best use of WG energy (or causing least confusion to the > protocol design work). agreed, if it helps the WG to finalize the work I am in favour of a combined draft. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 11 14:47:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17990 for ; Tue, 11 Nov 2003 14:47:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeTd-0007F7-ND for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14:47:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJl1b6027816 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 14:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeTd-0007ES-3J; Tue, 11 Nov 2003 14:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeTT-0007De-LS for nsis@optimus.ietf.org; Tue, 11 Nov 2003 14:46: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 OAA17928 for ; Tue, 11 Nov 2003 14:46:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJeTQ-000116-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:46:48 -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 1AJeTP-00010v-00 for nsis@ietf.org; Tue, 11 Nov 2003 14:46:47 -0500 Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 11 Nov 2003 21:46:46 +0200 Date: Tue, 11 Nov 2003 21:46:46 +0200 (EET) From: Jukka MJ Manner To: Marcus Brunner cc: nsis@ietf.org Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting In-Reply-To: <115186559.1068556850@dyn134-139.ietf58.ietf.org> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Marcus, A snapshop from the NSIS charter: "The work produced in this Working Group should work with existing IETF mobility and AAA protocols, including (but not limited to) Mobile IP, SeaMoby Context Transfer, etc." Now, it depends on the definition of "should work", whether if meant that "it should ,but it is not a problem if it doesn't" or rather "SHOULD work" as defined in RFC2119: "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." Thus, unless you have some clear and good reasons to disregard mobility, the charter RECOMMENDS to work on those issues, too. You seem to be the only one that argues against doing this type of work... as Robert already mentioned, this most probably will not bring out any major issues compared to the wired network operation. Regards, Jukka On Tue, 11 Nov 2003, Marcus Brunner wrote: > > it is now a good time for the WG to decide whether/how to have a > > working group document on these issues), and I do think this list would > > be helpful for studying the implications of mobility on the work within > > NSIS. > > I think it is far to early to talk about mobility (even when interesting > from a research point of view.) Let's first get the work on the table done. > I do not have problem when the directions of NTLP and NSLPs are carefully > reviewed checking the impact on mobility. And I think John already > mentioned mobility is not part of the charter. > > 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 Tue Nov 11 18:15:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27799 for ; Tue, 11 Nov 2003 18:15:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJhiw-0007Xv-Ko for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 18:15:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABNF2Yb028983 for nsis-archive@odin.ietf.org; Tue, 11 Nov 2003 18:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJhiv-0007XJ-Ao; Tue, 11 Nov 2003 18:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJhiN-0007WW-Ts for nsis@optimus.ietf.org; Tue, 11 Nov 2003 18:14: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 SAA27639 for ; Tue, 11 Nov 2003 18:14:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJhiK-0004Ah-00 for nsis@ietf.org; Tue, 11 Nov 2003 18:14:24 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AJhiK-0004AG-00 for nsis@ietf.org; Tue, 11 Nov 2003 18:14:24 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Nov 2003 23:13:53 -0000 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Date: Tue, 11 Nov 2003 23:13:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] slides from today Sender: nsis-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, for those of you not fast enough to note down the URL, today's NTLP/GIMPS slides are on-line at http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-00.ppt happy reading, r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 12 03:28:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10773 for ; Wed, 12 Nov 2003 03:28:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJqM9-0002sT-34 for nsis-archive@odin.ietf.org; Wed, 12 Nov 2003 03:28:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAC8S5Dd011026 for nsis-archive@odin.ietf.org; Wed, 12 Nov 2003 03:28:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJqM5-0002rg-NQ; Wed, 12 Nov 2003 03: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 1AJqLU-0002r2-Ng for nsis@optimus.ietf.org; Wed, 12 Nov 2003 03:27: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 DAA10753 for ; Wed, 12 Nov 2003 03:27:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJqLS-0003Kx-00 for nsis@ietf.org; Wed, 12 Nov 2003 03:27:22 -0500 Received: from smtp001.mail.ukl.yahoo.com ([217.12.11.32]) by ietf-mx with smtp (Exim 4.12) id 1AJqLR-0003KU-00 for nsis@ietf.org; Wed, 12 Nov 2003 03:27:21 -0500 Received: from unknown (HELO vivaldi) (gspsl@202.14.153.7 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 12 Nov 2003 08:26:51 -0000 Reply-To: From: "Saravanan Govindan" To: Subject: RE: [NSIS] Open issue 1 in NTLP draft: Protocol Naming Date: Wed, 12 Nov 2003 16:28:26 +0800 Message-ID: <000001c3a8f6$f2d2ac60$5b71510a@vivaldi> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, SIGPORT for SIGnaling transPORT ? Saravanan -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Jukka MJ Manner Sent: Tuesday, November 11, 2003 7:50 AM To: nsis@ietf.org Subject: [NSIS] Open issue 1 in NTLP draft: Protocol Naming Hi, Keeping with typical naming within the IETF, how about "Signaling Transport Protocol (STP)" Short and simple. Cheers, Jukka _______________________________________________ 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 Nov 12 07:40:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15844 for ; Wed, 12 Nov 2003 07:40: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 1AJuI6-0007FT-EF for nsis-archive@odin.ietf.org; Wed, 12 Nov 2003 07:40:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACCeAAB027844 for nsis-archive@odin.ietf.org; Wed, 12 Nov 2003 07:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJuI0-0007DI-IQ; Wed, 12 Nov 2003 07:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJuHk-0007Bl-Ef for nsis@optimus.ietf.org; Wed, 12 Nov 2003 07:39:48 -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 HAA15688 for ; Wed, 12 Nov 2003 07:39:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJuHj-0005su-00 for nsis@ietf.org; Wed, 12 Nov 2003 07:39:47 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJuHj-0005sr-00 for nsis@ietf.org; Wed, 12 Nov 2003 07:39:47 -0500 Received: from enst.fr (dragon.enst.fr [137.194.192.44]) by infres.enst.fr (Postfix) with ESMTP id 9F1C71998 for ; Wed, 12 Nov 2003 13:39:44 +0100 (MET) Message-ID: <3FB229AD.60E5F365@enst.fr> Date: Wed, 12 Nov 2003 13:38:05 +0100 From: Nguyen Thi Mai Trang X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming References: <3FB04F88.60906@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Internet Signaling Transport Protocol, then? Henning Schulzrinne wrote: > Already taken in the SS7 context (signaling transfer point). > > Jukka MJ Manner wrote: > > > Hi, > > > > Keeping with typical naming within the IETF, how about > > > > "Signaling Transport Protocol (STP)" > > > > Short and simple. > > > > Cheers, > > Jukka > > > > > > _______________________________________________ > > 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 -- ----------------------------------------------------- Nguyen Thi Mai Trang Ecole Nationale Superieure des Telecommunications Dept. INFRES - Bur. C234-4 46 Rue Barrault - 75013 Paris Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 email : trnguyen@enst.fr _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 12 07:51:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16057 for ; Wed, 12 Nov 2003 07:51:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJuSc-0007rc-2R for nsis-archive@odin.ietf.org; Wed, 12 Nov 2003 07:51:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACCp1Lq030188 for nsis-archive@odin.ietf.org; Wed, 12 Nov 2003 07:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJuSb-0007qn-Q1; Wed, 12 Nov 2003 07:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJuS6-0007i0-Ng for nsis@optimus.ietf.org; Wed, 12 Nov 2003 07:50: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 HAA16046 for ; Wed, 12 Nov 2003 07:50:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJuS5-00064f-00 for nsis@ietf.org; Wed, 12 Nov 2003 07:50:29 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJuS5-00064c-00 for nsis@ietf.org; Wed, 12 Nov 2003 07:50:29 -0500 Received: from enst.fr (dragon.enst.fr [137.194.192.44]) by infres.enst.fr (Postfix) with ESMTP id 5A3D21934 for ; Wed, 12 Nov 2003 13:50:28 +0100 (MET) Message-ID: <3FB22C31.9FC5F91F@enst.fr> Date: Wed, 12 Nov 2003 13:48:49 +0100 From: Nguyen Thi Mai Trang X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming References: <3FB04F88.60906@cs.columbia.edu> <3FB229AD.60E5F365@enst.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sorry, this name is already taken: http://www.scte.org/documents/pdf/ANSISCTE24112001DSS0016.pdf Nguyen Thi Mai Trang wrote: > Internet Signaling Transport Protocol, then? > > Henning Schulzrinne wrote: > > > Already taken in the SS7 context (signaling transfer point). > > > > Jukka MJ Manner wrote: > > > > > Hi, > > > > > > Keeping with typical naming within the IETF, how about > > > > > > "Signaling Transport Protocol (STP)" > > > > > > Short and simple. > > > > > > Cheers, > > > Jukka > > > > > > > > > _______________________________________________ > > > 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 > > -- > ----------------------------------------------------- > Nguyen Thi Mai Trang > Ecole Nationale Superieure des Telecommunications > Dept. INFRES - Bur. C234-4 > 46 Rue Barrault - 75013 Paris > Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 > email : trnguyen@enst.fr > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- ----------------------------------------------------- Nguyen Thi Mai Trang Ecole Nationale Superieure des Telecommunications Dept. INFRES - Bur. C234-4 46 Rue Barrault - 75013 Paris Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 email : trnguyen@enst.fr _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 12 07:57:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16182 for ; Wed, 12 Nov 2003 07:57:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJuYP-00088F-5q for nsis-archive@odin.ietf.org; Wed, 12 Nov 2003 07:57:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACCv0q4031237 for nsis-archive@odin.ietf.org; Wed, 12 Nov 2003 07:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJuYO-00087j-SV; Wed, 12 Nov 2003 07:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJuXf-000872-Ga for nsis@optimus.ietf.org; Wed, 12 Nov 2003 07:56:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16147 for ; Wed, 12 Nov 2003 07:56:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJuXe-000672-00 for nsis@ietf.org; Wed, 12 Nov 2003 07:56:14 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJuXe-00066z-00 for nsis@ietf.org; Wed, 12 Nov 2003 07:56:14 -0500 Received: from enst.fr (dragon.enst.fr [137.194.192.44]) by infres.enst.fr (Postfix) with ESMTP id 2E37D1934 for ; Wed, 12 Nov 2003 13:56:13 +0100 (MET) Message-ID: <3FB22D8A.D7485651@enst.fr> Date: Wed, 12 Nov 2003 13:54:34 +0100 From: Nguyen Thi Mai Trang X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] Open issue 1 in NTLP draft: Protocol Naming References: <3FB04F88.60906@cs.columbia.edu> <3FB229AD.60E5F365@enst.fr> <3FB22C31.9FC5F91F@enst.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit How about Generic Signaling Transport Protocol? I hope that there has not been GMPLS STP yet! ;-) MT Nguyen Thi Mai Trang wrote: > Sorry, this name is already taken: > http://www.scte.org/documents/pdf/ANSISCTE24112001DSS0016.pdf > > Nguyen Thi Mai Trang wrote: > > > Internet Signaling Transport Protocol, then? > > > > Henning Schulzrinne wrote: > > > > > Already taken in the SS7 context (signaling transfer point). > > > > > > Jukka MJ Manner wrote: > > > > > > > Hi, > > > > > > > > Keeping with typical naming within the IETF, how about > > > > > > > > "Signaling Transport Protocol (STP)" > > > > > > > > Short and simple. > > > > > > > > Cheers, > > > > Jukka > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > -- > > ----------------------------------------------------- > > Nguyen Thi Mai Trang > > Ecole Nationale Superieure des Telecommunications > > Dept. INFRES - Bur. C234-4 > > 46 Rue Barrault - 75013 Paris > > Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 > > email : trnguyen@enst.fr > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > -- > ----------------------------------------------------- > Nguyen Thi Mai Trang > Ecole Nationale Superieure des Telecommunications > Dept. INFRES - Bur. C234-4 > 46 Rue Barrault - 75013 Paris > Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 > email : trnguyen@enst.fr > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- ----------------------------------------------------- Nguyen Thi Mai Trang Ecole Nationale Superieure des Telecommunications Dept. INFRES - Bur. C234-4 46 Rue Barrault - 75013 Paris Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19 email : trnguyen@enst.fr _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 12 16:57:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11985 for ; Wed, 12 Nov 2003 16:57: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 1AK2z6-000208-DE for nsis-archive@odin.ietf.org; Wed, 12 Nov 2003 16:57:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLv84X007678 for nsis-archive@odin.ietf.org; Wed, 12 Nov 2003 16:57:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2yz-0001yv-R3; Wed, 12 Nov 2003 16: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 1AK2yM-0001wl-5R for nsis@optimus.ietf.org; Wed, 12 Nov 2003 16:56: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 QAA11939 for ; Wed, 12 Nov 2003 16:56:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2yJ-0007AS-00 for nsis@ietf.org; Wed, 12 Nov 2003 16:56:19 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AK2yI-00079d-00 for nsis@ietf.org; Wed, 12 Nov 2003 16:56:19 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Nov 2003 21:55:45 -0000 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Date: Wed, 12 Nov 2003 21:55:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] next steps for the GIMPS [NTLP] spec Sender: nsis-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, Here is a quick outline of how we would like to proceed with development of the GIMPS spec. The main goal for the next version is to put together a strawman for the packet formats (basically what is in 5.1, 5.2 and 5.3.1). Basically, this should start to put some precision into the specification, and it will also highlight some of the existing open issues. In addition, we have plans for some restructuring in section 3 (adding a very simple example) and 4.3 (splitting the management of different types of state). We will also get a review of section 7 (and what it impacts). Obviously, we also want to take in inputs from the WG on the issues discussed yesterday, or the open issues highlighted in the draft section 8, or indeed anything else. We are planning to issue -01 in a couple of months. Robert & Henning PS We're also receptive to suggestions about the best way to organise the material in the draft for comprehensibility (on which some concerns were expressed). For this, ideally, catch us here this week (if you can). _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Nov 14 09:51:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12102 for ; Fri, 14 Nov 2003 09:51:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfHu-0003E1-7r for nsis-archive@odin.ietf.org; Fri, 14 Nov 2003 09:51:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEEp6UA012393 for nsis-archive@odin.ietf.org; Fri, 14 Nov 2003 09:51:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfHp-0003Dg-1x; Fri, 14 Nov 2003 09:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfHa-0003DF-BC for nsis@optimus.ietf.org; Fri, 14 Nov 2003 09:50:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12074 for ; Fri, 14 Nov 2003 09:50:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfHY-00069Y-00 for nsis@ietf.org; Fri, 14 Nov 2003 09:50:44 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AKfHX-00069U-00 for nsis@ietf.org; Fri, 14 Nov 2003 09:50:43 -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.8) with ESMTP id hAEEoZSs028604; Fri, 14 Nov 2003 15:50:35 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Nov 2003 15:51:13 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'Henning Schulzrinne'" , "Hancock, Robert" , nsis@ietf.org Cc: "Lars Westberg (KI/EAB)" , karagian@cs.utwente.nl Subject: RE: [NSIS] NTLP draft Date: Fri, 14 Nov 2003 15:51:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert and Henning, We had a discussion with Lasse and Georgios about the NTLP draft and we are sending some comments regarding NTLP draft. We think NSLP an NTLP should support at least the same scenarios as RSVP (except multicast). One example is the scenario supported by the RSVP aggregation protocol(RFC3175). In this scenario the following node types are supported: * aggregating router: the first router that enters an aggregated region; * deaggregating router: the last router in the aggregation region * interior router: any router in the aggregating region that is neither an aggregating router nor deaggregating router. What is important to note is: * the end to end RSVP messages are hidden from the interior routers inside the aggregation region. In other words, for the end to end Resv messages, the Deaggregating router is the next signaling peer of the Aggregating router. * Different messages (e.g., Aggregated Path and Aggregated Resv) are used (locally) between Aggregating router and Deaggregating to provide aggregated reservations. * an aggregation scheme is able to accomodate recursive aggregation, with aggregate reservations being themselves aggregated. The aggregation level is written in the 2 byte field of the router alert option. It can therefore, be considered that for each level of aggregation different aggregating/deaggregating signaling peers are needed. Therefore, we propose two requirements for the NTLP: * Support of multiple levels of signaling transport associations between NTLP peers. For example, in the scenario used for RSVP aggregation, many NTLP signaling associations could be applied in the aggregated region. One signaling transport association is used for the end to end type of reservations. For each aggregation level a different signaling transport association is required. * Allow the support of NTLP minimal processing or bypass nodes for some signaling transport associations. For example, in the scenario used for RSVP aggregation, when the signaling transport association is used for the end to end type of reservations, the NTLP at the interior routers in the aggregated region should carry out minimal processing. This is due to the fact that only the aggregating and deaggregating routers are processing the complete NTLP functionality. Proposed solution: One solution to these requirements could be to specify different router-alert "value" to differentiate between signaling associations. A pre-configured policy could be set in the routers to identify the appropriate signalling association. Best regards, Lasse, Georgios, Attila _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 17 07:46:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10052 for ; Mon, 17 Nov 2003 07:46:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALilA-0004uG-16 for nsis-archive@odin.ietf.org; Mon, 17 Nov 2003 07:45:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHCje7r018856 for nsis-archive@odin.ietf.org; Mon, 17 Nov 2003 07:45:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALikX-0004qk-7z; Mon, 17 Nov 2003 07:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALijd-0004pk-K6 for nsis@optimus.ietf.org; Mon, 17 Nov 2003 07:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10014 for ; Mon, 17 Nov 2003 07:43:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALijc-0005zA-00 for nsis@ietf.org; Mon, 17 Nov 2003 07:44:04 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALijc-0005z7-00 for nsis@ietf.org; Mon, 17 Nov 2003 07:44:04 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id 81C38190E; Mon, 17 Nov 2003 13:44:01 +0100 (MET) Message-ID: <00d801c3ad08$c5316c40$7907c289@pcluu> From: "Thanh Tra LUU" To: "Sung Hycuk Lee" Cc: References: Subject: Re: [NSIS] Mobility-related issues in the NTLP/QoS-NSLP Date: Mon, 17 Nov 2003 13:46:06 +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 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 Lee, Some remarks : draft-jeong-nsis-mobility-ntlp-01 : In the section 4, I think more analysis are neccessary: At first, how can NTLP sent a MOBILE object to the cross router (CRN), is it sent from the last NTLP node to the previous (next) node or to the previous/next mQoS_NSLP hop ? Secondly, how a node know if it is the appropriate cross router ? You wrote : " When a route change caused by mobility occurs,the CRN can be recognized by comparing the existing session identifier with the session identifier of the flow received from an incoming interface. If the session identifier is still the same and the flow identifier or interface number has been changed, the current NSIS-aware node is recognized as a CRN ". It seems nonsense because this node can only know there is a routing change. In the section 5, what is dead CRN ? ( CRN is broken down, NTLP of CRN is broken down ? ) If you mean peer detection (discovery), I think this is always be supported for all signaling application. for draft-lee-nsis-mobility-nslp-01 : In the 5, local repair, i don't think CRN can be NI/NR (in the way you mean ). NI/NR is the signaling entities which initiate/terminate the signaling session. For me, NI/NR can only be endhost, edge router, proxy. I dont understand the last paragraph in the section 5. More analysis are necessary in this section. regards, Nary Tra ENST, Paris ----- Original Message ----- From: "Sung Hycuk Lee" To: Sent: Tuesday, November 04, 2003 11:11 AM Subject: [NSIS] Mobility-related issues in the NTLP/QoS-NSLP > > Hi all, > > We submitted the following drafts concerning > mobility functions in the NTLP/QoS-NSLP: > > http://widecomm.korea.ac.kr/~starsu/draft-lee-nsis-mobility-nslp-01.txt > http://widecomm.korea.ac.kr/~starsu/draft-jeong-nsis-mobility-ntlp-01.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 17 10:08:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14151 for ; Mon, 17 Nov 2003 10:08:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALkzX-0002KN-1b for nsis-archive@odin.ietf.org; Mon, 17 Nov 2003 10:08:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHF8drD008942 for nsis-archive@odin.ietf.org; Mon, 17 Nov 2003 10:08:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALkyw-0002F6-Pc; Mon, 17 Nov 2003 10:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALkyK-00026u-Cg for nsis@optimus.ietf.org; Mon, 17 Nov 2003 10:07: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 KAA13963 for ; Mon, 17 Nov 2003 10:07:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALkyI-0007VD-00 for nsis@ietf.org; Mon, 17 Nov 2003 10:07:22 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1ALkyF-0007Ud-00 for nsis@ietf.org; Mon, 17 Nov 2003 10:07:19 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 15:06:45 -0000 Message-ID: From: "Hancock, Robert" To: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , nsis@ietf.org Cc: "Lars Westberg (KI/EAB)" , karagian@cs.utwente.nl, "'Henning Schulzrinne'" Subject: RE: [NSIS] NTLP draft Date: Mon, 17 Nov 2003 15:06:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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, thanks for this input. if i understand correctly, what you are saying is that you would like nodes to be able to run more than one signalling session for a given flow; one of those sessions would have the property that it might not need all the NTLP functions to be invoked. this is a possible approach. there are clearly simplifications compared to other approaches (which are equivalent to using a single message carrying the data for >1 session, which=20 obviously implies some multi-level aspects to the encapsulation used). OTOH what needs to be understood here is how much the different=20 sessions need to 'know' about each other, and which layer in the=20 NSIS stack knows about this relationship. in particular, if one session needs 'help' from the other to function correctly (e.g.=20 congestion management or error reporting), the edge nodes need to understand the binding at the GIMPS level; at the moment, it isn't clear to me whether this specific support in the protocol. (it's similar to the tunnel binding question, see section 6.5 of the draft.) r. > -----Original Message----- > From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com] > Sent: Friday, November 14, 2003 08:51 > To: 'Henning Schulzrinne'; Hancock, Robert; nsis@ietf.org > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl > Subject: RE: [NSIS] NTLP draft >=20 >=20 > Hi Robert and Henning, >=20 > We had a discussion with Lasse and Georgios about the NTLP=20 > draft and we are sending some comments regarding NTLP draft. >=20 > We think NSLP an NTLP should support at least the same=20 > scenarios as RSVP (except multicast).=20 > One example is the scenario supported by the RSVP aggregation=20 > protocol(RFC3175). > In this scenario the following node types are supported: > * aggregating router: the first router that enters an=20 > aggregated region; > * deaggregating router: the last router in the aggregation region > * interior router: any router in the aggregating region that=20 > is neither=20 > an aggregating router nor deaggregating router. >=20 > What is important to note is: > * the end to end RSVP messages are hidden from the interior=20 > routers inside the aggregation region. In other words, for=20 > the end to end Resv messages, the Deaggregating router is the=20 > next signaling peer of the Aggregating router. > * Different messages (e.g., Aggregated Path and Aggregated=20 > Resv) are used (locally) between Aggregating router and=20 > Deaggregating to provide aggregated reservations. > * an aggregation scheme is able to accomodate recursive=20 > aggregation, with aggregate reservations being themselves=20 > aggregated. The aggregation level is written in the 2 byte=20 > field of the router alert option. It can therefore, be=20 > considered that for each level of aggregation different=20 > aggregating/deaggregating signaling peers are needed.=20 >=20 > Therefore, we propose two requirements for the NTLP: >=20 > * Support of multiple levels of signaling transport=20 > associations between NTLP peers. For example, in the scenario=20 > used for RSVP aggregation, many NTLP signaling associations=20 > could be applied in the aggregated region. One signaling=20 > transport association is used for the end to end type of=20 > reservations. For each aggregation level a different=20 > signaling transport association is required. >=20 > * Allow the support of NTLP minimal processing or bypass=20 > nodes for some signaling transport associations. > For example, in the scenario used for RSVP aggregation, when=20 > the signaling transport association is used for the end to=20 > end type of reservations, the NTLP at the interior routers in=20 > the aggregated region should carry out minimal processing.=20 > This is due to the fact that only the aggregating and=20 > deaggregating routers are processing the complete NTLP functionality. >=20 > Proposed solution: > One solution to these requirements could be to specify=20 > different router-alert "value" to differentiate between=20 > signaling associations. A pre-configured policy could be set=20 > in the routers to identify the appropriate signalling association. >=20 > Best regards, Lasse, Georgios, Attila >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 18 03:01:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09479 for ; Tue, 18 Nov 2003 03:01:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM0mu-0007qE-Df for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 03:00:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI80ekq030143 for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 03:00:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM0mI-0007lW-9z; Tue, 18 Nov 2003 03:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM0m9-0007kx-EJ for nsis@optimus.ietf.org; Tue, 18 Nov 2003 02:59:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09424 for ; Tue, 18 Nov 2003 02:59:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM0m5-00002W-00 for nsis@ietf.org; Tue, 18 Nov 2003 02:59:49 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AM0lw-00002R-00 for nsis@ietf.org; Tue, 18 Nov 2003 02:59:48 -0500 Received: from LocalHost (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hAI7wHls017870; Tue, 18 Nov 2003 16:58:26 +0900 (KST) From: "Sung Hycuk Lee" To: "Thanh Tra LUU" Cc: , "Seong-Ho Jeong" Subject: RE: [NSIS] Mobility-related issues in the NTLP/QoS-NSLP Date: Tue, 18 Nov 2003 16:58:33 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <00d801c3ad08$c5316c40$7907c289@pcluu> Importance: Normal Content-Transfer-Encoding: base64 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgTmFyeSBUcmEsDQogDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQpQbGVhc2UsIHJlZmVy IHRvIG15IGNvbW1lbnRzIFtTLUhdIGluIGxpbmU7DQogDQpSZWdhcmRzLA0KDQpTdW5nLUh5dWNr DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOYXJ5 IFRyYSB3cm90ZTsNCiANCj4gZHJhZnQtamVvbmctbnNpcy1tb2JpbGl0eS1udGxwLTAxIDoNCj4g DQo+IEluIHRoZSBzZWN0aW9uIDQsIEkgdGhpbmsgbW9yZSBhbmFseXNpcyBhcmUgbmVjY2Vzc2Fy eToNCj4gDQo+IEF0IGZpcnN0LCBob3cgY2FuIE5UTFAgc2VudCBhIE1PQklMRSBvYmplY3QgdG8g dGhlIGNyb3NzIHJvdXRlciANCj4gKENSTiksIGlzIGl0DQo+IHNlbnQgZnJvbSB0aGUgbGFzdCBO VExQIG5vZGUgdG8gdGhlIHByZXZpb3VzIChuZXh0KSBub2RlIG9yIHRvIHRoZQ0KPiBwcmV2aW91 cy9uZXh0IG1Rb1NfTlNMUCBob3AgPw0KDQpbUy1IXSBXZSBhc3N1bWUgdGhhdCB0aGUgTU9CSUxJ VFkgb2JqZWN0IGNhbiBiZSBwYXJ0IG9mIHRoZSBOVExQDQogICAgICAgaW5mb3JtYXRpb24gaW4g bW9iaWxlIHNjZW5hcmlvcywgc28gaXQgY2FuIGJlIHNlbnQgdG8gdGhlIENSTiBieSANCiAgICAg ICBhIHBlZXIgZGlzY292ZXJ5IG1lc3NhZ2UgYWZ0ZXIgaGFuZG92ZXIuIElmIHRoZSBpbnRlcmFj dGlvbnMgd2l0aCANCiAgICAgICBDQVJEICYgQ1QgYXJlIGNvbnNpZGVyZWQsIHRoZSBNT0JJTElU WSBvYmplY3QgY2FuIGFsc28gYmUgDQogICAgICAgdHJhbnNmZXJyZWQgZnJvbSBhbiBPQVIgdG8g dGhlIENSTiBieSB0aGUgQ1QgZHVyaW5nIGhhbmRvdmVyLiANCiAgICAgICBXZSBhbHNvIGFzc3Vt ZSB0aGF0IGEgcGVlciBkaXNjb3ZlcnkgbWVzc2FnZSBpcyBzZW50IGJldHdlZW4gDQogICAgICAg TlRMUCBub2RlcyBhZnRlciBoYW5kb3ZlciwgYW5kIGFmdGVyd2FyZCB0aGUgbVFvUy1OU0xQIHN0 YXRlIA0KICAgICAgIGNhbiBiZSByZS1lc3RhYmxpc2hlZCBmYXN0IHRocm91Z2ggdGhlIENSTi4g DQogICAgICAgIA0KID4gU2Vjb25kbHksIGhvdyBhIG5vZGUga25vdyBpZiBpdCBpcyB0aGUgYXBw cm9wcmlhdGUgY3Jvc3Mgcm91dGVyID8gDQo+IFlvdSB3cm90ZQ0KPiA6ICIgV2hlbiBhIHJvdXRl IGNoYW5nZSBjYXVzZWQgYnkgbW9iaWxpdHkgb2NjdXJzLHRoZSBDUk4gY2FuIGJlIA0KPiByZWNv Z25pemVkDQo+IGJ5IGNvbXBhcmluZyB0aGUgZXhpc3Rpbmcgc2Vzc2lvbiBpZGVudGlmaWVyIHdp dGggdGhlIHNlc3Npb24gDQo+IGlkZW50aWZpZXIgb2YNCj4gdGhlIGZsb3cgcmVjZWl2ZWQgZnJv bSBhbiBpbmNvbWluZyBpbnRlcmZhY2UuIElmIHRoZSBzZXNzaW9uIGlkZW50aWZpZXIgaXMNCj4g c3RpbGwgdGhlIHNhbWUgYW5kIHRoZSBmbG93IGlkZW50aWZpZXIgb3IgaW50ZXJmYWNlIG51bWJl ciBoYXMgDQo+IGJlZW4gY2hhbmdlZCwNCj4gdGhlIGN1cnJlbnQgTlNJUy1hd2FyZSBub2RlIGlz IHJlY29nbml6ZWQgYXMgYSBDUk4gIi4gSXQgc2VlbXMgbm9uc2Vuc2UNCj4gYmVjYXVzZSB0aGlz IG5vZGUgY2FuIG9ubHkga25vdyB0aGVyZSBpcyBhIHJvdXRpbmcgY2hhbmdlLg0KDQpbUy1IXSBB ZnRlciBhIHJvdXRlIGNoYW5nZSBjYXVzZWQgYnkgbW9iaWxpdHksIGFuIE5TSVMgbm9kZSBjYW4g c2V0IHVwIHRoZSANCiAgICAgICBOVExQIHN0YXRlIGFsb25nIHRoZSBuZXcgcGF0aCBieSBwZWVy IGRpc2NvdmVyeS4gVGhhdCBpcywgaWYgYW4gTlNJUyANCiAgICAgICBub2RlIGhhcyB0d28gZGlm ZmVyZW50IE5UTFAgc3RhdGVzIHdpdGggdGhlIHNhbWUgbVFvUy1OU0xQIGFuZCANCiAgICAgICBz ZXNzaW9uIGlkZW50aWZpZXIsIGl0IGNhbiBiZSBhbiBhcHByb3ByaWF0ZSBDUk4uIE5vdGUgdGhh dCBhbiBOU0lTLWF3YXJlDQogICAgICAgQ1JOIHNob3VsZCBiZSBhIG1lcmdpbmcgcG9pbnQgb2Yg dGhlIG9sZCBhbmQgbmV3IHBhdGhzLCB3aGljaCBzaG91bGQNCiAgICAgICBoYXZlIHR3byBkaWZm ZXJlbnQgKG9sZCBhbmQgbmV3KSBOVExQIHN0YXRlcy4NCg0KPiBJbiB0aGUgc2VjdGlvbiA1LCB3 aGF0IGlzIGRlYWQgQ1JOID8gKCBDUk4gaXMgYnJva2VuIGRvd24sIE5UTFAgb2YgQ1JOIGlzDQo+ IGJyb2tlbiBkb3duID8gKSBJZiB5b3UgbWVhbiBwZWVyIGRldGVjdGlvbiAoZGlzY292ZXJ5KSwg SSB0aGluayB0aGlzIGlzDQo+IGFsd2F5cyBiZSBzdXBwb3J0ZWQgZm9yIGFsbCBzaWduYWxpbmcg YXBwbGljYXRpb24uDQoNCltTLUhdIFdlIG1lbnRpb25lZCB0aGF0IHRoZSBDUk4gaXRzZWxmIGNv dWxkIGJlIGNvbnNpZGVyZWQgZGVhZCB3aGVuIGl0IHdhcw0KICAgICAgICB0ZW1wb3JhcmlseSBv ciBwZXJtYW5lbnRseSBkaXNjb25uZWN0ZWQgZnJvbSB0aGUgbmV0d29yayBkdWUgdG8gdGhlIA0K ICAgICAgICBmYWlsdXJlIG9mIGNvbW11bmljYXRpb24gbGlua3MgKG9yIHByb2Nlc3NvcnMpLCBz eXN0ZW0gcmVib290aW5nLCBvciBub2RlDQogICAgICAgIGNvbmdlc3Rpb24uIEl0IGlzIGFsc28g cG9zc2libGUgdGhhdCB0aGUgTlRMUCBvZiBDUk4gZG9lcyBub3Qgd29yayBwcm9wZXJseQ0KICAg ICAgICAoaW4gdGhpcyBjYXNlLCB0aGUgQ1JOIGNhbiBhbHNvIGJlIGNvbnNpZGVyZWQgZGVhZCku IERlYWQgcGVlciBkaXNjb3ZlcnkNCiAgICAgICAgY2FuIGJlIGNvbnNpZGVyZWQgYXMgYW4gZXh0 ZW5zaW9uIHRvIHRoZSBwZWVyIGRpc2NvdmVyeS4NCg0KPiBmb3IgZHJhZnQtbGVlLW5zaXMtbW9i aWxpdHktbnNscC0wMSA6DQo+IA0KPiBJbiB0aGUgNSwgbG9jYWwgcmVwYWlyLCBpIGRvbid0IHRo aW5rIENSTiBjYW4gYmUgTkkvTlIgKGluIHRoZSB3YXkgeW91DQo+IG1lYW4gKS4gTkkvTlIgaXMg dGhlIHNpZ25hbGluZyBlbnRpdGllcyB3aGljaCBpbml0aWF0ZS90ZXJtaW5hdGUgdGhlDQo+IHNp Z25hbGluZyBzZXNzaW9uLiBGb3IgbWUsIE5JL05SIGNhbiBvbmx5IGJlIGVuZGhvc3QsIGVkZ2Ug cm91dGVyLCBwcm94eS4NCg0KW1MtSF0gUGxlYXNlIHJlZmVyIHRvIFNlY3Rpb24gNS4yIGluIHRo ZSBOU0lTIHNpZ25hbGluZyByZXF1aXJlbWVudHMgZHJhZnQgDQogICAgICAgIHdoaWNoIGFkZHJl c3NlcyB0aGF0IHRoZSBwbGFjZW1lbnQgb2YgTlNJUyBJbml0aWF0b3IsIEZvcndhcmRlciwgYW5k IA0KICAgICAgICBSZXNwb25kZXIgYW55d2hlcmUgaW4gdGhlIG5ldHdvcmsgTVVTVCBiZSBhbGxv d2VkLiBQbGVhc2UgYWxzbyANCiAgICAgICAgc2VlIFNlY3Rpb24gNS42LjIgaW4gdGhlIE5TSVMg c2lnbmFsaW5nIHJlcXVpcmVtZW50cyBkcmFmdCB3aGljaCANCiAgICAgICAgYWRkcmVzc2VzIGZs ZXhpYmlsaXR5IGluIHRoZSBwbGFjZW1lbnQgb2YgdGhlIE5TSVMgSW5pdGlhdG9yL1Jlc3BvbmRl ci4gDQoNCiAgICAgICAgSWYgYW4gTU4gaXMgYSBzZW5kZXIsIHRoZSBDUk4gY2FuIHNlbmQgYSBS ZXN2IG1lc3NhZ2UgKG9yIGFuIEFDSw0KICAgICAgICBtZXNzYWdlKSBpbiByZXNwb25zZSB0byBh IFBhdGggbWVzc2FnZSAob3IgYSBSRVNFUlZFIG1lc3NnZSkgZnJvbQ0KICAgICAgICB0aGUgTU4g dG8gbG9jYWxpemUgdGhlIHJlLWVzdGFibGlzaG1lbnQgb2YgbVFvUy1OU0xQIHN0YXRlLiBJbiB0 aGlzIGNhc2UgDQogICAgICAgIHRoZSBDUk4gYWN0cyBhcyBhbiBOUi4gSWYgYW4gTU4gaXMgYSBy ZWNlaXZlciwgdGhlIENSTiBjYW4gc2VuZCBhIA0KICAgICAgICBQYXRoIG1lc3NnZSAob3IgYSBS RVNFUlZFIG1lc3NhZ2UpIHRvd2FyZCB0aGUgTU4gdG8gZmFzdCByZS1lc3RhYmxpc2ggDQogICAg ICAgIG1Rb1MtTlNMUCBzdGF0ZS4gSW4gdGhpcyBjYXNlLCB0aGUgQ1JOIGFjdHMgYXMgYW4gTkku DQoNCj4gSSBkb250IHVuZGVyc3RhbmQgdGhlIGxhc3QgcGFyYWdyYXBoIGluIHRoZSBzZWN0aW9u IDUuDQoNCltTLUhdICBUaGUgbGFzdCBwYXJhZ3JhcGggYWRkcmVzc2VzIHRoZSBsYXN0LW5vZGUt ZGV0ZWN0aW9uIHByb2JsZW0gDQogICAgICAgIHdoaWNoIG1heSBvY2N1ciBpbiBtb2JpbGUgc2Nl bmFyaW9zLiBBbiBOU0lTIG5vZGUgY2FuIHBlcmlvY2FsbHkgDQogICAgICAgIHNlbmQgcGVlciBk aXNjb3ZlcnkgbWVzc2FnZXMgdG8gZGV0ZWN0IGRlYWQgcGVlciBub2Rlcy4gSWYgdGhlIHByZXZp b3VzIA0KICAgICAgICBub2RlIG9mIHRoZSBsYXN0IG5vZGUgZGV0ZWN0cyB0aGF0IHRoZSBzaWdu YWxpbmcgbWVzc2FnZSBjYW4gbm90IGJlIA0KICAgICAgICBmb3J3YXJkZWQgdG8gdGhlIGxhc3Qg bm9kZSBmb3Igc29tZSByZWFzb24sIHRoZSBOU0lTIG5vZGUgbWF5IG5lZWQgdG8NCiAgICAgICAg bm90aWZ5IHRoZSBzZW5kZXIgb2YgdGhlIHNpZ25hbGluZyBtZXNzZ2Ugb2YgdW5yZWFjaGFiaWxp dHkgc3RhdGUgKG9mIA0KICAgICAgICBzaWduYWxpbmcgbWVzc2FnZSkgYnkgaW5pdGlhdGluZyBh biBlcnJvciBtZXNzYWdlIGluZGljYXRpbmcgICANCiAgICAgICAgJ0Nhbi1Ob3QtQmUtRm9yd2Fy ZGVkLXRvLXRoZS1MYXN0LU5vZGUnLiBUaGVyZWZvcmUsIHRoZSBzaWduYWxpbmcgc2Vzc2lvbg0K ICAgICAgICBzdGF0ZSB3aWxsIG5vdCBiZSB1cGRhdGVkIGJ5IHNpZ25hbGluZyBtZXNzYWdlcyBv ciB3aWxsIGJlIHJlbW92ZWQuDQoNCiAgICAgICBJZiBhbiBNTiBpcyB0aGUgbGFzdCBub2RlIG9m IHRoZSBtUW9TLU5TTFAgc2Vzc2lvbiwgdGhlIE9BUiBtYXkgaW5pdGlhdGUgDQogICAgICAgdGhl IGVycm9yIG1lc3NhZ2UgaW5kaWNhdGluZyAnQ2FuLU5vdC1CZS1Gb3J3YXJkZWQtdG8tdGhlLUxh c3QtTm9kZScgDQogICAgICAgYWZ0ZXIgaGFuZG92ZXIuIEhvd2V2ZXIsIE5FcyBhbG9uZyB0aGUg b2xkIHBhdGggc2hvdWxkIG5vdCByZW1vdmUgdGhlIA0KICAgICAgIG1Rb1MtTlNMUCBzdGF0ZSBi ZWZvcmUgcmUtZXN0YWJsaXNobWVudCBvZiB0aGUgbVFvUy1OU0xQIHN0YXRlIA0KICAgICAgIGFs b25nIG5ldyBwYXRoLiBQbGVhc2UgcmVmZXIgdG8gU2VjdGlvbiA1IG9mIGRyYWZ0LWplb25nLW5z aXMtbW9iaWxpdHktbnRscC0wMS4gDQoNCj4gcmVnYXJkcywNCj4gDQo+IE5hcnkgVHJhDQo+IEVO U1QsIFBhcmlzDQo+IA0KPiANCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9t OiAiU3VuZyBIeWN1ayBMZWUiIDxzdGFyc3VAc2FpdC5zYW1zdW5nLmNvLmtyPg0KPiBUbzogPG5z aXNAaWV0Zi5vcmc+DQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA0LCAyMDAzIDExOjExIEFN DQo+IFN1YmplY3Q6IFtOU0lTXSBNb2JpbGl0eS1yZWxhdGVkIGlzc3VlcyBpbiB0aGUgTlRMUC9R b1MtTlNMUA0KPiANCj4gDQo+ID4NCj4gPiBIaSBhbGwsDQo+ID4NCj4gPiBXZSBzdWJtaXR0ZWQg dGhlIGZvbGxvd2luZyBkcmFmdHMgY29uY2VybmluZw0KPiA+IG1vYmlsaXR5IGZ1bmN0aW9ucyBp biB0aGUgTlRMUC9Rb1MtTlNMUDoNCj4gPg0KPiA+IGh0dHA6Ly93aWRlY29tbS5rb3JlYS5hYy5r ci9+c3RhcnN1L2RyYWZ0LWxlZS1uc2lzLW1vYmlsaXR5LW5zbHAtMDEudHh0DQo+ID4gDQpodHRw Oi8vd2lkZWNvbW0ua29yZWEuYWMua3IvfnN0YXJzdS9kcmFmdC1qZW9uZy1uc2lzLW1vYmlsaXR5 LW50bHAtMDEudHh0DQo= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 18 06:03:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14254 for ; Tue, 18 Nov 2003 06:03:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3dy-0003LP-Us for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 06:03:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIB3c5b012856 for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 06:03:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3dN-0003Gu-OR; Tue, 18 Nov 2003 06:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3d4-0003GN-C4 for nsis@optimus.ietf.org; Tue, 18 Nov 2003 06:02:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14227 for ; Tue, 18 Nov 2003 06:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3d0-0002cS-00 for nsis@ietf.org; Tue, 18 Nov 2003 06:02:38 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3cz-0002cO-00 for nsis@ietf.org; Tue, 18 Nov 2003 06:02:37 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id E242E1B54; Tue, 18 Nov 2003 12:02:36 +0100 (MET) Message-ID: <003c01c3adc3$c764b600$7907c289@pcluu> From: "Thanh Tra LUU" To: "Sung Hycuk Lee" Cc: References: <20031118094128.60962.qmail@web21508.mail.yahoo.com> Subject: Re: [NSIS] Mobility-related issues in the NTLP/QoS-NSLP Date: Tue, 18 Nov 2003 12:04:45 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C3ADCC.2879A420" 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 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C3ADCC.2879A420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi Lee, [S-H] After a route change caused by mobility, an NSIS node can set up = the NTLP state along the new path by peer discovery. That is, if an NSIS = node has two different NTLP states with the same mQoS-NSLP and session = identifier, it can be an appropriate CRN. Note that an NSIS-aware CRN = should be a merging point of the old and new paths, which should have = two different (old and new) NTLP states. Why are there two NTLP states ? [S-H] We mentioned that the CRN itself could be considered dead when it = was temporarily or permanently disconnected from the network due to the = failure of communication links (or processors), system rebooting, or = node congestion. It is also possible that the NTLP of CRN does not work = properly (in this case, the CRN can also be considered dead). Dead peer = discoverycan be considered as an extension to the peer discovery. Dead=3Dinterruption ?=20 > for draft-lee-nsis-mobility-nslp-01 : >=20 > In the 5, local repair, i don't think CRN can be NI/NR (in the way you > mean ). NI/NR is the signaling entities which initiate/terminate the > signaling session. For me, NI/NR can only be endhost, edge router, = proxy. [S-H] Please refer to Section 5.2 in the NSIS signaling requirements = draft=20 which addresses that the placement of NSIS Initiator, Forwarder, = and=20 Responder anywhere in the network MUST be allowed. Please also=20 see Section 5.6.2 in the NSIS signaling requirements draft which = addresses flexibility in the placement of the NSIS = Initiator/Responder.=20 If an MN is a sender, the CRN can send a Resv message (or an ACK message) in response to a Path message (or a RESERVE messge) = from the MN to localize the re-establishment of mQoS-NSLP state. In = this case=20 the CRN acts as an NR. If an MN is a receiver, the CRN can send = a=20 Path messge (or a RESERVE message) toward the MN to fast = re-establish=20 mQoS-NSLP state. In this case, the CRN acts as an NI. I totally agree about the placement of NI,NR, NF in the requirement = draft. However, if you mean CRN is a NI/NR, it mean that CRN initiate a = new signaling application session and it can terminate this session. In = case of handover, CRN just send the trigger message which it has = receiced before (with some modified parameters) to reestablish the = session a new path. As a result, CRN is not the NI/NR. > I dont understand the last paragraph in the section 5. [S-H] The last paragraph addresses the last-node-detection problem=20 which may occur in mobile scenarios. An NSIS node can periocally = send peer discovery messages to detect dead peer nodes. If the = previous=20 node of the last node detects that the signaling message can not = be=20 forwarded to the last node for some reason, the NSIS node may = need to notify the sender of the signaling messge of unreachability = state (of=20 signaling message) by initiating an error message indicating =20 'Can-Not-Be-Forwarded-to-the-Last-Node'. Therefore, the = signaling session state will not be updated by signaling messages or will be = removed. If an MN is the last node of the mQoS-NSLP session, the OAR may = initiate=20 the error message indicating = 'Can-Not-Be-Forwarded-to-the-Last-Node'=20 after handover. However, NEs along the old path should not remove = the=20 mQoS-NSLP state before re-establishment of the mQoS-NSLP state=20 along new path. Please refer to Section 5 of = draft-jeong-nsis-mobility-ntlp-01.=20 ok. I agree. Nary Tra ENST, Paris ------=_NextPart_000_0039_01C3ADCC.2879A420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi Lee,
 
[S-H] After a=20 route change caused by mobility, an NSIS node can set up the NTLP state = along=20 the new path by peer discovery. That is, if an NSIS node has two = different NTLP=20 states with the same mQoS-NSLP and session identifier, it can be an = appropriate=20 CRN. Note that an NSIS-aware CRN should be a merging point of the old = and new=20 paths, which should have two different (old and new) NTLP=20 states.
Why are there two NTLP states ?
 
[S-H] We mentioned that the = CRN itself=20 could be considered dead when it was temporarily or permanently = disconnected=20 from the network due to the failure of communication links (or = processors),=20 system rebooting, or node congestion. It is also possible that the NTLP = of CRN=20 does not work properly (in this case, the CRN can also be considered = dead). Dead=20 peer discoverycan be considered as an extension to the peer=20 discovery.
Dead=3Dinterruption ?

> = for=20 draft-lee-nsis-mobility-nslp-01 :
>
> In the 5, local = repair, i=20 don't think CRN can be NI/NR (in the way you
> mean ). NI/NR is = the=20 signaling entities which initiate/terminate the
> signaling = session. For=20 me, NI/NR can only be endhost, edge router, proxy.

[S-H] Please = refer to=20 Section 5.2 in the NSIS signaling requirements draft=20
        which addresses that the=20 placement of NSIS Initiator, Forwarder, and=20
        Responder anywhere in the = network=20 MUST be allowed. Please also =
        see=20 Section 5.6.2 in the NSIS signaling requirements draft which=20
        addresses flexibility in = the=20 placement of the NSIS Initiator/Responder.=20

        If an MN is a sender, = the CRN=20 can send a Resv message (or an = ACK
       =20 message) in response to a Path message (or a RESERVE messge)=20 from
        the MN to localize = the=20 re-establishment of mQoS-NSLP state. In this case=20
        the CRN acts as an NR. If = an MN=20 is a receiver, the CRN can send a =
       =20 Path messge (or a RESERVE message) toward the MN to fast re-establish=20
        mQoS-NSLP state. In this = case,=20 the CRN acts as an NI.

I totally = agree about the=20 placement of NI,NR, NF in the requirement draft. However, if you mean = CRN is a=20 NI/NR, it mean that CRN initiate a new signaling application session and = it can=20 terminate this session. In case of handover, CRN just send the trigger=20 message  which it has receiced before (with some modified = parameters) to=20 reestablish the session a new path. As a result, CRN is not the=20 NI/NR.
 
 
> I dont understand the last paragraph in the section=20 5.

[S-H]  The last paragraph addresses the = last-node-detection=20 problem
        which may occur = in mobile=20 scenarios. An NSIS node can periocally=20
        send peer discovery = messages to=20 detect dead peer nodes. If the previous=20
        node of the last node = detects=20 that the signaling message can not be=20
        forwarded to the last = node for=20 some reason, the NSIS node may need=20 to
        notify the sender of = the=20 signaling messge of unreachability state (of=20
        signaling message) by = initiating=20 an error message indicating  =20
       =20 'Can-Not-Be-Forwarded-to-the-Last-Node'. Therefore, the signaling=20 session
        state will not be = updated=20 by signaling messages or will be=20 removed.

       If an MN is the = last node=20 of the mQoS-NSLP session, the OAR may initiate=20
       the error message indicating=20 'Can-Not-Be-Forwarded-to-the-Last-Node' =
      =20 after handover. However, NEs along the old path should not remove the=20
       mQoS-NSLP state before = re-establishment=20 of the mQoS-NSLP state
       along = new path.=20 Please refer to Section 5 of draft-jeong-nsis-mobility-ntlp-01. =
ok. I agree.
 
Nary Tra
ENST, Paris
------=_NextPart_000_0039_01C3ADCC.2879A420-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 18 06:20:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14971 for ; Tue, 18 Nov 2003 06:20:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3uP-0004zN-1P for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 06:20:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIBKb80019172 for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 06:20:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3tp-0004t8-NK; Tue, 18 Nov 2003 06:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3sv-0004lX-G0 for nsis@optimus.ietf.org; Tue, 18 Nov 2003 06:19: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 GAA14834 for ; Tue, 18 Nov 2003 06:18:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3sr-0002p8-00 for nsis@ietf.org; Tue, 18 Nov 2003 06:19:01 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AM3sq-0002o9-00 for nsis@ietf.org; Tue, 18 Nov 2003 06:19:01 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 11:18:29 -0000 Message-ID: From: "McDonald, Andrew" To: "'Cheng Hong'" , nsis@ietf.org, sven.van_den_bosch@alcatel.be Cc: Thanh Tra LUU Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt Date: Tue, 18 Nov 2003 11:18:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: nsis-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: , Cheng Hong wrote: > I have the similar question as Nary about the RII. Is that the same > as SII? Can it be just replace by the SII or using the same value? No, they are different. The RII (Requestor Identification Information) is something that goes in a message when you want to get a response (and is included in the response). It means: when the response gets passed back along the path it should not be forwarded beyond me. (It's a form of scope identifier.) The SII is an identifier between NSLP peers. The primary purpose is for working out if your NSLP neighbour has changed. (And possibly as an identifier for use with some form of NTLP explicit routing to allow removal of resources on an old path.) They are created (and used) by different nodes along the path and have different properties. So, they can't be the same thing. > Besides that, I have a few more comments on the -01 draft. > > a) Section 1.2 says "Only messages related to QoS are passed to the > QoS-NSLP. The NTLP may also generate triggers to the QoS-NSLP > (e.g.indications that a route change has occurred)." > > I don't think QoS-NSLP would be the only QoS related Signaling > Application. It is somehow confusing. Therefore, I think it maybe > better to clarify that as: > > "Only messages related to the particular QoS NSLP, e.g. indicated by > the Signaling Application Identifier defined in 4.6.3 of [3], are > passed to the QoS-NSLP.The NTLP may also generate triggers to the > QoS-NSLP (e.g.indications that a route change has occurred)." Yes, that could probably do with some clarification. > b) In Section 2.1, it says "Messages are normally passed from the > NSLP to the NTLP via an API,which also specifies the signaling > application (as QoS-NSLP), the flow/session identifier, and an > indication of the intended direction - towards data sender or > receiver." > > It sounds that the session identifier is provided through the NTLP. > And other than here, there is no mentioning about the session > identifier. My feeling is that it is better for the NSLP to actual > maintain the session ID, since there my be several session come from > the same NSLP instance, and only NSLP knows how to correlate the > session and flows. Therefore, it would be better to provide some > description about the operation on session ID in the NSLP draft. Again, extra text will be needed on the workings on flow/session identifiers. This is currently mentioned only in passing in the Open Issues section on Mobility. I think the current belief is that the session identifier is in the NTLP part of the message (and in some sense maintained by the NTLP). The NSLP however needs to perform whatever processing is necessary when multiple flows are associated with a single session. > c) In section 3.1 RESERVE, it is mentioned that "Note that the > potential initiation of (reverse path) state removal at the NTLP is a > separate issue. This will be signaled over the API between NTLP and > QoS-NSLP." > > Shouldn't the state removal a business of the NSLP only? NTLP could > provide hint/trigger for that, but the decision should still be made > by the NSLP. Also, whether to use API for this purpose is purely > implementation issue, e.g. we could use loopback message instead. There are a number of different levels at which state might exist. The NTLP may have some, besides what is needed by the NSLP (e.g. it's 'routing' state). It's not necessarily obvious that the NSLP should say to the NTLP: "get rid of that state". For example, it might also be in use by another NSLP at the time, or be needed to finish the NSLP state removal. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 18 10:34:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25965 for ; Tue, 18 Nov 2003 10:34:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7sH-0002Mn-86 for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 10:34:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIFYfq6009082 for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 10:34:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7rc-0002K6-VN; Tue, 18 Nov 2003 10:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7rK-0002Ju-FG for nsis@optimus.ietf.org; Tue, 18 Nov 2003 10:33:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25886 for ; Tue, 18 Nov 2003 10:33:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7rI-0006yl-00 for nsis@ietf.org; Tue, 18 Nov 2003 10:33:40 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AM7rG-0006yS-00 for nsis@ietf.org; Tue, 18 Nov 2003 10:33:39 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP for nsis@ietf.org; Tue, 18 Nov 2003 16:32:50 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Nov 2003 16:33:06 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6C7@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: nsis@ietf.org Date: Tue, 18 Nov 2003 16:33:02 +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 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] QoS NSLP expectations Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all, the actual state of NTLP, mobility and firewall=20 signaling seems to be relatively promising. The QoS NSLP work may benefit from a more focused scope. The draft-01 QoS NSLP is flexible=20 enough to support almost any application (message=20 set, signaling relations, scoping, stacking,=20 state models and in a future version aggregation).=20 It is more than QoS specific. The authors circumvent the sensitive issue of=20 determining or selecting particular QoS models.=20 I agree that NSIS shouldn't define QoS models.=20 I also agree that the QoS NSLP should be suitable=20 for all possible QoS models.=20 I'd favour an attempt like the one used for RTP:=20 NSIS defines the basic QoS NSLP and leaves it to=20 interested parties to standardise QoS model=20 specific behaviour. NSIS should clearly state,=20 where this should be done (NSIS, I'd suggest). The QoS NSLP should be provide a minimum set of=20 functionality and allow for QoS NSLP specific=20 extensions. If as many options are kept as offered by the current QoS NSLP draft, at least a basic=20 default behaviour should be defined. Otherwise=20 interoperability is at risk. The draft may further benefit if NSIS tried to develop=20 a detailed specification supporting deployed QoS=20 models. This should be an academic excercise - at=20 best informational or a non binding annex. Examples=20 of operational QoS models: - GEANT Premium service - hose model based QoS services (offered as part of=20 IP VPN services) - Internet2's LBE - ?? The QoS NSLP shouldn't be optimised for these services.=20 It should however easily be customisable to support=20 them in a deployable way. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 18 11:45:01 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29713 for ; Tue, 18 Nov 2003 11:45:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8y2-0007Yq-94 for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 11:44:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIGigXU029064 for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 11:44:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8xN-0007U4-Nb; Tue, 18 Nov 2003 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8wV-0007TM-LP for nsis@optimus.ietf.org; Tue, 18 Nov 2003 11:43:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29604 for ; Tue, 18 Nov 2003 11:42:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8wU-0000WT-00 for nsis@ietf.org; Tue, 18 Nov 2003 11:43:06 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AM8wT-0000WQ-00 for nsis@ietf.org; Tue, 18 Nov 2003 11:43:05 -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.8) with ESMTP id hAIGfJSs027523; Tue, 18 Nov 2003 17:41:20 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 17:41:19 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Hancock, Robert" , nsis@ietf.org Cc: "Lars Westberg (KI/EAB)" , karagian@cs.utwente.nl, "'Henning Schulzrinne'" Subject: RE: [NSIS] NTLP draft Date: Tue, 18 Nov 2003 17:42:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Robert,=20 see comments inline > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Monday, November 17, 2003 4:07 PM > To: Attila B=E1der (IJ/ETH); nsis@ietf.org > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl; 'Henning > Schulzrinne' > Subject: RE: [NSIS] NTLP draft >=20 >=20 > hi attila, >=20 > thanks for this input. if i understand correctly, what you > are saying is that you would like nodes to be able to run > more than one signalling session for a given flow; one of > those sessions would have the property that it might not > need all the NTLP functions to be invoked. >=20 Yes, exactly,=20 > this is a possible approach. there are clearly simplifications > compared to other approaches (which are equivalent to using > a single message carrying the data for >1 session, which=20 > obviously implies some multi-level aspects to the encapsulation > used). Yes, we propose it instead of multi-level encapsulation and I think = this is an important feature for achieving scalability. > OTOH what needs to be understood here is how much the different=20 > sessions need to 'know' about each other, and which layer in the=20 > NSIS stack knows about this relationship. in particular, if=20 > one session > needs 'help' from the other to function correctly (e.g.=20 > congestion management or error reporting), the edge nodes need > to understand the binding at the GIMPS level; at the moment, it > isn't clear to me whether this specific support in the protocol. > (it's similar to the tunnel binding question, see section 6.5 > of the draft.) I think we should distinguish different kind of aggregations e.g. per = routing states or per DSCP. In the first case, I think, it would be = reasonable if NTLP could bind these sessions in the (de)aggregator = nodes. In the second case DSCP and level indicator could be used to = bind messages together. It may be enough if NSLP layer knows about this = relationship but may be I am wrong. Best regards, Attila >=20 > r. >=20 > > -----Original Message----- > > From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com] > > Sent: Friday, November 14, 2003 08:51 > > To: 'Henning Schulzrinne'; Hancock, Robert; nsis@ietf.org > > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl > > Subject: RE: [NSIS] NTLP draft > >=20 > >=20 > > Hi Robert and Henning, > >=20 > > We had a discussion with Lasse and Georgios about the NTLP=20 > > draft and we are sending some comments regarding NTLP draft. > >=20 > > We think NSLP an NTLP should support at least the same=20 > > scenarios as RSVP (except multicast).=20 > > One example is the scenario supported by the RSVP aggregation=20 > > protocol(RFC3175). > > In this scenario the following node types are supported: > > * aggregating router: the first router that enters an=20 > > aggregated region; > > * deaggregating router: the last router in the aggregation region > > * interior router: any router in the aggregating region that=20 > > is neither=20 > > an aggregating router nor deaggregating router. > >=20 > > What is important to note is: > > * the end to end RSVP messages are hidden from the interior=20 > > routers inside the aggregation region. In other words, for=20 > > the end to end Resv messages, the Deaggregating router is the=20 > > next signaling peer of the Aggregating router. > > * Different messages (e.g., Aggregated Path and Aggregated=20 > > Resv) are used (locally) between Aggregating router and=20 > > Deaggregating to provide aggregated reservations. > > * an aggregation scheme is able to accomodate recursive=20 > > aggregation, with aggregate reservations being themselves=20 > > aggregated. The aggregation level is written in the 2 byte=20 > > field of the router alert option. It can therefore, be=20 > > considered that for each level of aggregation different > > aggregating/deaggregating signaling peers are needed.=20 > >=20 > > Therefore, we propose two requirements for the NTLP: > >=20 > > * Support of multiple levels of signaling transport=20 > > associations between NTLP peers. For example, in the scenario=20 > > used for RSVP aggregation, many NTLP signaling associations=20 > > could be applied in the aggregated region. One signaling=20 > > transport association is used for the end to end type of=20 > > reservations. For each aggregation level a different=20 > > signaling transport association is required. > >=20 > > * Allow the support of NTLP minimal processing or bypass=20 > > nodes for some signaling transport associations. > > For example, in the scenario used for RSVP aggregation, when=20 > > the signaling transport association is used for the end to=20 > > end type of reservations, the NTLP at the interior routers in=20 > > the aggregated region should carry out minimal processing.=20 > > This is due to the fact that only the aggregating and=20 > > deaggregating routers are processing the complete NTLP=20 > functionality. > >=20 > > Proposed solution: > > One solution to these requirements could be to specify=20 > > different router-alert "value" to differentiate between=20 > > signaling associations. A pre-configured policy could be set=20 > > in the routers to identify the appropriate signalling association. > >=20 > > Best regards, Lasse, Georgios, Attila > >=20 >=20 > -- > Registered Office: Roke Manor Research Ltd, Siemens House,=20 > Oldbury, Bracknell, > Berkshire. RG12 8FZ >=20 > The information contained in this e-mail and any attachments=20 > is confidential to > Roke Manor Research Ltd and must not be passed to any third=20 > party without > permission. This communication is for information only and=20 > shall not create or > change any contractual relationship. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Nov 18 15:07:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11060 for ; Tue, 18 Nov 2003 15:07:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMC8R-0003nc-Sh for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 15:07:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIK7dBm014604 for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 15:07:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMC7q-0003Y9-HW; Tue, 18 Nov 2003 15:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMC7j-0003WQ-Qk for nsis@optimus.ietf.org; Tue, 18 Nov 2003 15:06:55 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10832; Tue, 18 Nov 2003 15:06:42 -0500 (EST) Message-Id: <200311182006.PAA10832@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: nsis@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 18 Nov 2003 15:06:41 -0500 Subject: [NSIS] I-D ACTION:draft-lee-nsis-mobility-nslp-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility Functions in the QoS-NSLP Author(s) : S. Lee Filename : draft-lee-nsis-mobility-nslp-01.txt Pages : 18 Date : 2003-11-18 The NSIS working group is standardizing a signaling protocol suite with QoS signaling as the first use case. The overall signaling protocol suite is decomposed into a generic lower layer with separate upper layers for signaling applications. The upper layer protocol, called NSIS Signaling Layer Protocol (NSLP), has an end-to-end scope and contains application specific functionality. One of the important features of an NSLP is mobility support. This document identifies desired mobility functions in an NSLP for QoS signaling (QoS-NSLP) in the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-nsis-mobility-nslp-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lee-nsis-mobility-nslp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lee-nsis-mobility-nslp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-18124046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lee-nsis-mobility-nslp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-lee-nsis-mobility-nslp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-18124046.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 03:05:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08023 for ; Wed, 19 Nov 2003 03:05:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMNKO-0001o5-5m for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 03:04:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ84hlV006943 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 03:04:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMNJj-0001lB-HN; Wed, 19 Nov 2003 03:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMNJ7-0001kC-UU for nsis@optimus.ietf.org; Wed, 19 Nov 2003 03:03: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 DAA07986 for ; Wed, 19 Nov 2003 03:03:11 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMNJ3-0002c0-00 for nsis@ietf.org; Wed, 19 Nov 2003 03:03:21 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMNJ3-0002bw-00 for nsis@ietf.org; Wed, 19 Nov 2003 03:03:21 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJ83KA03787 for ; Wed, 19 Nov 2003 10:03:21 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 10:03:15 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 10:03:16 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] QoS NSLP expectations Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 19 Nov 2003 10:03:15 +0200 Message-ID: Thread-Topic: [NSIS] QoS NSLP expectations Thread-Index: AcOt6XDVpYUECcy/RoGQ0ZUEfrZEiQAieepA To: , X-OriginalArrivalTime: 19 Nov 2003 08:03:16.0174 (UTC) FILETIME=[963FC6E0:01C3AE73] 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 Rudiger, > the actual state of NTLP, mobility and firewall=20 > signaling seems to be relatively promising. > The QoS NSLP work may benefit from a more focused > scope. The draft-01 QoS NSLP is flexible=20 > enough to support almost any application (message=20 > set, signaling relations, scoping, stacking,=20 > state models and in a future version aggregation).=20 > It is more than QoS specific. >=20 > The authors circumvent the sensitive issue of=20 > determining or selecting particular QoS models.=20 > I agree that NSIS shouldn't define QoS models.=20 > I also agree that the QoS NSLP should be suitable=20 > for all possible QoS models.=20 >=20 > I'd favour an attempt like the one used for RTP:=20 > NSIS defines the basic QoS NSLP and leaves it to=20 > interested parties to standardise QoS model=20 > specific behaviour. NSIS should clearly state,=20 > where this should be done (NSIS, I'd suggest). >=20 > The QoS NSLP should be provide a minimum set of=20 > functionality and allow for QoS NSLP specific=20 > extensions. If as many options are kept as offered > by the current QoS NSLP draft, at least a basic=20 > default behaviour should be defined. Otherwise=20 > interoperability is at risk. I basically agree with your points above. > The draft may further benefit if NSIS tried to develop=20 > a detailed specification supporting deployed QoS=20 > models. This should be an academic excercise - at=20 > best informational or a non binding annex. Examples=20 > of operational QoS models: > - GEANT Premium service > - hose model based QoS services (offered as part of=20 > IP VPN services) > - Internet2's LBE > - ?? > The QoS NSLP shouldn't be optimised for these services.=20 > It should however easily be customisable to support=20 > them in a deployable way. One suggest would be to take 1 or 2 existing QoS models and detail them in a seperate draft, as as a sort of=20 proof-of-concept for the QoS NSLP. These documents could exist as individual submissions, but could be considered by the WG. =20 John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 03:46:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09019 for ; Wed, 19 Nov 2003 03:46:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMNy1-0003ok-L1 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 03:45:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ8jfV5014652 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 03:45:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMNxO-0003jr-W6; Wed, 19 Nov 2003 03: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 1AMNxK-0003jV-LW for nsis@optimus.ietf.org; Wed, 19 Nov 2003 03:44:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08999 for ; Wed, 19 Nov 2003 03:44:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMNxI-00037H-00 for nsis@ietf.org; Wed, 19 Nov 2003 03:44:56 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AMNxH-00037E-00 for nsis@ietf.org; Wed, 19 Nov 2003 03:44:55 -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 hAJ8ir8R006896; Wed, 19 Nov 2003 09:44:53 +0100 (MET) Message-ID: <001c01c3ae79$674755f0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "=?iso-8859-1?Q?Attila_B=E1der_\=28IJ/ETH\=29?=" , References: Subject: Re: [NSIS] NTLP draft Date: Wed, 19 Nov 2003 09:44:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by utrhcs.cs.utwente.nl id hAJ8ir8R006896 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 Yes, indeed this type of solution can be used instead of the multi-level encapsulation. Best Regards, Georgios ----- Original Message ----- From: "Attila B=E1der (IJ/ETH)" To: "Hancock, Robert" ; Cc: "Lars Westberg (KI/EAB)" ; ; "'Henning Schulzrinne'" Sent: Tuesday, November 18, 2003 5:42 PM Subject: RE: [NSIS] NTLP draft > Hi Robert, > > see comments inline > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Monday, November 17, 2003 4:07 PM > > To: Attila B=E1der (IJ/ETH); nsis@ietf.org > > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl; 'Henning > > Schulzrinne' > > Subject: RE: [NSIS] NTLP draft > > > > > > hi attila, > > > > thanks for this input. if i understand correctly, what you > > are saying is that you would like nodes to be able to run > > more than one signalling session for a given flow; one of > > those sessions would have the property that it might not > > need all the NTLP functions to be invoked. > > > Yes, exactly, > > > this is a possible approach. there are clearly simplifications > > compared to other approaches (which are equivalent to using > > a single message carrying the data for >1 session, which > > obviously implies some multi-level aspects to the encapsulation > > used). > > Yes, we propose it instead of multi-level encapsulation and I think thi= s is an important feature for achieving scalability. > > > OTOH what needs to be understood here is how much the different > > sessions need to 'know' about each other, and which layer in the > > NSIS stack knows about this relationship. in particular, if > > one session > > needs 'help' from the other to function correctly (e.g. > > congestion management or error reporting), the edge nodes need > > to understand the binding at the GIMPS level; at the moment, it > > isn't clear to me whether this specific support in the protocol. > > (it's similar to the tunnel binding question, see section 6.5 > > of the draft.) > > I think we should distinguish different kind of aggregations e.g. per routing states or per DSCP. In the first case, I think, it would be reasonable if NTLP could bind these sessions in the (de)aggregator nodes.= In the second case DSCP and level indicator could be used to bind messages together. It may be enough if NSLP layer knows about this relationship bu= t may be I am wrong. > > Best regards, Attila > > > > > r. > > > > > -----Original Message----- > > > From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com] > > > Sent: Friday, November 14, 2003 08:51 > > > To: 'Henning Schulzrinne'; Hancock, Robert; nsis@ietf.org > > > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl > > > Subject: RE: [NSIS] NTLP draft > > > > > > > > > Hi Robert and Henning, > > > > > > We had a discussion with Lasse and Georgios about the NTLP > > > draft and we are sending some comments regarding NTLP draft. > > > > > > We think NSLP an NTLP should support at least the same > > > scenarios as RSVP (except multicast). > > > One example is the scenario supported by the RSVP aggregation > > > protocol(RFC3175). > > > In this scenario the following node types are supported: > > > * aggregating router: the first router that enters an > > > aggregated region; > > > * deaggregating router: the last router in the aggregation region > > > * interior router: any router in the aggregating region that > > > is neither > > > an aggregating router nor deaggregating router. > > > > > > What is important to note is: > > > * the end to end RSVP messages are hidden from the interior > > > routers inside the aggregation region. In other words, for > > > the end to end Resv messages, the Deaggregating router is the > > > next signaling peer of the Aggregating router. > > > * Different messages (e.g., Aggregated Path and Aggregated > > > Resv) are used (locally) between Aggregating router and > > > Deaggregating to provide aggregated reservations. > > > * an aggregation scheme is able to accomodate recursive > > > aggregation, with aggregate reservations being themselves > > > aggregated. The aggregation level is written in the 2 byte > > > field of the router alert option. It can therefore, be > > > considered that for each level of aggregation different > > > aggregating/deaggregating signaling peers are needed. > > > > > > Therefore, we propose two requirements for the NTLP: > > > > > > * Support of multiple levels of signaling transport > > > associations between NTLP peers. For example, in the scenario > > > used for RSVP aggregation, many NTLP signaling associations > > > could be applied in the aggregated region. One signaling > > > transport association is used for the end to end type of > > > reservations. For each aggregation level a different > > > signaling transport association is required. > > > > > > * Allow the support of NTLP minimal processing or bypass > > > nodes for some signaling transport associations. > > > For example, in the scenario used for RSVP aggregation, when > > > the signaling transport association is used for the end to > > > end type of reservations, the NTLP at the interior routers in > > > the aggregated region should carry out minimal processing. > > > This is due to the fact that only the aggregating and > > > deaggregating routers are processing the complete NTLP > > functionality. > > > > > > Proposed solution: > > > One solution to these requirements could be to specify > > > different router-alert "value" to differentiate between > > > signaling associations. A pre-configured policy could be set > > > in the routers to identify the appropriate signalling association. > > > > > > Best regards, Lasse, Georgios, Attila > > > > > > > -- > > Registered Office: Roke Manor Research Ltd, Siemens House, > > Oldbury, Bracknell, > > Berkshire. RG12 8FZ > > > > The information contained in this e-mail and any attachments > > is confidential to > > Roke Manor Research Ltd and must not be passed to any third > > party without > > permission. This communication is for information only and > > shall not create or > > change any contractual relationship. > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 04:48:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10386 for ; Wed, 19 Nov 2003 04:48:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMOw3-00070t-6m for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 04:47:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ9lgHP026955 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 04:47:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMOvP-0006wV-Jm; Wed, 19 Nov 2003 04:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMOum-0006w4-3u for nsis@optimus.ietf.org; Wed, 19 Nov 2003 04:46: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 EAA10369 for ; Wed, 19 Nov 2003 04:46:10 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMOui-0003sZ-00 for nsis@ietf.org; Wed, 19 Nov 2003 04:46:20 -0500 Received: from gc-na165.alcatel.fr ([64.208.49.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AMOui-0003sW-00 for nsis@ietf.org; Wed, 19 Nov 2003 04:46:20 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id hAJ9kFCZ022440; Wed, 19 Nov 2003 10:46:15 +0100 Subject: Re: [NSIS] QoS NSLP expectations To: "Geib, Ruediger" Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 19 Nov 2003 10:46:13 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 11/19/2003 10:46:15 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Ruediger, Thanks for your comments on the draft. I think our view on the QoS mode= l is actually in line with what you propose. What we currently propose in th= e draft is to have a template for the QSpec and the consensus during the meeting was that we should define which parts of this template should b= e specified in the QoS NSLP draft. Also, we explicitly support what we ca= ll local QoS models which can be regarded as the QoS model specific extens= ions you refer to. I agree with you that the scope of the work is fairly broad, but I beli= eve it is not broader then the suite of RSVP-related RFCs that touch on the= QoS signalling issue. Are there any of the topics that we currently have in= the draft that you feel we should not be addressing? Best regards, Sven "Geib, Ruediger" @ietf.org on 18/11/2003 16:33:02 Sent by: nsis-admin@ietf.org To: nsis@ietf.org cc: Subject: [NSIS] QoS NSLP expectations Dear all, the actual state of NTLP, mobility and firewall signaling seems to be relatively promising. The QoS NSLP work may benefit from a more focused scope. The draft-01 QoS NSLP is flexible enough to support almost any application (message set, signaling relations, scoping, stacking, state models and in a future version aggregation). It is more than QoS specific. The authors circumvent the sensitive issue of determining or selecting particular QoS models. I agree that NSIS shouldn't define QoS models. I also agree that the QoS NSLP should be suitable for all possible QoS models. I'd favour an attempt like the one used for RTP: NSIS defines the basic QoS NSLP and leaves it to interested parties to standardise QoS model specific behaviour. NSIS should clearly state, where this should be done (NSIS, I'd suggest). The QoS NSLP should be provide a minimum set of functionality and allow for QoS NSLP specific extensions. If as many options are kept as offered by the current QoS NSLP draft, at least a basic default behaviour should be defined. Otherwise interoperability is at risk. The draft may further benefit if NSIS tried to develop a detailed specification supporting deployed QoS models. This should be an academic excercise - at best informational or a non binding annex. Examples of operational QoS models: - GEANT Premium service - hose model based QoS services (offered as part of IP VPN services) - Internet2's LBE - ?? The QoS NSLP shouldn't be optimised for these services. It should however easily be customisable to support them in a deployable way. Regards, R=FCdiger _______________________________________________ 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 Nov 19 05:54:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12172 for ; Wed, 19 Nov 2003 05:54:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMPyn-0001T2-81 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 05:54:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJAsbhg005622 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 05:54:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMPyC-0001OA-PZ; Wed, 19 Nov 2003 05:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMPxO-0001NZ-Cz for nsis@optimus.ietf.org; Wed, 19 Nov 2003 05:53:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12128 for ; Wed, 19 Nov 2003 05:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMPxK-0004mx-00 for nsis@ietf.org; Wed, 19 Nov 2003 05:53:06 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AMPxJ-0004mV-00 for nsis@ietf.org; Wed, 19 Nov 2003 05:53:06 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 19 Nov 2003 11:52:03 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Nov 2003 11:52:18 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6C8@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] QoS NSLP expectations Date: Wed, 19 Nov 2003 11:52:07 +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 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Sven, |I agree with you that the scope of the work is fairly broad,=20 |but I believe it is not broader then the suite of=20 |RSVP-related RFCs that touch on the QoS signalling issue.=20 |Are there any of the topics that we currently have in the |draft that you feel we should not be addressing? As compared to RSVP, NSLP QoS isn't optimised for=20 mobility support. But it adds=20 ( - indicates difference): message set - let's say nothing signaling relations - end-to-end is desired scoping - completely new stacking - completely new state models - reduced state and stateless added aggregation - remains to be seen. During the Minneapolis meeting I had the impression, that=20 QoS NSLP may support service- and parameter negotiation. I'd prefer the default NSLP QoS operation to offer the=20 features of the RSVP suite (no multicast, but including=20 aggregation). A few new "mandatory options" have to be=20 implemented (like requesting congestion awareness and=20 reliable transport from NTLP). Other features like=20 scoping, stacking or negotiation should be purely=20 optional (for implementation and support). Before I comment on the new "state modes" I'd like to get=20 a better understanding of what they mean. Which state is=20 maintained in which case? How does a stateless node differ=20 from a node not supporting NSIS at all? End-to-end signaling may be desireable. It however touches=20 on security issues, which I for now prefer to leave =20 out of my considerations. A currently missing aspect is operational stability. A later=20 version of the draft must specify handling of unknown=20 parameters and codings. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 06:25:54 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12845 for ; Wed, 19 Nov 2003 06:25:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQSp-0002yr-0U for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 06:25:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJBPcCH011451 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 06:25:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQSF-0002uY-9P; Wed, 19 Nov 2003 06:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQRa-0002ss-6M for nsis@optimus.ietf.org; Wed, 19 Nov 2003 06:24: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 GAA12837 for ; Wed, 19 Nov 2003 06:24:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMQRW-0005B1-00 for nsis@ietf.org; Wed, 19 Nov 2003 06:24:18 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AMQRV-0005Ay-00 for nsis@ietf.org; Wed, 19 Nov 2003 06:24:17 -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 hAJBNa8R016420; Wed, 19 Nov 2003 12:23:36 +0100 (MET) Message-ID: <007a01c3ae8f$93c87490$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Geib, Ruediger" Cc: References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6C8@G8PQD.blf01.telekom.de> Subject: Re: [NSIS] QoS NSLP expectations Date: Wed, 19 Nov 2003 12:23:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by utrhcs.cs.utwente.nl id hAJBNa8R016420 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Ruediger Thank you for your remarks! I totally agree with you that the default NSLP QoS operation may offer th= e features of the RSVP suite (no multicast, but including aggregation). I also agree with you that there will be few new "mandatory options" to be implemented (like requesting (or not requesting) congestion awarene= ss and reliable transport from NTLP). I also agree with you that there will be other features optional. Further discussions on this is needed. The reduced state and stateless modes are modes will probably be purely optional (for implementation and support). You might consider the RSVP aggregation support as an example of reduced state operation type. You might consider any MBAC (Measurement Based Admission Control) scheme = as an example of stateless operation type. Best Regards, Georgios ----- Original Message ----- From: "Geib, Ruediger" To: Cc: Sent: Wednesday, November 19, 2003 11:52 AM Subject: RE: [NSIS] QoS NSLP expectations > Hi Sven, > > |I agree with you that the scope of the work is fairly broad, > |but I believe it is not broader then the suite of > |RSVP-related RFCs that touch on the QoS signalling issue. > |Are there any of the topics that we currently have in the > |draft that you feel we should not be addressing? > > As compared to RSVP, NSLP QoS isn't optimised for > mobility support. But it adds > ( - indicates difference): > > message set - let's say nothing > signaling relations - end-to-end is desired > scoping - completely new > stacking - completely new > state models - reduced state and stateless added > aggregation - remains to be seen. > > During the Minneapolis meeting I had the impression, that > QoS NSLP may support service- and parameter negotiation. > > I'd prefer the default NSLP QoS operation to offer the > features of the RSVP suite (no multicast, but including > aggregation). A few new "mandatory options" have to be > implemented (like requesting congestion awareness and > reliable transport from NTLP). Other features like > scoping, stacking or negotiation should be purely > optional (for implementation and support). > > Before I comment on the new "state modes" I'd like to get > a better understanding of what they mean. Which state is > maintained in which case? How does a stateless node differ > from a node not supporting NSIS at all? > > End-to-end signaling may be desireable. It however touches > on security issues, which I for now prefer to leave > out of my considerations. > > A currently missing aspect is operational stability. A later > version of the draft must specify handling of unknown > parameters and codings. > > Regards, R=FCdiger > > > > _______________________________________________ > 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 Nov 19 07:00:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13739 for ; Wed, 19 Nov 2003 07:00:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMR0i-0004Q5-Sm for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 07:00:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJC0eTD016988 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 07:00:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMR06-0004Lj-FQ; Wed, 19 Nov 2003 07:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQzC-0004J2-9d for nsis@optimus.ietf.org; Wed, 19 Nov 2003 06:59: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 GAA13684 for ; Wed, 19 Nov 2003 06:58:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMQz7-0005nC-00 for nsis@ietf.org; Wed, 19 Nov 2003 06:59:01 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AMQz7-0005mS-00 for nsis@ietf.org; Wed, 19 Nov 2003 06:59:01 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 19 Nov 2003 12:44:37 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Nov 2003 12:44:52 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6C9@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: karagian@cs.utwente.nl Cc: nsis@ietf.org Subject: RE: [NSIS] QoS NSLP expectations Date: Wed, 19 Nov 2003 12:44:46 +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 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 Georgios, thanks for your answers. Agreed text deleted, two remarks: |You might consider the RSVP aggregation support as an example=20 |of reduced state operation type. Great to hear, I hoped for that comment.=20 |You might consider any MBAC (Measurement Based Admission=20 |Control) scheme as an example of stateless operation type. I don't think "any" would hold. Some MBAC algorithms expect=20 prior knowledge source traffic characteristics. Others=20 clearly benefit from knowing "per flow" characteristics.=20 In the core this can only be derived from signaled=20 information (unless individual flows are measured, which=20 I don't regard as an option). Further, also MBAC schemes=20 may require information about route changes (e.g. if they=20 should accept "exceptional" loads as a result of a link=20 failure they may need to be notified of the "exceptional" status). Regards, R=FCdiger |----- Original Message ----- |From: "Geib, Ruediger" |To: |Cc: |Sent: Wednesday, November 19, 2003 11:52 AM |Subject: RE: [NSIS] QoS NSLP expectations | | |> Hi Sven, |> |> |I agree with you that the scope of the work is fairly broad, |> |but I believe it is not broader then the suite of |> |RSVP-related RFCs that touch on the QoS signalling issue. |> |Are there any of the topics that we currently have in the |> |draft that you feel we should not be addressing? |> |> As compared to RSVP, NSLP QoS isn't optimised for |> mobility support. But it adds |> ( - indicates difference): |> |> message set - let's say nothing |> signaling relations - end-to-end is desired |> scoping - completely new |> stacking - completely new |> state models - reduced state and stateless added |> aggregation - remains to be seen. |> |> During the Minneapolis meeting I had the impression, that |> QoS NSLP may support service- and parameter negotiation. |> |> I'd prefer the default NSLP QoS operation to offer the |> features of the RSVP suite (no multicast, but including |> aggregation). A few new "mandatory options" have to be |> implemented (like requesting congestion awareness and |> reliable transport from NTLP). Other features like |> scoping, stacking or negotiation should be purely |> optional (for implementation and support). |> |> Before I comment on the new "state modes" I'd like to get |> a better understanding of what they mean. Which state is |> maintained in which case? How does a stateless node differ |> from a node not supporting NSIS at all? |> |> End-to-end signaling may be desireable. It however touches |> on security issues, which I for now prefer to leave |> out of my considerations. |> |> A currently missing aspect is operational stability. A later |> version of the draft must specify handling of unknown |> parameters and codings. |> |> Regards, R=FCdiger |> |> |> |> _______________________________________________ |> 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 Nov 19 07:13:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14006 for ; Wed, 19 Nov 2003 07:13:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRDC-00053J-JY for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 07:13:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJCDYjH019402 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 07:13:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRCd-0004yI-9h; Wed, 19 Nov 2003 07:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRBv-0004w3-SR for nsis@optimus.ietf.org; Wed, 19 Nov 2003 07:12:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13963 for ; Wed, 19 Nov 2003 07:12:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRBv-0005xI-00 for nsis@ietf.org; Wed, 19 Nov 2003 07:12:15 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AMRBu-0005wm-00 for nsis@ietf.org; Wed, 19 Nov 2003 07:12:14 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 19 Nov 2003 12:54:45 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Nov 2003 12:55:01 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6CA@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk, hgs@cs.columbia.edu Cc: nsis@ietf.org Date: Wed, 19 Nov 2003 12:54:58 +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 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] NTLP - separated functionalities Sender: nsis-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, Henning it may be worth considering a separation of NTLP=20 "route change discovery" from NTLP "service state=20 management". Comparing the requirements of both=20 funtions, it seems that - Route change discovery is enabled by=20 connectionless transport and router alert at=20 high detection frequency. The shorter the=20 "route change discovery" interval, the higher=20 service availability. - Service state management works best with=20 connection oriented (secure, reliable) transport=20 and medium refresh frequency (say every=20 30 seconds at the access, slower at the core). While above statement in itself may not justify=20 a separation of functionalities, a slightly deeper=20 analysis of route change discovery may help: - Both, service provider and user prefer a high=20 service availability. Hence discovery and service=20 restoration should be fast (for now let's say=20 below 5 seconds). - If route changes are detected by RSVP style=20 refresh packets, their frequency should be in=20 close orders of magnitude at access and core=20 network (say once per second at the access=20 and 100 ms at the core). - Core Load Balancing in combination with Terminal=20 mobility must not create high signaling load as=20 a result of route change discovery activities=20 while data flows remain "balanced". Looking at the last three arguments, a fair=20 question may be whether separation of route change=20 discovery mechanisms from other NTLP functions would=20 be a first step only. A second may be to ask, whether=20 simple the end-to-end route change discovery approach=20 of RSVP can't be replaced by a slightly more complex=20 alternative exposing the desired operational=20 behaviour in all parts of the network. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 07:21:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14174 for ; Wed, 19 Nov 2003 07:21:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRKy-0005KU-RF for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 07:21:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJCLal9020468 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 07:21:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRKP-0005Fk-Gt; Wed, 19 Nov 2003 07:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRK9-0005FR-T5 for nsis@optimus.ietf.org; Wed, 19 Nov 2003 07:20:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14151 for ; Wed, 19 Nov 2003 07:20:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRK9-00065H-00 for nsis@ietf.org; Wed, 19 Nov 2003 07:20:45 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AMRK8-000651-00 for nsis@ietf.org; Wed, 19 Nov 2003 07:20:44 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP for nsis@ietf.org; Wed, 19 Nov 2003 13:00:30 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Nov 2003 13:00:45 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6CB@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: nsis@ietf.org Date: Wed, 19 Nov 2003 13:00:45 +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 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Any Router Alert Option influence on router performance? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all, should anybody of you be aware of measurements=20 comparing the influence of processing "router=20 alert option" packets on router processing as=20 compared to complete absence of these packets,=20 I'd appreciate information or a URL. The=20 background isn't to prevent such messages. I'm=20 interested in learning more about the level=20 (if any) where they start to hurt. Regards, R=FCdiger=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 07:32:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14438 for ; Wed, 19 Nov 2003 07:32:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRVd-0005se-9a for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 07:32:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJCWbWw022586 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 07:32:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRV4-0005nr-3Q; Wed, 19 Nov 2003 07:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRUm-0005n3-G0 for nsis@optimus.ietf.org; Wed, 19 Nov 2003 07:31:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14407 for ; Wed, 19 Nov 2003 07:31:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRUl-0006DA-00 for nsis@ietf.org; Wed, 19 Nov 2003 07:31:43 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AMRUl-0006D5-00 for nsis@ietf.org; Wed, 19 Nov 2003 07:31:43 -0500 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id hAJCVe8R020099; Wed, 19 Nov 2003 13:31:40 +0100 (MET) Message-ID: <00a801c3ae99$160bb080$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Geib, Ruediger" Cc: References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6C9@G8PQD.blf01.telekom.de> Subject: Re: [NSIS] QoS NSLP expectations Date: Wed, 19 Nov 2003 13:31:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by utrhcs.cs.utwente.nl id hAJCVe8R020099 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Ruediger > > |You might consider any MBAC (Measurement Based Admission > |Control) scheme as an example of stateless operation type. > > I don't think "any" would hold. Some MBAC algorithms expect > prior knowledge source traffic characteristics. Others > clearly benefit from knowing "per flow" characteristics. > In the core this can only be derived from signaled > information (unless individual flows are measured, which > I don't regard as an option). Further, also MBAC schemes > may require information about route changes (e.g. if they > should accept "exceptional" loads as a result of a link > failure they may need to be notified of the "exceptional" > status). Agreed with you on the term "any". There are some (not any) MBAC schemes that can be used as examples of stateless operation type. Best regards, Georgios > |----- Original Message ----- > |From: "Geib, Ruediger" > |To: > |Cc: > |Sent: Wednesday, November 19, 2003 11:52 AM > |Subject: RE: [NSIS] QoS NSLP expectations > | > | > |> Hi Sven, > |> > |> |I agree with you that the scope of the work is fairly broad, > |> |but I believe it is not broader then the suite of > |> |RSVP-related RFCs that touch on the QoS signalling issue. > |> |Are there any of the topics that we currently have in the > |> |draft that you feel we should not be addressing? > |> > |> As compared to RSVP, NSLP QoS isn't optimised for > |> mobility support. But it adds > |> ( - indicates difference): > |> > |> message set - let's say nothing > |> signaling relations - end-to-end is desired > |> scoping - completely new > |> stacking - completely new > |> state models - reduced state and stateless added > |> aggregation - remains to be seen. > |> > |> During the Minneapolis meeting I had the impression, that > |> QoS NSLP may support service- and parameter negotiation. > |> > |> I'd prefer the default NSLP QoS operation to offer the > |> features of the RSVP suite (no multicast, but including > |> aggregation). A few new "mandatory options" have to be > |> implemented (like requesting congestion awareness and > |> reliable transport from NTLP). Other features like > |> scoping, stacking or negotiation should be purely > |> optional (for implementation and support). > |> > |> Before I comment on the new "state modes" I'd like to get > |> a better understanding of what they mean. Which state is > |> maintained in which case? How does a stateless node differ > |> from a node not supporting NSIS at all? > |> > |> End-to-end signaling may be desireable. It however touches > |> on security issues, which I for now prefer to leave > |> out of my considerations. > |> > |> A currently missing aspect is operational stability. A later > |> version of the draft must specify handling of unknown > |> parameters and codings. > |> > |> Regards, R=FCdiger > |> > |> > |> > |> _______________________________________________ > |> nsis mailing list > |> nsis@ietf.org > |> https://www1.ietf.org/mailman/listinfo/nsis > |> > | > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 09:10:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17106 for ; Wed, 19 Nov 2003 09:10:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMT1b-0003By-4Q for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 09:09:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJE9h4u012264 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 09:09:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMT0v-00036y-MM; Wed, 19 Nov 2003 09: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 1AMT0l-00036O-Is for nsis@optimus.ietf.org; Wed, 19 Nov 2003 09:08: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 JAA17070 for ; Wed, 19 Nov 2003 09:08:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMT0j-0007V5-00 for nsis@ietf.org; Wed, 19 Nov 2003 09:08:50 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AMT0j-0007V2-00 for nsis@ietf.org; Wed, 19 Nov 2003 09:08:49 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAJE8jU6013988; Wed, 19 Nov 2003 09:08:45 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hAJE8hf16739; Wed, 19 Nov 2003 09:08:44 -0500 Message-ID: <3FBB796B.4030505@cs.columbia.edu> Date: Wed, 19 Nov 2003 09:08:43 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Geib, Ruediger" CC: robert.hancock@roke.co.uk, nsis@ietf.org Subject: Re: [NSIS] NTLP - separated functionalities References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6CA@G8PQD.blf01.telekom.de> In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6CA@G8PQD.blf01.telekom.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id hAJE8jU6013988 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks for your comments. You are describing a variation of the CASP=20 approach, where discovery was a special service. The current design does not prevent frequent probing, if an application=20 so desires and is willing to pay the price in bandwidth and processing.=20 The advantage of combining the two is efficiency and faster initial=20 setup. I do agree that it may be worthwhile to allow, as an operational=20 mode, more frequent, small 'hello' packets between NTLP peers. We'll=20 need to work out the details, but I think this can be supported in the=20 existing framework. I don't want to make this mandatory since there are=20 engineering trade-offs. Sending a probe packet a second is only a 2%=20 overhead if you're sending 50 audio packets a second, but it is not so=20 great if the packet rate is lower (and/or the data packets are larger).=20 We may also revive an approach Ping Pan and I published under the YESSIR=20 label, where probing is integrated with the data flow, thus producing=20 extremely fast recovery, at the cost of more node processing. As far as I know, RSVP had a probing interval of 30 seconds, not one=20 second or below (although that is obviously tunable). Route change discovery by probing only matters if routers supporting=20 NTLP are far apart, i.e., outside the same IGP. Otherwise, it seems much=20 better to just use the routing information to track changes, as that's=20 already being delivered for free. Geib, Ruediger wrote: > Robert, Henning >=20 > it may be worth considering a separation of NTLP=20 > "route change discovery" from NTLP "service state=20 > management". Comparing the requirements of both=20 > funtions, it seems that >=20 > - Route change discovery is enabled by=20 > connectionless transport and router alert at=20 > high detection frequency. The shorter the=20 > "route change discovery" interval, the higher=20 > service availability. > - Service state management works best with=20 > connection oriented (secure, reliable) transport=20 > and medium refresh frequency (say every=20 > 30 seconds at the access, slower at the core). >=20 > While above statement in itself may not justify=20 > a separation of functionalities, a slightly deeper=20 > analysis of route change discovery may help: >=20 > - Both, service provider and user prefer a high=20 > service availability. Hence discovery and service=20 > restoration should be fast (for now let's say=20 > below 5 seconds). > - If route changes are detected by RSVP style=20 > refresh packets, their frequency should be in=20 > close orders of magnitude at access and core=20 > network (say once per second at the access=20 > and 100 ms at the core). > - Core Load Balancing in combination with Terminal=20 > mobility must not create high signaling load as=20 > a result of route change discovery activities=20 > while data flows remain "balanced". >=20 > Looking at the last three arguments, a fair=20 > question may be whether separation of route change=20 > discovery mechanisms from other NTLP functions would=20 > be a first step only. A second may be to ask, whether=20 > simple the end-to-end route change discovery approach=20 > of RSVP can't be replaced by a slightly more complex=20 > alternative exposing the desired operational=20 > behaviour in all parts of the network. >=20 > Regards, R=FCdiger >=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 Wed Nov 19 12:51:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29493 for ; Wed, 19 Nov 2003 12:51:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWTd-0003ML-22 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 12:50:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJHoq7f012890 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 12:50:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWSn-0003G5-ES; Wed, 19 Nov 2003 12:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWS6-00034y-JF for nsis@optimus.ietf.org; Wed, 19 Nov 2003 12:49:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29341 for ; Wed, 19 Nov 2003 12:48:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWRu-0004ks-00 for nsis@ietf.org; Wed, 19 Nov 2003 12:49:06 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMWRu-0004kJ-00 for nsis@ietf.org; Wed, 19 Nov 2003 12:49:06 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAJHmOw7019366; Wed, 19 Nov 2003 09:48:28 -0800 (PST) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AKB98678; Wed, 19 Nov 2003 09:48:23 -0800 (PST) Date: Wed, 19 Nov 2003 10:52:05 -0500 From: "David R. Oran" To: "Geib, Ruediger" , nsis@ietf.org Subject: Re: [NSIS] Any Router Alert Option influence on router performance? Message-ID: <779578594.1069239125@localhost> In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6CB@G8PQD.blf01.telekom.de> References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6CB@G8PQD.blf01.telekom.de > X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 --On Wednesday, November 19, 2003 1:00 PM +0100 "Geib, Ruediger"=20 wrote: > Dear all, > > should anybody of you be aware of measurements > comparing the influence of processing "router > alert option" packets on router processing as > compared to complete absence of these packets, > I'd appreciate information or a URL. The > background isn't to prevent such messages. I'm > interested in learning more about the level > (if any) where they start to hurt. > I don't have specific measurements, but without special-case hardware=20 support for the specific function being requested by RA, the performance=20 penalty is at least 100x (if you do nothing other than decide to ignore the = RA) to much more depending on how heavy-weight the actual processing in=20 software would be. I believe this is one big reason why the RSVP aggregation work jumped=20 through hoops to avoid the interior routers seing packets with RA set. Think of them as equivalent to processing a packet addressed specifically=20 to the router as opposed to a packet being forwarded. If you would have=20 processed the packet locally in software (e.g. you are setting or=20 maintaining local control state) using RA doesn't matter at all. The=20 serious problem is for routers which DO NOT want to handle the packets. Dave. > Regards, R=FCdiger > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 13:27:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01479 for ; Wed, 19 Nov 2003 13:27:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMX3A-00065T-1c for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 13:27:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJIRaPS023398 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 13:27:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMX2a-00062J-SJ; Wed, 19 Nov 2003 13:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMX1t-00061d-Rv for nsis@optimus.ietf.org; Wed, 19 Nov 2003 13:26: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 NAA01422 for ; Wed, 19 Nov 2003 13:26:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMX1r-0005u8-00 for nsis@ietf.org; Wed, 19 Nov 2003 13:26:15 -0500 Received: from viefep16-int.chello.at ([213.46.255.17]) by ietf-mx with esmtp (Exim 4.12) id 1AMX1r-0005sn-00 for nsis@ietf.org; Wed, 19 Nov 2003 13:26:15 -0500 Received: from work ([80.109.142.58]) by viefep16-int.chello.at (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20031119182506.OQXD20342.viefep16-int.chello.at@work>; Wed, 19 Nov 2003 19:25:06 +0100 From: "Michael Welzl" To: "David R. Oran" , "Geib, Ruediger" , Subject: AW: [NSIS] Any Router Alert Option influence on router performance? Date: Thu, 20 Nov 2003 19:24:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <779578594.1069239125@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, > > should anybody of you be aware of measurements > > comparing the influence of processing "router > > alert option" packets on router processing as > > compared to complete absence of these packets, > > I'd appreciate information or a URL. The > > background isn't to prevent such messages. I'm > > interested in learning more about the level > > (if any) where they start to hurt. This lack of knowledge has been annoying me for a long time - so we did measurements. The idea was not to test specific equipment and not to check its behavior under stress (that would depend on the brand, I suppose) but rather to get a general idea of the additional delay you get by adding ANY option (we used NOP) to a ping in today's Internet. > I don't have specific measurements, but without special-case hardware > support for the specific function being requested by RA, the performance > penalty is at least 100x (if you do nothing other than decide to > ignore the > RA) to much more depending on how heavy-weight the actual processing in > software would be. At least 100x to much more??? I wonder where these data come from. We did two measurements, one in 2001 and one in 2003, and we traversed 7something000 and approx. 80000 different router addresses (100 pings each with and without options, a break of a second in between). Then we did some statistics (applied weights based on the frequency of occurence of certain router addresses, variance etc. ... the total result is close to 1% of additional delay per router (I think it was 0.8% in 2001 and 1% in 2003 or vice versa). Now this is not representative for "the Internet", of course, but it's a measurement, so it's at least SOMETHING. I'm working on the documentation, and I'll make it available as a technical report via the web as soon as possible (maybe in the next 1 or 2 weeks). For those of you who are greedy for diagrams :) here's a VERY VERY VERY VERY preliminary link: http://www.welzl.at/tmp/option.html (BTW - it says "2002" on this page, but that's wrong, it was 2001) The tech-rep will be available from: http://www.welzl.at/publications/ I believe that there's a tendency to exaggerate about the impact of Slow Path processing, and this prevents any idea based on IP options to move forward. On the other hand, judging from your email address, you should know more details abour option processing than I do - so I really wonder where these data come from. Perhaps it's: difference in delay when looking at processing in a router vs. difference in end-to-end delay The latter - how the overhead relates to the RTT - is more interesting to me. Cheers, Michael _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 14:01:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03678 for ; Wed, 19 Nov 2003 14:01:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXZC-0007vm-S4 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 14:00:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJJ0f3p030469 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 14:00:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXYX-0007q8-TD; Wed, 19 Nov 2003 14:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXXm-0007oI-Oh for nsis@optimus.ietf.org; Wed, 19 Nov 2003 13:59: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 NAA03560 for ; Wed, 19 Nov 2003 13:59:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMXXk-0006ya-00 for nsis@ietf.org; Wed, 19 Nov 2003 13:59:12 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMXXj-0006xP-00 for nsis@ietf.org; Wed, 19 Nov 2003 13:59:12 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 19 Nov 2003 10:56:53 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAJIuZiR010751; Wed, 19 Nov 2003 10:56:39 -0800 (PST) Received: from [10.32.245.146] (stealth-10-32-245-146.cisco.com [10.32.245.146]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AKC07827; Wed, 19 Nov 2003 10:56:34 -0800 (PST) Date: Wed, 19 Nov 2003 13:56:29 -0500 From: David Oran To: Michael Welzl , "Geib, Ruediger" , nsis@ietf.org Subject: Re: AW: [NSIS] Any Router Alert Option influence on router performance? Message-ID: <273182703.1069250189@[10.32.245.146]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 The 7xxx is a software forwarding platform. The relative costs are obviously much smaller on such a platform. --On Thursday, November 20, 2003 7:24 PM +0100 Michael Welzl wrote: > Hi all, > >> > should anybody of you be aware of measurements >> > comparing the influence of processing "router >> > alert option" packets on router processing as >> > compared to complete absence of these packets, >> > I'd appreciate information or a URL. The >> > background isn't to prevent such messages. I'm >> > interested in learning more about the level >> > (if any) where they start to hurt. > > This lack of knowledge has been annoying me for a long > time - so we did measurements. The idea was not to test > specific equipment and not to check its behavior under > stress (that would depend on the brand, I suppose) but > rather to get a general idea of the additional delay > you get by adding ANY option (we used NOP) to a ping in > today's Internet. > > >> I don't have specific measurements, but without special-case hardware >> support for the specific function being requested by RA, the performance >> penalty is at least 100x (if you do nothing other than decide to >> ignore the >> RA) to much more depending on how heavy-weight the actual processing in >> software would be. > > At least 100x to much more??? I wonder where these data come from. > > We did two measurements, one in 2001 and one in 2003, and > we traversed 7something000 and approx. 80000 different router > addresses (100 pings each with and without options, a break > of a second in between). Then we did some statistics (applied > weights based on the frequency of occurrence of certain router > addresses, variance etc. ... the total result is close to 1% > of additional delay per router (I think it was 0.8% in 2001 > and 1% in 2003 or vice versa). > > Now this is not representative for "the Internet", of course, > but it's a measurement, so it's at least SOMETHING. I'm working > on the documentation, and I'll make it available as a technical > report via the web as soon as possible (maybe in the next 1 or > 2 weeks). For those of you who are greedy for diagrams :) > here's a VERY VERY VERY VERY preliminary link: > http://www.welzl.at/tmp/option.html > (BTW - it says "2002" on this page, but that's wrong, it was 2001) > > The tech-rep will be available from: > http://www.welzl.at/publications/ > > I believe that there's a tendency to exaggerate about the impact > of Slow Path processing, and this prevents any idea based on > IP options to move forward. On the other hand, judging from your > email address, you should know more details abour option processing > than I do - so I really wonder where these data come from. > > Perhaps it's: > difference in delay when looking at processing in a router > vs. > difference in end-to-end delay > > > The latter - how the overhead relates to the RTT - is more > interesting to me. > > > Cheers, > Michael > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 14:29:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05381 for ; Wed, 19 Nov 2003 14:29:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMY1A-0001Mr-PF for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 14:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJJTavi005251 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 14:29:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMY0b-0001HL-EE; Wed, 19 Nov 2003 14:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXzs-0001Fe-9d for nsis@optimus.ietf.org; Wed, 19 Nov 2003 14:28:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05342 for ; Wed, 19 Nov 2003 14:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMXzp-00001e-00 for nsis@ietf.org; Wed, 19 Nov 2003 14:28:13 -0500 Received: from viefep13-int.chello.at ([213.46.255.15]) by ietf-mx with esmtp (Exim 4.12) id 1AMXzp-0007nZ-00 for nsis@ietf.org; Wed, 19 Nov 2003 14:28:13 -0500 Received: from work ([80.109.142.58]) by viefep13-int.chello.at (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20031119191120.SAKF8256.viefep13-int.chello.at@work>; Wed, 19 Nov 2003 20:11:20 +0100 From: "Michael Welzl" To: "David Oran" , "Michael Welzl" , "Geib, Ruediger" , Subject: AW: AW: [NSIS] Any Router Alert Option influence on router performance? Date: Thu, 20 Nov 2003 20:11:12 +0100 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <273182703.1069250189@[10.32.245.146]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 7xxx? what is 7xxx? I guess that's a misunderstanding because I wrote "7something000" - I was referring to the number of router addresses we encountered, which was something around 76000 or so. Not a brand / product number :) Cheers, Michael > -----Ursprungliche Nachricht----- > Von: David Oran [mailto:oran@cisco.com] > Gesendet: Mittwoch, 19. November 2003 19:56 > An: Michael Welzl; Geib, Ruediger; nsis@ietf.org > Betreff: Re: AW: [NSIS] Any Router Alert Option influence on router > performance? > > > The 7xxx is a software forwarding platform. The relative costs are > obviously much smaller on such a platform. > > --On Thursday, November 20, 2003 7:24 PM +0100 Michael Welzl > wrote: > > > Hi all, > > > >> > should anybody of you be aware of measurements > >> > comparing the influence of processing "router > >> > alert option" packets on router processing as > >> > compared to complete absence of these packets, > >> > I'd appreciate information or a URL. The > >> > background isn't to prevent such messages. I'm > >> > interested in learning more about the level > >> > (if any) where they start to hurt. > > > > This lack of knowledge has been annoying me for a long > > time - so we did measurements. The idea was not to test > > specific equipment and not to check its behavior under > > stress (that would depend on the brand, I suppose) but > > rather to get a general idea of the additional delay > > you get by adding ANY option (we used NOP) to a ping in > > today's Internet. > > > > > >> I don't have specific measurements, but without special-case hardware > >> support for the specific function being requested by RA, the > performance > >> penalty is at least 100x (if you do nothing other than decide to > >> ignore the > >> RA) to much more depending on how heavy-weight the actual processing in > >> software would be. > > > > At least 100x to much more??? I wonder where these data come from. > > > > We did two measurements, one in 2001 and one in 2003, and > > we traversed 7something000 and approx. 80000 different router > > addresses (100 pings each with and without options, a break > > of a second in between). Then we did some statistics (applied > > weights based on the frequency of occurrence of certain router > > addresses, variance etc. ... the total result is close to 1% > > of additional delay per router (I think it was 0.8% in 2001 > > and 1% in 2003 or vice versa). > > > > Now this is not representative for "the Internet", of course, > > but it's a measurement, so it's at least SOMETHING. I'm working > > on the documentation, and I'll make it available as a technical > > report via the web as soon as possible (maybe in the next 1 or > > 2 weeks). For those of you who are greedy for diagrams :) > > here's a VERY VERY VERY VERY preliminary link: > > http://www.welzl.at/tmp/option.html > > (BTW - it says "2002" on this page, but that's wrong, it was 2001) > > > > The tech-rep will be available from: > > http://www.welzl.at/publications/ > > > > I believe that there's a tendency to exaggerate about the impact > > of Slow Path processing, and this prevents any idea based on > > IP options to move forward. On the other hand, judging from your > > email address, you should know more details abour option processing > > than I do - so I really wonder where these data come from. > > > > Perhaps it's: > > difference in delay when looking at processing in a router > > vs. > > difference in end-to-end delay > > > > > > The latter - how the overhead relates to the RTT - is more > > interesting to me. > > > > > > Cheers, > > Michael > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 15:16:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08593 for ; Wed, 19 Nov 2003 15:16:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYkf-000479-3k for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 15:16:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKGbaj015809 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 15:16:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYk5-00042F-DA; Wed, 19 Nov 2003 15: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 1AMYjC-00041W-IW for nsis@optimus.ietf.org; Wed, 19 Nov 2003 15:15: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 PAA08390 for ; Wed, 19 Nov 2003 15:14:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYjB-0001Gu-00 for nsis@ietf.org; Wed, 19 Nov 2003 15:15:05 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AMYjA-0001Gr-00 for nsis@ietf.org; Wed, 19 Nov 2003 15:15:04 -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 hAJKF3J05744; Wed, 19 Nov 2003 21:15:04 +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 hAJKF3914333; Wed, 19 Nov 2003 21:15:03 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 19 Nov 2003 21:14:47 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0446@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Geib, Ruediger'" , nsis@ietf.org Subject: RE: [NSIS] Any Router Alert Option influence on router performanc e? Date: Wed, 19 Nov 2003 21:14:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi ruediger,=20 you might also want to take a look at: [IP-OPT] P. Pan, H. Schulzrinne, "PF_IPOPTION: A kernel extension for IP option packet processing", Technical Memorandum 10009669-02TM, Bell Labs, Lucent Technologies, Murray Hill, NJ, June 2000. ping says in draft [draft-pan-nsis-rsvp-transport] : " This design (referring to [RFC2113]) is simple to implement and efficient to run. As shown from the experiments in [IP-OPT], IP option processing introduces very little overhead on a FreeBSD box with minor kernel changes. " [draft-pan-nsis-rsvp-transport] is also a nice-to-read document. ping = also provides details about the router alert option in his thesis. =20 a separate issue which cedric raised at the last ietf was directed = towards the problem of filtering packets by routers/firewalls which do not understand the router alert option.=20 maybe someone can point us to literature.=20 ciao hannes [draft-pan-nsis-rsvp-transport] P. Pan and H. Schulzrinne: "An = Evaluation on RSVP Transport Mechanism", , (expired), Jan. 2003. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Wednesday, November 19, 2003 1:01 PM > To: nsis@ietf.org > Subject: [NSIS] Any Router Alert Option influence on router=20 > performance? >=20 >=20 > Dear all, >=20 > should anybody of you be aware of measurements=20 > comparing the influence of processing "router=20 > alert option" packets on router processing as=20 > compared to complete absence of these packets,=20 > I'd appreciate information or a URL. The=20 > background isn't to prevent such messages. I'm=20 > interested in learning more about the level=20 > (if any) where they start to hurt. >=20 > Regards, R=FCdiger=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 15:41:03 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10779 for ; Wed, 19 Nov 2003 15:41:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZ81-0007Oa-Hh for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 15:40:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKejjr028425 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 15:40:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZ7Q-0007Io-Aj; Wed, 19 Nov 2003 15:40:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZ6r-0007De-Dv for nsis@optimus.ietf.org; Wed, 19 Nov 2003 15:39: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 PAA10705 for ; Wed, 19 Nov 2003 15:39:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZ6o-0001nu-00 for nsis@ietf.org; Wed, 19 Nov 2003 15:39:30 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMZ6n-0001nW-00 for nsis@ietf.org; Wed, 19 Nov 2003 15:39:30 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 19 Nov 2003 12:39:15 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAJKcmAt008063; Wed, 19 Nov 2003 12:38:48 -0800 (PST) Received: from [10.32.245.146] (stealth-10-32-245-146.cisco.com [10.32.245.146]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AKC20881; Wed, 19 Nov 2003 12:38:47 -0800 (PST) Date: Wed, 19 Nov 2003 15:38:42 -0500 From: David Oran To: Michael Welzl , "Geib, Ruediger" , nsis@ietf.org Subject: Re: AW: AW: [NSIS] Any Router Alert Option influence on router performance? Message-ID: <279315187.1069256322@[10.32.245.146]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 read the first number as the type of router and the second number as the count of addresses. Sorry for the confusion. It's still highly relevant if you were testing across routers which do software forwarding versus hardware forwarding. Dave. --On Thursday, November 20, 2003 8:11 PM +0100 Michael Welzl wrote: > 7xxx? what is 7xxx? > > I guess that's a misunderstanding because I wrote > "7something000" - I was referring to the number of > router addresses we encountered, which was something > around 76000 or so. Not a brand / product number :) > > Cheers, > Michael > >> -----Ursprungliche Nachricht----- >> Von: David Oran [mailto:oran@cisco.com] >> Gesendet: Mittwoch, 19. November 2003 19:56 >> An: Michael Welzl; Geib, Ruediger; nsis@ietf.org >> Betreff: Re: AW: [NSIS] Any Router Alert Option influence on router >> performance? >> >> >> The 7xxx is a software forwarding platform. The relative costs are >> obviously much smaller on such a platform. >> >> --On Thursday, November 20, 2003 7:24 PM +0100 Michael Welzl >> wrote: >> >> > Hi all, >> > >> >> > should anybody of you be aware of measurements >> >> > comparing the influence of processing "router >> >> > alert option" packets on router processing as >> >> > compared to complete absence of these packets, >> >> > I'd appreciate information or a URL. The >> >> > background isn't to prevent such messages. I'm >> >> > interested in learning more about the level >> >> > (if any) where they start to hurt. >> > >> > This lack of knowledge has been annoying me for a long >> > time - so we did measurements. The idea was not to test >> > specific equipment and not to check its behavior under >> > stress (that would depend on the brand, I suppose) but >> > rather to get a general idea of the additional delay >> > you get by adding ANY option (we used NOP) to a ping in >> > today's Internet. >> > >> > >> >> I don't have specific measurements, but without special-case hardware >> >> support for the specific function being requested by RA, the >> performance >> >> penalty is at least 100x (if you do nothing other than decide to >> >> ignore the >> >> RA) to much more depending on how heavy-weight the actual processing >> >> in software would be. >> > >> > At least 100x to much more??? I wonder where these data come from. >> > >> > We did two measurements, one in 2001 and one in 2003, and >> > we traversed 7something000 and approx. 80000 different router >> > addresses (100 pings each with and without options, a break >> > of a second in between). Then we did some statistics (applied >> > weights based on the frequency of occurrence of certain router >> > addresses, variance etc. ... the total result is close to 1% >> > of additional delay per router (I think it was 0.8% in 2001 >> > and 1% in 2003 or vice versa). >> > >> > Now this is not representative for "the Internet", of course, >> > but it's a measurement, so it's at least SOMETHING. I'm working >> > on the documentation, and I'll make it available as a technical >> > report via the web as soon as possible (maybe in the next 1 or >> > 2 weeks). For those of you who are greedy for diagrams :) >> > here's a VERY VERY VERY VERY preliminary link: >> > http://www.welzl.at/tmp/option.html >> > (BTW - it says "2002" on this page, but that's wrong, it was 2001) >> > >> > The tech-rep will be available from: >> > http://www.welzl.at/publications/ >> > >> > I believe that there's a tendency to exaggerate about the impact >> > of Slow Path processing, and this prevents any idea based on >> > IP options to move forward. On the other hand, judging from your >> > email address, you should know more details abour option processing >> > than I do - so I really wonder where these data come from. >> > >> > Perhaps it's: >> > difference in delay when looking at processing in a router >> > vs. >> > difference in end-to-end delay >> > >> > >> > The latter - how the overhead relates to the RTT - is more >> > interesting to me. >> > >> > >> > Cheers, >> > Michael >> > >> >> >> >> > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Nov 19 22:44:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02010 for ; Wed, 19 Nov 2003 22:44:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMfkD-00015V-Hj for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 22:44:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK3ibi5004160 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 22:44:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMfjd-0000xn-1D; Wed, 19 Nov 2003 22: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 1AMfij-0000x9-E6 for nsis@optimus.ietf.org; Wed, 19 Nov 2003 22:43:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01970 for ; Wed, 19 Nov 2003 22:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMfig-0002VE-00 for nsis@ietf.org; Wed, 19 Nov 2003 22:43:02 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AMfif-0002Ux-00 for nsis@ietf.org; Wed, 19 Nov 2003 22:43:01 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Nov 2003 03:42:31 -0000 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] Any Router Alert Option influence on router performanc e? Date: Thu, 20 Nov 2003 03:42:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Michael, Dave, these inputs are extremely interesting, thanks. some perspectives: i think we are at least as interested in the effect of the RAO on router processing time as on e2e delay. the second is the cost for the signalling; the first is the cost for the router. if widespread adoption of NSIS (e.g. for middlebox signalling) causes core router CPUs to collapse processing messages they don't care about, we will have failed. i think it's clear that we don't want to introduce a new option that needs to be processed in software (for the reasons Dave gives). we need to use an existing interception mechanism - either based on protocol number or RAO - to do selective interception. 3175 uses protocol number re-writing to avoid RAO processing for the microflow messages. my impression is that we won't be able to get enough protocol numbers to achieve the granularity of selection that we will probably need (and indeed, 3175 suggested RAO values to go further). my impression of the reasoning in 2113 is that the RAO is well- enough designed that you *should* be able to include support for processing it (and filtering some set of RAO values) in any hardware you build. it has the right degree of simplicity (fixed 32 bit format) and flexibility (16 bits of value space). the question is, is that what has actually happened? or do we need to rely on using some set of protocol numbers, and if so, how many? cheers, robert h. > -----Original Message----- > From: Michael Welzl [mailto:michael.welzl@uibk.ac.at] > Sent: Thursday, November 20, 2003 12:25 > To: David R. Oran; Geib, Ruediger; nsis@ietf.org > Subject: AW: [NSIS] Any Router Alert Option influence on router > performance? > > > Hi all, > > > > should anybody of you be aware of measurements > > > comparing the influence of processing "router > > > alert option" packets on router processing as > > > compared to complete absence of these packets, > > > I'd appreciate information or a URL. The > > > background isn't to prevent such messages. I'm > > > interested in learning more about the level > > > (if any) where they start to hurt. > > This lack of knowledge has been annoying me for a long > time - so we did measurements. The idea was not to test > specific equipment and not to check its behavior under > stress (that would depend on the brand, I suppose) but > rather to get a general idea of the additional delay > you get by adding ANY option (we used NOP) to a ping in > today's Internet. > > > > I don't have specific measurements, but without > special-case hardware > > support for the specific function being requested by RA, > the performance > > penalty is at least 100x (if you do nothing other than decide to > > ignore the > > RA) to much more depending on how heavy-weight the actual > processing in > > software would be. > > At least 100x to much more??? I wonder where these data come from. > > We did two measurements, one in 2001 and one in 2003, and > we traversed 7something000 and approx. 80000 different router > addresses (100 pings each with and without options, a break > of a second in between). Then we did some statistics (applied > weights based on the frequency of occurence of certain router > addresses, variance etc. ... the total result is close to 1% > of additional delay per router (I think it was 0.8% in 2001 > and 1% in 2003 or vice versa). > > Now this is not representative for "the Internet", of course, > but it's a measurement, so it's at least SOMETHING. I'm working > on the documentation, and I'll make it available as a technical > report via the web as soon as possible (maybe in the next 1 or > 2 weeks). For those of you who are greedy for diagrams :) > here's a VERY VERY VERY VERY preliminary link: > http://www.welzl.at/tmp/option.html > (BTW - it says "2002" on this page, but that's wrong, it was 2001) > > The tech-rep will be available from: > http://www.welzl.at/publications/ > > I believe that there's a tendency to exaggerate about the impact > of Slow Path processing, and this prevents any idea based on > IP options to move forward. On the other hand, judging from your > email address, you should know more details abour option processing > than I do - so I really wonder where these data come from. > > Perhaps it's: > difference in delay when looking at processing in a router > vs. > difference in end-to-end delay > > > The latter - how the overhead relates to the RTT - is more > interesting to me. > > > Cheers, > Michael > > > _______________________________________________ > 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 Nov 19 23:32:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02012 for ; Wed, 19 Nov 2003 22:44:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMfkD-00015U-HX for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 22:44:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK3ibGn004157 for nsis-archive@odin.ietf.org; Wed, 19 Nov 2003 22:44:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMfjd-0000xv-Fs; Wed, 19 Nov 2003 22: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 1AMfil-0000xE-KR for nsis@optimus.ietf.org; Wed, 19 Nov 2003 22: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 WAA01973 for ; Wed, 19 Nov 2003 22:42:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMfii-0002VJ-00 for nsis@ietf.org; Wed, 19 Nov 2003 22:43:04 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AMfih-0002Uy-00 for nsis@ietf.org; Wed, 19 Nov 2003 22:43:03 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Nov 2003 03:42:34 -0000 Message-ID: From: "Hancock, Robert" To: "Geib, Ruediger" , sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] QoS NSLP expectations Date: Thu, 20 Nov 2003 03:42:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, a tiny comment on qnslp vs. rsvp functionality: > scoping - completely new > stacking - completely new > state models - reduced state and stateless added i see these currently as consequences of the decision not to have a single QoS model. at the moment, we don't really have a clue how things should be done where several different QoS models are supported along the path - there was some alarming design-on-the-hoof activity going on during the WG session, but this is something that really needs to be thought out. the scoping and stacking in particular are possible mechanisms to make interworking/negotiation *less* complex to implement and administer; maybe we will find better ways to do this as time goes by, but for now I would be unhappy about saying (effectively) "let's make things simpler by deferring the hard problems until later". cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 20 06:22:54 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29035 for ; Thu, 20 Nov 2003 06:22:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMmtS-00012l-Hl for nsis-archive@odin.ietf.org; Thu, 20 Nov 2003 06:22:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKBMcCB003996 for nsis-archive@odin.ietf.org; Thu, 20 Nov 2003 06:22:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMmsq-0000yD-VC; Thu, 20 Nov 2003 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 1AMmsV-0000xp-V7 for nsis@optimus.ietf.org; Thu, 20 Nov 2003 06:21:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28990 for ; Thu, 20 Nov 2003 06:21:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMmsT-0000r0-00 for nsis@ietf.org; Thu, 20 Nov 2003 06:21:37 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AMmsS-0000qr-00 for nsis@ietf.org; Thu, 20 Nov 2003 06:21:36 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Thu, 20 Nov 2003 11:43:05 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 11:43:21 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6CC@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: michael.welzl@uibk.ac.at, oran@cisco.com, hannes.tschofenig@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] Any Router Alert Option influence on router performanc e? Date: Thu, 20 Nov 2003 11:43:19 +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 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 David, Michael, Hannes, thanks for distributing information on the issue! Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Nov 20 09:38:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06317 for ; Thu, 20 Nov 2003 09:38:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpwJ-0006fh-Tz for nsis-archive@odin.ietf.org; Thu, 20 Nov 2003 09:37:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEblsL025633 for nsis-archive@odin.ietf.org; Thu, 20 Nov 2003 09:37:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpvZ-0006No-Ux; Thu, 20 Nov 2003 09:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpvH-0006N2-Ne for nsis@optimus.ietf.org; Thu, 20 Nov 2003 09:36:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06214 for ; Thu, 20 Nov 2003 09:36:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpvF-0003ta-00 for nsis@ietf.org; Thu, 20 Nov 2003 09:36:41 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AMpvF-0003tW-00 for nsis@ietf.org; Thu, 20 Nov 2003 09:36:41 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAKEaeU6027039; Thu, 20 Nov 2003 09:36:40 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hAKEaRf19440; Thu, 20 Nov 2003 09:36:31 -0500 Message-ID: <3FBCD169.6070401@cs.columbia.edu> Date: Thu, 20 Nov 2003 09:36:25 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: [NSIS] Any Router Alert Option influence on router performanc e? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit To add to this: I think we need to distinguish at least three issues: (1) Delay added by RAO processing. This only matters if the delay is large (milliseconds) and if we include RAO in data packets, YESSIR-style. (2) CPU load caused by processing RAO where the packet is then ignored. (3) CPU load caused by processing RAO where the packet is processed. In that case, I suspect that the RAO processing is trivial compared to the rest of the packet processing and the important consideration is the total throughput of the router CPU in handling signaling messages. As long as the per-message overhead is reasonable, router vendors and Moore's law will make sure that routers have enough CPU horsepower. (Indications [see Darmstadt RSVP work] are that even old CPUs can handle tens of thousands, if not 100,000, messages a second, translating into approximately 3 million concurrent sessions at 30 second refresh. Even at OC-192 and 1 million sessions, every single bit of the channel would have to be taken up by 10 kb/s voice connections to reach that level.) Aggregation obviously avoids this problem, as well. Thus, only (2) matters in practice, as long as we keep the processing overhead for NSIS messages reasonable. Matching on RAO and the flag and detecting that there is nobody home for that combination should be doable at high speed, as Robert indicates below. Henning Hancock, Robert wrote: > Michael, Dave, > > these inputs are extremely interesting, thanks. > > some perspectives: > > i think we are at least as interested in the effect of the RAO > on router processing time as on e2e delay. the second is the cost > for the signalling; the first is the cost for the router. if > widespread adoption of NSIS (e.g. for middlebox signalling) > causes core router CPUs to collapse processing messages they don't > care about, we will have failed. > > i think it's clear that we don't want to introduce a new option > that needs to be processed in software (for the reasons Dave > gives). we need to use an existing interception mechanism - either > based on protocol number or RAO - to do selective interception. > > 3175 uses protocol number re-writing to avoid RAO processing for > the microflow messages. my impression is that we won't be able > to get enough protocol numbers to achieve the granularity of > selection that we will probably need (and indeed, 3175 suggested > RAO values to go further). > > my impression of the reasoning in 2113 is that the RAO is well- > enough designed that you *should* be able to include support for > processing it (and filtering some set of RAO values) in any > hardware you build. it has the right degree of simplicity > (fixed 32 bit format) and flexibility (16 bits of value space). > > the question is, is that what has actually happened? or do we > need to rely on using some set of protocol numbers, and if so, > how many? > > cheers, > > robert h. > > >>-----Original Message----- >>From: Michael Welzl [mailto:michael.welzl@uibk.ac.at] >>Sent: Thursday, November 20, 2003 12:25 >>To: David R. Oran; Geib, Ruediger; nsis@ietf.org >>Subject: AW: [NSIS] Any Router Alert Option influence on router >>performance? >> >> >>Hi all, >> >> >>>>should anybody of you be aware of measurements >>>>comparing the influence of processing "router >>>>alert option" packets on router processing as >>>>compared to complete absence of these packets, >>>>I'd appreciate information or a URL. The >>>>background isn't to prevent such messages. I'm >>>>interested in learning more about the level >>>>(if any) where they start to hurt. >> >>This lack of knowledge has been annoying me for a long >>time - so we did measurements. The idea was not to test >>specific equipment and not to check its behavior under >>stress (that would depend on the brand, I suppose) but >>rather to get a general idea of the additional delay >>you get by adding ANY option (we used NOP) to a ping in >>today's Internet. >> >> >> >>>I don't have specific measurements, but without >> >>special-case hardware >> >>>support for the specific function being requested by RA, >> >>the performance >> >>>penalty is at least 100x (if you do nothing other than decide to >>>ignore the >>>RA) to much more depending on how heavy-weight the actual >> >>processing in >> >>>software would be. >> >>At least 100x to much more??? I wonder where these data come from. >> >>We did two measurements, one in 2001 and one in 2003, and >>we traversed 7something000 and approx. 80000 different router >>addresses (100 pings each with and without options, a break >>of a second in between). Then we did some statistics (applied >>weights based on the frequency of occurence of certain router >>addresses, variance etc. ... the total result is close to 1% >>of additional delay per router (I think it was 0.8% in 2001 >>and 1% in 2003 or vice versa). >> >>Now this is not representative for "the Internet", of course, >>but it's a measurement, so it's at least SOMETHING. I'm working >>on the documentation, and I'll make it available as a technical >>report via the web as soon as possible (maybe in the next 1 or >>2 weeks). For those of you who are greedy for diagrams :) >>here's a VERY VERY VERY VERY preliminary link: >>http://www.welzl.at/tmp/option.html >>(BTW - it says "2002" on this page, but that's wrong, it was 2001) >> >>The tech-rep will be available from: >>http://www.welzl.at/publications/ >> >>I believe that there's a tendency to exaggerate about the impact >>of Slow Path processing, and this prevents any idea based on >>IP options to move forward. On the other hand, judging from your >>email address, you should know more details abour option processing >>than I do - so I really wonder where these data come from. >> >>Perhaps it's: >>difference in delay when looking at processing in a router >>vs. >>difference in end-to-end delay >> >> >>The latter - how the overhead relates to the RTT - is more >>interesting to me. >> >> >>Cheers, >>Michael >> >> >>_______________________________________________ >>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 Nov 20 21:57:54 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15024 for ; Thu, 20 Nov 2003 21:57:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN1UI-0000qC-1B for nsis-archive@odin.ietf.org; Thu, 20 Nov 2003 21:57:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL2vbmQ003215 for nsis-archive@odin.ietf.org; Thu, 20 Nov 2003 21:57:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN1Th-0000lM-7V; Thu, 20 Nov 2003 21: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 1AN1TK-0000kv-KO for nsis@optimus.ietf.org; Thu, 20 Nov 2003 21: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 VAA14990 for ; Thu, 20 Nov 2003 21:56:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN1TH-00022O-00 for nsis@ietf.org; Thu, 20 Nov 2003 21:56:35 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AN1TH-00022L-00 for nsis@ietf.org; Thu, 20 Nov 2003 21:56:35 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AN1TI-0002xC-2F; Fri, 21 Nov 2003 02:56:36 +0000 To: nsis@ietf.org Cc: john.loughney@nokia.com Reply-To: mankin@psg.com Date: Thu, 20 Nov 2003 18:56:36 -0800 From: Allison Mankin Message-Id: Subject: [NSIS] NSIS Requirements document approved Sender: nsis-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: , Folks, The IESG did their re-reviewing and approved the NSIS Requirements draft today. Thanks for your hard and good work on this, and for the great involvment with the comments (as well as your patience when IESG overload slowed the re-reviewing). Allison _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Nov 21 02:06:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26987 for ; Fri, 21 Nov 2003 02:06:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN5NH-0007Jq-H2 for nsis-archive@odin.ietf.org; Fri, 21 Nov 2003 02:06:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL76dDK028122 for nsis-archive@odin.ietf.org; Fri, 21 Nov 2003 02:06:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN5Mg-0007BW-C4; Fri, 21 Nov 2003 02:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN5MZ-0007Ay-LZ for nsis@optimus.ietf.org; Fri, 21 Nov 2003 02:05:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25833 for ; Fri, 21 Nov 2003 02:05:42 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN5MV-0004vz-00 for nsis@ietf.org; Fri, 21 Nov 2003 02:05:52 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AN5MV-0004vr-00 for nsis@ietf.org; Fri, 21 Nov 2003 02:05:51 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAL75k613478 for ; Fri, 21 Nov 2003 09:05:46 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Nov 2003 09:05:43 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 09:05:45 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 21 Nov 2003 09:05:45 +0200 Message-ID: Thread-Topic: NSIS Requirements document approved Thread-Index: AcOv2yhwTrevyqHlQTebCFyQJxzNTAAIqhTg To: , X-OriginalArrivalTime: 21 Nov 2003 07:05:45.0997 (UTC) FILETIME=[E29C0BD0:01C3AFFD] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RE: NSIS Requirements document approved Sender: nsis-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 Allison, > The IESG did their re-reviewing and approved the NSIS > Requirements draft today. Thanks for your hard and good work > on this, and for the great involvment with the comments (as well > as your patience when IESG overload slowed the re-reviewing). Thanks for the good news & thanks to Marcus for the hard work in editing the document! John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Nov 23 15:01:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27611 for ; Sun, 23 Nov 2003 15:01:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO0QK-0000vG-JM for nsis-archive@odin.ietf.org; Sun, 23 Nov 2003 15:01:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hANK1aBD003543 for nsis-archive@odin.ietf.org; Sun, 23 Nov 2003 15:01:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO0Pk-0000sK-FK; Sun, 23 Nov 2003 15:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO0Ot-0000rX-0h for nsis@optimus.ietf.org; Sun, 23 Nov 2003 15:00: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 OAA27553 for ; Sun, 23 Nov 2003 14:59:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO0Oq-0006b4-00 for nsis@ietf.org; Sun, 23 Nov 2003 15:00:04 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AO0Op-0006b1-00 for nsis@ietf.org; Sun, 23 Nov 2003 15:00:03 -0500 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Sun, 23 Nov 2003 21:00:02 +0100 Message-ID: <3FC111A4.1070801@cs.uni-goettingen.de> Date: Sun, 23 Nov 2003 20:59:32 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] Any Router Alert Option influence on router performanc e? References: <3FBCD169.6070401@cs.columbia.edu> In-Reply-To: <3FBCD169.6070401@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I also think (2) is something of importance in the sense of layering: If we assume every NSIS node needs to worry about control plane (relatively slow) functionality for any incoming NSIS packet, this can introduce additional RTT e.g., for firewalling NSLP, since it might only manage control state in a limited number of node(s) while traversing several (possibly tens of) other NSIS nodes along the path. The question is, can/should we engineer something only in forwarding plane - or a "faster" control plane - with NTLP packets by default (without intercepting into the content), and when the encoded NSLP type is recognized in a node, the NSIS packet is processed in control plane? If this is a desireable feature RAO plus filtering flag(s) can be a way. Regards, Xiaoming Henning Schulzrinne wrote: > To add to this: I think we need to distinguish at least three issues: > > (1) Delay added by RAO processing. This only matters if the delay is > large (milliseconds) and if we include RAO in data packets, YESSIR-style. > > (2) CPU load caused by processing RAO where the packet is then ignored. > > (3) CPU load caused by processing RAO where the packet is processed. In > that case, I suspect that the RAO processing is trivial compared to the > rest of the packet processing and the important consideration is the > total throughput of the router CPU in handling signaling messages. As > long as the per-message overhead is reasonable, router vendors and > Moore's law will make sure that routers have enough CPU horsepower. > (Indications [see Darmstadt RSVP work] are that even old CPUs can handle > tens of thousands, if not 100,000, messages a second, translating into > approximately 3 million concurrent sessions at 30 second refresh. Even > at OC-192 and 1 million sessions, every single bit of the channel would > have to be taken up by 10 kb/s voice connections to reach that level.) > Aggregation obviously avoids this problem, as well. > > Thus, only (2) matters in practice, as long as we keep the processing > overhead for NSIS messages reasonable. Matching on RAO and the flag and > detecting that there is nobody home for that combination should be > doable at high speed, as Robert indicates below. > > Henning > > > Hancock, Robert wrote: > >> Michael, Dave, >> >> these inputs are extremely interesting, thanks. >> >> some perspectives: >> >> i think we are at least as interested in the effect of the RAO >> on router processing time as on e2e delay. the second is the cost >> for the signalling; the first is the cost for the router. if >> widespread adoption of NSIS (e.g. for middlebox signalling) causes >> core router CPUs to collapse processing messages they don't >> care about, we will have failed. >> >> i think it's clear that we don't want to introduce a new option >> that needs to be processed in software (for the reasons Dave >> gives). we need to use an existing interception mechanism - either >> based on protocol number or RAO - to do selective interception. >> >> 3175 uses protocol number re-writing to avoid RAO processing for >> the microflow messages. my impression is that we won't be able >> to get enough protocol numbers to achieve the granularity of >> selection that we will probably need (and indeed, 3175 suggested >> RAO values to go further). >> >> my impression of the reasoning in 2113 is that the RAO is well- >> enough designed that you *should* be able to include support for >> processing it (and filtering some set of RAO values) in any hardware >> you build. it has the right degree of simplicity (fixed 32 bit format) >> and flexibility (16 bits of value space). >> >> the question is, is that what has actually happened? or do we need to >> rely on using some set of protocol numbers, and if so, >> how many? >> >> cheers, >> >> robert h. >> >> >>> -----Original Message----- >>> From: Michael Welzl [mailto:michael.welzl@uibk.ac.at] >>> Sent: Thursday, November 20, 2003 12:25 >>> To: David R. Oran; Geib, Ruediger; nsis@ietf.org >>> Subject: AW: [NSIS] Any Router Alert Option influence on router >>> performance? >>> >>> >>> Hi all, >>> >>> >>>>> should anybody of you be aware of measurements >>>>> comparing the influence of processing "router >>>>> alert option" packets on router processing as >>>>> compared to complete absence of these packets, >>>>> I'd appreciate information or a URL. The >>>>> background isn't to prevent such messages. I'm >>>>> interested in learning more about the level >>>>> (if any) where they start to hurt. >>> >>> >>> This lack of knowledge has been annoying me for a long >>> time - so we did measurements. The idea was not to test >>> specific equipment and not to check its behavior under >>> stress (that would depend on the brand, I suppose) but >>> rather to get a general idea of the additional delay >>> you get by adding ANY option (we used NOP) to a ping in >>> today's Internet. >>> >>> >>> >>>> I don't have specific measurements, but without >>> >>> >>> special-case hardware >>> >>>> support for the specific function being requested by RA, >>> >>> >>> the performance >>> >>>> penalty is at least 100x (if you do nothing other than decide to >>>> ignore the RA) to much more depending on how heavy-weight the actual >>> >>> >>> processing in >>> >>>> software would be. >>> >>> >>> At least 100x to much more??? I wonder where these data come from. >>> >>> We did two measurements, one in 2001 and one in 2003, and >>> we traversed 7something000 and approx. 80000 different router >>> addresses (100 pings each with and without options, a break >>> of a second in between). Then we did some statistics (applied >>> weights based on the frequency of occurence of certain router >>> addresses, variance etc. ... the total result is close to 1% >>> of additional delay per router (I think it was 0.8% in 2001 >>> and 1% in 2003 or vice versa). >>> >>> Now this is not representative for "the Internet", of course, >>> but it's a measurement, so it's at least SOMETHING. I'm working >>> on the documentation, and I'll make it available as a technical >>> report via the web as soon as possible (maybe in the next 1 or >>> 2 weeks). For those of you who are greedy for diagrams :) >>> here's a VERY VERY VERY VERY preliminary link: >>> http://www.welzl.at/tmp/option.html >>> (BTW - it says "2002" on this page, but that's wrong, it was 2001) >>> >>> The tech-rep will be available from: >>> http://www.welzl.at/publications/ >>> >>> I believe that there's a tendency to exaggerate about the impact >>> of Slow Path processing, and this prevents any idea based on >>> IP options to move forward. On the other hand, judging from your >>> email address, you should know more details abour option processing >>> than I do - so I really wonder where these data come from. >>> >>> Perhaps it's: >>> difference in delay when looking at processing in a router >>> vs. >>> difference in end-to-end delay >>> >>> >>> The latter - how the overhead relates to the RTT - is more >>> interesting to me. >>> >>> >>> Cheers, >>> Michael >>> >>> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 24 05:29:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02817 for ; Mon, 24 Nov 2003 05:29:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODxp-0007gT-6L for nsis-archive@odin.ietf.org; Mon, 24 Nov 2003 05:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOAT5ue029524 for nsis-archive@odin.ietf.org; Mon, 24 Nov 2003 05:29:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODxl-0007fj-9V; Mon, 24 Nov 2003 05:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODwx-0007ee-QQ for nsis@optimus.ietf.org; Mon, 24 Nov 2003 05:28: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 FAA02788 for ; Mon, 24 Nov 2003 05:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AODwu-0001sY-00 for nsis@ietf.org; Mon, 24 Nov 2003 05:28:08 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AODwt-0001sV-00 for nsis@ietf.org; Mon, 24 Nov 2003 05:28:08 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id 6D9DB1A57 for ; Mon, 24 Nov 2003 11:28:06 +0100 (MET) Message-ID: <004401c3b276$07f9c3c0$7907c289@pcluu> From: "Thanh Tra LUU" To: References: Date: Mon, 24 Nov 2003 11:30:50 +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 Content-Transfer-Encoding: 7bit Subject: [NSIS] NSIS minutes. Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all, Someone can send me the Minutes of NSIS WG ? Thanks, Nary Tra, ENST, Paris _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Nov 24 14:20:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22665 for ; Mon, 24 Nov 2003 14:20:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMFh-00027b-57 for nsis-archive@odin.ietf.org; Mon, 24 Nov 2003 14:20:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOJK4Fd008108 for nsis-archive@odin.ietf.org; Mon, 24 Nov 2003 14:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMFf-00026M-6K; Mon, 24 Nov 2003 14:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMFL-00025T-Gl for nsis@optimus.ietf.org; Mon, 24 Nov 2003 14:19:43 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22606 for ; Mon, 24 Nov 2003 14:19:28 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AOM2T-0003ob-KP; Mon, 24 Nov 2003 14:06:25 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Mon, 24 Nov 2003 14:06:25 -0500 Subject: [NSIS] Document Action: 'Requirements for Signaling Protocols' to Informational RFC Sender: nsis-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: , The IESG has approved following document: - 'Requirements for Signaling Protocols ' as an Informational RFC This document is the product of the Next Steps in Signaling Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis