From mailnull@www1.ietf.org Wed Oct 2 15:37:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05128 for ; Wed, 2 Oct 2002 15:37:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g92Jcqf14809 for nsis-archive@odin.ietf.org; Wed, 2 Oct 2002 15:38:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92Jcnv14803; Wed, 2 Oct 2002 15:38:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92Jbcv14757 for ; Wed, 2 Oct 2002 15:37:38 -0400 Received: from idcpa4.pa.interdigital.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05078 for ; Wed, 2 Oct 2002 15:35:33 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Oct 2002 15:35:58 -0400 Message-ID: <5238EB1F9A88D8499B8610F4BEEF46F724C4C1@PAEX2000.InterDigital.com> From: "Shahrier, Sharif M." To: "'nsis@ietf.org'" , "'aaa-wg@merit.edu'" Cc: mobile-ip@sunroof.eng.sun.com Date: Wed, 2 Oct 2002 15:32:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] White paper request Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, Could someone please send me a pointer to a good white paper on the DIAMETER protocol? (RADIUS as well if possible). Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 3 19:01:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07897 for ; Thu, 3 Oct 2002 19:01:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g93N2kw22359 for nsis-archive@odin.ietf.org; Thu, 3 Oct 2002 19:02:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93N2gv22352; Thu, 3 Oct 2002 19:02:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93N1pv22329 for ; Thu, 3 Oct 2002 19:01:51 -0400 Received: from mailrelay1.alcatel.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07851 for ; Thu, 3 Oct 2002 18:59:43 -0400 (EDT) From: Axel.Kuttner@alcatel.de Received: from slsas5.stgl.netd.alcatel.de (slsas5.stgl.netd.alcatel.de [149.204.45.57]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id BAA14734 for ; Fri, 4 Oct 2002 01:01:43 +0200 (MET DST) To: nsis@ietf.org Message-ID: Date: Fri, 4 Oct 2002 01:01:40 +0200 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.9 |November 16, 2001) at 10/04/2002 01:01:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Subject: [NSIS] Axel KUTTNER/DE/ALCATEL is out of the office. Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I will be out of the office starting 03.10.2002 and will not return until 13.10.2002. Thank you for keeping me informed. I will respond to your message when I return. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 4 07:43:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29474 for ; Fri, 4 Oct 2002 07:43:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94BjHN01813 for nsis-archive@odin.ietf.org; Fri, 4 Oct 2002 07:45:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94BjEv01806; Fri, 4 Oct 2002 07:45:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94BVXv00741 for ; Fri, 4 Oct 2002 07:31:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28941; Fri, 4 Oct 2002 07:29:29 -0400 (EDT) Message-Id: <200210041129.HAA28941@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 04 Oct 2002 07:29:29 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Next Steps in Signaling: Framework Author(s) : I. Freytsis et al. Filename : draft-ietf-nsis-fw-00.txt Pages : 49 Date : 2002-10-3 The NSIS working group is considering protocols for signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in [2]; this Internet Draft will propose a framework for such signaling. This initial version provides a model of the entities that take part in the signaling. It discusses the considerations that must be taken into account in developing the framework, particularly the structural options for the structure of such a protocol, and the interactions between NSIS and other protocols and functions, including security issues. Finally, it includes background material on how NSIS could support particular signaling applications. It is expected that future versions of this document will distill these structural options into a concrete technical framework, and material on particular signaling applications and deployment scenarios will be moved into separate NSIS applicability statements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-fw-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-fw-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-3150055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-fw-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-fw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-3150055.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Oct 5 17:35:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25728 for ; Sat, 5 Oct 2002 17:35:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g95Lb8F03619 for nsis-archive@odin.ietf.org; Sat, 5 Oct 2002 17:37:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g95Lb5v03498; Sat, 5 Oct 2002 17:37:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g95LZov03311 for ; Sat, 5 Oct 2002 17:35:50 -0400 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25704 for ; Sat, 5 Oct 2002 17:33:40 -0400 (EDT) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g95LZcR19377; Sat, 5 Oct 2002 14:35:38 -0700 (PDT) Date: Sat, 5 Oct 2002 14:35:38 -0700 (PDT) From: Bob Braden Message-Id: <200210052135.g95LZcR19377@boreas.isi.edu> To: hgs@cs.columbia.edu, Ruediger.Geib@t-systems.com Subject: Re: [NSIS] New NSIS-related drafts Cc: nsis@ietf.org X-Sun-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: , Rüdiger Geib wrote: *> One such capability could be "QoS". The second draft describes a *> QoS client. The casp-qos draft is not as elaborated as the CASP *> draft. It repeats one of the major drawbacks of IntServ/RSVP: it *> doesn't separate a service identifier from a service descriptor. I would say that this criticism is largely incorrect. The int-serv folks defined a family of service descriptors, with some common elements. It was expected that this family would be extended, and the syntactic hooks for extension are there. If for some reason this does not work for you, e.g., because (unwisely, I believe) you did not want the common elements defined by int-serv, you have only to define new formats of Flowspecs, etc. The CType seems to work just fine as a service identifier. I would therefore say that IntServ/RSVP DOES effectively separate service identifier from service descriptor. I also find it a little strange that you consider this a "major drawback". Different services will require different descriptors. Some examples: *> *> - Internet2's Scavenger Service requires signalling *> of a DSCP only. It is just turned on or off (it *> is "Less Than Best Effort"). I must be dense here... isn't the DSCP number a parameter to the signaling? *> - A globally well defined service only requires a *> limited set of parameters (ideally, bandwidth *> will do it) and a DSCP. *> - IntServ may require a couple of other parameters. *> A DSCP may be required. *> *> I'd suggest the following: *> A Service Identier MUST be present in every CASP-QoS reservation message. Depending on the service identified, a service descriptor containing service specific parameters is present. If the service itself doesn't require further description than just a service ID, we are fine. *> *> Assuming the CASP-QoS protocol to establish signalling for DiffServ domains, PHB-ID and DSCP MUST be present and could form parameters outside of the service dewscriptor (they could be part of the Service ID). I fail to understand the distinction you are making between service ID and service descriptor. I assumed that by service descriptor you meant the set of parameters needed to describe a service -- that would be the PHB-ID and the DSCP number in the case you cite -- and identified by a Service ID that is an assigned number. If the service ID is somehow a compound data structure that contains some of the service description, why have a separate service descriptor? I don't get it. Thanks, Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Oct 6 23:29:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27596 for ; Sun, 6 Oct 2002 23:29:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g973VNc14881 for nsis-archive@odin.ietf.org; Sun, 6 Oct 2002 23:31:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g973VKv14874; Sun, 6 Oct 2002 23:31:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94Ejav11740 for ; Fri, 4 Oct 2002 10:45:36 -0400 Received: from mailgw2.technion.ac.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06151 for ; Fri, 4 Oct 2002 10:43:31 -0400 (EDT) Received: by mailgw2.technion.ac.il (Postfix, from userid 60999) id 59CD136E39; Fri, 4 Oct 2002 17:45:30 +0300 (IDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 9E7FC36E3D for ; Fri, 4 Oct 2002 17:45:28 +0300 (IDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA08949 for ietf-123-outbound.07@ietf.org; Fri, 4 Oct 2002 09:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA07476 for ; Fri, 4 Oct 2002 07:31:30 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28941; Fri, 4 Oct 2002 07:29:29 -0400 (EDT) Message-Id: <200210041129.HAA28941@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 04 Oct 2002 07:29:29 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Next Steps in Signaling: Framework Author(s) : I. Freytsis et al. Filename : draft-ietf-nsis-fw-00.txt Pages : 49 Date : 2002-10-3 The NSIS working group is considering protocols for signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in [2]; this Internet Draft will propose a framework for such signaling. This initial version provides a model of the entities that take part in the signaling. It discusses the considerations that must be taken into account in developing the framework, particularly the structural options for the structure of such a protocol, and the interactions between NSIS and other protocols and functions, including security issues. Finally, it includes background material on how NSIS could support particular signaling applications. It is expected that future versions of this document will distill these structural options into a concrete technical framework, and material on particular signaling applications and deployment scenarios will be moved into separate NSIS applicability statements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-fw-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-fw-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-3150055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-fw-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-fw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-3150055.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 8 09:12:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10889 for ; Tue, 8 Oct 2002 09:12:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g98DEM303017 for nsis-archive@odin.ietf.org; Tue, 8 Oct 2002 09:14:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98DEJv03010; Tue, 8 Oct 2002 09:14:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98DDpv02976 for ; Tue, 8 Oct 2002 09:13:51 -0400 Received: from s2 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10802 for ; Tue, 8 Oct 2002 09:11:42 -0400 (EDT) Received: from ap12 (ap12.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.44]) by s2 with esmtp; Tue, 08 Oct 2002 15:13:47 +0200 From: "Xiaoming Fu" To: Ruediger.Geib@t-systems.com Cc: "'Henning Schulzrinne'" , nsis@ietf.org Subject: Re: [NSIS] New NSIS-related drafts Date: Tue, 8 Oct 2002 15:13:37 +0200 Message-ID: <004401c26ecc$83263c20$2c514c86@ap12> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g98DDpv02977 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rüdiger, Thanks for your comments. My remarks inline [XF]: ---Original message--- From: "Geib, Ruediger" To: hgs@cs.columbia.edu Cc: nsis@ietf.org Subject: Re: [NSIS] New NSIS-related drafts Date: Mon, 30 Sep 2002 16:50:50 +0200 The maximum/minimum bandwidth procedure seems to be the only feasible way of realising a simple negotiation mechanism. I still feel it to be too complex and would favor a single bandwidth as only requirement for the protocol. I'd be curious in learning more about application developers views on that. [XF] We thought this is helpful particullarly in wireless mobile environments; people may use only one bandwidth if a single bandwidth information is available. Meanwhile we would also like to see how this could or could not well-fit the QoS provisioning techniques and applications. If negotiation is kept, how are things handled for bidirectional reservations? A reservation will still be accepted if one direction gets maximum resources while the other gets minimum? [XF]IMO the space left for bidirectional reservations in CASP is small. In general, bidirectional ones introduce new error message types, related control and increased protocol complexity. I'd also favour the basic CASP-QoS protocol to be free of any pre-emption mechanism. Not every QoS service does require support of emergency calls (e.g. Internet2's Scavenger Service doesn't). Pre-emption adds signaling load and operational complexity and should at best be optional. Further, there's a parameter "L2 properties". It should be removed without replacement. Layer 2 issues are opaque to NSIS signalling. A network operator learns which service is required by NSIS signaling. The operator then decides whether his network meets these service requirements or whether it doesn't. If NSIS signaling will contain a Layer 2 specific service descriptor combining every possible layer 2 with every possible interpretation of service mapping per operator, we don't need NSIS. by the way, didn't we agree to limit NSIS strictly to layer 3? [XF] Pre-emption and L2 properties have been tentatively discussed because we learned such requirement from some operators. We'd also be listening to others whether it makes sense for supporting local objects. Cheers, Xiaoming Fu University of Goettingen, Telematics Group Lotzestr. 16-18, 37083 Goettingen, Germany Tel.+49-551-39-14411, Fax.+49-551-39-14403 mailto:fu@cs.uni-goettingen.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 10 09:29:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03203 for ; Thu, 10 Oct 2002 09:29:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ADVYW10085 for nsis-archive@odin.ietf.org; Thu, 10 Oct 2002 09:31:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ADVVv10078; Thu, 10 Oct 2002 09:31:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ABJxv03022 for ; Thu, 10 Oct 2002 07:19:59 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28374; Thu, 10 Oct 2002 07:17:48 -0400 (EDT) Message-Id: <200210101117.HAA28374@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 10 Oct 2002 07:17:47 -0400 Subject: [NSIS] I-D ACTION:draft-brunner-nsis-rsvp2-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Towards RSVP Version 2 Author(s) : M. Brunner, R. Greco Filename : draft-brunner-nsis-rsvp2-00.txt Pages : 14 Date : 2002-10-9 This memo is a first step towards the design of RSVP Version 2. We take RSVP Version 1 as a basis of this work. RSVP has been criticized mainly because of its complexity and poor scalability among others. We present the first steps towards the definition of a new version of RSVP. The goal is to provide a more 'light' approach that can help improve handling reservations in the network by means of a simplified behavior. This proposal for RSVP Version 2 is not meant as a complete replacement of RSVP Version 1 but is meant to coexist with Version 1. For some scenarios such as receiver orientation and multicasting we assume that RSVP version 1 works fine. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-nsis-rsvp2-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-brunner-nsis-rsvp2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-brunner-nsis-rsvp2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-9145013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brunner-nsis-rsvp2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brunner-nsis-rsvp2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-9145013.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 14 04:20:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12052 for ; Mon, 14 Oct 2002 04:20:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9E8Mm217439 for nsis-archive@odin.ietf.org; Mon, 14 Oct 2002 04:22:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9E8Mkv17432; Mon, 14 Oct 2002 04:22:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9E8Lqv17410 for ; Mon, 14 Oct 2002 04:21:52 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12045 for ; Mon, 14 Oct 2002 04:19:31 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9E8MaK14226 for ; Mon, 14 Oct 2002 11:22:36 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 14 Oct 2002 11:21:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Oct 2002 11:21:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 14 Oct 2002 11:21:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A57CF@esebe004.ntc.nokia.com> Thread-Topic: Planning Meeting Agendas in Atlanta Thread-Index: AcJy4h+/HdJv5pyDSB6KjbSI1LDexAAeAaIA X-Priority: 1 priority: Urgent Importance: high To: X-OriginalArrivalTime: 14 Oct 2002 08:21:39.0094 (UTC) FILETIME=[B7FE4360:01C2735A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9E8Lqv17411 Subject: [NSIS] Planning NSIS Agendas in Atlanta Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, We need to start to set the NSIS agenda for IETF 55. Let me know if you have something to discuss at the meeting and please include a reference & proposed time needed. Our time slots are as follows: TUESDAY, November 19, 2002 1300-1400 Afternoon Sessions I TSV nsis Next Steps in Signaling WG WEDNESDAY, November 20, 2002 TSV nsis Next Steps in Signaling WG I'm tentatively planning the following rough agenda. Tuesday WG update Requirements discussion Signaling Comparison discussion Wenesday Framework WG Draft discussion Discussion on individual protocol solutions draft As always the slots will be allocated for discussions according to what is outlined below. It is not the purpose of a WG session to have presentation of the content of a document. It is assumed that all attendees will have read the drafts in advance of the meeting. For documents that are work-in-progress, the presentation should cover issues resolved since the last draft followed by open issues, and controversial topics with the intent to reach a resolution of said issues and topics. For new work items, the presentation should focus on what the problem is and why it is necessary for the work group to address it. Further it must be shown how the work falls within the existing charter; no time will be allocated for proposals that do not fit the current WG charter. The solution should only be sketched. The appropriate way of bringing new work to the working group is to post an Internet Draft, send a pointer to the draft to the mailing list and promote discussion on the list. Slots on the agenda should be used to discuss outstanding topics that haven't been settled on the mailing list. In all cases only a limited number of slides should be used. Speakers should budget their at least 25% of their time to allow for discussion/questions. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 14 07:32:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14903 for ; Mon, 14 Oct 2002 07:32:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EBYMG25730 for nsis-archive@odin.ietf.org; Mon, 14 Oct 2002 07:34:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBYKv25723; Mon, 14 Oct 2002 07:34:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EBXtv25683 for ; Mon, 14 Oct 2002 07:33:55 -0400 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14874 for ; Mon, 14 Oct 2002 07:31:44 -0400 (EDT) Received: from jeongcheol ([203.255.254.88]) (authenticated) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g9EBMba27626 for ; Mon, 14 Oct 2002 20:22:37 +0900 Message-ID: <007c01c27375$514af530$58feffcb@jeongcheol> From: "jclee" To: Date: Mon, 14 Oct 2002 20:32:01 +0900 Organization: =?ks_c_5601-1987?B?xMTHu8XNxeu9xb3H?= MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0078_01C273C0.C054E760" 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 Subject: [NSIS] unsubscribe Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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_0078_01C273C0.C054E760 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0079_01C273C0.C054E760" ------=_NextPart_001_0079_01C273C0.C054E760 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 uvG+7iDA1sC9dW5zdWJzY3JpYmUgZGlzY3VzcyBqY2xlZUBjY2wuY251LmFjLmtyDQoNCg== ------=_NextPart_001_0079_01C273C0.C054E760 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRSBpZD1yaWRUaXRsZT668b7uIMDWwL08L1RJVExFPjxC QVNFIA0KaHJlZj0iZmlsZTovL0M6XFByb2dyYW0gRmlsZXNcQ29tbW9uIEZpbGVzXE1pY3Jvc29m dCBTaGFyZWRcU3RhdGlvbmVyeVwiPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxTVFlMRT5CT0RZIHsN CglNQVJHSU4tVE9QOiAyNXB4OyBGT05ULVNJWkU6IDEwcHQ7IE1BUkdJTi1MRUZUOiAyNXB4OyBD T0xPUjogIzAwMDAwMDsgRk9OVC1GQU1JTFk6ILG8uLIsIEhlbHZldGljYQ0KfQ0KUC5tc29Ob3Jt YWwgew0KCU1BUkdJTi1UT1A6IDBweDsgRk9OVC1TSVpFOiAxMHB0OyBNQVJHSU4tTEVGVDogMHB4 OyBDT0xPUjogI2ZmZmZjYzsgRk9OVC1GQU1JTFk6IEhlbHZldGljYSwgIlRpbWVzIE5ldyBSb21h biINCn0NCkxJLm1zb05vcm1hbCB7DQoJTUFSR0lOLVRPUDogMHB4OyBGT05ULVNJWkU6IDEwcHQ7 IE1BUkdJTi1MRUZUOiAwcHg7IENPTE9SOiAjZmZmZmNjOyBGT05ULUZBTUlMWTogSGVsdmV0aWNh LCAiVGltZXMgTmV3IFJvbWFuIg0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMTA2IiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBpZD1yaWRCb2R5 IGJnQ29sb3I9I2ZmZmZmZiANCmJhY2tncm91bmQ9Y2lkOjAwNzcwMWMyNzM3NSQ1MDVjNzY4MCQ1 OGZlZmZjYkBqZW9uZ2NoZW9sPg0KPERJVj51bnN1YnNjcmliZSBkaXNjdXNzIGpjbGVlQGNjbC5j bnUuYWMua3I8L0RJVj4NCjxQPiZuYnNwOzwvUD48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_001_0079_01C273C0.C054E760-- ------=_NextPart_000_0078_01C273C0.C054E760 Content-Type: image/gif; name="=?ks_c_5601-1987?B?uenB9iC56LDmLmdpZg==?=" Content-Transfer-Encoding: base64 Content-ID: <007701c27375$505c7680$58feffcb@jeongcheol> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhLQAtAID/AP////f39ywAAAAALQAtAEACcAxup8vtvxKQsFon6d02898pGkgiYoCm6sq2 7iqWcmzOsmeXeA7uPJd5CYdD2g9oPF58ygqz+XhCG9JpJGmlYrPXGlfr/Yo/VW45e7amp2tou/lW xo/zX513z+Vt+1n/tiX2pxP4NUhy2FM4xtjIUQAAOw== ------=_NextPart_000_0078_01C273C0.C054E760-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 04:05:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23384 for ; Tue, 15 Oct 2002 04:05:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9F87gE31335 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 04:07:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F87dv31328; Tue, 15 Oct 2002 04:07:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F84Dv30689 for ; Tue, 15 Oct 2002 04:04:13 -0400 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23340 for ; Tue, 15 Oct 2002 04:01:50 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9F83hw16346 for ; Tue, 15 Oct 2002 11:03:43 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 15 Oct 2002 11:03:21 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 10:49:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 15 Oct 2002 10:49:51 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F90@esebe004.ntc.nokia.com> Thread-Topic: Planning Meeting Agendas in Atlanta Thread-Index: AcJy4h+/HdJv5pyDSB6KjbSI1LDexAAeAaIAADEiFWA= To: X-OriginalArrivalTime: 15 Oct 2002 07:49:51.0857 (UTC) FILETIME=[719ABE10:01C2741F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9F84Dv30690 Subject: [NSIS] WG Last call on the Requirements Draft? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, The Requirements Document (found here) and seems largely stable and discussion on it has largely quieted down. It seems reasonable to start a working group last call on it. If there is no opposition, I propose a working group last call on the document, starting October 18th and completing on November 1st. If this is OK with the WG, I will send another mail with instructions on how to file issues. best regards, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 04:10:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23439 for ; Tue, 15 Oct 2002 04:10:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9F8CEh31474 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 04:12:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F8CCv31458; Tue, 15 Oct 2002 04:12:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F8Btv31437 for ; Tue, 15 Oct 2002 04:11:55 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23418 for ; Tue, 15 Oct 2002 04:09:33 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9F8CgK21964 for ; Tue, 15 Oct 2002 11:12:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 15 Oct 2002 11:03:21 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 10:51:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 15 Oct 2002 10:51:30 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F91@esebe004.ntc.nokia.com> Thread-Topic: Planning Meeting Agendas in Atlanta Thread-Index: AcJy4h+/HdJv5pyDSB6KjbSI1LDexAAeAaIAADElYAA= To: X-OriginalArrivalTime: 15 Oct 2002 07:51:30.0947 (UTC) FILETIME=[ACAAAD30:01C2741F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9F8Btv31438 Subject: [NSIS] draft-brunner-nsis-rsvp2-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, The following draft I found very interesting and suggest the WG read and comment on it: http://www.ietf.org/internet-drafts/draft-brunner-nsis-rsvp2-00.txt I'm not sure if we are yet ready to go into details of protocol design, so I am suggesting that chapters 1 through 4 are the most interesting parts at the present. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 04:44:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23855 for ; Tue, 15 Oct 2002 04:44:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9F8kOR00564 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 04:46:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F8kLv00557; Tue, 15 Oct 2002 04:46:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F8jav00526 for ; Tue, 15 Oct 2002 04:45:36 -0400 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23852 for ; Tue, 15 Oct 2002 04:43:15 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9F8jOKW003019; Tue, 15 Oct 2002 10:45:24 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 44MKK6VD; Tue, 15 Oct 2002 10:45:24 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Oct 2002 10:38:41 +0200 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE11E@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] draft-brunner-nsis-rsvp2-00.txt Date: Tue, 15 Oct 2002 10:45:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Actually, I also like the concepts presented in this draft (draft-brunner-nsis-rsvp2-00.txt) since they are similar with the concepts that we have presented some months ago in our draft entitled: "A Proposal for RSVPv2" and located at: http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-00.txt We have got a comment from Melinda on this draft related to the separation of the protocol in two levels. We are working on this and we will submit a new version end of the next week. The new version of our draft will include the two level concept presented in the draft-braden-2level-signaling-00.txt. Our draft will also contain solutions for intra-domain and inter-domain signalling. Best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: dinsdag 15 oktober 2002 9:52 To: nsis@ietf.org Subject: [NSIS] draft-brunner-nsis-rsvp2-00.txt Hi all, The following draft I found very interesting and suggest the WG read and comment on it: http://www.ietf.org/internet-drafts/draft-brunner-nsis-rsvp2-00.txt I'm not sure if we are yet ready to go into details of protocol design, so I am suggesting that chapters 1 through 4 are the most interesting parts at the present. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 06:50:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25935 for ; Tue, 15 Oct 2002 06:50:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FApkG06653 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 06:51:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FApiv06646; Tue, 15 Oct 2002 06:51:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FAocv06619 for ; Tue, 15 Oct 2002 06:50:38 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25932 for ; Tue, 15 Oct 2002 06:48:26 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9FApXK04181 for ; Tue, 15 Oct 2002 13:51:33 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Oct 2002 13:49:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 13:49:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] draft-brunner-nsis-rsvp2-00.txt Date: Tue, 15 Oct 2002 13:49:20 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5803@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] draft-brunner-nsis-rsvp2-00.txt Thread-Index: AcJ0JzXjQMHLhNmcQIis9BHvDXLflAAERNvg To: , X-OriginalArrivalTime: 15 Oct 2002 10:49:23.0352 (UTC) FILETIME=[85EA7180:01C27438] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9FAocv06620 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Georgios, > Actually, I also like the concepts presented in this draft > (draft-brunner-nsis-rsvp2-00.txt) > since they are similar with the concepts that we have presented > some months ago in our draft entitled: I think both proposals are playing in the same sandbox. > "A Proposal for RSVPv2" and located at: > > http://www.ietf.org/internet-drafts/draft-westberg-proposal-fo > r-rsvpv2-00.txt > > We have got a comment from Melinda on this draft related to the > separation of the protocol in two levels. We are working on this > and we will submit a new version end of the next week. > The new version of our draft will include the two level concept > presented in the draft-braden-2level-signaling-00.txt. > Our draft will also contain solutions for intra-domain and > inter-domain signalling. I think we are still (as a WG) sorting through some architectural considerations, so I hope you try to focus on such considerations before jumping into protocol design. I'm hoping for the Atlanta meeting, we could nail down framework & architectural considerations first. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 08:40:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29058 for ; Tue, 15 Oct 2002 08:40:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FCgO312500 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 08:42:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCgLv12490; Tue, 15 Oct 2002 08:42:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FCfKv12458 for ; Tue, 15 Oct 2002 08:41:20 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28994 for ; Tue, 15 Oct 2002 08:39:06 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9FCf7aW016574; Tue, 15 Oct 2002 05:41:07 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAF41456; Tue, 15 Oct 2002 05:36:20 -0700 (PDT) Message-Id: <200210151236.AAF41456@mira-sjc5-4.cisco.com> To: john.loughney@nokia.com cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] WG Last call on the Requirements Draft? In-Reply-To: Message from john.loughney@nokia.com of "Tue, 15 Oct 2002 10:49:51 +0300." <0C1353ABB1DEB74DB067ADFF749C4EEFD38F90@esebe004.ntc.nokia.com> Date: Tue, 15 Oct 2002 08:41:15 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I think that if last call is needed to stimulate discussion we should forge ahead but it seems to me that the document is nowhere near ready to go to the IESG. I've been remiss about going through it in detail, but a quick scan shows that there's quite a bit of framework material in it. Aside from being unnecessary to the document, it runs the risk of conflicting with the separate framework document that's currently under development. If you take a look at other requirements documents that have recently been published as RFCs in the Transport Area you'll see that the actual requirements material typically starts somewhere around page 4 or 5 and sometimes as early as page 1. In the NSIS requirements document the requirements material starts on page 10. I think a great deal of that introductory material should be removed from the requirements document and integrated into the framework document if it's not already in there. I'll post more specific comments by the end of the week, but thought that the above may bear on the question of whether or not the document should go into last call. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 09:35:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01095 for ; Tue, 15 Oct 2002 09:35:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FDbKt15645 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 09:37:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDbHv15566; Tue, 15 Oct 2002 09:37:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDarv15104 for ; Tue, 15 Oct 2002 09:36:53 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01076 for ; Tue, 15 Oct 2002 09:34:39 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT57KQ>; Tue, 15 Oct 2002 14:36:48 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5AA0@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Tue, 15 Oct 2002 14:36:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [NSIS] new framework (was: RE: I-D ACTION:draft-ietf-nsis-fw-00.txt) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="windows-1252" Hi all, I'd like to highlight the existence of this draft to the wg, in the hope of stimulating some discussion before Atlanta. It's an updated (mainly structurally re-arranged) version of our framework document discussed in Yokohama. It contains just as many open issues and discussion points as then, but the terminology has been cleaned up and the open issues highlighted in their own special section. I am aware of printouts of earlier framework versions, covered with comments and questions and objections ... maybe some of these could see daylight at last ... If people want to pick on one of the open issues to start off with, I would highlight the question of the function split between the 'basic' NSIS protocol, and the signalling applications which operate somehow above it. There may be lessons for the framework coming out of some of the protocol proposals which have been made recently. Obviously, all the other open issues are just as open to comment as well. If there is rapid progress, we could even imagine an update before Atlanta. Cheers, Robert Hancock (ed) > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 04 October 2002 12:29 > Cc: nsis@ietf.org > Subject: I-D ACTION:draft-ietf-nsis-fw-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Next Steps in Signaling > Working Group of the IETF. > > Title : Next Steps in Signaling: Framework > Author(s) : I. Freytsis et al. > Filename : draft-ietf-nsis-fw-00.txt > Pages : 49 > Date : 2002-10-3 > > The NSIS working group is considering protocols for signaling for > resources for a traffic flow along its path in the network. The > requirements for such signaling are being developed in [2]; this > Internet Draft will propose a framework for such signaling. > This initial version provides a model of the entities that take part > in the signaling. It discusses the considerations that must be taken > into account in developing the framework, particularly the > structural > options for the structure of such a protocol, and the interactions > between NSIS and other protocols and functions, including security > issues. Finally, it includes background material on how NSIS could > support particular signaling applications. > It is expected that future versions of this document will distill > these structural options into a concrete technical framework, and > material on particular signaling applications and deployment > scenarios will be moved into separate NSIS applicability statements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nsis-fw-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nsis-fw-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 10:52:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04020 for ; Tue, 15 Oct 2002 10:52:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FEsMZ20163 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 10:54:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FEsKv20155; Tue, 15 Oct 2002 10:54:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FErev20126 for ; Tue, 15 Oct 2002 10:53:40 -0400 Received: from mgw-x3.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04007 for ; Tue, 15 Oct 2002 10:51:27 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9FEs7210576 for ; Tue, 15 Oct 2002 17:54:07 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Oct 2002 15:50:37 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 15:50:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last call on the Requirements Draft? Date: Tue, 15 Oct 2002 15:50:31 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A580E@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] WG Last call on the Requirements Draft? Thread-Index: AcJ0SCs1eYCxPeOgR3icu0FFbQs07gAAQlvA To: Cc: X-OriginalArrivalTime: 15 Oct 2002 12:50:36.0179 (UTC) FILETIME=[74DBC630:01C27449] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9FErev20127 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, > I think that if last call is needed to stimulate discussion > we should forge ahead but it seems to me that the document > is nowhere near ready to go to the IESG. I've been remiss > about going through it in detail, but a quick scan shows > that there's quite a bit of framework material in it. Aside > from being unnecessary to the document, it runs the risk of > conflicting with the separate framework document that's > currently under development. If the current Requirements has fluff, duplicate information and or unnescessary requirements, we should clean it up. Of course, WG last call is still quite far from IESG last call. > If you take a look at other requirements documents that have > recently been published as RFCs in the Transport Area you'll > see that the actual requirements material typically starts > somewhere around page 4 or 5 and sometimes as early as page > 1. In the NSIS requirements document the requirements > material starts on page 10. I think a great deal of that > introductory material should be removed from the > requirements document and integrated into the framework > document if it's not already in there. > > I'll post more specific comments by the end of the week, but > thought that the above may bear on the question of whether > or not the document should go into last call. The best way forward on this is for you to document specific concerns. thanks! John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 11:11:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04587 for ; Tue, 15 Oct 2002 11:11:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FFDBQ21305 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 11:13:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FFD8v21297; Tue, 15 Oct 2002 11:13:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FFCVv21275 for ; Tue, 15 Oct 2002 11:12:31 -0400 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04571 for ; Tue, 15 Oct 2002 11:10:18 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9FFCQcl001471; Tue, 15 Oct 2002 08:12:26 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAF44318; Tue, 15 Oct 2002 08:07:30 -0700 (PDT) Message-Id: <200210151507.AAF44318@mira-sjc5-4.cisco.com> To: john.loughney@nokia.com cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] WG Last call on the Requirements Draft? In-Reply-To: Message from john.loughney@nokia.com of "Tue, 15 Oct 2002 15:50:31 +0300." <0C1353ABB1DEB74DB067ADFF749C4EEF015A580E@esebe004.ntc.nokia.com> Date: Tue, 15 Oct 2002 11:12:25 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I'm in the process of going through the document and one thing pops out at me that I really think has to be addressed ASAP. In section 5.2, several requirements (which are not actually stated as requirements, incidentally) suggest that we're supporting off-path signaling. I believe that this is currently (and possibly forever) out of scope. This has been discussed quite a bit and it's my recollection that the working group never came to a decision. This also needs to be consistent with the framework document. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 12:47:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07300 for ; Tue, 15 Oct 2002 12:47:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FGnOR27026 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 12:49:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FGnLv27010; Tue, 15 Oct 2002 12:49:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FGmfv26970 for ; Tue, 15 Oct 2002 12:48:41 -0400 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07265 for ; Tue, 15 Oct 2002 12:46:27 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9FGmLw23055 for ; Tue, 15 Oct 2002 19:48:21 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Oct 2002 19:48:36 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 19:48:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last call on the Requirements Draft? Date: Tue, 15 Oct 2002 19:48:33 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5818@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] WG Last call on the Requirements Draft? Thread-Index: AcJ0XWW+0hLlsF0dSkSA9bafzaGuhAADTzLw To: Cc: X-OriginalArrivalTime: 15 Oct 2002 16:48:34.0538 (UTC) FILETIME=[B36C74A0:01C2746A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9FGmfv26971 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, > I'm in the process of going through the document and one > thing pops out at me that I really think has to be addressed > ASAP. In section 5.2, several requirements (which are not > actually stated as requirements, incidentally) suggest that > we're supporting off-path signaling. I believe that this is > currently (and possibly forever) out of scope. This has > been discussed quite a bit and it's my recollection that the > working group never came to a decision. > > This also needs to be consistent with the framework document. This sounds like a reasonable request, but more detail would help - what text looks bad, etc. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 12:50:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07399 for ; Tue, 15 Oct 2002 12:50:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FGq7b27173 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 12:52:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FGq3v27162; Tue, 15 Oct 2002 12:52:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FGpBv27138 for ; Tue, 15 Oct 2002 12:51:11 -0400 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07374 for ; Tue, 15 Oct 2002 12:48:56 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9FGonw24520 for ; Tue, 15 Oct 2002 19:50:49 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Oct 2002 19:51:05 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 19:51:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [NSIS] new framework (was: RE: I-D ACTION:draft-ietf-nsis-fw-00.txt) Date: Tue, 15 Oct 2002 19:51:04 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A581A@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] new framework (was: RE: I-D ACTION:draft-ietf-nsis-fw-00.txt) Thread-Index: AcJ0UAQF/f48ezlqSRewm/fDCVnFxwAGvEYA To: , X-OriginalArrivalTime: 15 Oct 2002 16:51:05.0201 (UTC) FILETIME=[0D39CE10:01C2746B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9FGpBv27139 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi All, I would second Robert's request. Remember that if you point to specific text & submit text to replace it, you stand a better chance of effecting things ... thanks, John > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 15 October, 2002 16:37 > To: nsis@ietf.org > Subject: [NSIS] new framework (was: RE: I-D > ACTION:draft-ietf-nsis-fw-00.txt) > > > Hi all, > > I'd like to highlight the existence of this draft to the wg, > in the hope of stimulating some discussion before Atlanta. > > It's an updated (mainly structurally re-arranged) version of > our framework document discussed in Yokohama. It contains > just as many open issues and discussion points as then, but > the terminology has been cleaned up and the open issues > highlighted in their own special section. > > I am aware of printouts of earlier framework versions, > covered with comments and questions and objections ... maybe > some of these could see daylight at last ... > > If people want to pick on one of the open issues to start off > with, I would highlight the question of the function split > between the 'basic' NSIS protocol, and the signalling > applications which operate somehow above it. There may be > lessons for the framework coming out of some of the protocol > proposals which have been made recently. Obviously, all the > other open issues are just as open to comment as well. > > If there is rapid progress, we could even imagine an update > before Atlanta. > > Cheers, > > Robert Hancock (ed) > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 04 October 2002 12:29 > > Cc: nsis@ietf.org > > Subject: I-D ACTION:draft-ietf-nsis-fw-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Next Steps in Signaling > > Working Group of the IETF. > > > > Title : Next Steps in Signaling: Framework > > Author(s) : I. Freytsis et al. > > Filename : draft-ietf-nsis-fw-00.txt > > Pages : 49 > > Date : 2002-10-3 > > > > The NSIS working group is considering protocols for signaling for > > resources for a traffic flow along its path in the network. The > > requirements for such signaling are being developed in [2]; this > > Internet Draft will propose a framework for such signaling. > > This initial version provides a model of the entities that > take part > > in the signaling. It discusses the considerations that must > be taken > > into account in developing the framework, particularly the > > structural > > options for the structure of such a protocol, and the interactions > > between NSIS and other protocols and functions, including security > > issues. Finally, it includes background material on how NSIS could > > support particular signaling applications. > > It is expected that future versions of this document will distill > > these structural options into a concrete technical framework, and > > material on particular signaling applications and deployment > > scenarios will be moved into separate NSIS applicability statements. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-00.txt > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body > > of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-nsis-fw-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-nsis-fw-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > ============================================================== > ========================== > Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 13:35:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08646 for ; Tue, 15 Oct 2002 13:35:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FHb9d29386 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 13:37:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FHZmv29099; Tue, 15 Oct 2002 13:35:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FHX0v28970 for ; Tue, 15 Oct 2002 13:33:00 -0400 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08493 for ; Tue, 15 Oct 2002 13:30:41 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9FHWocl019358 for ; Tue, 15 Oct 2002 10:32:50 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAF49587; Tue, 15 Oct 2002 10:27:54 -0700 (PDT) Message-Id: <200210151727.AAF49587@mira-sjc5-4.cisco.com> To: nsis@ietf.org From: Melinda Shore Date: Tue, 15 Oct 2002 13:32:49 -0400 Subject: [NSIS] Comments on requirements draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I spent the morning going through the requirements document and have appended some comments. A couple of general points: 1) requirements documents are really hard. They need to document the actual requirements upon the protocol that's to be developed and not do much else, which is more difficult than it sounds. The requirements mustn't include mechanisms and they shouldn't provide architecture or framework material - that's why we have a separate framework document 2) this requirement document contains a tremendous amount of framework material. That material needs to be separated out and integrated into the framework document. 3) the requirements are often not stated as requirements or they're stated somewhat mushily, which can lead to confusion. "The NSIS protocol MUST be able to frobnitz the gorblatt" is not the same thing as "The NSIS protocol MUST frobnitz the gorblatt" and isn't, I believe, actually a requirement. 4) we need to get religion about the two-layer model. Should we have a separate QoS signaling application requirements document in addition to the NSIS protocol requirements document? In the very least the QoS stuff should be moved into a separate section. Comments appended. Some are nit-picky and some, I think, are fairly substantive. Melinda ======== Editorial: should be "NSIS Working Group", not "Network Working Group" References need to be split into normative and informative Need to include: "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited." in "Status of this Memo" section Introduction: Change "It does not list any problems of existing signaling protocols such as RSVP" to something like "We do not identify problems with existing signaling protocols, such as RSVP". Better still, delete it. Change paragraph starting with "QoS is a pretty large field" to "While we anticipate this protocol will be used for other applications in addition to QoS signaling, this document focuses on QoS" or something like that. Requirements: Change "All of them are not strictly defined and should not be regarded as that, but should give a feeling about where in the network we have different requirements concerning signaling." To "These divisions between network types are not strict and do not appear in all networks, but where they do exist they may influence signaling requirements and will be highlighted as necessary." In terminology: define "Upstream" and "Downstream" 5.3.4 Second MAY should be lowercase Section 6: "threads" should be "threats" Substance: The QoS signaling scenarios belong in the framework document. Shouldn't there be some scenarios for something beside QoS, so that we can better generalize the protocol? This document should *not* be presenting conceptual models, just requirements. Conceptual models belong in the framework. Remove related material, such as introductory paragraph beginning with "It is clear that the subject of QoS is uniquely complex" Delete first paragraph of terminology section, make sure that all terms are actually used in the document. Receiver-initiated signaling protocol and sender-initiated signaling protocol are not. Get rid of mom-and-apple-pie or obvious terms, like "QoS Technology." "Resource Management Function" definition is far too abstract. Definitions too QoS-y. For example, "Flow" can be defined in terms of resources requested rather than QoS requested. "QoS Provisioning" should be "Provisioning," etc. I would give serious thought to a separate QoS application requirements document. "Trigger" used a lot - I think I probably know what's intended by it, but I don't know for a fact what it means. Needs definition. Delete section 3, refer to framework Delete section 4, refer to framework Consistent problem throughout Requirements section: requirements aren't stated *as* requirements. Application and transport need to be separated out more cleanly (for example, 5.3.4 and 5.3.5) Use of "may be able to" - what does that mean? Needs to be more definite. 5.1.1 Needs to be hardened up lest risks being mom-and-apple- pie. 5.1.2 not stated as a requirement. "The NSIS protocol MUST allow the NI to query for resource availability without initiating a request." 5.1.3 is a weak protocol requirement and is probably redundant with 5.1.1. It's unclear whether or not bullet items are requirements 5.1.4 is related to 5.1.1 and 5.1.3. We should probably try to distill them down to one or two requirements 5.1.5 is not a protocol requirement 5.1.7 is related to 5.1.1, 5.1.3, and 5.1.4 See 5.1.4. Also, not stated as requirement. 5.2.1 Not stated as requirement. The first sentence is closer, I think, to what's intended than the header (requirement) is. 5.2.2 Not stated as requirement. Also wrong - this is out of scope 5.2.3 Requirement in body of paragraph? SHOULD in 2nd paragraph should be lower-case 5.3 I'd rename to something like "Messages" 5.3.2 Unclear. Possibilities: do you mean that any NSIS node, whether NI, NF, or NR, should be able to initiate a teardown, or do you mean that any NSIS node that releases its resources without a request from the initiator should send out a teardown, or do you mean that any NSIS node that releases its resources without a request from the initiator should send out a notice? Don't know what "The goal is to prevent stale state within the network and adds robustness to the operation of NSIS. So in other words, an NSIS signaling protocol or mechanisms MUST provide means for an NSIS entity to discover and remove local stale state." means. Resource discovery is covered in 5.1.2, and for a node to discover its own state is node mechanism and not a protocol requirement 5.3.3 I would change that first SHOULD to a MUST. Note that "MUST be able to notify" is not the same as "MUST notify." Do we care? Bit about security should be moved to security requirements. Discussion is a bit frameworky, I'd delete it. 5.3.4 Some questions: Doesn't the answer depend on the application (if we're using the two-layer architecture)? If so, wouldn't the contents of the answer be opaque to the protocol machinery anyway? 5.3.5 A bit murky. My thinking is that local information may be added or removed from NSIS messages as they traverse NSIS nodes, rather than suggesting that additional dialogue (i.e. traffic) is needed between nodes. 5.4.1 A bit frameworky. At least make sure this is consistent with framework 5.4.2 See 5.3.4 and 5.3.5 5.4.3 This needs to be rewritten so that it's a protocol requirement and not a mechanism requirement. Also, it's a bit application-ish and may depend on the application 5.4.4. (the word "seamless" makes me queasy) This can be deleted - it's about NF mechanism 5.5 This section really needs more discussion. Some of it is either obvious or meaningless, and some of it is outside the scope of what is even possible. A requirements document should state requirements in the form of things like "The NSIS protocol MUST support aggregation of requests." 5.6 This might be best broken up and redistributed among other sections 5.6.1 I'm not sure what this means - something akin to IPSec selectors? 5.6.2 Can probably be deleted unless a specific protocol requirement can be identified 5.6.3 Needs to be stated more clearly: "Either the NI or NR of a specific reservation MAY initiate a renegotiation of that reservation." I'd delete the rest and create a new requirement around NF initiation of a renegotiation. 5.6.4 "The NSIS protocol SHOULD permit signaling both unidirectional and bidirectional reservation requests." Delete second paragraph. 5.7.1. "The NSIS protocol MUST support strong authentication among NSIS nodes. The protocol MUST NOT support the use of plaintext passwords for authentication or encryption." Delete the rest. (Note that this is actually quite difficult to do in practice, particularly interdomain). 5.7.2 Need to distinguish between application and transport. Delete frameworky text. 5.7.3 Need to think about protecting individual message elements as well as entire message 5.7.4 Second sentence: "Replay protection SHOULD be resilient to crashes and other network outages." (not MUST because it's harder than it sounds). delete last sentence - not a requirement 5.7.5 Belongs in framework document 5.7.6 Identity of what? Where does this sit in terms of transport layer/application layer split? Accounting stuff - application layer 5.7.7 "The NSIS protocol SHOULD be resilient against denial-of-service attacks." Currently unclear. Delete rest of paragraph 5.7.8 "The NSIS protocol MUST allow encryption of NSIS messages between NSIS nodes." 5.7.10 Delete 5.8.1 Delete the word "efficient" - motherhood/apple pie 5.9.1 Not a protocol requirement. 5.9.2 "The NSIS protocol MUST support IPv4 and IPv6." 5.9.4 Not just the security mechanism, need to identify considerations for transport and for application. Also, might want to think about interactions with 5.9.3 5.9.5 Delete "seamless" Isn't this redundant with 5.8.1? 5.9.6 This is really unclear and should probably be deleted. There are specific issues with policy-based routing that need to be addressed in the framework document and may be reflected back here as specific protocol requirements - needs more discussion. 5.10.1 Keep first sentence, delete rest 5.10.2 Um, how does this work with on-path signaling? Delete 5.10.3 "If an NSIS node detects that another NSIS node is malfunctioning, it SHOULD notify the NSIS initiator." Delete failover discussion. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 18:13:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17178 for ; Tue, 15 Oct 2002 18:13:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FMFdx12496 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 18:15:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FMFXv12485; Tue, 15 Oct 2002 18:15:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FMEBv12443 for ; Tue, 15 Oct 2002 18:14:11 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17154 for ; Tue, 15 Oct 2002 18:11:54 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9FME3s28567; Tue, 15 Oct 2002 15:14:03 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA10140; Tue, 15 Oct 2002 22:14:03 GMT Date: Tue, 15 Oct 2002 22:14:03 GMT Message-Id: <200210152214.WAA10140@gra.isi.edu> To: Ruediger.Geib@t-systems.com, fu@cs.uni-goettingen.de Subject: Re: [NSIS] New NSIS-related drafts Cc: hgs@cs.columbia.edu, nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> Further, there's a parameter "L2 properties". It should be removed *> without replacement. Layer 2 issues are opaque to NSIS signalling. A *> network operator learns which service is required by NSIS signaling. The *> operator then decides whether his network meets these service *> requirements or whether it doesn't. If NSIS signaling will contain a *> Layer 2 specific service descriptor combining every possible layer 2 *> with every possible interpretation of service mapping per operator, we *> don't need NSIS. by the way, didn't we agree to limit NSIS strictly to *> layer 3? *> I would suggest that this issue needs more thought. I can tell you that our ATM friends are adding a whole new object class to RSVP[-TE] to carry one 3-bit integer encoding the ATM Qos class -- CBR, etc. I know because the IANA asked me as RSVP expert to comment on the assignment of an RSVP class number. I think that this particular extension is severely brain-dead; it should rather be a single CType for an L2 properties object (or be in a flowspec). Unfortunately this work, like a lot of the stuff going on now, is outside the IETF so I have no say. However, it does show that L2 properties may have a place in the general signaling regime (which *I* think is what the present NSIS WG should be addressing, not just a particular subset such as QoS). Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 15 20:14:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19619 for ; Tue, 15 Oct 2002 20:14:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9G0GL918086 for nsis-archive@odin.ietf.org; Tue, 15 Oct 2002 20:16:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9G0GIv18079; Tue, 15 Oct 2002 20:16:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9G0FKv18046 for ; Tue, 15 Oct 2002 20:15:20 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19611 for ; Tue, 15 Oct 2002 20:13:02 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT58DN>; Wed, 16 Oct 2002 01:14:44 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5AB9@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Melinda Shore Cc: nsis@ietf.org Date: Wed, 16 Oct 2002 01:14:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [NSIS] on/off path, and requirements vs. framework content (was RE: WG L ast call on the Requirements Draft?) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi melinda, one of the problems we had during the on/off path discussion shortly after yokohama was agreeing how to define the terms for what was in and out of scope in the first place, since there seemed to be many nuances (in some minds) about possible meanings of the terms. the latest framework contains a carefully worded proposed definition (we used the terms path coupled/decoupled). if we could agree that was a useful definition, maybe it could be incorporated into some scoping section of the requirements document. on the other hand, I probably agree with you (other mails) that some of the requirements draft material is more framework related. what i'm unclear about is just how 'bare bones' the requirements document should be. without context, terminology and so on, the requirements could end up being a write-only RFC. from a frameworker's perspective, i guess i'm interested in suggestions for where the requirements/framework split should go. robert ps. i didn't follow the midcom work in detail, but the RFCs appear very much as companion documents. that's nice, but at the moment (in my view anyway) the NSIS requirements content is vastly more mature than the framework, so the same approach doesn't necessarily apply. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 15 October 2002 17:12 > To: john.loughney@nokia.com > Cc: nsis@ietf.org > Subject: Re: [NSIS] WG Last call on the Requirements Draft? > > > I'm in the process of going through the document and one > thing pops out at me that I really think has to be addressed > ASAP. In section 5.2, several requirements (which are not > actually stated as requirements, incidentally) suggest that > we're supporting off-path signaling. I believe that this is > currently (and possibly forever) out of scope. This has > been discussed quite a bit and it's my recollection that the > working group never came to a decision. > > This also needs to be consistent with the framework document. > > Melinda > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 16 00:02:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23295 for ; Wed, 16 Oct 2002 00:02:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9G44Uc28293 for nsis-archive@odin.ietf.org; Wed, 16 Oct 2002 00:04:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9G44Hv28278; Wed, 16 Oct 2002 00:04:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIkNv00624 for ; Tue, 15 Oct 2002 14:46:23 -0400 Received: from web14906.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11454 for ; Tue, 15 Oct 2002 14:44:08 -0400 (EDT) Message-ID: <20021015184618.66747.qmail@web14906.mail.yahoo.com> Received: from [208.28.84.65] by web14906.mail.yahoo.com via HTTP; Tue, 15 Oct 2002 11:46:18 PDT Date: Tue, 15 Oct 2002 11:46:18 -0700 (PDT) From: Sharif Shahrier To: mobile-ip@sunroof.eng.sun.com, seamoby@ietf.org, nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [NSIS] Carl Williams e-mail Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, Could Carl Williams please send me e-mail directly, so I have his e-mail address. I was working on a draft with him, but don't have access to my old computer right now. I am not subscribed to any IETFl ists. Thus, I'll be glad if Carl can send me e-mail so we can establish communication. Thanks. Sharif. __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 16 07:16:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24578 for ; Wed, 16 Oct 2002 07:16:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GBHpE28130 for nsis-archive@odin.ietf.org; Wed, 16 Oct 2002 07:17:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GBHmv28123; Wed, 16 Oct 2002 07:17:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GBGfv28084 for ; Wed, 16 Oct 2002 07:16:41 -0400 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24555 for ; Wed, 16 Oct 2002 07:14:29 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 16 Oct 2002 13:15:50 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <464HSPKM>; Wed, 16 Oct 2002 13:15:49 +0200 Message-Id: From: "Geib, Ruediger" To: braden@ISI.EDU Cc: nsis@ietf.org Subject: RE: [NSIS] New NSIS-related drafts Date: Wed, 16 Oct 2002 13:15:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9GBGfv28085 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Bob, if you use C-Type to identify a single service, I would agree with you. By single service I mean: - Less Than Best Effort -> own C-Type - IntServ Guaranteed -> own C-Type - IntServ Controlled -> own C-Type IntServ doesn't make this distinction in the C-Type, there's only one C-Type saying "IntServ". The two IntServ services are identified explicitely where required (Receiver FLOWSPEC, 9th octet). Prior to this separation IntServ signals information about policing and MTU sizes (Sender). Services specified in other ways than IntServ may not require signaling of this information. I continue to look at this as a major drawback of IntServ/RSVP (using IntServ signaling for one of these other services is somewhat unattractive). Please note that I've put "IntServ" in front of RSVP already in my first message. C-Type is an 8-bit field. Instead of identifying individual services it may be useful to identify "Meta services" only (e.g QoS, MidBox) and have the service ID / service descriptor there. I didn't read the RSVP related drafts yet, please don't critisise me if this is already proposed there. To me the "elements common" to all DiffServ based QoS services are a service name, a PHB, and a DSCP as part of a service ID. This allows flexible addition of a service specfic parameter TLV. If it is required. Examples: Service specific parameters are absent by definition the case of Less Than Best Effort. They must be the IntServ Guaranteed service parametrisation (like Flowspec etc.), should the latter be signaled that way. Regards, Rüdiger > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: Saturday, October 05, 2002 11:36 PM > To: hgs@cs.columbia.edu; Geib, Rudiger > Cc: nsis@ietf.org > Subject: Re: [NSIS] New NSIS-related drafts > > > Rüdiger Geib wrote: > > *> One such capability could be "QoS". The second draft describes a > *> QoS client. The casp-qos draft is not as elaborated as the CASP > *> draft. It repeats one of the major drawbacks of IntServ/RSVP: it > *> doesn't separate a service identifier from a service descriptor. > > I would say that this criticism is largely incorrect. The int-serv > folks defined a family of service descriptors, with some common > elements. It was expected that this family would be extended, and the > syntactic hooks for extension are there. If for some reason this does > not work for you, e.g., because (unwisely, I believe) you did not want > the common elements defined by int-serv, you have only to define new > formats of Flowspecs, etc. The CType seems to work just fine as a > service identifier. I would therefore say that IntServ/RSVP DOES > effectively separate service identifier from service descriptor. > > I also find it a little strange that you consider this a > "major drawback". > > Different services will require different descriptors. Some examples: > *> > *> - Internet2's Scavenger Service requires signalling > *> of a DSCP only. It is just turned on or off (it > *> is "Less Than Best Effort"). > > I must be dense here... isn't the DSCP number a parameter to the > signaling? > > *> - A globally well defined service only requires a > *> limited set of parameters (ideally, bandwidth > *> will do it) and a DSCP. > *> - IntServ may require a couple of other parameters. > *> A DSCP may be required. > *> > *> I'd suggest the following: > *> A Service Identier MUST be present in every CASP-QoS > reservation message. Depending on the service identified, a > service descriptor containing service specific parameters is > present. If the service itself doesn't require further > description than just a service ID, we are fine. > > *> > *> Assuming the CASP-QoS protocol to establish signalling > for DiffServ domains, PHB-ID and DSCP MUST be present and > could form parameters outside of the service dewscriptor > (they could be part of the Service ID). > > I fail to understand the distinction you are making between service ID > and service descriptor. I assumed that by service descriptor > you meant > the set of parameters needed to describe a service -- that > would be the > PHB-ID and the DSCP number in the case you cite -- and identified by a > Service ID that is an assigned number. If the service ID is somehow a > compound data structure that contains some of the service description, > why have a separate service descriptor? I don't get it. > > Thanks, > > Bob Braden > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 16 10:31:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00904 for ; Wed, 16 Oct 2002 10:31:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GEXhU05673 for nsis-archive@odin.ietf.org; Wed, 16 Oct 2002 10:33:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GEXev05660; Wed, 16 Oct 2002 10:33:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GEVJv05286 for ; Wed, 16 Oct 2002 10:31:19 -0400 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00658 for ; Wed, 16 Oct 2002 10:29:04 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 16 Oct 2002 16:31:14 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <464HS84N>; Wed, 16 Oct 2002 16:31:14 +0200 Message-Id: From: "Geib, Ruediger" To: braden@ISI.EDU Cc: nsis@ietf.org Subject: RE: [NSIS] New NSIS-related drafts - L2 issue Date: Wed, 16 Oct 2002 16:31:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9GEVJv05287 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Bob Braden wrote> > ...L2 properties may > have a place in the general signaling regime (which *I* think > is what the present NSIS WG should be addressing, not just a > particular subset such as QoS). Do you have a preference how to continue on L2 issues? Assuming a single basic NSIS signaling protocol supporting different NSIS client protocols NSIS could: - Have a separate NSIS client protocol taking care of L2 related signaling - Insert L2 stuff into other NSIS client protocols (like QoS, may be others too) I'd prefer the first attempt. The NSIS signaling transport protocol is IP however. So this would be limited to L2 services with an IP control plane. This would leave us with insertion into other client protocols as a solution. If support of L2 information is no more than an option, I think I could live with it. By "option" I mean: - A NSIS client protocols progress to standard is not delayed by the specification state of its L2 information elements. - The L2 TLV(s) may be present in a signaling dialogue, but don't have to be. I favour to keep interworking and service mapping issues out of signalling specifications. Regards, Rüdiger Rüdiger Geib>*> >*> Further, there's a parameter "L2 properties". It should >*> be removed without replacement. Layer 2 issues are >*> opaque to NSIS signalling. A network operator learns >*> which service is required by NSIS signaling. The >*> operator then decides whether his network meets these service >*> requirements or whether it doesn't. If NSIS signaling >*> will contain a Layer 2 specific service descriptor >*> combining every possible layer 2 with every possible >*> interpretation of service mapping per operator, we >*> don't need NSIS. by the way, didn't we agree to limit >*> NSIS strictly to layer 3? > Bob Braden> > I would suggest that this issue needs more thought. I can tell you > that our ATM friends are adding a whole new object class to RSVP[-TE] > to carry one 3-bit integer encoding the ATM Qos class -- CBR, etc. I > know because the IANA asked me as RSVP expert to comment on the > assignment of an RSVP class number. I think that this particular > extension is severely brain-dead; it should rather be a single CType > for an L2 properties object (or be in a flowspec). Unfortunately this > work, like a lot of the stuff going on now, is outside the IETF so I > have no say. However, it does show that L2 properties may > have a place in the general signaling regime (which *I* think > is what the present NSIS WG should be addressing, not just a > particular subset such as QoS). _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 16 10:54:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01996 for ; Wed, 16 Oct 2002 10:54:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GEuBi07575 for nsis-archive@odin.ietf.org; Wed, 16 Oct 2002 10:56:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GEu8v07560; Wed, 16 Oct 2002 10:56:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GEt2v07478 for ; Wed, 16 Oct 2002 10:55:02 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01958 for ; Wed, 16 Oct 2002 10:52:47 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9GEsvxF014676; Wed, 16 Oct 2002 07:54:57 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAF83221; Wed, 16 Oct 2002 07:49:58 -0700 (PDT) Message-Id: <200210161449.AAF83221@mira-sjc5-4.cisco.com> To: "Hancock, Robert" cc: nsis@ietf.org From: Melinda Shore In-Reply-To: Message from "Hancock, Robert" of "Wed, 16 Oct 2002 01:14:39 BST." <76C92FBBFB58D411AE760090271ED41805DF5AB9@rsys002a.roke.co.uk> Date: Wed, 16 Oct 2002 10:54:52 -0400 Subject: [NSIS] Re: on/off path, and requirements vs. framework content (was RE: WG L ast call on the Requirements Draft?) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > the latest framework contains a carefully worded proposed > definition (we used the terms path coupled/decoupled). if > we could agree that was a useful definition, maybe it > could be incorporated into some scoping section of the > requirements document. That's a good suggestion, although my personal preference is to refer between the documents rather than to include large amounts of redundant material. But maybe one of the first things we need to focus on in the framework document are the on-path/off-path definition and to come to some absolute, documented agreement about what the NSIS protocol will cover. > ps. i didn't follow the midcom work in detail, but the > RFCs appear very much as companion documents. that's nice, > but at the moment (in my view anyway) the NSIS > requirements content is vastly more mature than the > framework, so the same approach doesn't necessarily apply. It's impossible, I think, to have two document progress at exactly the same rate of speed. I think it's almost certainly the case that there are requirements either implied or explicitly stated in the framework draft, and those will need to be identified and incorporated into requirements draft, and it's likely that the requirements currently identified in the requirements draft may change as the framework is solidified. I wouldn't be in favor of completing one document too far in advance of the other. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 16 18:31:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14018 for ; Wed, 16 Oct 2002 18:31:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GMXVe01923 for nsis-archive@odin.ietf.org; Wed, 16 Oct 2002 18:33:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GMXSv01916; Wed, 16 Oct 2002 18:33:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GMWJv01890 for ; Wed, 16 Oct 2002 18:32:19 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13954 for ; Wed, 16 Oct 2002 18:30:02 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9GMWBxF001499 for ; Wed, 16 Oct 2002 15:32:11 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG03450; Wed, 16 Oct 2002 15:27:15 -0700 (PDT) Message-Id: <200210162227.AAG03450@mira-sjc5-4.cisco.com> To: nsis@ietf.org From: Melinda Shore Date: Wed, 16 Oct 2002 18:32:09 -0400 Subject: [NSIS] Comments on framework draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I've appended some comments on the framework draft. As with the requirements draft, some are substantive and others are just nitpicky. However, this document does raise some significant issues that I think need resolution before the requirements draft can be wrapped up, and I've listed those towards the top (and I have absolutely no doubt that I've missed some). One thing that particularly concerns me is that while in some places these issues are treated as open in others they're treated as settled, and settled in the direction of the CASP protocol. Let's not do that. Melinda ISSUES TO RESOLVE ----------------- 1) Addressing - hop-by-hop or end-to-end? If hop-by-hop, how is it routed? 2) Are "sessions" established between NSIS Entities? Note that they don't eliminate state, but just move it to another layer - what advantages does this have over the more stateless RSVP protocol machinery? 3) Is multicast really out of scope? 4) receiver-oriented vs. sender-oriented 5) Will NFs be able to request, release, or modify reservations (either initiate requests or modify existing requests in transit)? 6) Is the use of periodic refresh messages the primary means of installing state? Should these messages be idempotent? 7) Rely on internal or external security mechanisms? (Can we punt on this until we know more about the protocol?) =============== This document reads more like a framework for discussion than as a framework for a protocol. Need to talk about the protocol rather than the working group (Section 1, first sentence, for example) The document is clear about distinctions between protocol layer and application layer. 1.1 "This document will provide a framework for the NSIS protocol, both an architecture for the protocol itself and potential use scenarios. It is not intended to define an overarching resource management architecture for the Internet." Terminology: "Classifier" - small nit but decision may be based on something other than packet header - I'd say "packet contents." "Resource Management Function": set of functions within an NSIS Entity ... " I don't think it's that abstract. Maybe need to clean up use in this document; later it seems to be used to describe a policy function rather than specifically resource management. "peer session" - "session" implies some sort of persistence in the connection between two nsis forwarders that's not yet agreed upon. The use of double-headed arrows in Figure 1 implies (nsis) hop-by-hop signaling (addressing). Need to be clear that NSIS Forwarders and NSIS Receivers MUST be on the data path. NSIS Initiators MUST be placed somewhere topologically appropriate. This may be a deployment issue rather than a protocol design issue, but off-path signaling is out-of-scope and we shouldn't design for it (unless it's "free" - i.e. it doesn't complicate the protocol). 3.2 should be clearer that these are *NOT* nsis modes of operation, but rather a discussion of possible modes of operation and tradeoffs. Out-of-band is out of scope, and discussion of it in sections other than 3.2.1 should be deleted. 3.2.2 Maybe definition should say crosses more than one administrative domain. I would be more concerned with issues of authorization, etc. What's the real difference between functioning within one domain and functioning across more than one domain? Also, some of this discussion is specific to QoS application. 3.2.4 What's the difference between local objects and opaque data? 3.2.6 Disagree that error reporting is faster for sender- oriented reservations - it need not be if you allow an nsis device to send an error report back to the sender immediately, rather than continuing to forward the message. The definition of receiver initiated signaling is incorrect. In receiver-initiated signaling the *reservation* is confirmed and installed in response to a message from the receiver to the sender, but the data still originate with the sender. There may be cases in which you're looking for the last appropriate NE on the path, for example when you use the protocol for tunnel endpoint discovery. Receiver-oriented signaling works better for this case. Sender-oriented signaling would work but would require more messages. 3.3 contains requirements and those should be excerpted once there's agreement and the material is consolidated elsewhere. 3.3.1 "Optimized for unicast" is not the same thing as "not doing multicast" - can this decision be either finalized or tabled and revisited later? I'd put in some language about two-layer model here. 3.3.2 The first sentence is *excellent* - IETF documents need more of this kind of thing. Otherwise section needs to be aligned with requirements document - currently they're somewhat out of alignment 3.3.3 Need to clarify what's meant by "maintaining relations". We haven't agreed to session model. Think it would be helpful to reframe some of the discussion in terms of policy and authorization - helps to modularize architecture. 3.3.4 "Peer session" and "hop-by-hop" are not the same thing, and this section desribes hop-by-hop. "Peer session" implies a connection model that's orthogonal to the addressing model. (we could have end-to-end sessions, too) 3.3.5 I don't understand what the problem being addressed is 4.1 Feel quite strongly that interface selection should be handled by IP routing 4.2 control primitives seem to assume sender-oriented signaling (para 3). Writing in para starting "We have a basic design goal" is a little unclear - why not simply state that we assume the following functions will be available by other means and are therefore will not be included in the NSIS protocol? 4.3.2 depends entirely on whether sender-oriented or receiver-oriented signaling is used. 4.4 Idempotent refresh messages allow routes to be changed transparently to the NSIS protocol machinery 4.5.1 Why do you want to identify "flows" at the NSIS protocol layer? The text doesn't make a good case for it. This belongs in the application 4.5.2 Text describes application use of reservation ids. The actual NSIS control layer use of application ids would be in manipulation of existing reservations (teardown, modification, etc.) 5.2 Some of this would fall under the rubric "policy routing," which could be mentioned 5.2.4 The old path may no longer exist 6.1 seems to assume the use of an external security protocol aside from key management (IPSec, SSL). Does it need to? What about authenticating individual elements? 6.2 I'd restate question as "Does the requestor have permission?" Payment, etc. may very well not enter into it. No negotiation! Request has a yes/no/"no but" answer with possibility of additional information ("these are the nodes that would not satisfy the request and this is the reason they gave"), but negotiation introduces complexity with no real advantages. 6.3 Accounting also includes auditing 6.5 Not always reasonable to assume hop-by-hop protection, but is reasonable to assume "session" (if that's what we're doing) protection. There are many situations in which you cannot assume transitivity of trust (financial institutions, for example, hate it). Could this be a group keying application? If so, how would that affect arguments here? 7.4 For a framework for middlebox signaling, see my "Network-friendlier Midcom" draft 7.5 Split Figure 9 into two? Does two things: 1) provides picture of proxies, and 2) shows multilayer architecture. Probably should do (2) before (1), or else move (1) up to section 3 somewhere _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 03:03:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02590 for ; Thu, 17 Oct 2002 03:03:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9H75eN01966 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 03:05:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H75Xv01959; Thu, 17 Oct 2002 03:05:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H74av01908 for ; Thu, 17 Oct 2002 03:04:36 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02550 for ; Thu, 17 Oct 2002 03:02:13 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT5967>; Thu, 17 Oct 2002 08:04:09 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5AE6@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Melinda Shore , nsis@ietf.org Subject: RE: [NSIS] Comments on framework draft Date: Thu, 17 Oct 2002 08:04:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi melinda, thanks for the comments (appreciated). i thought i'd make a couple of points on your 'major issues' to encourage some more feedback. one background process point: all the substantive text was written before the any of the authors knew anything about the approach proposed by casp (or indeed any of the other protocols other than Bob's cstp proposal, so far as i know). i don't think the issues are settled in any direction at the moment. [snip] > > ISSUES TO RESOLVE > ----------------- > 1) Addressing - hop-by-hop or end-to-end? If hop-by-hop, > how is it routed? [reh] at the moment, it did't seem we could rule out either. RSVP uses both, after all. it's possible that a pure sender-initiated-everything approach could use end-to-end addressing only. > > 2) Are "sessions" established between NSIS Entities? Note > that they don't eliminate state, but just move it to > another layer - what advantages does this have over the > more stateless RSVP protocol machinery? [reh] all 'session' is is a name for whatever protocol layer state is established between NSIS peers. this could be very small (nothing), just next/previous hop id (like RSVP), or quite complex (including security information). the relative amounts of state in NSIS protocol vs. signalling applications is a very good question, as is working out how it can be minimised. i don't personally expect it can be eliminated in a real protocol, but nothing is fixed. (people are free to suggest a less loaded term than 'session'.) > > 3) Is multicast really out of scope? [reh] question for the group (and a requirements question, as you point out). > > 4) receiver-oriented vs. sender-oriented [reh] good question (again). i suspect the answers may be different at the NSIS protocol layer and signalling applications (this is something we haven't really thought about, however.) > > 5) Will NFs be able to request, release, or modify > reservations (either initiate requests or modify existing > requests in transit)? [reh] good question (again). i think this is especially critical for the mobility case (is re-authorisation logically required if the actual path changes?) > > 6) Is the use of periodic refresh messages the primary means > of installing state? Should these messages be > idempotent? [reh] i think in fact this may be a protocol design question, it might be at the boundary of what the framework document is supposed to define. (john, any views?) > > 7) Rely on internal or external security mechanisms? (Can > we punt on this until we know more about the protocol?) [reh] i think the basic point here is that there may be very significant advantages to at least considering using existing security infrastructure, namely (a) it may be hard to design ourselves and (b) in deployment terms, maybe one would rather avoid having to manage an NSIS-specific (or signalling application specific) set of identities and keys and rights. however, at this stage in the process, i think the main point is to try to map the overall security requirements onto the various components in the framework, and (maybe) look at goodness of fit to existing mechanisms. cheers, robert h. > > > =============== > This document reads more like a framework for discussion > than as a framework for a protocol. Need to talk about the > protocol rather than the working group (Section 1, first > sentence, for example) > > The document is clear about distinctions between protocol > layer and application layer. > > 1.1 "This document will provide a framework for the NSIS > protocol, both an architecture for the protocol itself and > potential use scenarios. It is not intended to define an > overarching resource management architecture for the > Internet." > > Terminology: > "Classifier" - small nit but decision may be based on > something other than packet header - I'd say "packet > contents." > > "Resource Management Function": set of functions within an > NSIS Entity ... " I don't think it's that abstract. Maybe > need to clean up use in this document; later it seems to be > used to describe a policy function rather than specifically > resource management. > > "peer session" - "session" implies some sort of persistence > in the connection between two nsis forwarders that's not yet > agreed upon. The use of double-headed arrows in > Figure 1 implies (nsis) hop-by-hop signaling (addressing). > > Need to be clear that NSIS Forwarders and NSIS Receivers > MUST be on the data path. NSIS Initiators MUST be placed > somewhere topologically appropriate. This may be a > deployment issue rather than a protocol design issue, but > off-path signaling is out-of-scope and we shouldn't design > for it (unless it's "free" - i.e. it doesn't complicate the > protocol). > > 3.2 should be clearer that these are *NOT* nsis modes of > operation, but rather a discussion of possible modes of > operation and tradeoffs. Out-of-band is out of scope, and > discussion of it in sections other than 3.2.1 should be > deleted. > > 3.2.2 Maybe definition should say crosses more than one > administrative domain. I would be more concerned with > issues of authorization, etc. What's the real difference > between functioning within one domain and functioning across > more than one domain? Also, some of this discussion is > specific to QoS application. > > 3.2.4 What's the difference between local objects and opaque > data? > > 3.2.6 Disagree that error reporting is faster for sender- > oriented reservations - it need not be if you allow an nsis > device to send an error report back to the sender > immediately, rather than continuing to forward the message. > > The definition of receiver initiated signaling is > incorrect. In receiver-initiated signaling the > *reservation* is confirmed and installed in response to a > message from the receiver to the sender, but the data still > originate with the sender. > > There may be cases in which you're looking for the last > appropriate NE on the path, for example when you use the > protocol for tunnel endpoint discovery. Receiver-oriented > signaling works better for this case. Sender-oriented > signaling would work but would require more messages. > > 3.3 contains requirements and those should be excerpted once > there's agreement and the material is consolidated > elsewhere. > > 3.3.1 "Optimized for unicast" is not the same thing as "not > doing multicast" - can this decision be either finalized > or tabled and revisited later? > I'd put in some language about two-layer model here. > > 3.3.2 The first sentence is *excellent* - IETF documents > need more of this kind of thing. Otherwise section > needs to be aligned with requirements document - > currently they're somewhat out of alignment > > 3.3.3 Need to clarify what's meant by "maintaining > relations". We haven't agreed to session model. Think > it would be helpful to reframe some of the discussion in > terms of policy and authorization - helps to modularize > architecture. > > 3.3.4 "Peer session" and "hop-by-hop" are not the same > thing, and this section desribes hop-by-hop. "Peer > session" implies a connection model that's orthogonal to > the addressing model. (we could have end-to-end > sessions, too) > > 3.3.5 I don't understand what the problem being addressed is > > 4.1 Feel quite strongly that interface selection should be > handled by IP routing > > 4.2 control primitives seem to assume sender-oriented > signaling (para 3). Writing in para starting "We have a > basic design goal" is a little unclear - why not simply > state that we assume the following functions will be > available by other means and are therefore will not be > included in the NSIS protocol? > > 4.3.2 depends entirely on whether sender-oriented or > receiver-oriented signaling is used. > > 4.4 Idempotent refresh messages allow routes to be changed > transparently to the NSIS protocol machinery > > 4.5.1 Why do you want to identify "flows" at the NSIS > protocol layer? The text doesn't make a good case for > it. This belongs in the application > > 4.5.2 Text describes application use of reservation ids. > The actual NSIS control layer use of application ids > would be in manipulation of existing reservations > (teardown, modification, etc.) > > 5.2 Some of this would fall under the rubric "policy > routing," which could be mentioned > > 5.2.4 The old path may no longer exist > > 6.1 seems to assume the use of an external security protocol > aside from key management (IPSec, SSL). Does it need > to? What about authenticating individual elements? > > 6.2 I'd restate question as "Does the requestor have > permission?" Payment, etc. may very well not enter into > it. No negotiation! Request has a yes/no/"no but" > answer with possibility of additional information > ("these are the nodes that would not satisfy the request > and this is the reason they gave"), but negotiation > introduces complexity with no real advantages. > > 6.3 Accounting also includes auditing > > 6.5 Not always reasonable to assume hop-by-hop protection, > but is reasonable to assume "session" (if that's what > we're doing) protection. There are many situations in > which you cannot assume transitivity of trust (financial > institutions, for example, hate it). Could this be a > group keying application? If so, how would that affect > arguments here? > > 7.4 For a framework for middlebox signaling, see my > "Network-friendlier Midcom" draft > > 7.5 Split Figure 9 into two? Does two things: 1) provides > picture of proxies, and 2) shows multilayer > architecture. Probably should do (2) before (1), or > else move (1) up to section 3 somewhere > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 04:11:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03417 for ; Thu, 17 Oct 2002 04:11:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9H8DIk05839 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 04:13:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H8DFv05832; Thu, 17 Oct 2002 04:13:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H8CEv05800 for ; Thu, 17 Oct 2002 04:12:15 -0400 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03402 for ; Thu, 17 Oct 2002 04:09:51 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9H8Bdw15692 for ; Thu, 17 Oct 2002 11:11:39 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Oct 2002 11:11:57 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 11:11:54 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] Comments on framework draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 17 Oct 2002 11:11:54 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F9F@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] Comments on framework draft Thread-Index: AcJ1rGaKhA5BUcE9TLKaOW4jaln1cAABzxOA To: , , X-OriginalArrivalTime: 17 Oct 2002 08:11:54.0849 (UTC) FILETIME=[DAFECD10:01C275B4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9H8CFv05801 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, My two cents. I believe that, after the Yokohama meeting, there was WG consensus to move to a two layer approach: 1) Upper layer, defining services, running end-to-end 2) lower layer, defining transport, running hop-by-hop (though if only a single hop is needed, I guess that would qualify as end-to-end - for example if the service you are signaling for is on your access router ...) > > ISSUES TO RESOLVE > > ----------------- > > 1) Addressing - hop-by-hop or end-to-end? If hop-by-hop, > > how is it routed? > [reh] at the moment, it did't seem we could rule out either. > RSVP uses both, after all. it's possible that a pure > sender-initiated-everything approach could use end-to-end > addressing only. I would think that the Framework document could take my proposal above to resolve this issue. > > 2) Are "sessions" established between NSIS Entities? Note > > that they don't eliminate state, but just move it to > > another layer - what advantages does this have over the > > more stateless RSVP protocol machinery? > [reh] all 'session' is is a name for whatever protocol layer > state is established between NSIS peers. this could be very > small (nothing), just next/previous hop id (like RSVP), or > quite complex (including security information). Agreed. > the relative amounts of state in NSIS protocol vs. signalling > applications is a very good question, as is working out how > it can be minimised. i don't personally expect it can be > eliminated in a real protocol, but nothing is fixed. > > (people are free to suggest a less loaded term than 'session'.) > > > > > 3) Is multicast really out of scope? > [reh] question for the group (and a requirements question, as > you point out). I'd prefer to think that multicast is not out of scope, but we are not defining the NSIS protocol for multicast services. > > 4) receiver-oriented vs. sender-oriented > [reh] good question (again). i suspect the answers may be > different at the NSIS protocol layer and signalling > applications (this is something we haven't really thought > about, however.) This we should discuss and make some decisions on it. > > 6) Is the use of periodic refresh messages the primary means > > of installing state? Should these messages be > > idempotent? > [reh] i think in fact this may be a protocol design question, > it might be at the boundary of what the framework document is > supposed to define. (john, any views?) This may be getting into protocol design. Should the framework document define this? I am no so sure. > > 7) Rely on internal or external security mechanisms? (Can > > we punt on this until we know more about the protocol?) > [reh] i think the basic point here is that there may be very > significant advantages to at least considering using existing > security infrastructure, namely (a) it may be hard to design > ourselves and (b) in deployment terms, maybe one would rather > avoid having to manage an NSIS-specific (or signalling > application specific) set of identities and keys and rights. > however, at this stage in the process, i think the main point > is to try to map the overall security requirements onto the > various components in the framework, and (maybe) look at > goodness of fit to existing mechanisms. I think we punt, but perhaps we can at least can start setting the table. My knee-jerk reaction would be that the transport layer use something like TLS and the service layer use some sort of end-to-end encryption of payload. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 06:33:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05481 for ; Thu, 17 Oct 2002 06:33:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HAYjo12803 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 06:34:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HAYgv12796; Thu, 17 Oct 2002 06:34:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HAVBv12670 for ; Thu, 17 Oct 2002 06:31:11 -0400 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05392 for ; Thu, 17 Oct 2002 06:28:57 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 17 Oct 2002 12:31:06 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <464H415Z>; Thu, 17 Oct 2002 12:31:05 +0200 Message-Id: From: "Geib, Ruediger" To: fu@cs.uni-goettingen.de Cc: nsis@ietf.org Subject: RE: [NSIS] New NSIS-related drafts - bandwidth negotiation Date: Thu, 17 Oct 2002 12:31:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9HAVBv12671 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Xiaoming, [RG] Would negotiation then be an option or a requirement? Option would be ok to me. The mechanism suggested leaves the granularity of bandwidth reduction to CASP signaling elements within the network. It may not be aware of the way an application reduces bandwidth. A voice or MPEG Codec may reduce bandwidth by changing its analog/digital coding scheme. The bandwidth is by granular steps. The NSIS unit within the network probably isn't application aware. The sender may then have the options of reducing it's rate to the next possible one below the bandwidth resulting from negotiation or restart the reservation with that value (if no more then the required bandwidth should be reserved). [RG] Wouldn't it be simpler if an application indicates that it is able to reduce transmission bandwidth during reservation? If the network notices upcoming shortage of resources, further reservations may be accepted while some active (and new) reservations are asked to reduce their sending rate. [RG] Again my suggestion to ask application experts on their expectations or preferences. Regards, Rüdiger > [RG] The maximum/minimum bandwidth procedure seems to be the only > feasible way of realising a simple negotiation mechanism. I still > feel it to be too complex and would favor a single bandwidth as > only requirement for the protocol. I'd be curious in learning > more about application developers views on that. > > [XF] We thought this is helpful particullarly in wireless mobile > environments; people may use only one bandwidth if a single bandwidth > information is available. Meanwhile we would also like to see how this > could or could not well-fit the QoS provisioning techniques and > applications. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 07:15:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06008 for ; Thu, 17 Oct 2002 07:15:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HBHZX15069 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 07:17:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HBHUv15057; Thu, 17 Oct 2002 07:17:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HBGqv15034 for ; Thu, 17 Oct 2002 07:16:52 -0400 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05988 for ; Thu, 17 Oct 2002 07:14:39 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g9HBGit21921; Thu, 17 Oct 2002 13:16:44 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g9HBGi819334; Thu, 17 Oct 2002 13:16:44 +0200 (MEST) Reply-To: From: "Hannes Tschofenig" To: , Subject: [NSIS] Comments on requirements draft Date: Thu, 17 Oct 2002 13:17:07 +0200 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 hi melinda thank you for your comments to the requriements draft. my my questions/comments to security related issues can be found inline. additionally i would like to thank you for for editorial comments and your interest to get the document more readable. > Section 6: "threads" should be "threats" definitly true. > Consistent problem throughout Requirements section: > requirements aren't stated *as* requirements. Application > and transport need to be separated out more cleanly (for > example, 5.3.4 and 5.3.5) the separation into application and transport is a very related aspect. if you take a look then you will find a three layer architecture where we have a transport layer, messaging layer and a client layer (=application). hence such a separation would be very solution oriented. however i see a need to add some other application layer issues and examples (such as midcom - nat and firewall traversal). > 5.3.3 I would change that first SHOULD to a MUST. Note > that "MUST be able to notify" is not the same as "MUST > notify." Do we care? > > Bit about security should be moved to security > requirements. Discussion is a bit frameworky, I'd > delete it. i will try to consider it. > 5.6.1 I'm not sure what this means - something akin to IPSec > selectors? there are various ways to provide aggregation. we described the importance of more powerful flow identifiers (traffic selectors) in detail in casp. > > 5.7.1. "The NSIS protocol MUST support strong authentication > among NSIS nodes. The protocol MUST NOT support the use > of plaintext passwords for authentication or > encryption." Delete the rest. (Note that this is > actually quite difficult to do in practice, particularly > interdomain). difficult in a inter-domain case? true. but without signaling message protection (and authentication) you are in trouble. > > 5.7.2 Need to distinguish between application and > transport. Delete frameworky text. what do you mean in the context of resource authorization with application and transport? > > 5.7.3 Need to think about protecting individual message > elements as well as entire message whether to protect individual message parts or the entire message is a solution (not a requirement). if you look at casp then you will find both. in case of rsvp you also find both. > > 5.7.4 Second sentence: "Replay protection SHOULD be > resilient to crashes and other network outages." (not > MUST because it's harder than it sounds). delete last > sentence - not a requirement replay protection is a must. why a node lost synchronization is thereby irrelevant (i.e. network outages, etc.) > > 5.7.5 Belongs in framework document it is eleborated in more detail in the framework document. however i think that is also has to be included in this document. in many other protocols there are only two entities involved. hence there is no difference between hop-by-hop, end-to-middle, middle-to-middle, end-to-end protection. hop-by-hop protection is the minimal requirement. > > 5.7.6 Identity of what? if you look at rsvp then you see that user identifies are transmitted as part of the policy objects (to provide authorization). it does not mean protecting the ip addresses. i did not want to use the term user identities since in nsis an initiator might not always be a user. hence it would be anything e.g. a network, or a router, etc. Where does this sit in terms of > transport layer/application layer split? Accounting > stuff - application layer accounting - application layer: do you mean that accouting is only an application layer business? > > 5.7.7 "The NSIS protocol SHOULD be resilient against > denial-of-service attacks." Currently unclear. Delete > rest of paragraph i my point of view it is difficult to prevent dos attacks totally. hence you can only have a should here. protocols designers should consider dos attacks in their design. in casp we tried this and you can find it described at various places. there are very easy ways to introduce dos attacks in a signaling protocols: use pk-based authentication (and possibly key agreement) with a single message. an adversary only has to flood a node with a huge number of bogus requests (possibly created randomly). the receiver has todo heavy cryptographic computations. > > 5.7.8 "The NSIS protocol MUST allow encryption of NSIS > messages between NSIS nodes." must? rsvp for example does not provide it. i also saw something in the midcom-requirements document without any indication why particularly. in casp we indicate a good reason why to use encryption. i looked at the midcom requirements document (rfc3304) and found something like: " 2.3.1. The Midcom protocol must provide for message authentication, confidentiality, and integrity. " "2.3.2. The Midcom protocol must allow for optional confidentiality protection of control messages. If provided, the mechanism should allow a choice in the algorithm to be used." this confuses me. you suggest a must in the nsis requirements document (section 5.7.8). in rfc3304 in section 2.3.1 there is a must for conf. and in the subsequent section 2.3.2 there is a must ..optional.. > 5.9.4 Not just the security mechanism, need to identify > considerations for transport and for application. > Also, might want to think about interactions with 5.9.3 i am not sure what you would like to suggest. this requirement talks about aaa hooks which are (in case of qos) important. to make a distinction throught the document between transporting, application (or something else) it is maybe a little bit too solution oriented. the requirements document was written at a time where most people had no particular protocol in mind. now things are different and i am not sure whether we should reflect current discussions in the initial requirements document. the requirements document is generic enough to support many different solutions. i hope that my comments/questions are helpful for you. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 07:42:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06857 for ; Thu, 17 Oct 2002 07:42:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HBiLQ16547 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 07:44:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HBiHv16540; Thu, 17 Oct 2002 07:44:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HBhnv16509 for ; Thu, 17 Oct 2002 07:43:49 -0400 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06793 for ; Thu, 17 Oct 2002 07:41:35 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9HBhjKV025843; Thu, 17 Oct 2002 13:43:45 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VAYPT95F; Thu, 17 Oct 2002 13:43:45 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Oct 2002 13:37:19 +0200 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE129@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'Melinda Shore'" , nsis@ietf.org Subject: RE: [NSIS] Comments on requirements draft Date: Thu, 17 Oct 2002 13:43:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Melinda Thank you very much for spending time and effort on trying to improve the quality of the NSIS requirements draft! However, please note that I have not looked carefully into your comments but I would like to mention that the text that is included in the NSIS requirements draft is the result of many discussions and agreements within the NSIS WG. The NSIS WG has been working since almost one year now on defining this NSIS requirements draft and we should be very careful on deciding which text and how it should be modified. Best regards, Georgios -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: dinsdag 15 oktober 2002 19:33 To: nsis@ietf.org Subject: [NSIS] Comments on requirements draft I spent the morning going through the requirements document and have appended some comments. A couple of general points: 1) requirements documents are really hard. They need to document the actual requirements upon the protocol that's to be developed and not do much else, which is more difficult than it sounds. The requirements mustn't include mechanisms and they shouldn't provide architecture or framework material - that's why we have a separate framework document 2) this requirement document contains a tremendous amount of framework material. That material needs to be separated out and integrated into the framework document. 3) the requirements are often not stated as requirements or they're stated somewhat mushily, which can lead to confusion. "The NSIS protocol MUST be able to frobnitz the gorblatt" is not the same thing as "The NSIS protocol MUST frobnitz the gorblatt" and isn't, I believe, actually a requirement. 4) we need to get religion about the two-layer model. Should we have a separate QoS signaling application requirements document in addition to the NSIS protocol requirements document? In the very least the QoS stuff should be moved into a separate section. Comments appended. Some are nit-picky and some, I think, are fairly substantive. Melinda ======== Editorial: should be "NSIS Working Group", not "Network Working Group" References need to be split into normative and informative Need to include: "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited." in "Status of this Memo" section Introduction: Change "It does not list any problems of existing signaling protocols such as RSVP" to something like "We do not identify problems with existing signaling protocols, such as RSVP". Better still, delete it. Change paragraph starting with "QoS is a pretty large field" to "While we anticipate this protocol will be used for other applications in addition to QoS signaling, this document focuses on QoS" or something like that. Requirements: Change "All of them are not strictly defined and should not be regarded as that, but should give a feeling about where in the network we have different requirements concerning signaling." To "These divisions between network types are not strict and do not appear in all networks, but where they do exist they may influence signaling requirements and will be highlighted as necessary." In terminology: define "Upstream" and "Downstream" 5.3.4 Second MAY should be lowercase Section 6: "threads" should be "threats" Substance: The QoS signaling scenarios belong in the framework document. Shouldn't there be some scenarios for something beside QoS, so that we can better generalize the protocol? This document should *not* be presenting conceptual models, just requirements. Conceptual models belong in the framework. Remove related material, such as introductory paragraph beginning with "It is clear that the subject of QoS is uniquely complex" Delete first paragraph of terminology section, make sure that all terms are actually used in the document. Receiver-initiated signaling protocol and sender-initiated signaling protocol are not. Get rid of mom-and-apple-pie or obvious terms, like "QoS Technology." "Resource Management Function" definition is far too abstract. Definitions too QoS-y. For example, "Flow" can be defined in terms of resources requested rather than QoS requested. "QoS Provisioning" should be "Provisioning," etc. I would give serious thought to a separate QoS application requirements document. "Trigger" used a lot - I think I probably know what's intended by it, but I don't know for a fact what it means. Needs definition. Delete section 3, refer to framework Delete section 4, refer to framework Consistent problem throughout Requirements section: requirements aren't stated *as* requirements. Application and transport need to be separated out more cleanly (for example, 5.3.4 and 5.3.5) Use of "may be able to" - what does that mean? Needs to be more definite. 5.1.1 Needs to be hardened up lest risks being mom-and-apple- pie. 5.1.2 not stated as a requirement. "The NSIS protocol MUST allow the NI to query for resource availability without initiating a request." 5.1.3 is a weak protocol requirement and is probably redundant with 5.1.1. It's unclear whether or not bullet items are requirements 5.1.4 is related to 5.1.1 and 5.1.3. We should probably try to distill them down to one or two requirements 5.1.5 is not a protocol requirement 5.1.7 is related to 5.1.1, 5.1.3, and 5.1.4 See 5.1.4. Also, not stated as requirement. 5.2.1 Not stated as requirement. The first sentence is closer, I think, to what's intended than the header (requirement) is. 5.2.2 Not stated as requirement. Also wrong - this is out of scope 5.2.3 Requirement in body of paragraph? SHOULD in 2nd paragraph should be lower-case 5.3 I'd rename to something like "Messages" 5.3.2 Unclear. Possibilities: do you mean that any NSIS node, whether NI, NF, or NR, should be able to initiate a teardown, or do you mean that any NSIS node that releases its resources without a request from the initiator should send out a teardown, or do you mean that any NSIS node that releases its resources without a request from the initiator should send out a notice? Don't know what "The goal is to prevent stale state within the network and adds robustness to the operation of NSIS. So in other words, an NSIS signaling protocol or mechanisms MUST provide means for an NSIS entity to discover and remove local stale state." means. Resource discovery is covered in 5.1.2, and for a node to discover its own state is node mechanism and not a protocol requirement 5.3.3 I would change that first SHOULD to a MUST. Note that "MUST be able to notify" is not the same as "MUST notify." Do we care? Bit about security should be moved to security requirements. Discussion is a bit frameworky, I'd delete it. 5.3.4 Some questions: Doesn't the answer depend on the application (if we're using the two-layer architecture)? If so, wouldn't the contents of the answer be opaque to the protocol machinery anyway? 5.3.5 A bit murky. My thinking is that local information may be added or removed from NSIS messages as they traverse NSIS nodes, rather than suggesting that additional dialogue (i.e. traffic) is needed between nodes. 5.4.1 A bit frameworky. At least make sure this is consistent with framework 5.4.2 See 5.3.4 and 5.3.5 5.4.3 This needs to be rewritten so that it's a protocol requirement and not a mechanism requirement. Also, it's a bit application-ish and may depend on the application 5.4.4. (the word "seamless" makes me queasy) This can be deleted - it's about NF mechanism 5.5 This section really needs more discussion. Some of it is either obvious or meaningless, and some of it is outside the scope of what is even possible. A requirements document should state requirements in the form of things like "The NSIS protocol MUST support aggregation of requests." 5.6 This might be best broken up and redistributed among other sections 5.6.1 I'm not sure what this means - something akin to IPSec selectors? 5.6.2 Can probably be deleted unless a specific protocol requirement can be identified 5.6.3 Needs to be stated more clearly: "Either the NI or NR of a specific reservation MAY initiate a renegotiation of that reservation." I'd delete the rest and create a new requirement around NF initiation of a renegotiation. 5.6.4 "The NSIS protocol SHOULD permit signaling both unidirectional and bidirectional reservation requests." Delete second paragraph. 5.7.1. "The NSIS protocol MUST support strong authentication among NSIS nodes. The protocol MUST NOT support the use of plaintext passwords for authentication or encryption." Delete the rest. (Note that this is actually quite difficult to do in practice, particularly interdomain). 5.7.2 Need to distinguish between application and transport. Delete frameworky text. 5.7.3 Need to think about protecting individual message elements as well as entire message 5.7.4 Second sentence: "Replay protection SHOULD be resilient to crashes and other network outages." (not MUST because it's harder than it sounds). delete last sentence - not a requirement 5.7.5 Belongs in framework document 5.7.6 Identity of what? Where does this sit in terms of transport layer/application layer split? Accounting stuff - application layer 5.7.7 "The NSIS protocol SHOULD be resilient against denial-of-service attacks." Currently unclear. Delete rest of paragraph 5.7.8 "The NSIS protocol MUST allow encryption of NSIS messages between NSIS nodes." 5.7.10 Delete 5.8.1 Delete the word "efficient" - motherhood/apple pie 5.9.1 Not a protocol requirement. 5.9.2 "The NSIS protocol MUST support IPv4 and IPv6." 5.9.4 Not just the security mechanism, need to identify considerations for transport and for application. Also, might want to think about interactions with 5.9.3 5.9.5 Delete "seamless" Isn't this redundant with 5.8.1? 5.9.6 This is really unclear and should probably be deleted. There are specific issues with policy-based routing that need to be addressed in the framework document and may be reflected back here as specific protocol requirements - needs more discussion. 5.10.1 Keep first sentence, delete rest 5.10.2 Um, how does this work with on-path signaling? Delete 5.10.3 "If an NSIS node detects that another NSIS node is malfunctioning, it SHOULD notify the NSIS initiator." Delete failover discussion. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 07:57:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07139 for ; Thu, 17 Oct 2002 07:57:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HBxCR16938 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 07:59:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HBx8v16928; Thu, 17 Oct 2002 07:59:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H9v0v10958 for ; Thu, 17 Oct 2002 05:57:00 -0400 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04886 for ; Thu, 17 Oct 2002 05:54:46 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g9H9uwt07756; Thu, 17 Oct 2002 11:56:58 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g9H9uv817572; Thu, 17 Oct 2002 11:56:57 +0200 (MEST) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" , Subject: RE: [NSIS] Comments on requirements draft Date: Thu, 17 Oct 2002 11:57:19 +0200 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200210151727.AAF49587@mira-sjc5-4.cisco.com> 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 hi melinda thank you for your comments to the requriements draft. my my questions/comments to security related issues can be found inline. additionally i would like to thank you for for editorial comments and your interest to get the document more readable. > Section 6: "threads" should be "threats" definitly true. > Consistent problem throughout Requirements section: > requirements aren't stated *as* requirements. Application > and transport need to be separated out more cleanly (for > example, 5.3.4 and 5.3.5) the separation into application and transport is a very related aspect. if you take a look then you will find a three layer architecture where we have a transport layer, messaging layer and a client layer (=application). hence such a separation would be very solution oriented. however i see a need to add some other application layer issues and examples (such as midcom - nat and firewall traversal). > 5.3.3 I would change that first SHOULD to a MUST. Note > that "MUST be able to notify" is not the same as "MUST > notify." Do we care? > > Bit about security should be moved to security > requirements. Discussion is a bit frameworky, I'd > delete it. i will try to consider it. > 5.6.1 I'm not sure what this means - something akin to IPSec > selectors? there are various ways to provide aggregation. we described the importance of more powerful flow identifiers (traffic selectors) in detail in casp. > > 5.7.1. "The NSIS protocol MUST support strong authentication > among NSIS nodes. The protocol MUST NOT support the use > of plaintext passwords for authentication or > encryption." Delete the rest. (Note that this is > actually quite difficult to do in practice, particularly > interdomain). difficult in a inter-domain case? true. but without signaling message protection (and authentication) you are in trouble. > > 5.7.2 Need to distinguish between application and > transport. Delete frameworky text. what do you mean in the context of resource authorization with application and transport? > > 5.7.3 Need to think about protecting individual message > elements as well as entire message whether to protect individual message parts or the entire message is a solution (not a requirement). if you look at casp then you will find both. in case of rsvp you also find both. > > 5.7.4 Second sentence: "Replay protection SHOULD be > resilient to crashes and other network outages." (not > MUST because it's harder than it sounds). delete last > sentence - not a requirement replay protection is a must. why a node lost synchronization is thereby irrelevant (i.e. network outages, etc.) > > 5.7.5 Belongs in framework document it is eleborated in more detail in the framework document. however i think that is also has to be included in this document. in many other protocols there are only two entities involved. hence there is no difference between hop-by-hop, end-to-middle, middle-to-middle, end-to-end protection. hop-by-hop protection is the minimal requirement. > > 5.7.6 Identity of what? if you look at rsvp then you see that user identifies are transmitted as part of the policy objects (to provide authorization). it does not mean protecting the ip addresses. i did not want to use the term user identities since in nsis an initiator might not always be a user. hence it would be anything e.g. a network, or a router, etc. Where does this sit in terms of > transport layer/application layer split? Accounting > stuff - application layer accounting - application layer: do you mean that accouting is only an application layer business? > > 5.7.7 "The NSIS protocol SHOULD be resilient against > denial-of-service attacks." Currently unclear. Delete > rest of paragraph i my point of view it is difficult to prevent dos attacks totally. hence you can only have a should here. protocols designers should consider dos attacks in their design. in casp we tried this and you can find it described at various places. there are very easy ways to introduce dos attacks in a signaling protocols: use pk-based authentication (and possibly key agreement) with a single message. an adversary only has to flood a node with a huge number of bogus requests (possibly created randomly). the receiver has todo heavy cryptographic computations. > > 5.7.8 "The NSIS protocol MUST allow encryption of NSIS > messages between NSIS nodes." must? rsvp for example does not provide it. i also saw something in the midcom-requirements document without any indication why particularly. in casp we indicate a good reason why to use encryption. i looked at the midcom requirements document (rfc3304) and found something like: " 2.3.1. The Midcom protocol must provide for message authentication, confidentiality, and integrity. " "2.3.2. The Midcom protocol must allow for optional confidentiality protection of control messages. If provided, the mechanism should allow a choice in the algorithm to be used." this confuses me. you suggest a must in the nsis requirements document (section 5.7.8). in rfc3304 in section 2.3.1 there is a must for conf. and in the subsequent section 2.3.2 there is a must ..optional.. > 5.9.4 Not just the security mechanism, need to identify > considerations for transport and for application. > Also, might want to think about interactions with 5.9.3 i am not sure what you would like to suggest. this requirement talks about aaa hooks which are (in case of qos) important. to make a distinction throught the document between transporting, application (or something else) it is maybe a little bit too solution oriented. the requirements document was written at a time where most people had no particular protocol in mind. now things are different and i am not sure whether we should reflect current discussions in the initial requirements document. the requirements document is generic enough to support many different solutions. i hope that my comments/questions are helpful for you. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 09:16:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09752 for ; Thu, 17 Oct 2002 09:16:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HDII422411 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 09:18:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HDIDv22395; Thu, 17 Oct 2002 09:18:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HDHlv22360 for ; Thu, 17 Oct 2002 09:17:47 -0400 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09716 for ; Thu, 17 Oct 2002 09:15:33 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9HDHfcl018619; Thu, 17 Oct 2002 06:17:41 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG21379; Thu, 17 Oct 2002 06:12:47 -0700 (PDT) Message-Id: <200210171312.AAG21379@mira-sjc5-4.cisco.com> From: Melinda Shore To: "Georgios Karagiannis (ELN)" Cc: nsis@ietf.org Subject: Re: [NSIS] Comments on requirements draft Date: Thu, 17 Oct 2002 09:17:41 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > However, please note that I have not looked carefully into your > comments but I would like to mention that the text that > is included in the NSIS requirements > draft is the result of many discussions and agreements > within the NSIS WG. > The NSIS WG has been working since almost one year now > on defining this NSIS requirements draft and we should be very > careful on deciding which text and how it should be modified. Clearly a great deal of work has gone into that document, and I'm not suggesting that the expository material be discarded, but rather moved into the framework document. Framework material does not belong in requirements documents. Also, I think the discussion has primarily been 1) among the authors, and 2) at meetings. There has actually been very little discussion of the document (none recently) on the mailing list, and in the IETF work is advanced primarily on mailing lists. For example, mailing lists are where decisions are made and finalized. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 09:40:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10617 for ; Thu, 17 Oct 2002 09:40:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HDgEH24282 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 09:42:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HDgBv24269; Thu, 17 Oct 2002 09:42:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HDfRv24245 for ; Thu, 17 Oct 2002 09:41:27 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10578 for ; Thu, 17 Oct 2002 09:39:13 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9HDfOot004087 for ; Thu, 17 Oct 2002 06:41:24 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG21783; Thu, 17 Oct 2002 06:36:29 -0700 (PDT) Message-Id: <200210171336.AAG21783@mira-sjc5-4.cisco.com> To: nsis@ietf.org From: Melinda Shore Date: Thu, 17 Oct 2002 09:41:23 -0400 Subject: [NSIS] "sessions" and discovery Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I think that these are two of the most fundamental questions that this working group needs to resolve, and while there's been a suggestion to send the requirements draft through WG last call both of these questions, along with some other basic questions (like addressing) are still open. Frankly, I think that this is something that RSVP got very, very right and that it might be difficult to improve on it. In the framework draft it says that NSIS Entity discovery is not to be included in an NSIS protocol, and in the CASP draft discovery is a separate process. What concerns me is that 1) it leads to a lack of robustness, and 2) it increases the number of messages required to accomplish a given task. Rerunning the discovery process every time route moves or a node goes down seems to me to be far less desirable than having discovery be implicit in the state maintenance mechanism. Using a stand-alone discovery process becomes more attractive when you have persistent, (hopefully) durable connections between NEs. While I understand that the use of persistent connections for QoS signaling *might* have better scaling properties (although I'm not convinced of it), by rerunning the discovery protocol and then introducing round trips between entities it makes the system slower to respond to changes in the network, increases the amount of local traffic (between NEs), and *requires* an external discovery process. My preference would be to look for ways to aggregate/multiplex messages over a protocol that looks more like RSVP than it would to create persistent sessions among NEs. There have been arguments for creating a stand-alone RSVP-like discovery protocol that doesn't actually convey requests or install state, and that's certainly what TED does. I would argue that a correctly designed RSVPv2 could do that very easily and is almost certainly preferable to separate discovery/state processes. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 12:01:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15641 for ; Thu, 17 Oct 2002 12:01:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HG4D101576 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 12:04:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HG4Bv01565; Thu, 17 Oct 2002 12:04:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HG0lv01106 for ; Thu, 17 Oct 2002 12:00:47 -0400 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15567 for ; Thu, 17 Oct 2002 11:58:30 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9HG0gIm007693; Thu, 17 Oct 2002 09:00:42 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG25512; Thu, 17 Oct 2002 08:55:47 -0700 (PDT) Message-Id: <200210171555.AAG25512@mira-sjc5-4.cisco.com> To: Hannes.Tschofenig@siemens.com cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Comments on requirements draft In-Reply-To: Message from "Hannes Tschofenig" of "Thu, 17 Oct 2002 11:57:19 +0200." Date: Thu, 17 Oct 2002 12:00:41 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > the separation into application and transport is a very related aspect. if > you take a look then you will find a three layer architecture where we have > a transport layer, messaging layer and a client layer (=application). > hence such a separation would be very solution oriented. I'm concerned that the requirements for the transport layer and the requirements for the application may be different, and what's in the requirements document seems to specifically cover a QoS application, while the framework document focuses on the transport (protocol machinery). Authorization, for example, almost certainly belongs in the application, not the transport. > there are various ways to provide aggregation. we described the importance > of more powerful flow identifiers (traffic selectors) in detail in casp. Hello! CASP is not the NSIS protocol. > difficult in a inter-domain case? true. but without signaling message > protection (and authentication) you are in trouble. Absolutely, but there's a big problem here that isn't unique to this working group but probably needs a few moments of consideration anyway. My favorite economics joke is about a physicist, an engineer, and an economist stranded on a desert island with a can of beans and no way to open it. The punchline is "And the economist says, 'Assume we have a can opener ...'" We tend to assume that we're going to be able to authenticate arbitrary elements in the network, and it's the rare working group that has a plan for what to do in the absence of a PKI. This was a big problem with the defined security mechanisms in RSVP. What I think would be useful is a discussion of this problem in the threats/security document, which I hope will be revised and re-issued. > if you look at casp then you will find both. in case of rsvp you also find > both. Once again, CASP is not the NSIS protocol. > > > > 5.7.4 Second sentence: "Replay protection SHOULD be > > resilient to crashes and other network outages." (not > > MUST because it's harder than it sounds). delete last > > sentence - not a requirement > > replay protection is a must. Agreed, but making it resilient to outages should be a SHOULD. > do you mean that accouting is only an application layer business? Accounting means both traditional accounting, I think, and also auditing. Accounting for resource use belongs in the application layer because the NSIS transport can't know what the resources are. Auditing - ??? > > 5.7.7 "The NSIS protocol SHOULD be resilient against > > denial-of-service attacks." Currently unclear. Delete > > rest of paragraph > i my point of view it is difficult to prevent dos attacks > totally. hence you can only have a should here. I agree, and I agree with the requirement as stated, but I would definitely delete the subsequent text. > to make a distinction throught the document between transporting, > application (or something else) it is maybe a little bit too solution > oriented. the requirements document was written at a time where most people > had no particular protocol in mind. now things are different and i am not > sure whether we should reflect current discussions in the initial > requirements document. The only clear decision that this working group has made about an NSIS protocol, to my recollection, is that the protocol will follow the recommendations in Bob Braden's "Two-Layer" draft - there will be a generic signaling machinery layer which is able to support a multiplicity of applications. This draft partly reflects that decision, but there's more that needs to be done. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 13:00:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17781 for ; Thu, 17 Oct 2002 13:00:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HH3F004872 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 13:03:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HH3Bv04865; Thu, 17 Oct 2002 13:03:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HH2Dv04831 for ; Thu, 17 Oct 2002 13:02:13 -0400 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17764 for ; Thu, 17 Oct 2002 12:59:56 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9HH25cl009549; Thu, 17 Oct 2002 10:02:06 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG27965; Thu, 17 Oct 2002 09:57:11 -0700 (PDT) Message-Id: <200210171657.AAG27965@mira-sjc5-4.cisco.com> To: brunner@ccrle.nec.de cc: john.loughney@nokia.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] WG Last call on the Requirements Draft? In-Reply-To: Message from Marcus Brunner of "Thu, 17 Oct 2002 18:57:34 +0200." <34267724.1034881054@[192.168.102.207]> Date: Thu, 17 Oct 2002 13:02:05 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > But in some of your later mails you say we need to define what this and > that means. And I do not see framework stuff in it more terminology. I'm referring specifically to sections 3 and 4, as well as text scattered throughout the requirements section (section 5). Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 13:05:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17947 for ; Thu, 17 Oct 2002 13:05:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HH8BG05657 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 13:08:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HH89v05610; Thu, 17 Oct 2002 13:08:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HH75v05084 for ; Thu, 17 Oct 2002 13:07:05 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17885 for ; Thu, 17 Oct 2002 13:04:48 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9HH6sot004371; Thu, 17 Oct 2002 10:06:55 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG28172; Thu, 17 Oct 2002 10:01:59 -0700 (PDT) Message-Id: <200210171701.AAG28172@mira-sjc5-4.cisco.com> To: brunner@ccrle.nec.de cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] WG Last call on the Requirements Draft? In-Reply-To: Message from Marcus Brunner of "Thu, 17 Oct 2002 18:53:31 +0200." <34024965.1034880811@[192.168.102.207]> Date: Thu, 17 Oct 2002 13:06:53 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > But as far as I have seen the list the consensus was to > not rule-out the off-path (what ever it is, see the E-Mail > thread on that), but focus on the on-path. And I hope that > the formulation does reflect this. Or in other words if > we find a protocol which works mainly on-path but also for > off-path we can still use it in NSIS and are not obliged > to throw it away. I think it would be a big mistake and could easily result in never producing a working protocol. It would be helpful if someone who thinks that it is in scope could scratch together a diagram of how they think it might work. That's not to say that I think this is not IETF work - I do think it is. I just don't think that it could reasonably fit into an end-to-end signaling protocol. As it happens, there is a diagram in the framework document of how it could be done by NSIS working in conjunction with another protocol, and that's Figure 8. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 14:24:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20725 for ; Thu, 17 Oct 2002 14:24:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HIQK010925 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 14:26:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HIQIv10914; Thu, 17 Oct 2002 14:26:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HIPZv10890 for ; Thu, 17 Oct 2002 14:25:35 -0400 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20673 for ; Thu, 17 Oct 2002 14:23:19 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HIPR209398; Thu, 17 Oct 2002 11:25:28 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HIPdM02662; Thu, 17 Oct 2002 13:25:39 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Oct 2002 13:25:25 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E063C543F@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Melinda Shore , Hannes.Tschofenig@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] Comments on requirements draft Date: Thu, 17 Oct 2002 13:25:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2760A.89F72060" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2760A.89F72060 Content-Type: text/plain We tend to assume that we're going to be able to authenticate arbitrary elements in the network, and it's the rare working group that has a plan for what to do in the absence of a PKI. This was a big problem with the defined security mechanisms in RSVP. What I think would be useful is a discussion of this problem in the threats/security document, which I hope will be revised and re-issued. GM] I wholeheartedly agree with this sentiment. The security needs to be worked out first. Just saying something is secureable won't cut it. ------_=_NextPart_001_01C2760A.89F72060 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [NSIS] Comments on requirements draft

 

We tend to assume that we're going to be able = to
authenticate arbitrary elements in the network, and = it's the rare working group that has a plan for what to do in the = absence of a PKI.  This was a big problem with the defined = security mechanisms in RSVP.

What I think would be useful is a discussion of this = problem
in the threats/security document, which I hope will = be
revised and re-issued.

GM] I wholeheartedly agree with this sentiment. The = security needs to be worked out first. Just saying something is = secureable won't cut it.

------_=_NextPart_001_01C2760A.89F72060-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 18:52:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28655 for ; Thu, 17 Oct 2002 18:52:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HMsG626392 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 18:54:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HMs9v26350; Thu, 17 Oct 2002 18:54:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HMp4v26278 for ; Thu, 17 Oct 2002 18:51:04 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28587 for ; Thu, 17 Oct 2002 18:48:43 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT6ANC>; Thu, 17 Oct 2002 23:50:49 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5B13@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Melinda Shore Cc: nsis@ietf.org Date: Thu, 17 Oct 2002 23:50:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [NSIS] RE: on/off path, and requirements vs. framework content (was RE: WG L ast call on the Requirements Draft?) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi melinda, modulo document timing, requirements/framework split, argument passing by reference or value and so on: what do you actually think of the path coupled/decoupled definition (that is currently hanging out in the framework section 3.2.1)? cheers, robert h. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 16 October 2002 15:55 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: on/off path, and requirements vs. framework content (was > RE: WG L ast call on the Requirements Draft?) > > > > the latest framework contains a carefully worded proposed > > definition (we used the terms path coupled/decoupled). if > > we could agree that was a useful definition, maybe it > > could be incorporated into some scoping section of the > > requirements document. > > That's a good suggestion, although my personal preference is > to refer between the documents rather than to include large > amounts of redundant material. But maybe one of the first > things we need to focus on in the framework document are the > on-path/off-path definition and to come to some absolute, > documented agreement about what the NSIS protocol will cover. > > > ps. i didn't follow the midcom work in detail, but the > > RFCs appear very much as companion documents. that's nice, > > but at the moment (in my view anyway) the NSIS > > requirements content is vastly more mature than the > > framework, so the same approach doesn't necessarily apply. > > It's impossible, I think, to have two document progress at > exactly the same rate of speed. I think it's almost > certainly the case that there are requirements either > implied or explicitly stated in the framework draft, and > those will need to be identified and incorporated into > requirements draft, and it's likely that the requirements > currently identified in the requirements draft may change as > the framework is solidified. I wouldn't be in favor of > completing one document too far in advance of the other. > > Melinda > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 18:52:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28668 for ; Thu, 17 Oct 2002 18:52:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HMsHO26404 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 18:54:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HMsCv26365; Thu, 17 Oct 2002 18:54:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HMp5v26282 for ; Thu, 17 Oct 2002 18:51:05 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28590 for ; Thu, 17 Oct 2002 18:48:45 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT6AN1>; Thu, 17 Oct 2002 23:50:52 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5B15@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Melinda Shore , nsis@ietf.org Subject: RE: [NSIS] "sessions" and discovery Date: Thu, 17 Oct 2002 23:50:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi melinda, a quick clarification: > In the framework draft it says that NSIS Entity discovery is > not to be included in an NSIS protocol if you're referring to the statement at the very end of section 4.2, the key word there is 'potentially'. the framework doesn't exclude the basic NSIS protocol working out for itself where to send messages (even doing to implicitly, i.e. operating in end-to-end addressing mode). the framework leaves open the option that there might be additional/complementary approaches, which would be seen as being handled by other protocols which supported NSIS. [one example might be a wireless node being told by DHCP that all its traffic was going to arrive via a single router which it could then request resources from.] in other words, the framework doesn't say "you have to separate message transport from discovery". if you think this is unclear, we can fix it. cheers, robert h. > Melinda > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 18:52:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28681 for ; Thu, 17 Oct 2002 18:52:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HMsIo26416 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 18:54:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HMsDv26380; Thu, 17 Oct 2002 18:54:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HMp6v26286 for ; Thu, 17 Oct 2002 18:51:06 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28592 for ; Thu, 17 Oct 2002 18:48:45 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT6AND>; Thu, 17 Oct 2002 23:50:49 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5B12@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, mshore@cisco.com, nsis@ietf.org Subject: RE: [NSIS] Comments on framework draft Date: Thu, 17 Oct 2002 23:50:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" john, i think (hope?) that the 2 layer (or "2 level") approach is agreed as a way forward. i suspect there is also a fair amount of agreement about the scopes of the two layers (although the framework currently doesn't cover this, maybe it should - if people want to propose something & where it should go...) however, i suspect that's orthogonal to melinda's concern, which is that merely using what we call peer-session addressing (either for things with local or end-to-end scope) is a Bad Idea, because you lose certain self-healing properties. i don't think the layering separation helps matters. (melinda, did i get your message?) personally, i think you may gain as much as you lose, or even more. but that's the argument we have to work out here. cheers, robert PS why did we use 'peer session' rather than 'hop by hop' in the framework? because people tend to assume 'hop' = 'IP hop' which wouldn't be valid here. but if people think hop-by-hop is a better term, we can go back to it. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 17 October 2002 09:12 > To: Hancock, Robert; mshore@cisco.com; nsis@ietf.org > Subject: RE: [NSIS] Comments on framework draft > > > Hi all, > > My two cents. I believe that, after the Yokohama meeting, > there was WG consensus to move to a two layer approach: > > 1) Upper layer, defining services, running end-to-end > 2) lower layer, defining transport, running hop-by-hop > (though if only a single hop is needed, I guess > that would qualify as end-to-end - for example > if the service you are signaling for is on your > access router ...) > > > > ISSUES TO RESOLVE > > > ----------------- > > > 1) Addressing - hop-by-hop or end-to-end? If hop-by-hop, > > > how is it routed? > > [reh] at the moment, it did't seem we could rule out either. > > RSVP uses both, after all. it's possible that a pure > > sender-initiated-everything approach could use end-to-end > > addressing only. > > I would think that the Framework document could take my proposal > above to resolve this issue. > > > > 2) Are "sessions" established between NSIS Entities? Note > > > that they don't eliminate state, but just move it to > > > another layer - what advantages does this have over the > > > more stateless RSVP protocol machinery? > > [reh] all 'session' is is a name for whatever protocol layer > > state is established between NSIS peers. this could be very > > small (nothing), just next/previous hop id (like RSVP), or > > quite complex (including security information). > > Agreed. > > > the relative amounts of state in NSIS protocol vs. signalling > > applications is a very good question, as is working out how > > it can be minimised. i don't personally expect it can be > > eliminated in a real protocol, but nothing is fixed. > > > > (people are free to suggest a less loaded term than 'session'.) > > > > > > > > 3) Is multicast really out of scope? > > [reh] question for the group (and a requirements question, as > > you point out). > > I'd prefer to think that multicast is not out of scope, but we > are not defining the NSIS protocol for multicast services. > > > > 4) receiver-oriented vs. sender-oriented > > [reh] good question (again). i suspect the answers may be > > different at the NSIS protocol layer and signalling > > applications (this is something we haven't really thought > > about, however.) > > This we should discuss and make some decisions on it. > > > > 6) Is the use of periodic refresh messages the primary means > > > of installing state? Should these messages be > > > idempotent? > > [reh] i think in fact this may be a protocol design question, > > it might be at the boundary of what the framework document is > > supposed to define. (john, any views?) > > This may be getting into protocol design. Should the framework > document define this? I am no so sure. > > > > 7) Rely on internal or external security mechanisms? (Can > > > we punt on this until we know more about the protocol?) > > [reh] i think the basic point here is that there may be very > > significant advantages to at least considering using existing > > security infrastructure, namely (a) it may be hard to design > > ourselves and (b) in deployment terms, maybe one would rather > > avoid having to manage an NSIS-specific (or signalling > > application specific) set of identities and keys and rights. > > however, at this stage in the process, i think the main point > > is to try to map the overall security requirements onto the > > various components in the framework, and (maybe) look at > > goodness of fit to existing mechanisms. > > I think we punt, but perhaps we can at least can start setting the > table. My knee-jerk reaction would be that the transport layer > use something like TLS and the service layer use some sort of > end-to-end > encryption of payload. > > John > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 23:47:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05143 for ; Thu, 17 Oct 2002 23:47:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I3nS808617 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 23:49:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I3nOv08610; Thu, 17 Oct 2002 23:49:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HGvqv04600 for ; Thu, 17 Oct 2002 12:57:52 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17640 for ; Thu, 17 Oct 2002 12:55:35 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9HGvYY17643; Thu, 17 Oct 2002 18:57:34 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CFC5813E25; Thu, 17 Oct 2002 18:57:33 +0200 (CEST) Date: Thu, 17 Oct 2002 18:57:34 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Melinda Shore , john.loughney@nokia.com Cc: nsis@ietf.org Subject: Re: [NSIS] WG Last call on the Requirements Draft? Message-ID: <34267724.1034881054@[192.168.102.207]> In-Reply-To: <200210151236.AAF41456@mira-sjc5-4.cisco.com> References: <200210151236.AAF41456@mira-sjc5-4.cisco.com> X-Mailer: Mulberry/2.2.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 [..] > If you take a look at other requirements documents that have > recently been published as RFCs in the Transport Area you'll > see that the actual requirements material typically starts > somewhere around page 4 or 5 and sometimes as early as page > 1. In the NSIS requirements document the requirements > material starts on page 10. I think a great deal of that > introductory material should be removed from the > requirements document and integrated into the framework > document if it's not already in there. But in some of your later mails you say we need to define what this and that means. And I do not see framework stuff in it more terminology. 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 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 17 23:47:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05159 for ; Thu, 17 Oct 2002 23:47:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I3nZi08629 for nsis-archive@odin.ietf.org; Thu, 17 Oct 2002 23:49:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I3nLv08594; Thu, 17 Oct 2002 23:49:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HGrqv04458 for ; Thu, 17 Oct 2002 12:53:52 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17392 for ; Thu, 17 Oct 2002 12:51:35 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9HGrVY17561; Thu, 17 Oct 2002 18:53:31 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2138515B59; Thu, 17 Oct 2002 18:53:31 +0200 (CEST) Date: Thu, 17 Oct 2002 18:53:31 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Melinda Shore Cc: nsis@ietf.org Subject: Re: [NSIS] WG Last call on the Requirements Draft? Message-ID: <34024965.1034880811@[192.168.102.207]> In-Reply-To: <200210151507.AAF44318@mira-sjc5-4.cisco.com> References: <200210151507.AAF44318@mira-sjc5-4.cisco.com> X-Mailer: Mulberry/2.2.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 But as far as I have seen the list the consensus was to not rule-out the off-path (what ever it is, see the E-Mail thread on that), but focus on the on-path. And I hope that the formulation does reflect this. Or in other words if we find a protocol which works mainly on-path but also for off-path we can still use it in NSIS and are not obliged to throw it away. Marcus --On Dienstag, 15. Oktober 2002 11:12 -0400 Melinda Shore wrote: > I'm in the process of going through the document and one > thing pops out at me that I really think has to be addressed > ASAP. In section 5.2, several requirements (which are not > actually stated as requirements, incidentally) suggest that > we're supporting off-path signaling. I believe that this is > currently (and possibly forever) out of scope. This has > been discussed quite a bit and it's my recollection that the > working group never came to a decision. > > This also needs to be consistent with the framework document. > > Melinda > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- 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 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 01:19:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06733 for ; Fri, 18 Oct 2002 01:19:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I5LU112888 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 01:21:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I5LQv12866; Fri, 18 Oct 2002 01:21:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I5KKv12840 for ; Fri, 18 Oct 2002 01:20:20 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06721 for ; Fri, 18 Oct 2002 01:17:56 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9I5KAH01908 for ; Fri, 18 Oct 2002 08:20:10 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 08:20:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 08:20:07 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] "sessions" and discovery MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 18 Oct 2002 08:20:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0170A7F7@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] "sessions" and discovery Thread-Index: AcJ2MCN4tPh03Y3GTYunTLuGhGzJAAAL1rwQ To: , , X-OriginalArrivalTime: 18 Oct 2002 05:20:08.0174 (UTC) FILETIME=[0626C0E0:01C27666] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9I5KKv12841 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Robert, > in other words, the framework doesn't say "you have to > separate message transport from discovery". if you think this > is unclear, we can fix it. Perhaps it would be good to clarify it. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 01:19:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06746 for ; Fri, 18 Oct 2002 01:19:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I5LWQ12901 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 01:21:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I5LTv12881; Fri, 18 Oct 2002 01:21:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I5KQv12845 for ; Fri, 18 Oct 2002 01:20:26 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06724 for ; Fri, 18 Oct 2002 01:18:02 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9I5KHH01967 for ; Fri, 18 Oct 2002 08:20:17 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 08:20:15 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 08:20:14 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] WG Last call on the Requirements Draft? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 18 Oct 2002 08:20:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0170A7F9@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] WG Last call on the Requirements Draft? Thread-Index: AcJ2WVxdfdIhow63RuakRSrMFK5lKgABpmlQ To: , Cc: X-OriginalArrivalTime: 18 Oct 2002 05:20:14.0542 (UTC) FILETIME=[09F26EE0:01C27666] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9I5KQv12846 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marcus, > But as far as I have seen the list the consensus was to not > rule-out the > off-path (what ever it is, see the E-Mail thread on that), > but focus on the > on-path. And I hope that the formulation does reflect this. > > Or in other words if we find a protocol which works mainly > on-path but also > for off-path we can still use it in NSIS and are not obliged > to throw it away. For what it is worth, the ADs don't want us to work on off-path. That being said, after we are done with our work & have a protocol - someone could apply it for the off-path signaling. I think if we leave off-path considerations in the requirements doc, the ADs will not be happy. I think that the Framework doc can have some discussion on off-path, however. If it becomes controversial, then it can be moved into an appendix. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 03:53:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18056 for ; Fri, 18 Oct 2002 03:53:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I7tSG29004 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 03:55:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7tPv28993; Fri, 18 Oct 2002 03:55:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7gqv28499 for ; Fri, 18 Oct 2002 03:42:52 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17796 for ; Fri, 18 Oct 2002 03:40:23 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9I7gPY30795; Fri, 18 Oct 2002 09:42:25 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8546753E9A; Fri, 18 Oct 2002 09:42:24 +0200 (CEST) Date: Fri, 18 Oct 2002 09:50:03 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Melinda Shore Cc: nsis@ietf.org Subject: Re: [NSIS] WG Last call on the Requirements Draft? Message-ID: <327831.1034934603@[192.168.102.207]> In-Reply-To: <200210171701.AAG28172@mira-sjc5-4.cisco.com> References: <200210171701.AAG28172@mira-sjc5-4.cisco.com> X-Mailer: Mulberry/2.2.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 What I have seen from CASP as well as our proposal for RSVP version 2 does have the off-path signaling option. The main difference (and I regard this as implementation issue) is that there need to be two ways of finding the next hop in an NSIS deamon ( I think CASP even provides more cases). Marcus --On Donnerstag, 17. Oktober 2002 13:06 -0400 Melinda Shore wrote: >> But as far as I have seen the list the consensus was to >> not rule-out the off-path (what ever it is, see the E-Mail >> thread on that), but focus on the on-path. And I hope that >> the formulation does reflect this. Or in other words if >> we find a protocol which works mainly on-path but also for >> off-path we can still use it in NSIS and are not obliged >> to throw it away. > > I think it would be a big mistake and could easily result in > never producing a working protocol. It would be helpful if > someone who thinks that it is in scope could scratch > together a diagram of how they think it might work. > > That's not to say that I think this is not IETF work - I do > think it is. I just don't think that it could reasonably > fit into an end-to-end signaling protocol. As it happens, > there is a diagram in the framework document of how it could > be done by NSIS working in conjunction with another > protocol, and that's Figure 8. > > Melinda -------------------------------------- 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 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 03:56:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18124 for ; Fri, 18 Oct 2002 03:56:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I7w7e29105 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 03:58:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7w4v29094; Fri, 18 Oct 2002 03:58:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7vYv29056 for ; Fri, 18 Oct 2002 03:57:34 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18098 for ; Fri, 18 Oct 2002 03:55:11 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9I7vMY31444 for ; Fri, 18 Oct 2002 09:57:22 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CBACD280E7 for ; Fri, 18 Oct 2002 09:57:21 +0200 (CEST) Date: Fri, 18 Oct 2002 10:05:00 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Subject: Re: [NSIS] WG Last call on the Requirements Draft? Message-ID: <1225301.1034935500@[192.168.102.207]> X-Mailer: Mulberry/2.2.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 But as far as I have seen the list the consensus was to not rule-out the off-path (what ever it is, see the E-Mail thread on that), but focus on the on-path. And I hope that the formulation does reflect this. Or in other words if we find a protocol which works mainly on-path but also for off-path we can still use it in NSIS and are not obliged to throw it away. Marcus --On Dienstag, 15. Oktober 2002 11:12 -0400 Melinda Shore wrote: > I'm in the process of going through the document and one > thing pops out at me that I really think has to be addressed > ASAP. In section 5.2, several requirements (which are not > actually stated as requirements, incidentally) suggest that > we're supporting off-path signaling. I believe that this is > currently (and possibly forever) out of scope. This has > been discussed quite a bit and it's my recollection that the > working group never came to a decision. > > This also needs to be consistent with the framework document. > > Melinda > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- 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 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 03:57:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18171 for ; Fri, 18 Oct 2002 03:57:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I7x4429171 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 03:59:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7x2v29144; Fri, 18 Oct 2002 03:59:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7w6v29101 for ; Fri, 18 Oct 2002 03:58:06 -0400 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18105 for ; Fri, 18 Oct 2002 03:55:42 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9I7vZw15885 for ; Fri, 18 Oct 2002 10:57:35 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 10:57:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 10:57:53 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] WG Last call on the Requirements Draft? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 18 Oct 2002 10:57:50 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A589E@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] WG Last call on the Requirements Draft? Thread-Index: AcJ2e7t76MYLRv8aS8yQWYg9ylHWFAAACwpw To: , Cc: X-OriginalArrivalTime: 18 Oct 2002 07:57:53.0616 (UTC) FILETIME=[0FFE9500:01C2767C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9I7w6v29102 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marcus, > What I have seen from CASP as well as our proposal for RSVP version 2 does > have the off-path signaling option. > > The main difference (and I regard this as implementation issue) is that > there need to be two ways of finding the next hop in an NSIS deamon ( I > think CASP even provides more cases). I think that we can leave hooks in for the off-path signaling, but I hope we don't drive protocol work to accomplish it. I would prefer to get the basic on-path signaling work well stablized before developing off-path signaling. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 03:57:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18185 for ; Fri, 18 Oct 2002 03:57:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I7x5h29195 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 03:59:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7x3v29159; Fri, 18 Oct 2002 03:59:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7w4v29087 for ; Fri, 18 Oct 2002 03:58:04 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18102 for ; Fri, 18 Oct 2002 03:55:40 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9I7vqY31477 for ; Fri, 18 Oct 2002 09:57:52 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6E6426C88B for ; Fri, 18 Oct 2002 09:57:51 +0200 (CEST) Date: Fri, 18 Oct 2002 10:05:30 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Subject: Re: [NSIS] WG Last call on the Requirements Draft? Message-ID: <1254924.1034935530@[192.168.102.207]> X-Mailer: Mulberry/2.2.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 [..] > If you take a look at other requirements documents that have > recently been published as RFCs in the Transport Area you'll > see that the actual requirements material typically starts > somewhere around page 4 or 5 and sometimes as early as page > 1. In the NSIS requirements document the requirements > material starts on page 10. I think a great deal of that > introductory material should be removed from the > requirements document and integrated into the framework > document if it's not already in there. But in some of your later mails you say we need to define what this and that means. And I do not see framework stuff in it more terminology. 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 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 03:57:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18206 for ; Fri, 18 Oct 2002 03:57:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I7x7M29207 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 03:59:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7x5v29188; Fri, 18 Oct 2002 03:59:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7wOv29118 for ; Fri, 18 Oct 2002 03:58:24 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18119 for ; Fri, 18 Oct 2002 03:56:01 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9I7wDY31496 for ; Fri, 18 Oct 2002 09:58:13 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 372DC6C861 for ; Fri, 18 Oct 2002 09:58:12 +0200 (CEST) Date: Fri, 18 Oct 2002 10:05:51 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Subject: Re: [NSIS] WG Last call on the Requirements Draft? Message-ID: <1275704.1034935551@[192.168.102.207]> X-Mailer: Mulberry/2.2.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 What I have seen from CASP as well as our proposal for RSVP version 2 does have the off-path signaling option. The main difference (and I regard this as implementation issue) is that there need to be two ways of finding the next hop in an NSIS deamon ( I think CASP even provides more cases). Marcus --On Donnerstag, 17. Oktober 2002 13:06 -0400 Melinda Shore wrote: >> But as far as I have seen the list the consensus was to >> not rule-out the off-path (what ever it is, see the E-Mail >> thread on that), but focus on the on-path. And I hope that >> the formulation does reflect this. Or in other words if >> we find a protocol which works mainly on-path but also for >> off-path we can still use it in NSIS and are not obliged >> to throw it away. > > I think it would be a big mistake and could easily result in > never producing a working protocol. It would be helpful if > someone who thinks that it is in scope could scratch > together a diagram of how they think it might work. > > That's not to say that I think this is not IETF work - I do > think it is. I just don't think that it could reasonably > fit into an end-to-end signaling protocol. As it happens, > there is a diagram in the framework document of how it could > be done by NSIS working in conjunction with another > protocol, and that's Figure 8. > > Melinda -------------------------------------- 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 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 04:10:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18478 for ; Fri, 18 Oct 2002 04:10:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I8CFB30606 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 04:12:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I8CDv30599; Fri, 18 Oct 2002 04:12:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I8B1v30568 for ; Fri, 18 Oct 2002 04:11:01 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18471 for ; Fri, 18 Oct 2002 04:08:37 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9I8ApH14358 for ; Fri, 18 Oct 2002 11:10:51 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 11:10:48 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 11:10:48 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 11:10:48 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] Comments on requirements draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 18 Oct 2002 11:10:47 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58A2@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] Comments on requirements draft Thread-Index: AcJ198Sko6gzB5rqT0CPhlR9uWtB1wAhW8UA To: , Cc: X-OriginalArrivalTime: 18 Oct 2002 08:10:48.0192 (UTC) FILETIME=[DDAD8000:01C2767D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9I8B1v30569 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, > I'm concerned that the requirements for the transport layer > and the requirements for the application may be different, > and what's in the requirements document seems to > specifically cover a QoS application, while the framework > document focuses on the transport (protocol machinery). > Authorization, for example, almost certainly belongs in the > application, not the transport. So what I suggest is that the requirements document goes through as a general requirements - we don't split the considerations into 2 pieces, etc. The framework document would be good to handle the split between the signaling application & the transport part. If needed, we can work on a 2nd document which goes further into protocol design issues, if there is need. > > there are various ways to provide aggregation. we described > the importance > > of more powerful flow identifiers (traffic selectors) in > detail in casp. > > Hello! CASP is not the NSIS protocol. CASP is a proposal, but at the moment, it is too early to say what protocols are good & and which are not. However, we do have the burden of re-using things from RSVP that have proven to be useful. > What I think would be useful is a discussion of this problem > in the threats/security document, which I hope will be > revised and re-issued. Yes, there was consensus that this is a WG document, so I hope Hannes has the cycles to re-issue it for the Atlanta meeting. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 04:36:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18820 for ; Fri, 18 Oct 2002 04:36:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I8cGF31990 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 04:38:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I8cDv31981; Fri, 18 Oct 2002 04:38:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I8btv31965 for ; Fri, 18 Oct 2002 04:37:55 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18810 for ; Fri, 18 Oct 2002 04:35:31 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9I8biY33787 for ; Fri, 18 Oct 2002 10:37:44 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1A7D46CD48 for ; Fri, 18 Oct 2002 10:37:43 +0200 (CEST) Date: Fri, 18 Oct 2002 10:37:43 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Subject: Next Steps in Out-of-Band Signaling (was RE: [NSIS] WG Last call on the Requirements Draft? ) Message-ID: <3646513.1034937463@[192.168.102.207]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF0170A7F9@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF0170A7F9@esebe004.ntc.nokia.com > X-Mailer: Mulberry/2.2.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 Dear all, So far I thought there is a chance to provide one protocol for on- and off path signaling. Since this IMHO most reasonable ways does not work. I setup an mailing list to discuss this issue. mailing list is called "nsobs", which stands for "Next Steps in Out-of-Band Signaling" is Majordomo list at ccrle.nec.de To subscribe send e-mail to nsobs-request@ccrle.nec.de with subscribe in the body. To send E-Mail to the list use nsobs@ccrle.nec.de Marcus --On Freitag, 18. Oktober 2002 08:20 +0300 john.loughney@nokia.com wrote: > Hi Marcus, > >> But as far as I have seen the list the consensus was to not >> rule-out the >> off-path (what ever it is, see the E-Mail thread on that), >> but focus on the >> on-path. And I hope that the formulation does reflect this. >> >> Or in other words if we find a protocol which works mainly >> on-path but also >> for off-path we can still use it in NSIS and are not obliged >> to throw it away. > > For what it is worth, the ADs don't want us to work on > off-path. That being said, after we are done with our work > & have a protocol - someone could apply it for the off-path > signaling. > > I think if we leave off-path considerations in the requirements > doc, the ADs will not be happy. I think that the Framework > doc can have some discussion on off-path, however. If it > becomes controversial, then it can be moved into an appendix. > > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- 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 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 04:43:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18902 for ; Fri, 18 Oct 2002 04:43:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I8j7D32286 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 04:45:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I8j5v32279; Fri, 18 Oct 2002 04:45:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I8iRv32246 for ; Fri, 18 Oct 2002 04:44:27 -0400 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18897 for ; Fri, 18 Oct 2002 04:42:03 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9I8iFY34012; Fri, 18 Oct 2002 10:44:15 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 9FD3E6C971; Fri, 18 Oct 2002 10:44:14 +0200 (CEST) Date: Fri, 18 Oct 2002 10:44:15 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org, nsobs@ccrle.nec.de Cc: SLS list Message-ID: <4038136.1034937855@[192.168.102.207]> X-Mailer: Mulberry/2.2.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 Subject: [NSIS] on-path versus off-path discussion Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 issue about on-path signaling versus off-path signaling raises quite a bit of traffic on the NSIS WG mailing list. You can call it also in-band or out-of-band signaling. There still not a clear definition of what on and what off-path is. E.g. you could call RSVPv1 RSRV message off-path because it does not follow the path base on IP routing. There definitely are some pro and cons for both approaches. See "On path and off path signaling for NSIS", draft-schelen-nsis-opopsig-00.txt for a discussion on some of them. Furthermore, there are some implementations (experimentqal and products) available for centralized QoS provisioning. We need to clarify what the way forward is concerning off-path signaling. On-path is in the charter of the NSIS WG. Additionally, there are a number of issues for clarifying what on-path includes. In certain cases the boundary is not straight forward. Currently, there seam to be 3 positions in the community: 1) Forget about off-path, nobody will use it and it is architecturally problematic in IP networks 2) Form a new WG taking care of the off-path issue completely independent of NSIS. 3) Require NSIS to work for on- and off-path signaling, because data objects to be carried by the protocol should basically be the same in both cases, and a soft-state approach is worth for off-path as well. Current draft dealing with some of the issues "On path and off path signaling for NSIS", draft-schelen-nsis-opopsig-00.txt Discussion list: mailing list is called "nsobs", which stands for "Next Steps in Out-of-Band Signaling" is Majordomo list at ccrle.nec.de To subscribe send e-mail to nsobs-request@ccrle.nec.de with subscribe in the body. To send E-Mail to the list use nsobs@ccrle.nec.de -------------------------------------- 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 personal home page: http://www.brubers.org/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 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 05:44:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19641 for ; Fri, 18 Oct 2002 05:44:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I9kcH03223 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 05:46:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I9kWv03215; Fri, 18 Oct 2002 05:46:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I9k0v03188 for ; Fri, 18 Oct 2002 05:46:00 -0400 Received: from iramx1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19638 for ; Fri, 18 Oct 2002 05:43:46 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iramx1 with esmtp (Exim 3.30 #10 (Debian)) id 182Thd-00028q-00; Fri, 18 Oct 2002 11:45:57 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 182Thd-0004iL-00; Fri, 18 Oct 2002 11:45:57 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g9I9jve10158; Fri, 18 Oct 2002 11:45:57 +0200 Message-Id: <200210180945.g9I9jve10158@tpce10.ipv6.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: brunner@ccrle.nec.de cc: nsis@ietf.org, nsobs@ccrle.nec.de, SLS list Subject: Re: [NSIS] on-path versus off-path discussion In-Reply-To: Message from Marcus Brunner of "Fri, 18 Oct 2002 10:44:15 +0200." <4038136.1034937855@[192.168.102.207]> References: <4038136.1034937855@[192.168.102.207]> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 18 Oct 2002 11:45:57 +0200 From: Roland Bless Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marcus, > The issue about on-path signaling versus off-path signaling raises quite a > bit of traffic on the NSIS WG mailing list. You can call it also in-band or > out-of-band signaling. There still not a clear definition of what on and I disagree here: in-band/out-of-band is another distinction: a typical case of in-band signaling is DTMF tone in-band signaling within the telephone system, so I would say that in-band signaling would mean to place the signaling data into the header or user data part of an IP datagram which is part of the user data flow. I like the proposed term from Robert Hancock path-coupled/path-decoupled. > what off-path is. E.g. you could call RSVPv1 RSRV message off-path because > it does not follow the path base on IP routing. Right RESV not, PATH yes. I thought that on-path signaling messages simply have the same source and destination address as the data flow which is true for PATH messages. Off-path signaling may use different addresses. However, you gain flexibility when using off-path signaling while you can let the signaling messages still follow the same data path as corresponding on-path message would. > There definitely are some pro and cons for both approaches. See "On path > and off path signaling for NSIS", draft-schelen-nsis-opopsig-00.txt for a > discussion on some of them. Furthermore, there are some implementations > (experimentqal and products) available for centralized QoS provisioning. If we meet the I-D deadline there should be a new draft revision before the next meeting. > We need to clarify what the way forward is concerning off-path signaling. > On-path is in the charter of the NSIS WG. Additionally, there are a number > of issues for clarifying what on-path includes. In certain cases the > boundary is not straight forward. > > Currently, there seam to be 3 positions in the community: > 1) Forget about off-path, nobody will use it and it is architecturally > problematic in IP networks I don't see that it's problematic. > 2) Form a new WG taking care of the off-path issue completely independent > of NSIS. I don't think that this makes sense. > 3) Require NSIS to work for on- and off-path signaling, because data > objects to be carried by the protocol should basically be the same in both > cases, and a soft-state approach is worth for off-path as well. Right. It is absolutely no problem to define a protocol that supports both variants at the same time. > Current draft dealing with some of the issues > "On path and off path signaling for NSIS", draft-schelen-nsis-opopsig-00.txt We will try to write a new revision with a more clear structure and distinction between properties and examples for advantages/disadvantages. > Discussion list: > mailing list is called "nsobs", which stands for "Next Steps in Out-of-Band > Signaling" is Majordomo list at ccrle.nec.de > > To subscribe send e-mail to nsobs-request@ccrle.nec.de with subscribe in > the body. > > To send E-Mail to the list use nsobs@ccrle.nec.de Best regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 05:50:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19719 for ; Fri, 18 Oct 2002 05:50:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I9qAC03407 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 05:52:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I9q5v03400; Fri, 18 Oct 2002 05:52:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I9pQv03377 for ; Fri, 18 Oct 2002 05:51:26 -0400 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19708 for ; Fri, 18 Oct 2002 05:49:11 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 18 Oct 2002 11:44:54 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <464HV4NC>; Fri, 18 Oct 2002 11:44:22 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] on-path versus off-path discussion Date: Fri, 18 Oct 2002 11:44:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9I9pQv03378 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Marcus, what's the definition of path? I remember one of John (I think) saying path means AS path and nothing more. Is this still valid? Regards, Rüdiger > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Friday, October 18, 2002 10:44 AM > To: nsis@ietf.org; nsobs@ccrle.nec.de > Cc: SLS list > Subject: [NSIS] on-path versus off-path discussion > > > The issue about on-path signaling versus off-path signaling > raises quite a > bit of traffic on the NSIS WG mailing list. You can call it > also in-band or > out-of-band signaling. There still not a clear definition of > what on and > what off-path is. E.g. you could call RSVPv1 RSRV message > off-path because > it does not follow the path base on IP routing. > > There definitely are some pro and cons for both approaches. > See "On path > and off path signaling for NSIS", > draft-schelen-nsis-opopsig-00.txt for a > discussion on some of them. Furthermore, there are some > implementations > (experimentqal and products) available for centralized QoS > provisioning. > > We need to clarify what the way forward is concerning > off-path signaling. > On-path is in the charter of the NSIS WG. Additionally, there > are a number > of issues for clarifying what on-path includes. In certain cases the > boundary is not straight forward. > > Currently, there seam to be 3 positions in the community: > 1) Forget about off-path, nobody will use it and it is > architecturally > problematic in IP networks > 2) Form a new WG taking care of the off-path issue completely > independent > of NSIS. > 3) Require NSIS to work for on- and off-path signaling, because data > objects to be carried by the protocol should basically be the > same in both > cases, and a soft-state approach is worth for off-path as well. > > Current draft dealing with some of the issues > "On path and off path signaling for NSIS", > draft-schelen-nsis-opopsig-00.txt > > Discussion list: > mailing list is called "nsobs", which stands for "Next Steps > in Out-of-Band > Signaling" is Majordomo list at ccrle.nec.de > > To subscribe send e-mail to nsobs-request@ccrle.nec.de with > subscribe in > the body. > > To send E-Mail to the list use nsobs@ccrle.nec.de > > > -------------------------------------- > 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 > personal home page: http://www.brubers.org/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 > 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 mailnull@www1.ietf.org Fri Oct 18 06:03:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20003 for ; Fri, 18 Oct 2002 06:03:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IA5f103814 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 06:05:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IA5cv03806; Fri, 18 Oct 2002 06:05:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IA4wv03764 for ; Fri, 18 Oct 2002 06:04:58 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19996 for ; Fri, 18 Oct 2002 06:02:44 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT6A0Q>; Fri, 18 Oct 2002 11:04:44 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA60B@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Geib, Ruediger'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] on-path versus off-path discussion Date: Fri, 18 Oct 2002 11:04:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all, there are plenty of definitions of "path", and plenty of definitions of = what "on/off" one of them might mean. what the *nsis* w.g. needs to be clear about (as melinda has pointed = out) is what definition we agree on, and then (implicitly) what is = currently in or out of NSIS scope. (i guess this would also be useful = input to discussing the scope of any complementary or additional = activity.) a proposed definition is on the table in 3.2.1 of = draft-ietf-nsis-fw-00.txt ("path coupled/decoupled"). as a teaser, this = definition would classify both RSVP PATH and RESV messages as path = coupled, and therefore legitimately in NSIS scope (even though the = latter uses what we call peer-session and not end-to-end addressing). send comments!=20 cheers, robert h. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 18 October 2002 10:44 > To: brunner@ccrle.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] on-path versus off-path discussion >=20 >=20 > Marcus, >=20 > what's the definition of path? I remember=20 > one of John (I think) saying path=20 > means AS path and nothing more. Is this=20 > still valid? >=20 > Regards, R=FCdiger=20 >=20 > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: Friday, October 18, 2002 10:44 AM > > To: nsis@ietf.org; nsobs@ccrle.nec.de > > Cc: SLS list > > Subject: [NSIS] on-path versus off-path discussion > >=20 > >=20 > > The issue about on-path signaling versus off-path signaling=20 > > raises quite a=20 > > bit of traffic on the NSIS WG mailing list. You can call it=20 > > also in-band or=20 > > out-of-band signaling. There still not a clear definition of=20 > > what on and=20 > > what off-path is. E.g. you could call RSVPv1 RSRV message=20 > > off-path because=20 > > it does not follow the path base on IP routing. > >=20 > > There definitely are some pro and cons for both approaches.=20 > > See "On path=20 > > and off path signaling for NSIS",=20 > > draft-schelen-nsis-opopsig-00.txt for a=20 > > discussion on some of them. Furthermore, there are some=20 > > implementations=20 > > (experimentqal and products) available for centralized QoS=20 > > provisioning. > >=20 > > We need to clarify what the way forward is concerning=20 > > off-path signaling.=20 > > On-path is in the charter of the NSIS WG. Additionally, there=20 > > are a number=20 > > of issues for clarifying what on-path includes. In certain=20 > cases the=20 > > boundary is not straight forward. > >=20 > > Currently, there seam to be 3 positions in the community: > > 1) Forget about off-path, nobody will use it and it is=20 > > architecturally=20 > > problematic in IP networks > > 2) Form a new WG taking care of the off-path issue completely=20 > > independent=20 > > of NSIS. > > 3) Require NSIS to work for on- and off-path signaling,=20 > because data=20 > > objects to be carried by the protocol should basically be the=20 > > same in both=20 > > cases, and a soft-state approach is worth for off-path as well. > >=20 > > Current draft dealing with some of the issues > > "On path and off path signaling for NSIS",=20 > > draft-schelen-nsis-opopsig-00.txt > >=20 > > Discussion list: > > mailing list is called "nsobs", which stands for "Next Steps=20 > > in Out-of-Band=20 > > Signaling" is Majordomo list at ccrle.nec.de > >=20 > > To subscribe send e-mail to nsobs-request@ccrle.nec.de with=20 > > subscribe in=20 > > the body. > >=20 > > To send E-Mail to the list use nsobs@ccrle.nec.de > >=20 > >=20 > > -------------------------------------- > > Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > >=20 > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > Phone: +49 (0) 6221 905 11 29 > > personal home page: http://www.brubers.org/marcus > >=20 > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > >=20 > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > Phone: +49 (0) 6221 905 11 29 > > personal home page: http://www.brubers.org/marcus > >=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 >=20 =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=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=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 Permission is hereby granted to pass the contents of this communication = to third parties and any restrictions regarding confidentiality do not = apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 06:10:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20116 for ; Fri, 18 Oct 2002 06:10:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IAC4004603 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 06:12:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IAC2v04596; Fri, 18 Oct 2002 06:12:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IAB2v04552 for ; Fri, 18 Oct 2002 06:11:02 -0400 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20109 for ; Fri, 18 Oct 2002 06:08:48 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9IAAfw22761 for ; Fri, 18 Oct 2002 13:10:41 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 13:10:59 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 13:10:59 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] on-path versus off-path discussion MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 18 Oct 2002 13:10:58 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58A9@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] on-path versus off-path discussion Thread-Index: AcJ2jA/BmsH+OUY6Ql2HX9295AksfwAAm8kw To: , Cc: X-OriginalArrivalTime: 18 Oct 2002 10:10:59.0486 (UTC) FILETIME=[A7F1A3E0:01C2768E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9IAB2v04553 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rüdiger, > what's the definition of path? I remember > one of John (I think) saying path > means AS path and nothing more. Is this > still valid? Making an overtly simple example. If A wants to signal B, on-path means he signals to B. Off path means he signals to C. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 07:39:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21854 for ; Fri, 18 Oct 2002 07:39:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IBfLH09120 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 07:41:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBfJv09113; Fri, 18 Oct 2002 07:41:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBeAv09044 for ; Fri, 18 Oct 2002 07:40:10 -0400 Received: from iramx1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21816 for ; Fri, 18 Oct 2002 07:37:54 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iramx1 with esmtp (Exim 3.30 #10 (Debian)) id 182VU6-0002Iw-00; Fri, 18 Oct 2002 13:40:06 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 182VU7-0002cm-00; Fri, 18 Oct 2002 13:40:07 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g9IBe0e10797; Fri, 18 Oct 2002 13:40:06 +0200 Message-Id: <200210181140.g9IBe0e10797@tpce10.ipv6.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: john.loughney@nokia.com cc: Ruediger.Geib@t-systems.com, brunner@ccrle.nec.de, nsis@ietf.org Subject: Re: [NSIS] on-path versus off-path discussion In-Reply-To: Message from john.loughney@nokia.com of "Fri, 18 Oct 2002 13:10:58 +0300." <0C1353ABB1DEB74DB067ADFF749C4EEF015A58A9@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58A9@esebe004.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 18 Oct 2002 13:40:00 +0200 From: Roland Bless Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi John, > > what's the definition of path? I remember > > one of John (I think) saying path > > means AS path and nothing more. Is this > > still valid? > > Making an overtly simple example. If A wants to signal B, > on-path means he signals to B. Off path means he signals to C. Oops, this is third-party/proxy signaling in my understanding. What is A and B? sender, receiver? Although the above example may be simple, I thought on-path means that the signaling messages follow the same path (forward or reverse) router-hop by router-hop as the data of the corresponding flow (which the signaling is about). So obviously the notion "on-path" is interpreted differently and we need a clear definition (maybe from A-Ds) _what_ they don't want to see in NSIS and why (or did I miss a statement on the list). Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 07:45:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22023 for ; Fri, 18 Oct 2002 07:45:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IBlEV09412 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 07:47:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBlCv09405; Fri, 18 Oct 2002 07:47:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBkXv09353 for ; Fri, 18 Oct 2002 07:46:33 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21967 for ; Fri, 18 Oct 2002 07:44:17 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9IBkWH23131 for ; Fri, 18 Oct 2002 14:46:33 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 14:46:30 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 14:46:29 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] on-path versus off-path discussion X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 18 Oct 2002 14:46:28 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58B4@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] on-path versus off-path discussion Thread-Index: AcJ2m0L9EEXnOS9SSle3fdw+X2V4NQAAGVDQ To: Cc: , , X-OriginalArrivalTime: 18 Oct 2002 11:46:29.0213 (UTC) FILETIME=[FF2098D0:01C2769B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9IBkXv09354 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Roland, > Oops, this is third-party/proxy signaling in my understanding. Yes, the ADs don't like 3rd party signaling. If there is a proxy somewhere, it should be on the (rough) data path. My feeling is that they don't want us to work on discovery. Discovery should come automatically, due to the signaling. > What is A and B? sender, receiver? > Although the above example may be simple, I thought on-path means > that the signaling messages follow the same path (forward or reverse) > router-hop by router-hop as the data of the corresponding flow > (which the signaling is about). > So obviously the notion "on-path" is interpreted differently > and we need a > clear definition (maybe from A-Ds) _what_ they don't want to > see in NSIS and why (or did I miss a statement on the list). Here you go! John ------- Forwarded Message Date: Thu, 16 May 2002 08:58:44 -0400 From: Scott Bradner To: mankin@ISI.EDU my take on what NSIS should be working on now is: signaling from an end system that follows a path through the net that is determined by the normal L3 routing and is used to convey per-flow information to the devices the signals pass through - the signaling can install soft state (maintained by repetition) in the devices it passes through an end system could be a device along the path that signals for a data flow that passes through it there is no requirement that the per-flow information be QoS related i.e. NSIS should only worry about how to do the signaling - what the signaling conveys should be opaque to NSIS this rules out bandwidth brokers, 3rd party QoS controllers, hard state, etc after they do this, NSIS could move on to other things (like BBs) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 08:14:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22700 for ; Fri, 18 Oct 2002 08:14:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ICGbk10921 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 08:16:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ICGUv10896; Fri, 18 Oct 2002 08:16:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ICFKv10849 for ; Fri, 18 Oct 2002 08:15:20 -0400 Received: from iramx1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22668 for ; Fri, 18 Oct 2002 08:13:06 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iramx1 with esmtp (Exim 3.30 #10 (Debian)) id 182W28-0002LK-00; Fri, 18 Oct 2002 14:15:16 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 182W29-0004Y0-00; Fri, 18 Oct 2002 14:15:17 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g9ICFGe11037; Fri, 18 Oct 2002 14:15:16 +0200 Message-Id: <200210181215.g9ICFGe11037@tpce10.ipv6.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: john.loughney@nokia.com cc: bless@tm.uka.de, Ruediger.Geib@t-systems.com, brunner@ccrle.nec.de, nsis@ietf.org, bless@tm.uka.de Subject: Re: [NSIS] on-path versus off-path discussion In-Reply-To: Message from john.loughney@nokia.com of "Fri, 18 Oct 2002 14:46:28 +0300." <0C1353ABB1DEB74DB067ADFF749C4EEF015A58B4@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58B4@esebe004.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Oct 2002 14:15:16 +0200 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 Roland, > > > Oops, this is third-party/proxy signaling in my understanding. > > Yes, the ADs don't like 3rd party signaling. If there is a > proxy somewhere, it should be on the (rough) data path. My > feeling is that they don't want us to work on discovery. Discovery > should come automatically, due to the signaling. While I know that discovery may be an issue that may need a lot of discussion and work: Resolving hostnames is also an essential service and needs automatic or static configuration of DNS server's addresses. Is thus DNS broken? I also had the consensus in mind that we concentrate on on-path while not excluding off-path completely. > > What is A and B? sender, receiver? > > Although the above example may be simple, I thought on-path means > > that the signaling messages follow the same path (forward or reverse) > > router-hop by router-hop as the data of the corresponding flow > > (which the signaling is about). > > So obviously the notion "on-path" is interpreted differently > > and we need a > > clear definition (maybe from A-Ds) _what_ they don't want to > > see in NSIS and why (or did I miss a statement on the list). > > Here you go! > John Ok, I knew that mail, but I thought after the interim-meeting the should be an additional clarification... Regards, Roland > ------- Forwarded Message > > Date: Thu, 16 May 2002 08:58:44 -0400 > From: Scott Bradner > To: mankin@ISI.EDU > > my take on what NSIS should be working on now is: > > signaling from an end system that follows a path through the net that is > determined by the normal L3 routing and is used to convey > per-flow information to the devices the signals pass through - the > signaling can install soft state (maintained by repetition) in the devices > it passes through > > an end system could be a device along the path that signals for a data > flow that passes through it > > there is no requirement that the per-flow information be QoS related i.e. > NSIS should only worry about how to do the signaling - what the signaling > conveys should be opaque to NSIS > > this rules out bandwidth brokers, 3rd party QoS controllers, hard state, > etc > > after they do this, NSIS could move on to other things (like BBs) > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 08:45:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23560 for ; Fri, 18 Oct 2002 08:45:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IClD712518 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 08:47:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IClAv12511; Fri, 18 Oct 2002 08:47:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ICkmv12495 for ; Fri, 18 Oct 2002 08:46:48 -0400 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23511 for ; Fri, 18 Oct 2002 08:44:33 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 18 Oct 2002 14:46:36 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <464HWBBP>; Fri, 18 Oct 2002 14:46:36 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] on-path versus off-path discussion Date: Fri, 18 Oct 2002 14:46:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9ICkmv12496 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello John Is this feeling part of the requirements doc or the charter or wherever it fits well to? Or would it be a bad idea to put it down somewhere? Thanks for clarification, Rüdiger > [JL] My feeling is that they don't want us to work on discovery. > Discovery should come automatically, due to the signaling. > [SB] signaling from an end system that follows a path through > the net that is determined by the normal L3 routing and is > used to convey per-flow information to the devices the > signals pass through - the signaling can install soft state > (maintained by repetition) in the devices it passes through _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 08:55:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23931 for ; Fri, 18 Oct 2002 08:55:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ICv6D12994 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 08:57:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ICv4v12983; Fri, 18 Oct 2002 08:57:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ICtRv12890 for ; Fri, 18 Oct 2002 08:55:27 -0400 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23848 for ; Fri, 18 Oct 2002 08:53:12 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9ICt4w06744 for ; Fri, 18 Oct 2002 15:55:05 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 15:55:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 15:55:23 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Comments on framework draft X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 18 Oct 2002 15:55:19 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58BE@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] Comments on framework draft Thread-Index: AcJ2L6TuBLuiEuevTMOZBxz4sUy6pwAddJkg To: , , X-OriginalArrivalTime: 18 Oct 2002 12:55:23.0232 (UTC) FILETIME=[9F31D600:01C276A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9ICtRv12891 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, > i think (hope?) that the 2 layer (or "2 level") approach is > agreed as a way forward. i suspect there is also a fair > amount of agreement about the scopes of the two layers > (although the framework currently doesn't cover this, maybe > it should - if people want to propose something & where it > should go...) My working assumption is the same as yours. > however, i suspect that's orthogonal to melinda's concern, > which is that merely using what we call peer-session > addressing (either for things with local or end-to-end scope) > is a Bad Idea, because you lose certain self-healing > properties. i don't think the layering separation helps > matters. (melinda, did i get your message?) That should be worked out in the discussion of the framwork, I think. > personally, i think you may gain as much as you lose, or even > more. but that's the argument we have to work out here. Exactly. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 08:59:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24053 for ; Fri, 18 Oct 2002 08:59:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ID1Ds13231 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 09:01:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ID1Av13219; Fri, 18 Oct 2002 09:01:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ID0Rv13165 for ; Fri, 18 Oct 2002 09:00:27 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24009 for ; Fri, 18 Oct 2002 08:58:12 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9ID0NxF029336; Fri, 18 Oct 2002 06:00:23 -0700 (PDT) Received: from spandex.cisco.com (rtp-dial-1-191.cisco.com [10.83.97.191]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG58877; Fri, 18 Oct 2002 05:55:28 -0700 (PDT) Message-Id: <5.1.0.14.0.20021018085740.00abf380@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Oct 2002 09:01:28 -0400 To: "Hancock, Robert" , john.loughney@nokia.com, nsis@ietf.org From: Melinda Shore Subject: RE: [NSIS] Comments on framework draft In-Reply-To: <76C92FBBFB58D411AE760090271ED41805DF5B12@rsys002a.roke.co. uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 11:50 PM 10/17/02 +0100, Hancock, Robert wrote: >however, i suspect that's orthogonal to melinda's concern, which is that merely using what we call peer-session addressing (either for things with local or end-to-end scope) is a Bad Idea, because you lose certain self-healing properties. i don't think the layering separation helps matters. (melinda, did i get your message?) Sort of. I'm less concerned about hop-by-hop addressing (in the reverse direction, anyway) than I am about the creation of persistent links between NSIS entities. I'm unclear on why this would be considered advantageous (at this point I see it as highly disadvantageous), but at the very least I think that it's something that needs to be agreed to by the working group before becoming part of the framework. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 09:00:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24093 for ; Fri, 18 Oct 2002 09:00:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ID24a13278 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 09:02:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ID22v13271; Fri, 18 Oct 2002 09:02:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ID1Ov13249 for ; Fri, 18 Oct 2002 09:01:24 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24043 for ; Fri, 18 Oct 2002 08:59:09 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9ID1Lot020477; Fri, 18 Oct 2002 06:01:21 -0700 (PDT) Received: from spandex.cisco.com (rtp-dial-1-191.cisco.com [10.83.97.191]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG58897; Fri, 18 Oct 2002 05:56:24 -0700 (PDT) Message-Id: <5.1.0.14.0.20021018090139.00ac8ec0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Oct 2002 09:02:24 -0400 To: "Hancock, Robert" From: Melinda Shore Cc: nsis@ietf.org In-Reply-To: <76C92FBBFB58D411AE760090271ED41805DF5B13@rsys002a.roke.co. uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [NSIS] RE: on/off path, and requirements vs. framework content (was RE: WG L ast call on the Requirements Draft?) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 11:50 PM 10/17/02 +0100, Hancock, Robert wrote: >what do you actually think of the path coupled/decoupled definition (that is currently hanging out in the framework section 3.2.1)? D'oh! Sorry not to mention that earlier - I like it a lot and think that it's probably a better way to frame the distinction than "on path/off path." Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 09:02:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24178 for ; Fri, 18 Oct 2002 09:02:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ID45O13382 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 09:04:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ID43v13374; Fri, 18 Oct 2002 09:04:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ID37v13340 for ; Fri, 18 Oct 2002 09:03:07 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24130 for ; Fri, 18 Oct 2002 09:00:53 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9ID2rxF001136; Fri, 18 Oct 2002 06:02:53 -0700 (PDT) Received: from spandex.cisco.com (rtp-dial-1-191.cisco.com [10.83.97.191]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG58916; Fri, 18 Oct 2002 05:57:57 -0700 (PDT) Message-Id: <5.1.0.14.0.20021018090342.00abfcd0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Oct 2002 09:03:57 -0400 To: , From: Melinda Shore Subject: RE: [NSIS] WG Last call on the Requirements Draft? Cc: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A589E@esebe004.ntc.noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 10:57 AM 10/18/02 +0300, john.loughney@nokia.com wrote: >I think that we can leave hooks in for the off-path signaling, but I hope >we don't drive protocol work to accomplish it. I would agree with that - it seems like the right approach. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 09:05:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24269 for ; Fri, 18 Oct 2002 09:05:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ID78g13714 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 09:07:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ID75v13614; Fri, 18 Oct 2002 09:07:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ID62v13483 for ; Fri, 18 Oct 2002 09:06:02 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24230 for ; Fri, 18 Oct 2002 09:03:48 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9ID61H23796 for ; Fri, 18 Oct 2002 16:06:01 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 16:05:59 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 16:05:58 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] RE: on/off path, and requirements vs. framework content (was RE: WG L ast call on the Requirements Draft?) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 18 Oct 2002 16:05:57 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58C4@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] RE: on/off path, and requirements vs. framework content (was RE: WG L ast call on the Requirements Draft?) Thread-Index: AcJ2ppdQKgUIFKezQKS+YuIHShqCVwAAHJoQ To: , Cc: X-OriginalArrivalTime: 18 Oct 2002 13:05:58.0867 (UTC) FILETIME=[1A100A30:01C276A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9ID62v13484 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, > At 11:50 PM 10/17/02 +0100, Hancock, Robert wrote: > >what do you actually think of the path coupled/decoupled > definition (that is currently hanging out in the framework > section 3.2.1)? > > D'oh! Sorry not to mention that earlier - I like it a lot > and think that it's probably a better way to frame the distinction > than "on path/off path." So, should we use the definition going forward? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 09:06:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24332 for ; Fri, 18 Oct 2002 09:06:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ID84c14143 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 09:08:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ID82v14133; Fri, 18 Oct 2002 09:08:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ID7nv14103 for ; Fri, 18 Oct 2002 09:07:49 -0400 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24292 for ; Fri, 18 Oct 2002 09:05:34 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9ID7icl019992; Fri, 18 Oct 2002 06:07:44 -0700 (PDT) Received: from spandex.cisco.com (rtp-dial-1-191.cisco.com [10.83.97.191]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG58998; Fri, 18 Oct 2002 06:02:48 -0700 (PDT) Message-Id: <5.1.0.14.0.20021018090413.00ac87b0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Oct 2002 09:08:48 -0400 To: , From: Melinda Shore Subject: RE: [NSIS] Comments on requirements draft Cc: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58A2@esebe004.ntc.noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 11:10 AM 10/18/02 +0300, john.loughney@nokia.com wrote: >So what I suggest is that the requirements document goes through >as a general requirements - we don't split the considerations >into 2 pieces, etc. What I'm primarily concerned is that some of the requirements seem specifically to apply to a QoS application. Clearly we don't want to lose these, but they are distinct from the NSIS protocol machinery and perhaps would be best moved, if not into a different document then into another section. >CASP is a proposal, but at the moment, it is too early to say >what protocols are good & and which are not. I am somewhat concerned that on several occasions the authors of or contributors to the various working group documents have referred us to CASP to provide more information about what's in the WG documents. There have been several instances in other working groups of requirements and framework documents being written to reflect the behavior of someone's favorite new protocol rather than the actual problem to be solved, and I would hope that we can avoid that. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 09:08:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24406 for ; Fri, 18 Oct 2002 09:08:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IDA6414267 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 09:10:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IDA4v14258; Fri, 18 Oct 2002 09:10:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ID98v14208 for ; Fri, 18 Oct 2002 09:09:08 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24366 for ; Fri, 18 Oct 2002 09:06:54 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9ID8wxF004348; Fri, 18 Oct 2002 06:08:58 -0700 (PDT) Received: from spandex.cisco.com (rtp-dial-1-191.cisco.com [10.83.97.191]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG59008; Fri, 18 Oct 2002 06:04:02 -0700 (PDT) Message-Id: <5.1.0.14.0.20021018090903.00ac2390@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Oct 2002 09:10:02 -0400 To: brunner@ccrle.nec.de, nsis@ietf.org, nsobs@ccrle.nec.de From: Melinda Shore Subject: Re: [NSIS] on-path versus off-path discussion Cc: SLS list In-Reply-To: <4038136.1034937855@[192.168.102.207]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 10:44 AM 10/18/02 +0200, Marcus Brunner wrote: >1) Forget about off-path, nobody will use it and it is architecturally problematic in IP networks I think that's not exactly what's been said. There are ways of doing off-path signaling that will work and ways of doing off-path signaling that are "architecturally problematic." Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 09:11:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24570 for ; Fri, 18 Oct 2002 09:11:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IDD6414460 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 09:13:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IDD4v14445; Fri, 18 Oct 2002 09:13:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IDCFv14391 for ; Fri, 18 Oct 2002 09:12:15 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24496 for ; Fri, 18 Oct 2002 09:10:00 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9IDCCH28445 for ; Fri, 18 Oct 2002 16:12:12 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 16:12:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 16:12:08 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Comments on requirements draft X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 18 Oct 2002 16:12:07 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58C6@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] Comments on requirements draft Thread-Index: AcJ2p1x5nrI1QJqXRHinh+vBYLSctAAAHwdw To: , Cc: X-OriginalArrivalTime: 18 Oct 2002 13:12:08.0312 (UTC) FILETIME=[F644DF80:01C276A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9IDCGv14392 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, > What I'm primarily concerned is that some of the requirements > seem specifically to apply to a QoS application. Clearly we > don't want to lose these, but they are distinct from the NSIS > protocol machinery and perhaps would be best moved, if not into > a different document then into another section. That is reasonable. > I am somewhat concerned that on several occasions the authors of > or contributors to the various working group documents have > referred us to CASP to provide more information about what's > in the WG documents. There have been several instances in other > working groups of requirements and framework documents being written > to reflect the behavior of someone's favorite new protocol rather > than the actual problem to be solved, and I would hope that we can > avoid that. We need to avoid that, I agree. I just put down the comments as a bit of promotion by the authors ... John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 09:13:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24717 for ; Fri, 18 Oct 2002 09:13:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IDF6N14575 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 09:15:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IDF4v14562; Fri, 18 Oct 2002 09:15:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IDE3v14519 for ; Fri, 18 Oct 2002 09:14:03 -0400 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24632 for ; Fri, 18 Oct 2002 09:11:48 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9IDDfw21202 for ; Fri, 18 Oct 2002 16:13:41 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 16:13:59 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 16:13:59 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 16:13:58 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] on-path versus off-path discussion X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 18 Oct 2002 16:13:57 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58C7@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] on-path versus off-path discussion Thread-Index: AcJ2p7VO78TkCg7eT1uudv9l3+gi5QAAFOHA To: , , Cc: X-OriginalArrivalTime: 18 Oct 2002 13:13:58.0659 (UTC) FILETIME=[380A7D30:01C276A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9IDE3v14520 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marcus, > 1) Forget about off-path, nobody will use it and it is > architecturally problematic in IP networks The correct answer is, of course, NSIS was chartered for on-path signaling. Off-path may have some validity, but should be done after the basic protocol work has been completed or done in a seperate WG. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 18 09:28:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25409 for ; Fri, 18 Oct 2002 09:28:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IDUEF15193 for nsis-archive@odin.ietf.org; Fri, 18 Oct 2002 09:30:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IDUAv15186; Fri, 18 Oct 2002 09:30:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IDTgv15128 for ; Fri, 18 Oct 2002 09:29:42 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25353 for ; Fri, 18 Oct 2002 09:27:27 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9IDTcot001564; Fri, 18 Oct 2002 06:29:38 -0700 (PDT) Received: from spandex.cisco.com (rtp-dial-1-191.cisco.com [10.83.97.191]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG59274; Fri, 18 Oct 2002 06:24:42 -0700 (PDT) Message-Id: <5.1.0.14.0.20021018093023.00acf5c0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Oct 2002 09:30:39 -0400 To: , From: Melinda Shore Subject: RE: [NSIS] RE: on/off path, and requirements vs. framework content (was RE: WG L ast call on the Requirements Draft?) Cc: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58C4@esebe004.ntc.noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 04:05 PM 10/18/02 +0300, john.loughney@nokia.com wrote: >So, should we use the definition going forward? If there's consensus, I think it's good. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Oct 19 15:16:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06475 for ; Sat, 19 Oct 2002 15:16:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9JJIDv07334 for nsis-archive@odin.ietf.org; Sat, 19 Oct 2002 15:18:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JJHxv07318; Sat, 19 Oct 2002 15:17:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JJGFv07295 for ; Sat, 19 Oct 2002 15:16:15 -0400 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06463 for ; Sat, 19 Oct 2002 15:13:54 -0400 (EDT) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g9JJG1024596; Sat, 19 Oct 2002 12:16:01 -0700 (PDT) Date: Sat, 19 Oct 2002 12:16:01 -0700 (PDT) From: Bob Braden Message-Id: <200210191916.g9JJG1024596@boreas.isi.edu> To: Ruediger.Geib@t-systems.com, brunner@ccrle.nec.de, robert.hancock@roke.co.uk Subject: RE: [NSIS] on-path versus off-path discussion Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> From nsis-admin@ietf.org Fri Oct 18 03:05:47 2002 *> X-UIDL: m!L"!Y2E!!jAW"!0d7"! *> From: "Hancock, Robert" *> To: "'Geib, Ruediger'" , brunner@ccrle.nec.de *> Cc: nsis@ietf.org *> Subject: RE: [NSIS] on-path versus off-path discussion *> Date: Fri, 18 Oct 2002 11:04:41 +0100 *> MIME-Version: 1.0 *> X-BeenThere: nsis@ietf.org *> X-Mailman-Version: 2.0.12 *> List-Unsubscribe: , *> *> List-Id: Next Steps in Signaling *> List-Post: *> List-Help: *> List-Subscribe: , *> *> X-AntiVirus: scanned by AMaViS 0.2.1 *> *> hi all, *> *> there are plenty of definitions of "path", and plenty of definitions of what "on/off" one of them might mean. *> Robert, RSVP established a meaning for "path". I fail to see why NSIS should try to (re-)invent terminology. *> what the *nsis* w.g. needs to be clear about (as melinda has pointed out) is what definition we agree on, and then (implicitly) what is currently in or out of NSIS scope. (i guess this would also be useful input to discussing the scope of any complementary or additional activity.) *> *> a proposed definition is on the table in 3.2.1 of draft-ietf-nsis-fw-00.txt ("path coupled/decoupled"). as a teaser, this definition would classify both RSVP PATH and RESV messages as path coupled, and therefore legitimately in NSIS scope (even though the latter uses what we call peer-session and not end-to-end addressing). I believe that your term has the same meaning as the term I already introduced in my 2-level signaling I-D, "path-directed [signaling]". Again, why should we have to keep re-inventing terminology? Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Oct 19 15:22:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06531 for ; Sat, 19 Oct 2002 15:22:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9JJO5s07460 for nsis-archive@odin.ietf.org; Sat, 19 Oct 2002 15:24:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JJO3v07453; Sat, 19 Oct 2002 15:24:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JJNCv07439 for ; Sat, 19 Oct 2002 15:23:12 -0400 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06505 for ; Sat, 19 Oct 2002 15:20:51 -0400 (EDT) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g9JJN0026291; Sat, 19 Oct 2002 12:23:00 -0700 (PDT) Date: Sat, 19 Oct 2002 12:23:00 -0700 (PDT) From: Bob Braden Message-Id: <200210191923.g9JJN0026291@boreas.isi.edu> To: brunner@ccrle.nec.de, Ruediger.Geib@t-systems.com Subject: RE: [NSIS] on-path versus off-path discussion Cc: nsis@ietf.org X-Sun-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, *> *> what's the definition of path? I remember *> one of John (I think) saying path *> means AS path and nothing more. Is this *> still valid? *> *> Regards, Rüdiger *> Friends, This is not really that hard. A [network] path is a sequence of network locations. To be precise, you have to say what kind of path you mean. In the BGP context (only!), an AS path is a sequence of autonomous systems. In common usage in the Internet, an unqualified "path" usually means a data path, ie the sequence of nodes traversed by some data flow (or aggregate). That is the way that RSVP uses the term. Since there seems to be some confusion in the NSIS membership, perhaps we had better always qualify "path". Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Oct 19 16:05:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07035 for ; Sat, 19 Oct 2002 16:05:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9JK7Aw09111 for nsis-archive@odin.ietf.org; Sat, 19 Oct 2002 16:07:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JK78v09054; Sat, 19 Oct 2002 16:07:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JK6Uv08794 for ; Sat, 19 Oct 2002 16:06:30 -0400 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07018 for ; Sat, 19 Oct 2002 16:04:10 -0400 (EDT) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g9JK6Lu11176; Sat, 19 Oct 2002 13:06:21 -0700 (PDT) Date: Sat, 19 Oct 2002 13:06:21 -0700 (PDT) From: Bob Braden Message-Id: <200210192006.g9JK6Lu11176@boreas.isi.edu> To: mshore@cisco.com, nsis@ietf.org, robert.hancock@roke.co.uk Subject: RE: [NSIS] Comments on framework draft X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> > *> > 2) Are "sessions" established between NSIS Entities? Note *> > that they don't eliminate state, but just move it to *> > another layer - what advantages does this have over the *> > more stateless RSVP protocol machinery? *> [reh] all 'session' is is a name for whatever protocol layer state is established between NSIS peers. this could be very small (nothing), just next/previous hop id (like RSVP), or quite complex (including security information). *> *> the relative amounts of state in NSIS protocol vs. signalling applications is a very good question, as is working out how it can be minimised. i don't personally expect it can be eliminated in a real protocol, but nothing is fixed. *> *> (people are free to suggest a less loaded term than 'session'.) *> I suggest that the solution is to simply eliminate the term. It does not seem necessary, and perhaps not useful. Note that in routing protocols, neighboring routers announce their presence to each other and may even exchange security information, but these neighbor announcements are not said to create sessions. My 2-level signaling draft simply says: A CSTP module must maintain state that lists the node's neighbors. This state includes the IP address of the neighbor and the local interface used to reach it. This per-neighbor state also includes two Boolean flags giving important properties of the neighbor, e.g., ISPS-capable and Direct-Neighbor. A node builds the neighbor list as a result of receiving CSTP messages. The neighbor list should be implemented as soft state that is deleted if it is not refreshed. Introducing a term like "session" for this neighbor state does not seem to me to add any clarity. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Oct 19 16:24:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07154 for ; Sat, 19 Oct 2002 16:24:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9JKQNG09695 for nsis-archive@odin.ietf.org; Sat, 19 Oct 2002 16:26:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JKQJv09688; Sat, 19 Oct 2002 16:26:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JKP9v09658 for ; Sat, 19 Oct 2002 16:25:09 -0400 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07144 for ; Sat, 19 Oct 2002 16:22:49 -0400 (EDT) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g9JKP0517085; Sat, 19 Oct 2002 13:25:00 -0700 (PDT) Date: Sat, 19 Oct 2002 13:25:00 -0700 (PDT) From: Bob Braden Message-Id: <200210192025.g9JKP0517085@boreas.isi.edu> To: nsis@ietf.org, mshore@cisco.com Subject: Re: [NSIS] Comments on framework draft X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Melinda, Here are a few comments on your questions. *> *> *> ISSUES TO RESOLVE *> ----------------- *> 1) Addressing - hop-by-hop or end-to-end? Yes. ;-) If hop-by-hop, how is it routed? This is a deep question. In fact, NSIS has not even begun to talk about the issue of the interaction of routing and signaling. This is the one major area of IntServ/RSVP that was never satisfactorily answered, because it is a very hard technical problem. *> *> 2) Are "sessions" established between NSIS Entities? Note *> that they don't eliminate state, but just move it to *> another layer - what advantages does this have over the *> more stateless RSVP protocol machinery? I commented separately on this. *> *> 3) Is multicast really out of scope? *> It would be good if the NSIS result was not actively hostile to multicasting as an option. That is, a multicast extension could be engineered later without extreme trauma on the underlying mechanisms. RSVP1 shows us about the resulting additional complexity, while substantial, should not be outrageous. *> 4) receiver-oriented vs. sender-oriented Receive-initiated vs. sender-initiated, I think. (The discussion of this in the Requirements doc seemed to me to be confused. RSVP1 does receiver-initiated reservations.) *> *> 5) Will NFs be able to request, release, or modify *> reservations (either initiate requests or modify existing *> requests in transit)? *> *> 6) Is the use of periodic refresh messages the primary means *> of installing state? Should these messages be *> idempotent? *> I didn't think this was even a question any more. (I assume the question you are asking is: can we get along without reliable delivery of trigger messages, instead depending upon refresh messages for reliability?) The vendors doing (or considering) implementation of RSVP1 certainly said "NO!". That is, the signaling protocol has to at least include the option of reliable delivery. *> 7) Rely on internal or external security mechanisms? (Can *> we punt on this until we know more about the protocol?) *> The general security issues are pretty much independent of the protocol details, I would claim. They are also hard, if you go beyond the hop/hop security of RSVP1. You could have broadened your question from "security" to "policy". Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Oct 19 19:18:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08807 for ; Sat, 19 Oct 2002 19:18:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9JNJup16022 for nsis-archive@odin.ietf.org; Sat, 19 Oct 2002 19:19:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JNJrv15998; Sat, 19 Oct 2002 19:19:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JNISv15965 for ; Sat, 19 Oct 2002 19:18:28 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08791 for ; Sat, 19 Oct 2002 19:16:06 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT6CJX>; Sun, 20 Oct 2002 00:18:14 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5B1F@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden , nsis@ietf.org, mshore@cisco.com Date: Sun, 20 Oct 2002 00:18:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [NSIS] an nsis security assumption? (was: RE: Comments on framework draf t) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi all, a quick comment on melinda's Q7: [snip] > [Melinda] > *> 7) Rely on internal or external security mechanisms? (Can > *> we punt on this until we know more about the protocol?) > *> > [Bob] > The general security issues are pretty much independent > of the protocol details, I would claim. They are also hard, > if you go beyond the hop/hop security of RSVP1. > > You could have broadened your question from "security" to "policy". > > Bob Braden [reh] for what it's worth [?] the current working assumption in the framework document is that security at the basic NSIS [cstp-like] layer is purely local ("hop by hop") and is limited to various aspects of message protection and the authentication needed to support it. any policy/authorisation issues are assumed to be so signalling application specific that they might as well be handled in the layer above, where non-local-scope aspects might also be considered. my understanding is that this is pretty well the same as the functionality division between 2747 and 2750 in RSVP1. i guess we're assuming that nothing since then has suggested the split should be changed (in particular, that there is no point in trying to define a more powerful 'security' capability within the base NSIS protocol). robert h. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Oct 19 19:18:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08820 for ; Sat, 19 Oct 2002 19:18:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9JNJwD16047 for nsis-archive@odin.ietf.org; Sat, 19 Oct 2002 19:19:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JNJuv16013; Sat, 19 Oct 2002 19:19:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JNIdv15972 for ; Sat, 19 Oct 2002 19:18:39 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08796 for ; Sat, 19 Oct 2002 19:16:17 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT6CJZ>; Sun, 20 Oct 2002 00:18:23 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5B20@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden , mshore@cisco.com, nsis@ietf.org Date: Sun, 20 Oct 2002 00:18:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [NSIS] drop the term session? (was: RE: Comments on framework draft) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi all, > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: 19 October 2002 21:06 > To: mshore@cisco.com; nsis@ietf.org; Hancock, Robert > Subject: RE: [NSIS] Comments on framework draft > > > > *> > *> > > *> > 2) Are "sessions" established between NSIS Entities? Note > *> > that they don't eliminate state, but just move it to > *> > another layer - what advantages does this have over the > *> > more stateless RSVP protocol machinery? > *> [reh] all 'session' is is a name for whatever protocol > layer state is established between NSIS peers. this could be > very small (nothing), just next/previous hop id (like RSVP), > or quite complex (including security information). > *> > *> the relative amounts of state in NSIS protocol vs. > signalling applications is a very good question, as is > working out how it can be minimised. i don't personally > expect it can be eliminated in a real protocol, but nothing is fixed. > *> > *> (people are free to suggest a less loaded term than 'session'.) > *> > > I suggest that the solution is to simply eliminate the term. It does > not seem necessary, and perhaps not useful. Note that in routing > protocols, neighboring routers announce their presence to each other > and may even exchange security information, but these neighbor > announcements are not said to create sessions. My 2-level signaling > draft simply says: > > > A CSTP module must maintain state that lists the node's > neighbors. > This state includes the IP address of the neighbor and the local > interface used to reach it. This per-neighbor state > also includes > two Boolean flags giving important properties of the neighbor, > e.g., ISPS-capable and Direct-Neighbor. A node builds the > neighbor list as a result of receiving CSTP messages. The > neighbor list should be implemented as soft state that > is deleted > if it is not refreshed. > > Introducing a term like "session" for this neighbor state does not > seem to me to add any clarity. > > Bob Braden > how about: where we use 'peer session' as a noun, replace it with 'peer relationship' (probably a better term anyway, as well as less loaded); replace 'peer session addressing' with 'peer-peer addressing'. the abstract fact of there being some relationship is in any case more important than any specific state information. [why not just say "hop by hop"? that's the term i used to use, but i was then assailed by people who claimed i was talking about IP hops. sometimes you can't win.] cheers, robert h. > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Oct 19 19:18:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08833 for ; Sat, 19 Oct 2002 19:18:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9JNJxw16059 for nsis-archive@odin.ietf.org; Sat, 19 Oct 2002 19:19:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JNJvv16040; Sat, 19 Oct 2002 19:19:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9JNIev15976 for ; Sat, 19 Oct 2002 19:18:40 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08799 for ; Sat, 19 Oct 2002 19:16:18 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT6CJY>; Sun, 20 Oct 2002 00:18:14 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5B1E@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden Cc: nsis@ietf.org Subject: RE: [NSIS] on-path versus off-path discussion Date: Sun, 20 Oct 2002 00:18:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Bob, [snip] > RSVP established a meaning for "path". I fail to see why NSIS should > try to (re-)invent terminology. [reh] I don't think NSIS is trying to invent a new definition. > > *> what the *nsis* w.g. needs to be clear about (as melinda > has pointed out) is what definition we agree on, and then > (implicitly) what is currently in or out of NSIS scope. (i > guess this would also be useful input to discussing the scope > of any complementary or additional activity.) > *> > *> a proposed definition is on the table in 3.2.1 of > draft-ietf-nsis-fw-00.txt ("path coupled/decoupled"). as a > teaser, this definition would classify both RSVP PATH and > RESV messages as path coupled, and therefore legitimately in > NSIS scope (even though the latter uses what we call > peer-session and not end-to-end addressing). > > I believe that your term has the same meaning as the term I already > introduced in my 2-level signaling I-D, "path-directed [signaling]". > Again, why should we have to keep re-inventing terminology? [reh] there is no intended difference, just an attempt to pin down some of the corner cases which some people were unclear about. (the only reason for using 'path-coupled' is that 'path-decoupled' sounds OK as a term for the opposite, which we also needed.) > > Bob Braden > cheers, robert h. ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Oct 19 20:04:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09397 for ; Sat, 19 Oct 2002 20:04:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9K069717476 for nsis-archive@odin.ietf.org; Sat, 19 Oct 2002 20:06:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9K067v17469; Sat, 19 Oct 2002 20:06:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9K05ov17450 for ; Sat, 19 Oct 2002 20:05:50 -0400 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09379 for ; Sat, 19 Oct 2002 20:03:28 -0400 (EDT) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g9K05cI00271; Sat, 19 Oct 2002 17:05:38 -0700 (PDT) Date: Sat, 19 Oct 2002 17:05:38 -0700 (PDT) From: Bob Braden Message-Id: <200210200005.g9K05cI00271@boreas.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, mshore@cisco.com, robert.hancock@roke.co.uk X-Sun-Charset: US-ASCII Subject: [NSIS] Re: an nsis security assumption? (was: RE: Comments on framework draf t) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> > *> [Melinda] *> > *> 7) Rely on internal or external security mechanisms? (Can *> > *> we punt on this until we know more about the protocol?) *> > *> *> > *> [Bob] *> > The general security issues are pretty much independent *> > of the protocol details, I would claim. They are also hard, *> > if you go beyond the hop/hop security of RSVP1. *> > *> > You could have broadened your question from "security" to "policy". *> > *> > Bob Braden *> *> [reh] for what it's worth [?] the current working assumption in the framework document is that security at the basic NSIS [cstp-like] layer is purely local ("hop by hop") and is limited to various aspects of message protection and the authentication needed to support it. *> *> any policy/authorisation issues are assumed to be so signalling application specific that they might as well be handled in the layer above, where non-local-scope aspects might also be considered. *> *> my understanding is that this is pretty well the same as the functionality division between 2747 and 2750 in RSVP1. i guess we're assuming that nothing since then has suggested the split should be changed (in particular, that there is no point in trying to define a more powerful 'security' capability within the base NSIS protocol). *> Robert, Yes, all you say is true, and this division is the best I know how to do about signaling security. Yet security is still a hard problem, and maybe we need some other approach; I am not sure. Bob *> robert h. *> > _______________________________________________ *> > nsis mailing list *> > nsis@ietf.org *> > https://www1.ietf.org/mailman/listinfo/nsis *> > *> > *> ======================================================================================== *> Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Oct 20 23:19:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07839 for ; Sun, 20 Oct 2002 23:19:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9L3Lmi24536 for nsis-archive@odin.ietf.org; Sun, 20 Oct 2002 23:21:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L3Liv24531; Sun, 20 Oct 2002 23:21:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9KHr8v03464 for ; Sun, 20 Oct 2002 13:53:08 -0400 Received: from pimout2-ext.prodigy.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00804 for ; Sun, 20 Oct 2002 13:50:49 -0400 (EDT) Received: from ciena.com (adsl-64-175-244-154.dsl.sntc01.pacbell.net [64.175.244.154]) by pimout2-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9KHqwcK258138; Sun, 20 Oct 2002 13:53:03 -0400 Message-ID: <3DB2ED7E.9060801@ciena.com> Date: Sun, 20 Oct 2002 10:53:02 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: [NSIS] on-path versus off-path discussion References: <76C92FBBFB58D411AE760090271ED41805DF5B1E@rsys002a.roke.co.uk> 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 Actually why not take a look what GMPLS has done? In optical networks, a control channel is used to control multiple data channels. In GMPLS, RSVP and OSPF messages are going back and forth to deal with a bunch of physical trunks. In cases where NSIS are trying to do, this can be helpful... I know, people will think of SS7... sorry! :-) In terms of reinventing wheels, try not to reinvent both terminology (which personally I don't think any engineer really cares), and mechanisms. Thanks! - Ping Hancock, Robert wrote: > Hi Bob, > > [snip] > >>RSVP established a meaning for "path". I fail to see why NSIS should >>try to (re-)invent terminology. > > [reh] I don't think NSIS is trying to invent a new definition. > > >> *> what the *nsis* w.g. needs to be clear about (as melinda >>has pointed out) is what definition we agree on, and then >>(implicitly) what is currently in or out of NSIS scope. (i >>guess this would also be useful input to discussing the scope >>of any complementary or additional activity.) >> *> >> *> a proposed definition is on the table in 3.2.1 of >>draft-ietf-nsis-fw-00.txt ("path coupled/decoupled"). as a >>teaser, this definition would classify both RSVP PATH and >>RESV messages as path coupled, and therefore legitimately in >>NSIS scope (even though the latter uses what we call >>peer-session and not end-to-end addressing). >> >>I believe that your term has the same meaning as the term I already >>introduced in my 2-level signaling I-D, "path-directed [signaling]". >>Again, why should we have to keep re-inventing terminology? > > > [reh] there is no intended difference, just an attempt to pin down some of the corner cases which some people were unclear about. (the only reason for using 'path-coupled' is that 'path-decoupled' sounds OK as a term for the opposite, which we also needed.) > >>Bob Braden >> > > > cheers, > > robert h. > > ======================================================================================== > Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. > > > ------------------------------------------------------------------------ > > 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 mailnull@www1.ietf.org Sun Oct 20 23:20:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07852 for ; Sun, 20 Oct 2002 23:20:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9L3Lvd24565 for nsis-archive@odin.ietf.org; Sun, 20 Oct 2002 23:21:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L3Lrv24558; Sun, 20 Oct 2002 23:21:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L2s8v23428 for ; Sun, 20 Oct 2002 22:54:08 -0400 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07535 for ; Sun, 20 Oct 2002 22:51:38 -0400 (EDT) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g9L2rrc17963; Sun, 20 Oct 2002 19:53:53 -0700 (PDT) Date: Sun, 20 Oct 2002 19:53:53 -0700 (PDT) From: Bob Braden Message-Id: <200210210253.g9L2rrc17963@boreas.isi.edu> To: nsis@ietf.org Cc: braden@ISI.EDU X-Sun-Charset: US-ASCII Subject: [NSIS] Some comments on draft-ietf-nsis-req-04.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Friends, Recently John Loughney asked me to review the requirements document, and I have finally found a little time. I am far behind in reading NSIS messages, but I think I have seen that there is some intent to issue a WG last call on this document. (If I am wrong, I apologize). I am afraid that I think that this document is not ready for a last call. Besides many issues of content, its editorial form is far from satisfactory. It would certainly not be acceptable at this point for publication as an RFC, which is presumably the eventual intent of a last call; there are too many confusing, awkward, and/or grammatically incorrect sentences, for one thing. I hope the following comments will be useful. I am aware that they are hastily composed and undoubtedly could benefit from further consideration. I regret mixing together problems at all levels from architectural issues to English composition to editorial nits. However, I believe that the majority of my comments reflect problems that need some kind of fix. These comments are incomplete, but fixing/clarifying the issues marked will be a good step forward. Before I start, let me make a few general comments. 1. I believe that the ADs sent the WG on a Mission Impossible by asking for a requirements document before a framework document. It really is not possible to write a useful requirements document except within the context of an overall signaling architecture, which I believe is what the framework document aspires to provide. Details aside, this is not a bad job of reaching an intrinsically impossible goal. 2. I believe that NSIS will be successful (only) if its product turns out to handle signaling applications that we have not thought of yet. It is not enough in the Internet to handle today's problems; given the rapidly shifting technology, we can survive only if we build protocol structures of sufficient generality to handle tomorrow's problems. 3. In this light, I am concerned with the WG's focusing exclusively on the QoS problem (or the many QoS problems, to be more precise.) A major lesson from RSVP is that we need to think more generally. Here goes. *> *> *> Network Working Group M. Brunner (Editor) *> Internet Draft NEC *> Category: Informational August 2002 *> *> *> *> Requirements for Signaling Protocols "Requirements for Internet Signaling Protocols" *> *> *> Abstract *> *> This document defines requirements for signaling across different *> network environments, where different network environments across *> administrative and technology domains. Huh? *> Signaling is mainly though "The primary focus of this memo is on signaling for QoS; however, there are many other potential applications of Internet signaling. *> for QoS such as [1], however in recent year several other No references in Abstracts. *> applications of signaling have been defined such as signaling for *> MPLS label distribution [2]. To achieve wide applicability of the *> requirements, the starting point is a diverse set of scenarios/use *> cases concerning various types of networks and application *> interactions. We also provide an outline structure for the problem, (Actually it is not very diverse set, but I leave that for later.) *> including related terminology. Taken with the scenarios, this allows *> us to focus more precisely on which parts of the overall problem *> need to be solved. We present the assumptions and the aspects not *> considered within scope before listing the requirements grouped *> according to areas such as architecture and design goals, signaling *> flows, layering, performance, flexibility, security, and mobility. The Abstract is a little mungey, composition-wise. *> *> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", *> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in *> this document are to be interpreted as described in RFC 2119. *> Not in the Abstract! *> Brunner (Editor) Informational [Page 1] *> *> Requirements for Signaling Protocols August 2002 *> *> Table of Contents *> *> Status of this Memo................................................1 *> Abstract...........................................................1 *> Table of Contents..................................................2 *> 1 Introduction...................................................3 *> 2 Terminology....................................................4 *> 3 Problem Statement and Scope....................................6 *> 4 Assumptions and Exclusions.....................................8 *> 4.1 Assumptions and Non-Assumptions..............................8 *> 4.2 Exclusions...................................................9 *> 5 Requirements..................................................11 *> 5.1 Architecture and Design Goals...............................11 Too fine-grained a TOC! *> 5.1.1 MUST be applicable for different technologies...............11 *> 5.1.2 Resource availability information on request................12 *> 5.1.3 NSIS MUST be designed modular...............................12 *> 5.1.4 NSIS MUST decouple protocol and information.................12 *> 5.1.5 NSIS MUST reuse existing QoS provisioning...................12 *> 5.1.6 Independence of signaling and provisioning paradigm.........12 *> 5.1.7 Application independence....................................13 *> 5.2 Signaling Flows.............................................13 *> 5.2.1 Free placement of NSIS Initiator, Forwarder, Responder......13 *> 5.2.2 No constraint of the signaling and NSIS Forwarders to be in *> the data path.....................................................13 *> 5.2.3 Concealment of topology and technology information..........14 *> 5.2.4 Transparency of signaling to network........................14 *> 5.3 Additional information beyond signaling for a service.......14 *> 5.3.1 Explicit release of resources...............................14 *> 5.3.2 Possibility for automatic release of resources after failure15 *> 5.3.3 Notifications sent upstream.................................15 *> 5.3.4 Feedback about success of service request...................16 *> 5.3.5 Local information exchange..................................16 *> 5.4 Control Information.........................................16 *> 5.4.1 Mutability information on parameters........................16 *> 5.4.2 Possibility to add and remove local domain information......17 *> 5.4.3 Independence of reservation identifier......................17 *> 5.4.4 Seamless modification of already reserved resources.........17 *> 5.4.5 Grouping of signaling for several microflows................17 *> 5.5 Performance.................................................17 *> 5.5.1 Scalability.................................................18 *> 5.5.2 Low latency in setup........................................18 *> 5.5.3 Allow for low bandwidth consumption for signaling protocol..18 *> 5.5.4 Ability to constrain load on devices........................18 *> 5.5.5 Highest possible network utilization........................19 *> 5.6 Flexibility.................................................19 *> 5.6.1 Flow aggregation............................................19 *> 5.6.2 Flexibility in the placement of the NSIS Initiator..........19 *> 5.6.3 Flexibility in the initiation of re-negotiation.............19 *> 5.6.4 Uni / bi-directional reservation............................19 *> 5.7 Security....................................................20 *> 5.7.1 Authentication of signaling requests........................20 *> 5.7.2 Resource Authorization......................................20 *> 5.7.3 Integrity protection........................................20 *> 5.7.4 Replay protection...........................................20 *> *> Brunner (Editor) Informational [Page 2] ... *> *> 1 Introduction *> Should start by defining "signaling" (?) *> This document defines requirements for signaling across different " requirements for level 3 signaling" *> network environments. It does not list any problems of existing *> signaling protocols such as RSVP [1]. The last hardly needs to be said; the reader is unlikely to expect that it would. *> *> In order to derive requirements for signaling it is necessary to *> first have a clear idea of the scope within which they are *> applicable. *> *> We describe a set of QoS signaling scenarios and use cases in the XXX XXX XXXXX *> Appendix of that document. These scenarios derive from a variety of this? *> backgrounds, and help obtain a clearer picture of what is in or out *> of scope of the NSIS work. They illustrate the problem of QoS You jumped without explanation into QoS. *> signaling from various perspectives (end-system, access network, *> core network) and for various areas (fixed line, mobile, wireless *> environments). *> *> *> *> Brunner (Editor) Informational [Page 3] *> *> Requirements for Signaling Protocols August 2002 *> *> Based on these scenarios, we are able to define the signaling *> problem on a more abstract level. In Section 3, we thus present a *> simple conceptual model of the signaling problem. Additionally, we *> describe the entities involved in signaling and typical signaling *> paths. In Section 4 we list assumptions and exclusions. Using the 1st person plural here detracts. *> *> The model of Section 3 allows deriving requirements from the *> scenarios presented in the appendix in a coherent and consistent *> manner. Requirements are grouped according to areas such as *> Architecture and design goals, Signaling Flows, Layering, *> Performance, Flexibility, Security and Mobility. *> *> QoS is a pretty large field with a lot of interaction with other *> protocols, mechanisms, applications etc. However, it is not the *> only field where signaling is used in the Internet. Even if this *> requirement documents mainly used QoS as the sample application *> other application should be possible. This is an explanation of scope that needs to be more explicit and perhaps earlier. *> *> It is clear that the subject of QoS is uniquely complex and any XX XX XXXXX XXXX T *uniquely*? , *> investigation could potentially have a very broad scope - so broad *> that it is a challenge to focus work on an area, which could lead to *> a concrete and useful result. This is our motivation for considering *> a set of use cases, which map out the domain of application that we *> want to address. It is also the motivation for defining a problem *> structure, which allows us to state the boundaries of what types of *> functionality to consider, and to list background assumptions. *> *> There are several areas of the requirements related to networking *> aspects which are incomplete, for example, interaction with host and *> site multi-homing, use of anycast services, and so on. These issues *> should be considered in any future analysis work. *> *> 2 Terminology *> *> In the area of Quality of Service (QoS) it is quite difficult and an *> exercise for its own to define terminology. Nevertheless, we tried *> to list the most often used terms in the draft and tried to explain *> them. However, don't be to religious about it, they are not meant to *> prescribe any thing in the draft. But you do prescribe .. to much, in my view. I cannot resist a polemic about bad protocol documentation. There is an increasingly common way to produce totally opaque protocol specifications: instead of a clear, step-by-step explanation of the architectural model, we put in a Terminology section. The naive reader who expects to be able to just read and understand the material, is forced instead into decoding the terms, skipping back and forth to find the definition of the definition of the definition of the definition... It replaces prose by a logical puzzle. *> *> NSIS Domain (ND) - Administrative domain where an NSIS protocol An administrative domain in which an ... *> signals for a resource or set of resources. You are falling right into the QoS-exclusive trap. How about: NSIS Domain - An administrative domain in which an NSIS protocol passes some control information. *> *> NSIS Entity (NE) - the function within a node, which implements an *> NSIS protocol. - the function within a node that implements an We are starting to fall into the habit of calling the signaling protocol NSIS. That does not make any sense to me. NSIS is the name of the WG, but it makes little sense as the name of a protocol. We could have called BGP "Next Step in Routing" (NSIR), but I don't think that would have been useful. What name should we use? Beats me, but we will need a name. Or maybe a bunch of names, if you believe all of the generality later in this document. *> *> NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR, Expand NI and NR here, since they have not yet been defined. *> which may interact with local resource management function (RMF) for Again this is QoS specific... need it more general. *> this purpose. NSIS Forwarder also propagates NSIS signaling further *> through the network. It is responsible for interpreting the *> signaling carrying the user parameters, optionally inserting or User parameters -- defined? The same as "control information" used later? *> modifying the parameters according to domain network management *> policy. *> *> *> Brunner (Editor) Informational [Page 4] *> *> Requirements for Signaling Protocols August 2002 *> *> NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for *> a network resource based on user or application requirements. This *> can be located in the end system, but may reside elsewhere in *> network. *> *> NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and *> can optionally interact with applications as well. *> These definitions are confusing. RSVP initiates signaling from both ends, so by this definition RSVP has an NI and an NR in both sender and receiver (and in fact, I think that's right.) But in several places later in the document this gets confused with which way the reservation/state setup flows. There may be a deep issue here. The WG has a tendency to think only about a simplistic view of signaling as a one-way process. But RSVP showed that some signaling may be essentially two-way, and the protocol needs to be able to handle that when it *is* required. *> Resource Management Function (RMF) - an abstract concept, *> representing the management of resources in a domain or a node. *> *> Egress point: the router via which a path exits a domain/subdomain. *> *> End Host: the end system or host, for whose flows QoS is being *> requested and provisioned. (As worded, precludes edge-to-edge signaling) *> *> End-to-End QoS: the QoS delivered by the network between two *> communicating end hosts. End-to-end QoS co-ordinates and enforces *> predefined traffic management policies across multiple network Predefined?? What doe this sentence mean? *> entities and administrative domains. *> *> Edge-to-edge QoS: QoS within an administrative domain that connects *> to other networks rather than hosts or end systems. *> Define End-to-Edge signaling, which is used later? *> Flow: a traffic stream (sequence of IP packets between two end *> systems) for which a specific level of QoS is to be provided. The *> flow can be unicast (uni- or bi-directional) or multicast. *> *> Higher Layers: the higher layer (transport protocol and application) *> functions that request QoS from the network layer. The request might *> be a trigger generated within the end system, or the trigger might *> be provided by some entity within the network (e.g. application *> proxy or policy server). I suggest that using "higher layer", already overloaded, for the present purpose is a bad idea. This use of the word "trigger" is related to RSVP's usage, but it is not entirely obvious. *> *> Indication: feedback from QoS provisioning to indicate the current *> QoS being provided to a flow or aggregate, and whether any *> violations have been detected by the QoS technology is being used *> within the local domain/subdomain. *> *> Ingress point: the router via which a path enters a *> domain/subdomain. *> *> Path: the route across the networks taken by a flow or aggregate, *> i.e. which domains/subdomains it passes through and the *> egress/ingress points for each. I don't accept this definition; for one thing, it precludes RSVP-style hop/hop signaling. You have to work harder here. *> *> Path segment: the segment of a path within a single *> domain/subdomain. *> *> Control Information: the information the governs for instance the that *> QoS treatment to be applied to a flow or aggregate, including the *> service class, flow administration, and any associated security or *> accounting information. *> Security/accounting == policy, as the IETF defines it. *> *> Brunner (Editor) Informational [Page 5] *> *> Requirements for Signaling Protocols August 2002 *> *> QoS Provisioning: the act of actually allocating resources to a flow *> or aggregate of flows, may include mechanisms such as LSP initiation *> for MPLS, packet scheduler configuration within a router, and so on. *> The mechanisms depend on the overall QoS technology being used *> within the domain. [How] is QoS provisioning different from resource allocation??? *> *> Subdomain: a network within an administrative domain using a uniform *> technology, e.g., a single QoS provisioning function to provision *> resources. *> *> QoS Technology: a generic term for a set of protocols, standards and *> mechanisms that can be used within a QoS domain/subdomain to manage *> the QoS provided to flows or aggregates that traverse the domain. *> Examples might include MPLS, DiffServ, and so on. A QoS technology *> is associated with certain QoS provisioning techniques. *> *> Resource: something of value in a network infrastructure to which *> rules or policy criteria are first applied before access is granted. *> Examples of resources include the buffers in a router and bandwidth *> on an interface. Which rules or policy criteria are used to grant access to buffers? *> *> Resource Allocation: part of a resource that has been dedicated for *> the use of a particular traffic type for a period of time through *> the application of policies. "traffic type" means??? Maybe you mean something more like a flow? *> *> Sender-initiated signaling protocol: A sender-initiated signaling *> protocol is a protocol where the NI initiates the signaling on *> behalf of the sender of the data. What this means is that admission *> control and resource allocation functions are processed from the *> data sender towards the data receiver. However, the triggering *> instance is not specified. I have no idea what the last sentence meant. Except that the definition is QoS-specific, the 2nd sentence here makes some sense. But the use of NI here confuses the definition, as in the RSVP case. *> *> Receiver-initiated signaling protocol: A receiver-initiated *> protocol, (see e.g., RSVP [1]) is a protocol where the NSIS *> Responder on behalf of the receiver of the user data initiates the *> reservations. What this means is that admission control and resource *> allocation functions are processed from the data receiver back *> towards the data sender. However, the triggering instance is not *> specified. *> *> 3 Problem Statement and Scope *> *> We provide in the following a preliminary architectural picture as a *> basis for discussion. We will refer to it in the following *> requirement section. This architectural picture, which seems to be an instance of Lixia Zhang's hierarchical model for resource reservation, would seem to belong in the framework document. It is, I think, QoS-specific, and it may be controversial. Let me suggest an alternative: at this point in the requirements insert a general definition of the two-level model and a discussion of layering issues. I suppose some of the material below could then be included as an example of one way to structure a QoS signaling function. *> *> A set of issues and problems to be solved has been given at a top *> level by the use cases/scenarios of the appendix. However, the *> problem of QoS has an extremely wide scope and there is a great deal *> of work already done to provide different components of the *> solution, such as QoS technologies for example. A basic goal should *> be to re-use these wherever possible, and to focus requirements work *> at an early stage on those areas where a new solution is needed *> *> *> Brunner (Editor) Informational [Page 6] *> *> Requirements for Signaling Protocols August 2002 *> *> (e.g. an especially simple one). We also try to avoid defining *> requirements related to internal implementation aspects. *> *> In this section, we present a simple conceptual model of the overall *> problem in order to identify the applicability to NSIS of *> requirements derived from the use cases, and to clarify the scope of *> the work, including any open issues. This model also identifies *> further sources of requirements from external interactions with *> other parts of an overall solution, clarifies the terminology used, *> and allows the statement of design goals about the nature of the *> solution (see section 5). *> *> Note that this model is intended not to constrain the technical *> approach taken subsequently, simply to allow concrete phrasing of *> requirements (e.g. requirements about placement of the NSIS *> Initiator, or ability to 'drive' particular QoS technologies.) *> *> Roughly, the scope of NSIS is assumed to be the interaction between *> the NSIS Initiator and NSIS Forwarder(s), and NSIS Responder *> including a protocol to carry the information, and the *> syntax/semantics of the information that is exchanged. Further *> statements on assumptions/exclusions are given in the next Section. *> *> The main elements are: *> *> 1. Something that starts the request for resources, the NSIS triggers a? *> Initiator. *> *> This might be in the end system or within some other part of the *> network. The distinguishing feature of the NSIS Initiator is that it *> acts on triggers coming (directly or indirectly) from the higher requests? *> layers in the end systems. It needs to map the resources requested Not necessarily an end system. *> by them, and also provides feedback information to the higher *> layers, which might be used by transport layer rate management or *> adaptive applications. *> *> 2. Something that assists in managing resources further along the *> path, the NSIS Forwarder. *> *> The NSIS Forwarder does not interact with higher layers, but *> interacts with the NSIS Initiator and possibly more NSIS Forwarders *> on the path, edge-to-edge or possibly end-to-end. *> *> 3. The NSIS Initiator and NSIS Forwarder(s) interact with each *> other, path segment by path segment. This interaction involves the *> exchange of data (resources control information) over some signaling *> protocol. *> *> 4. The path segment traverses an underlying network covering one or *> more IP hops. The underlying network uses some local QoS technology. *> This QoS technology has to be provisioned appropriately for the *> service requested. An NSIS Forwarder maps service-specific *> information to technology-related QoS parameters and receiving *> indications about success or failure in response. Maybe this discussion could be clarified by a diagram? Use your term RMF here? *> *> Brunner (Editor) Informational [Page 7] *> *> Requirements for Signaling Protocols August 2002 *> *> *> Now concentrating more on the overall end to end (multiple domain) *> aspects, in particular: *> *> 1. The NSIS Initiator need not be located at an end system, and the *> NSIS Forwarders are not assumed to be located on the flow's data *> path. However, they must be able to identify the ingress and egress *> points for the flow path as it traverses the domain/subdomain. Any *> signaling protocol must be able to find the appropriate NSIS *> Forwarder and carry this ingress/egress point information. *> *> 2. We see the network at the level of domains/subdomains rather than *> individual routers (except in the special case that the domain *> contains one link). Domains are assumed to be administrative *> entities, so security requirements apply to the signaling between *> them. *> *> 3. Any domain may contain Resource Management Function (e.g. to do *> with traffic engineering, admission control, policy and so on). *> These are assumed to interact with the NSIS Initiator and *> Controllers (and end systems) using standard mechanisms. *> *> 4. The placement of the NSIS Initiators and NSIS Forwarders is not *> fixed. *> Yes! I could never figure out why people made such a big deal out of this. The RSVP protocol really does not care whether signaling is initiated; it would have been a simple matter of word-smithing to extend RSVP to cover end-to-edge, edge-to-edge, etc. We get knee-deep in bogus concerns. *> 4 Assumptions and Exclusions *> *> 4.1 Assumptions and Non-Assumptions *> *> 1. The NSIS signaling could run end to end, end to edge, or edge to *> edge, or network-to-network ((between providers), depending on what Yes, of course. *> point in the network acts as the initiator, and how far towards the *> other end of the network the signaling propagates. Although the *> figures show NSIS Forwarders at a very limited number of locations *> in the network (e.g. at domain or subdomain borders, or even *> controlling a complete domain), this is only one possible case. In *> general, we could expect NSIS Forwarders to become more 'dense' *> towards the edges of the network, but this is not a requirement. An *> over-provisioned domain might contain no NSIS Forwarders at all (and *> be NSIS transparent); at the other extreme, NSIS Forwarders might be *> placed at every router. In the latter case, QoS provisioning can be *> carried out in a local implementation-dependent way without further *> signaling, whereas in the case of remote NSIS Forwarders, a *> provisioning protocol might be needed to control the routers along *> the path. This provisioning protocol is then independent of the end- *> to-end NSIS signaling. The last sentence is confusing. *> *> 2. We do not consider 'pure' end-to-end signaling that is not *> interpreted anywhere within the network. Such signaling is an *> application-layer issue and IETF protocols such as SIP etc. can be *> used. *> *> 3. Where the signaling does cover several NSIS domains or XXX crossesXXX *> subdomains, we do not exclude that different signaling protocols are *> *> Brunner (Editor) Informational [Page 8] *> *> Requirements for Signaling Protocols August 2002 *> *> used in each path segment. We only place requirements on the *> universality of the control information that is being transported. *> (The goals here would be to allow the use of signaling protocols, *> which are matched to the characteristics of the portion of the *> network being traversed.) Note that the outcome of NSIS work might *> result in various protocols or various flavors of the same protocol. *> This implies the need for the translation of information into domain *> specific format as well. *> *> 4. We assume that the service definitions a NSIS Initiator can ask *> for are known in advance of the signaling protocol running. Service *> definition includes QoS parameters, lifetime of QoS guarantee etc., *> or any other service-specific parameters. *> *> There are many ways service requesters get to know about it. There *> might be standardized services, the definition can be negotiated *> together with a contract, the service definition is published at a *> Web page, etc. *> *> 5. We assume that there are means for the discovery of NSIS entities There must be ... *> in order to know the signaling peers (solutions include static *> configuration, automatically discovered, or implicitly runs over the *> right nodes, etc.) The discovery of the NSIS entities has security *> implications that need to be addressed properly. These implications *> largely depend on the chosen protocol. For some security mechanisms *> (i.e. Kerberos, pre-shared secret) it is required to know the *> identity of the other entity. Hence the discovery mechanism may *> provide means to learn this identity, which is then later used to *> retrieve the required keys and parameters. *> *> 6. NSIS assumes to operate with networks using standard ("normal") *> L3 routing. Where "normal" is not specified more exactly on purpose. *> *> 4.2 Exclusions *> Are you excluding requirements, or excluding mechanisms? If the latter, this section does not seem to belong in a requirements document. If the former, rephase each in terms of requirements. *> 1. Development of specific mechanisms and algorithms for application *> and transport layer adaptation are not considered, nor are the *> protocols that would support it. *> *> 2. Specific mechanisms (APIs and so on) for interaction between *> transport/applications and the network layer are not considered, *> except to clarify the requirements on the negotiation capabilities *> and information semantics that would be needed of the signaling *> protocol. The same applies to application adaptation mechanisms. *> *> 3. Specific mechanisms for QoS provisioning within a *> domain/subdomain are not considered. However, NSIS can be used for *> signaling within a domain/subdomain performing QoS provisioning. It *> should be possible to exploit these mechanisms optimally within the *> end-to-end context. Consideration of how to do this might generate *> new requirements for NSIS however. For example, the information *> needed by a NSIS Forwarder to manage a radio subnetwork needs to be *> provided by the NSIS solution. *> *> *> Brunner (Editor) Informational [Page 9] *> *> Requirements for Signaling Protocols August 2002 *> *> 4. Specific mechanisms (APIs and so on) for interaction between the *> network layer and underlying QoS provisioning mechanisms are not *> considered. *> *> 5. Interaction with resource management capabilities is not *> considered. Standard protocols should be used for this (e.g. COPS). *> This may imply requirements for the sort of information that should *> be exchanged between the NSIS entities. *> *> 6. Security implications related to multicasting are outside the *> scope of the signaling protocol. *> *> 7. Protection of non-signaling messages is outside the scope of the *> protocol *> *> The protection of non-signaling messages (including data traffic *> following a reservation) is not directly considered by a signaling *> protocol. The protection of data messages transmitted along the *> provisioned path is outside the scope of a signaling protocol. *> Regarding data traffic there is an interaction with accounting *> (metering) and edge routers might require packets to be integrity *> protected to be able to securely assign incoming data traffic to a *> particular user. *> *> Additionally there might be an interaction with IPSec protected *> traffic experiencing QoS treatment and the established state created *> due to signaling. One example of such an interaction is the different *> flow identification with and without IPSec protection. *> *> Many security properties are likely to be application specific and *> may be provided by the corresponding application layer protocol. *> *> 8. Service definitions and in particular QoS classes are out of *> scope. Together with the service definition any definition of *> service specific parameters are not considered in this draft. Only *> the base NSIS signaling protocol for transporting the service *> information are handled. *> *> 9. Similarly, specific methods, protocols, and ways to express *> QoS/service information in the Application/Session level are not *> considered (e.g., SDP, SIP, RTSP, etc.). *> *> 10. The specification of any extensions needed to signal information *> via application level protocols (e.g. SDP), and the mapping on NSIS *> information are considered outside of the scope of NSIS working *> group, as this work is in the direct scope of other IETF working *> groups (e.g. MMUSIC). *> *> 11. Handoff decision and trigger sources: An NSIS protocol is not *> used to trigger handoffs in mobile IP, nor is it used to decide Why not, and who says? *> whether to handoff or not. As soon as or in some situation even *> before a handoff happened, an NSIS protocol might be used for *> signaling for QoS again. However, NSIS MUST interwork with several *> protocols for mobility management. *> *> Brunner (Editor) Informational [Page 10] *> *> Requirements for Signaling Protocols August 2002 *> *> *> 12. QoS monitoring is out of scope. It is heavily dependent on the *> type of the application and or transport service, and in what *> scenario it is used. *> Sounds like a serious omission to me. *> 5 Requirements *> *> This section defines more detailed requirements for a signaling *> solution, derived from consideration of the use cases/scenarios *> described in the appendix, and respecting the framework, scoping *> assumptions, and terminology considered earlier. The requirements *> are in subsections, grouped roughly according to general technical *> aspects: architecture and design goals, topology issues, parameters, *> performance, security, information, and flexibility. *> *> Two general (and potentially contradictory) goals for the solution *> are that it should be applicable in a very wide range of scenarios, *> and at the same time lightweight in implementation complexity and *> resource requirements in nodes. One approach to this is that the *> solution could deal with certain requirements via modular components *> or capabilities, which are optional to implement in individual *> nodes. *> *> Some of the requirements are technically contradictory. Depending on *> the scenarios a solution applies to, one or the other requirement is *> applicable. *> *> In order to prioritize the various requirements we define different *> 'parts of the network'. In the different parts of the network a *> particular requirement might have a different priority. *> *> The parts of the networks we differentiate are the host-to-first *> router, the access network, and the core network. The host to first *> router part includes all the layer 2 technologies to access to the *> Internet. In many cases, there is an application and/or user running *> on the host initiating signaling. The access network can be *> characterized by low capacity links, medium speed IP processing *> capabilities, and it might consist of a complete layer 2 network as *> well. The core network characteristics include high-speed forwarding *> capacities and inter-domain issues. All of them are not strictly *> defined and should not be regarded as that, but should give a Then maybe better not to include something so mushy? *> feeling about where in the network we have different requirements *> concerning signaling. *> *> 5.1 Architecture and Design Goals *> *> This section contains requirements related to desirable overall *> characteristics of a solution, e.g. enabling flexibility, or *> independence of parts of the framework. *> *> 5.1.1 MUST be applicable for different technologies. *> *> The signaling protocol MUST work with various QoS technologies as *> well as other technologies needing signaling. The information *> *> Brunner (Editor) Informational [Page 11] *> *> Requirements for Signaling Protocols August 2002 *> *> exchanged over the signaling protocol must be in such detail and *> quantity that it is useful for various technologies. *> *> 5.1.2 Resource availability information on request *> *> In some scenarios, e.g., the mobile terminal scenario, it is *> required to query, whether resources are available, without *> performing a reservation on the resource. One solution might be a *> feedback mechanism based on which a QoS inferred handover can take *> place. So NSIS SHOULD provide a mechanism to check whether resources *> are available without performing a reservation *> *> 5.1.3 NSIS MUST be designed modular *> *> A modular design allows for more lightweight implementations, if *> fewer features are needed. Mutually exclusive solutions are *> supported. Examples for modularity: Modularity is good, but the following examples bear no relationship to MY idea of "modularity"?! See two-level signaling model for modularity discussion. Also, many of these occur later as requirements. *> *> - Work over any kind of network (narrowband versus broadband, error- *> prone versus reliable, ...). This implies low bandwidth signaling *> and redundant information MUST be supported if necessary. *> *> - Uni- and bi-directional reservations are possible *> *> - Extensible in the future with different add-ons for certain *> environments or scenarios *> *> - Protocol layering, where appropriate. This means NSIS MUST provide *> a base protocol, which can be adapted to different environments. *> *> 5.1.4 NSIS MUST decouple protocol and information Maybe there is a more elegant way to phrase this? *> *> The signaling protocol MUST be clearly separated from the control *> information being transported. This provides for the independent *> development of these two aspects of the solution, and allows for *> this control information to be carried within other protocols, *> including application layer ones, existing ones or those being *> developed in the future. The gained flexibility in the information *> transported allows for the applicability of the same protocol in *> various scenarios. *> *> However, note that the information carried needs to be the *> standardized; otherwise interoperability is difficult to achieve. *> *> 5.1.5 NSIS MUST reuse existing QoS provisioning *> *> Reuse existing functions and protocols for QoS provisioning within a *> domain/subdomain unchanged. (Motivation: 'Don't re-invent the *> wheel'.) *> *> 5.1.6 Independence of signaling and provisioning paradigm *> *> The signaling MUST be independent of the paradigm and mechanism of *> provisioning. E.g., in the case of signaling for QoS, the *> *> Brunner (Editor) Informational [Page 12] *> *> Requirements for Signaling Protocols August 2002 *> *> independence of the signaling protocol from the QoS provisioning *> allows for using the NSIS protocol together with various QoS *> technologies in various scenarios. *> *> 5.1.7 Application independence *> *> The signaling protocol MUST be independent of the application. The *> control information SHOULD be application independent, because we *> look into network level signaling. *> *> The requirement relates to the way the signaling interacts with *> upper layer functions (users, applications, and QoS administration), *> and lower layer QoS technologies. *> *> Opaque application information MAY get transported in the signaling *> message, without being handled in the network. Development and Really?? I suggest you want to think twice about that, and justify it. It certainly mungs the Internet architecture, so yoiu want to be sure there is a strong justification. *> deployment of new applications SHOULD be possible without impacting *> the network infrastructure. *> *> 5.2 Signaling Flows *> *> This section contains requirements related to the possible signaling *> flows that should be supported, e.g. over what parts of the flow *> path, between what entities (end-systems, routers, middle boxes, *> management systems), in which direction. *> *> 5.2.1 Free placement of NSIS Initiator, Forwarder, Responder *> *> The protocol MUST work in various scenarios such as host-to-network- be applicable to various... *> to-host, edge-to-edge, (e.g., just within one providers domain), *> user-to-network (from end system into the network, ending, e.g., at *> the entry to the network and vice versa), and network-to-network *> (e.g., between providers). *> *> Placing the NSIS Forwarder and NSIS Initiator functions at different *> locations allows for various scenarios to work with the same *> protocol. *> *> 5.2.2 No constraint of the signaling and NSIS Forwarders to be in the *> data path. *> *> There is a set of scenarios, where signaling is not on the data *> path. The NSIS Forwarder being in the data path is one extreme case *> and useful in many cases. Therefore the case of having NSIS entities *> on the data path only MUST be allowed. *> *> There are going to be cases where a centralized entity will take a *> decision about service requests. In this case, there is no need to *> have the data follow the signaling path. *> *> There are going to be cases without a centralized entity managing *> resources and the signaling will be used as a tool for resource *> management. For various reasons (such as efficient use of expensive *> *> *> Brunner (Editor) Informational [Page 13] *> *> Requirements for Signaling Protocols August 2002 *> *> bandwidth), one will want to have fine-grained, fast, and very *> dynamic control of the resources in the network. *> *> There are going to be cases where there will be neither signaling *> nor a centralized entity (over-provisioning). Nothing has to be done *> anyway. *> *> One can capture the requirement with the following, different *> wording: If one views the domain with a QoS technology as a virtual *> router then NSIS signaling used between those virtual routers MUST *> follow the same path as the data. *> *> Routing the signaling protocol along an independent path is desired *> by network operators/designers. Ideally, the capability to route the !! This is a statement without proof, and probably without relevance. You may be able to justify off-path signaling by architectural argument about the cleanest/most robust/... way to accomplish some desirable goal. But claiming that some people want it, without any technical justification, is not appropriate. *> protocol along an independent path would give the network *> designer/operator the option to manage bandwidth utilization through *> the topology. *> *> There are other possibilities as well. An NSIS protocol MUST accept *> all of these possibilities with a strong focus on the on-path *> signaling. *> *> 5.2.3 Concealment of topology and technology information *> *> The NSIS protocol SHOULD allow for hiding the internal structure of *> a NSIS domain from end-nodes and from other networks. Hence an *> adversary should not be able to learn the internal structure of a *> network with the help of the signaling protocol. *> I think these security requirements need a LOT more thought! It is very unclear to me that 5.2.3 is a reasonable requirement, except in the context of the hierarchical model of section 3. *> In various scenarios, topology information SHOULD be hidden for *> various reasons. From a business point of view, some administrations *> don't want to reveal the topology and technology used. *> *> 5.2.4 Transparency of signaling to network *> *> It SHOULD be possible that the signaling for some flows traverse *> path segments transparently, i.e., without interpretation at NSIS *> Forwarders within the network. An example would be a subdomain *> within a core network, which only interpreted signaling for *> aggregates established at the domain edge, with the flow-related *> signaling passing transparently through it. *> *> In other words, NSIS SHOULD work in hierarchical scenarios, where *> big pipes/trunks are setup using NSIS signaling, but also flows *> which run within that big pipe/trunk are setup using NSIS. This hierarchical model deserves discussion, maybe even a diagram, in section 3. *> *> 5.3 Additional information beyond signaling for a service *> *> 5.3.1 Explicit release of resources *> *> When a resource reservation is no longer necessary, e.g. because the *> application terminates, or because a mobile host experienced a hand- *> *> *> *> Brunner (Editor) Informational [Page 14] *> *> Requirements for Signaling Protocols August 2002 *> *> off, it MUST be possible to explicitly release resources. In general *> explicit release enhances the overall network utilization. *> *> 5.3.2 Possibility for automatic release of resources after failure *> *> When the NSIS Initiator goes down, the resources it requested in the *> network SHOULD be released, since they will no longer be necessary. *> *> After detection of a failure in the network, any NSIS *> Forwarder/Initiator MUST be able to release a reservation it is *> involved in. For example, this may require signaling of the "Release *> after Failure" message upstream as well as downstream, or soft state *> timing out of reservations. *> *> The goal is to prevent stale state within the network and adds *> robustness to the operation of NSIS. So in other words, an NSIS *> signaling protocol or mechanisms MUST provide means for an NSIS *> entity to discover and remove local stale state. *> *> Note that this might need to work together with a notification *> mechanism. *> Is this section hinting at soft state? Please clarify. *> 5.3.3 Notifications sent upstream *> *> NSIS Forwarders SHOULD be able to notify the NSIS Initiator or any *> other NSIS Forwarder upstream, if there is a state change inside the *> network. There are various types of network changes for instance *> among them: *> Why should an initator always be notified of a failure, even when the network (routing) is able to recover internally without disturbing the QoS? *> Recoverable errors: the network nodes can locally repair this type *> error. The network nodes do not have to notify the users of the *> error immediately. This is a condition when the danger of *> degradation (or actual short term degradation) of the provided QoS *> was overcome by the network (NSIS Forwarder) itself. *> Isn't recovery from errors an L3 routing problem? The relation to signaling is more subtle than reflected here. Maybe you need to distinguish data forwarding failures (ie., routing) from QoS failures (in normal cases, I would expect the latter to be must less common than the former.) *> Unrecoverable errors: the network nodes cannot handle this type of *> error, and have to notify the users as soon as possible. (If they can reach the users.) BTW, what is a "user" here? Not a defined term in this document. *> *> QoS degradation/severe congestion: In case the service cannot be *> provided completely but partially only. *> *> Repair indication: If an error occurred and it has been fixed, this *> triggers the sending of a notification. *> *> Service upgrade available: If a previously requested better service *> becomes available. *> *> The content of the notification is very service specific, but it is *> must at least carry type information. Additionally, it may carry the *> location of the state change. *> *> The notifications may or may not be in response to a NSIS message. *> This means an NSIS entity has to be able to handle notifications at *> any time. *> *> Brunner (Editor) Informational [Page 15] *> *> Requirements for Signaling Protocols August 2002 *> *> *> Note however, that there are a number of security consideration *> needs to be solved with notification, even more important if the *> notification is sent without prior request (asynchronously). The *> problem basically is, that everybody could send notifications to any *> NSIS entity and the NSIS entity most likely reacts on the *> notification. E.g., if it gets an error notification it might *> teardown the reservation, even if everything is ok. So the *> notification might depend on security associations between the *> sender of the notification and its receiver. If a hop-by-hop *> security mechanism is chosen, this implies also that notifications *> need to be sent on the reverse path. *> *> 5.3.4 Feedback about success of service request *> *> A request for service MUST be answered at least with yes or no. *> However, it MAY be useful in case of a negative answer to also get a *> description of what amount of resources a request is possible. So an *> opaque element MAY be included into the answer. The element heavily *> depends on the service requested. *> *> 5.3.5 Local information exchange *> *> The signaling protocol MUST be able to exchange local information *> between NSIS Forwarders located within one single administrative *> domain. Local information might, for example, be IP addresses, *> severe congestion notification, notification of successful or *> erroneous processing of signaling messages. *> *> In some cases, the NSIS signaling protocol MAY carry identification *> of the NSIS Forwarders located at the boundaries of a domain. *> However, the identification of edge should not be visible to the end *> host (NSIS Initiator) and only applies within one administrative *> domain. *> *> 5.4 Control Information *> *> This section contains requirements related to the control *> information that needs to be exchanged. *> *> 5.4.1 Mutability information on parameters *> *> It SHOULD be possible for the NSIS initiator to control the *> mutability of the signaled information. This prevents from being *> changed in a non-recoverable way. The NSIS initiator SHOULD be able *> to control what is requested end to end, without the request being *> gradually mutated as it passes through a sequence of domains. This *> implies that in case of changes made on the parameters, the original *> requested ones must still be available. *> *> Note that we do not require anything about particular parameters *> being changed. *> I have no idea what this section is talking about. Could you explain in terms of RSVP, for example? *> *> *> Brunner (Editor) Informational [Page 16] *> *> Requirements for Signaling Protocols August 2002 *> *> Additionally, note that a provider or that particular services *> requested, can still influence the QoS provisioning but in the *> signaling message the request should stay the same. *> *> 5.4.2 Possibility to add and remove local domain information *> *> It SHOULD be possible for the Resource Management Function to add *> and remove local scope elements. E.g., at the entrance to a domain *> domain-specific information is added, which is used in this domain *> only, and the information is removed again when a signaling message *> leaves the domain. The motivation is in the economy of re-use the *> protocol for domain internal signaling of various information *> pieces. Where additional information is needed within a particular *> domain, it should be possible to carry this at the same time as the *> end-to-end information. *> This gets into an architectural issue. "Re-use" means? It could be the same protocol used hierarchically (as in the adaptation of RSVP to the Subnet Bandwidth Manager for 802 signaling). However, it seems to mean that the same signaling messages carry "inner" and "outer" signling requests. This sounds tricky and needs some careful thought. Decoupling into two protocols, or two instances of the same protocol, may be a sounder architecture with fewer feature interactions. *> 5.4.3 Independence of reservation identifier *> *> A reservation identifier, which is independent of the flow *> identifier (flow end-points), MUST be used. Various scenarios in the *> mobility area require this independence because flows resulting from *> handoff might have changed end-points etc. but still have the same *> service requirement. Also several proxy-based signaling methods *> might profit from such as independence. The semantics of this identifier needs to be precisely defined. It is unclear whether it needs to be used E-E, or only in the mobile domain. *> *> 5.4.4 Seamless modification of already reserved resources *> *> In many case, the reservation needs to be updated (up or downgrade). *> This SHOULD happen seamlessly without service interruption. At least *> the signaling protocol should allow for it, even if some data path *> elements might not be capable of doing so. *> *> 5.4.5 Grouping of signaling for several micro-flows *> *> NSIS MAY group signaling information for several micro-flow into one *> signaling message. The goal of this is the optimization in terms of *> setup delay, which can happen in parallel. This helps applications *> requesting several flows at once. Also potential refreshes (in case *> of a soft state solution) might profit of grouping. I believe we have a term for this in RSVP; it is called bundling. *> *> However, the network MUST NOT know that a relationship between the *> grouped flows exists. There MUST NOT be any transactional semantic *> associated with the grouping. It is only meant for optimization *> purposes and each reservation MUST be handled separately from each *> other. *> *> 5.5 Performance *> *> This section discusses performance requirements and evaluation *> criteria and the way in which these could and should be traded off *> against each other in various parts of the solution. *> *> Scalability is a must anyway. However, depending on the scenario the XXXXXX *> question to which extends the protocol must be scalable. *> *> Brunner (Editor) Informational [Page 17] *> *> Requirements for Signaling Protocols August 2002 *> *> *> Note that many of the performance issues are heavily dependent on *> the scenario assumed and are normally a trade-off between speed, *> reliability, complexity, and scalability. The trade-off varies in *> different parts of the network. For example, in radio access *> networks low bandwidth consumption will overweight the low latency *> requirement, while in core networks it may be reverse. *> *> 5.5.1 Scalability *> *> NSIS MUST be scalable in the number of messages received by a *> signaling communication partner (NSIS Initiator, NSIS Forwarder, and *> NSIS Responder). The major concern lies in the core of the network, *> where large numbers of messages arrive. *> What does "scalable in" mean, exactly? This statement as written has no content at all, I am afraid. Can you give an example of an architectural design that would NOT satisfy this requirement, for example? *> It MUST be scalable in number of hand-offs in mobile environments. *> This mainly applies in access networks, because the core is *> transparent to mobility in most cases. *> Ditto. *> It MUST be scalable in the number of interactions for setting up a *> reservation. This applies for end-systems setting up several *> reservations. Some servers might be expected to setup a large number *> of reservations. *> Ditto. *> Scalability in the number of state per entity MUST be achieved for *> NSIS Forwarders in the core of the network. *> Ditto. *> And Scalability in CPU use MUST be achieved on end terminals in case *> of many reservations at the same time and intermediate nodes mainly *> in the core. *> I am REALLY confused by scalability in CPU use. How can it NOT be scalable in CPU use?? *> 5.5.2 Low latency in setup *> *> NSIS SHOULD allow for low latency setup of reservations. This is *> only needed in scenarios, where reservations are in a short time *> scale (e.g. handover in mobile environments), or where human *> interaction is immediately concerned (e.g., voice communication *> setup delay). *> *> 5.5.3 Allow for low bandwidth consumption for signaling protocol *> *> NSIS MUST allow for low bandwidth consumption in certain access *> networks. Again only small sets of scenarios call for low bandwidth, *> mainly those where wireless links are involved. *> *> 5.5.4 Ability to constrain load on devices *> *> The NSIS architecture SHOULD give the ability to constrain the load *> (CPU load, memory space, signaling bandwidth consumption and *> signaling intensity) on devices where it is needed. One of the *> reasons is that the protocol handling should have a minimal impact *> on interior (core) nodes. *> *> *> *> Brunner (Editor) Informational [Page 18] *> *> Requirements for Signaling Protocols August 2002 *> *> This can be achieved by many different methods. Examples, and this *> are only examples, include message aggregation, by ignoring *> signaling message, header compression, or minimizing functionality. *> The framework may choose any method as long as the requirement is *> met. *> *> 5.5.5 Highest possible network utilization *> *> There are networking environments that require high network *> utilization for various reasons, and the signaling protocol SHOULD *> to its best ability support high resource utilization while *> maintaining appropriate QoS. What does this mean, and what can a signaling protocol do/not do to achieve it? It seems to me to depend rather upon the QoS technology, which I believe is out of scope. *> *> In networks where resources are very expensive (as is the case for *> many wireless networks), efficient network utilization is of *> critical financial importance. On the other hand there are other *> parts of the network where high utilization is not required. *> *> 5.6 Flexibility *> *> This section lists the various ways the protocol can flexibly be *> employed. *> *> 5.6.1 Flow aggregation *> *> NSIS MUST allow for flow aggregation, including the capability to *> select and change the level of aggregation. *> *> 5.6.2 Flexibility in the placement of the NSIS Initiator *> *> NSIS MUST be flexible in placing an NSIS Initiator. The NSIS *> Initiator might be the sender or the receiver of content. But also *> network-initiated reservations MUST be available in various *> scenarios such as PSTN gateways, some VPNs, and mobility. *> Is this maybe the 3rd time you've said this? *> 5.6.3 Flexibility in the initiation of re-negotiation *> *> The sender or the receiver of content SHOULD be able to initiate a *> re-negotiation or change the reservation due to various reasons, *> such as local resource shortage (CPU, memory on end-system) or a *> user changed application preference/profiles. But also network- *> initiated re-negotiation SHOULD be supported in cases, where the *> network is not able to further guarantee resources etc. *> *> 5.6.4 Uni / bi-directional reservation *> *> Both unidirectional as well as bi-direction reservations SHOULD be *> possible. With bi-directional reservations we mean here reservations *> having the same end-points. But the path in the two directions does *> not need to be the same. *> ?? Incomplete definition *> *> *> *> *> Brunner (Editor) Informational [Page 19] *> *> Requirements for Signaling Protocols August 2002 *> *> The goal of a bi-directional reservation is mainly an optimization *> in terms of setup delay. There is no requirements on constrains such x or constraint *> as use the same data path etc. *> Note that a bi-directional setup seems to further confuse the definitions of NI, NR, sender-initiation, and receiver-initiation. *> 5.7 Security *> *> This section discusses security-related requirements. For a *> discussion of security threats see [3]. The NSIS protocol MUST *> provide means for security, but it MUST be allowed that nodes *> implementing NSIS signaling do not need use the security means. *> *> 5.7.1 Authentication of signaling requests *> *> A signaling protocol MUST make provision for enabling various *> entities to be authenticated against each other using strong *> authentication mechanisms. The term strong authentication points to *> the fact that weak plain-text password mechanisms must not be used *> for authentication. *> *> 5.7.2 Resource Authorization *> *> The signaling protocol MUST provide means to authorize resource *> requests. This requirement demands a hook to interact with a policy *> entity to request authorization data. This allows an authenticated *> entity to be associated with authorization data and to verify the *> resource request. Authorization prevents reservations by unauthorized *> entities, reservations violating policies, and theft of service. *> Additionally it limits denial of service attacks against parts of the *> network or the entire network caused by unrestricted reservations. *> Additionally it might be helpful to provide some means to inform *> other protocols of participating nodes within the same administrative *> domain about a previous successful authorization event. *> *> 5.7.3 Integrity protection *> *> The signaling protocol MUST provide means to protect the message *> payloads against modifications. Integrity protection prevents an *> adversary from modifying parts of the signaling message and from *> mounting denial of service or theft of service type of attacks *> against network elements participating in the protocol execution. *> *> 5.7.4 Replay protection *> *> To prevent replay of previous signaling messages the signaling *> protocol MUST provide means to detect old i.e. already transmitted *> signaling messages. A solution must cover issues of synchronization *> problems in the case of a restart or a crash of a participating *> network element. The use of replay mechanism apart from sequence *> numbers should be investigated. How about old duplicate signaling packets? *> *> 5.7.5 Hop-by-hop security *> *> Hop-by-Hop security SHOULD be supported. It is a well known and *> proven concept in Quality-of-Service and other signaling protocols *> *> Brunner (Editor) Informational [Page 20] *> *> Requirements for Signaling Protocols August 2002 *> *> that allows intermediate nodes that actively participate in the *> protocol to modify the messages as it is required by processing rule. *> Note that this requirement does not exclude end-to-end or network-to- *> network security of a signaling message. End-to-end security between *> the initiator and the responder may be used to provide protection of *> non-mutable data fields. Network-to-network security refers to the *> protection of messages over various hops but not in an end-to-end *> manner i.e. protected over a particular network. *> *> 5.7.6 Identity confidentiality and location privacy *> *> Identity confidentiality SHOULD be supported. It enables privacy and *> avoids profiling of entities by adversary eavesdropping the signaling *> traffic along the path. The identity used in the process of *> authentication may also be hidden to a limited extent from a network *> to which the initiator is attached. However the identity MUST provide *> enough information for the nodes in the access network to collect *> accounting data. *> Location privacy MAY be supported. It is an issue for the initiator *> who triggers the signaling protocol. In some scenarios the initiator *> may not be willing to reveal location information to the responder as *> part the signaling procedure. *> *> 5.7.7 Denial-of-service attacks *> *> A signaling protocol SHOULD provide prevention of DoS attacks. *> To effectively prevent denial-of-service attacks it is necessary that *> the used security and protocol mechanisms MUST have low computation *> complexity to verify a resource request prior authenticating the *> requesting entity. Additionally the signaling protocol and the used *> security mechanisms SHOULD NOT require large resource consumption *> (for example main memory or other additional message exchanges) *> before a successful authentication was done. Good luck!! *> *> 5.7.8 Confidentiality of signaling messages *> *> Based on the signaling information exchanged between nodes *> participating in the signaling protocol an adversary may learn both *> the identities and the content of the signaling messages. To prevent *> this from happening, confidentiality of the signaling message in a *> hop-by-hop manner MAY be provided. Note that the protection can be *> provided on a hop-by-hop basis for most message payloads since it is *> required that entities which actively participating in the signaling *> protocol must be able to read and eventually modify the content of *> the signaling messages. *> *> 5.7.9 Ownership of a reservation *> *> When existing reservations have to be modified then there is a need *> to use a reservation identifier to uniquely identify the established *> state. A signaling protocol MUST provide the appropriate security *> protection to prevent other entities to modify state without having *> the proper ownership. *> This appears to be identical in meaning to 5.7.1, and therefore redundant. *> *> Brunner (Editor) Informational [Page 21] *> *> Requirements for Signaling Protocols August 2002 *> *> 5.7.10 Hooks with Authentication and Key Agreement protocols *> *> This requirement covers two subsequent steps before a signaling *> protocol is executed and the required hooks. First there is a need to , *> agree on a specific authentication protocol. Later this protocol is *> executed and provides authentication and establishes the desired *> security associations. Using these security associations it is then *> possible to exchange secured signaling messages. *> *> The signaling protocol implementation SHOULD provide hooks to *> interact with protocols that allow the negotiation of authentication *> and key agreement protocols. Although the negotiation of an *> authentication and key management protocol within the signaling *> protocol may be outside the scope it is still required to trigger *> this exchange in case that no such security association is available. *> This requirement originates from the fact that more than one key *> management protocol may be used to provide a security association for *> the signaling protocol. Hence the communicating entities must be *> capable to agree on a specific authentication. The selected *> authentication and key agreement protocol must however be able to *> create a security association that can be used within the signaling *> protocol. *> *> Key management protocols typically require a larger number of *> messages to be transmitted to allow a session key and the *> corresponding security association to be derived. To avoid the *> complex issue of embedding individual authentication and key *> agreement protocols into a specific signaling protocol it is required *> that most of these protocols are executed independently (prior to the *> signaling protocol) and although the key management protocol may be *> independent there must be a way for the signaling protocol to access *> and use available (i.e. already established) security associations to *> avoid executing a separate key management protocol (or instance of *> the same protocol) for protocols that closely operate together. If no *> such security association exists then there SHOULD be means for the *> signaling protocol to dynamically trigger such a protocol. *> *> 5.8 Mobility *> *> 5.8.1 Allow efficient QoS re-establishment after handover *> *> Handover is an essential function in wireless networks. After *> handover, the reservation may need to be completely or partially re- *> established due to route changes. The re-establishment may be *> requested by the mobile node itself or triggered by the access point *> that the mobile node is attached to. In the first case, the *> signaling MUST allow efficient re-establishment after handover. Re- *> establishment after handover MUST be as quick as possible so that "As quick as possible" .. A MUST is a little harsh for so ill-defined a requirement. *> the mobile node does not experience service interruption or service *> degradation. The re-establishment SHOULD be localized, and not *> require end-to-end signaling. *> *> *> *> *> Brunner (Editor) Informational [Page 22] *> *> Requirements for Signaling Protocols August 2002 *> *> 5.9 Interworking with other protocols and techniques *> *> Hooks SHOULD be provided to enable efficient interworking between *> various protocols and techniques including: *> *> 5.9.1 MUST interwork with IP tunneling *> *> IP tunneling for various applications MUST be supported. More *> specifically tunneling for IPSec tunnels are of importance as *> discussed in Section 4.2. This mainly impacts the identification of *> flows. Using IPSec parts of information used for flow identification *> (e.g. transport protocol information and ports) may not be accessible *> due to encryption. *> *> 5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6 *> *> 5.9.3 MUST be independent from charging model *> *> Signaling MUST NOT be constrained by charging models or the charging *> infrastructure used. *> *> 5.9.4 SHOULD provide hooks for AAA protocols *> *> The security mechanism SHOULD be developed with respect to be able *> to collect usage records from one or more network elements. *> *> 5.9.5 SHOULD interwork with seamless handoff protocols *> *> An NSIS protocol SHOULD interwork with seamless handoff protocols *> such as context transfer and candidate access router (CAR) *> discovery. The goal to achieve is that signaling works fast enough *> in case of a handoff, where that protocols might help in one way or *> the other. *> *> 5.9.6 MAY interwork with non-traditional routing *> *> NSIS assumes traditional routing, but networks, which do non- *> traditional L3 routing, should not break it. Please give me an example of non-traditional L3 routing; I don't know what you mean. *> *> 5.10 Operational *> *> 5.10.1 Ability to assign transport quality to signaling messages. *> *> The NSIS architecture SHOULD allow the network operator to assign *> the NSIS protocol messages a certain transport quality. As signaling *> opens up for possible denial-of-service attacks, this requirement *> gives the network operator a mean, but also the obligation, to *> trade-off between signaling latency and the impact (from the *> signaling messages) on devices within his/her network. From protocol *> design this requirement states that the protocol messages SHOULD be *> detectable, at least where the control and assignment of the *> messages priority is done. *> *> *> Brunner (Editor) Informational [Page 23] *> *> *> Requirements for Signaling Protocols August 2002 *> *> Furthermore, the protocol design must take into account reliability *> concerns. Communication reliability is seen as part of the quality *> assigned to signaling messages. So procedures MUST be defined how an *> NSIS signaling system behaves if some kind of request it sent stays *> without answer. The basic transport protocol to be used between *> adjacent NSIS units MAY ensure message integrity and reliable *> transport. *> *> 5.10.2 Graceful fail over *> *> Any unit participating in NSIS signaling MUST NOT cause further *> damage to other systems involved in NSIS signaling when it has to go *> out of service. ?? Sounds like phone-speak for some concept I don't understand. Do you mean that if an network manager deliberately takes a router down, the signaling needs to be able to retain the E2E QoS seamlessly? What is "damage", or "further damage"? *> *> 5.10.3 Graceful handling of NSIS entity problems *> *> NSIS peers SHOULD be able to detect the malfunctioning peer. It may Was NSIS peer (what we normally call "neighbor" in Internet-speak) defined earlier? *> notify the NSIS Initiator or another NSIS entity involved in the *> signaling process. The NSIS peer may handle the problem itself e.g. *> switching to a backup NSIS entity. In the latter case note that *> synchronization of state between the primary and the backup entity *> is needed. *> *> 6 Security Considerations *> *> Section 5.8 of this draft provides security related requirements of *> a signaling protocol. Another document describes security threads *> for NSIS [3]. *> *> 7 Reference *> *> [1] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., *> "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional *> Specification", RFC 2205, September 1997. *> *> [2] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, *> "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December *> 2001. *> *> [3] Tschofenig, H., "NSIS Threats", 00.txt>, May 2002. *> *> 8 Acknowledgments *> ... *> 9 Author's Addresses *> ... *> *> 10 Appendix: Scenarios/Use cases *> ... Sorry, I did not have time to comment on the Appendix. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 21 04:35:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21562 for ; Mon, 21 Oct 2002 04:35:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9L8brl15202 for nsis-archive@odin.ietf.org; Mon, 21 Oct 2002 04:37:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L8bov15193; Mon, 21 Oct 2002 04:37:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L8aYv14590 for ; Mon, 21 Oct 2002 04:36:34 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21535 for ; Mon, 21 Oct 2002 04:34:06 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9L8aRH05096 for ; Mon, 21 Oct 2002 11:36:27 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 21 Oct 2002 11:36:21 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Oct 2002 11:36:21 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Oct 2002 11:36:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] on-path versus off-path discussion Date: Mon, 21 Oct 2002 11:36:19 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58EE@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] on-path versus off-path discussion Thread-Index: AcJ2jfG3bdw7FZWdSuSPanKqCRfAsACTvIfw To: , , Cc: X-OriginalArrivalTime: 21 Oct 2002 08:36:20.0794 (UTC) FILETIME=[EE6B41A0:01C278DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9L8aYv14591 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, > what the *nsis* w.g. needs to be clear about (as melinda has > pointed out) is what definition we agree on, and then > (implicitly) what is currently in or out of NSIS scope. (i > guess this would also be useful input to discussing the scope > of any complementary or additional activity.) Agreed. > a proposed definition is on the table in 3.2.1 of > draft-ietf-nsis-fw-00.txt ("path coupled/decoupled"). as a > teaser, this definition would classify both RSVP PATH and > RESV messages as path coupled, and therefore legitimately in > NSIS scope (even though the latter uses what we call > peer-session and not end-to-end addressing). This I can live with. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 21 05:19:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22224 for ; Mon, 21 Oct 2002 05:19:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9L9LKu17097 for nsis-archive@odin.ietf.org; Mon, 21 Oct 2002 05:21:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L9LGv17090; Mon, 21 Oct 2002 05:21:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L9Kpv17071 for ; Mon, 21 Oct 2002 05:20:51 -0400 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22218 for ; Mon, 21 Oct 2002 05:18:34 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g9L9Dim07074; Mon, 21 Oct 2002 11:13:44 +0200 To: nsis@ietf.org Cc: Bob Braden , Ruediger.Geib@t-systems.com, brunner@ccrle.nec.de, robert.hancock@roke.co.uk X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 21 Oct 2002 11:20:43 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/21/2002 11:20:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [NSIS] framework discussion Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, I have tried to make an overview of some of the issues that have been brought up during the flurry of e-mails that we have seen over the past couple of days. I have reacted to some of them. Please correct me if my impression of the ongoing discussion is not correct or indeed if you have comments on my reaction. Cheers, Sven. Path-coupled/de-coupled issue ========================= - There still seems to be a terminology concern. For me coupled is OK but I wouldn't want to make an issue of it. - I saw this statement, that seemed to receive some support from various parties. "I think that we can leave hooks in for the off-path signaling, but I hope we don't drive protocol work to accomplish it. I would prefer to get the basic on-path signaling work well stablized before developing off-path signaling." I agree with this statement, but I think that it does not directly lead to the conclusion that all path-decoupled issues should be removed from requirements and framework (in fact, I see it as contradictory: how can you leave hooks for something that you do not otherwise describe in any of the documents). The WG has clearly decided to focus on an path-coupled solution first. For me, combining this with the above statement means: * a separation in the requirements documents stating what would be needed extra for path-decoupled signalling * a discussion of the most important issues related to path-decoupled signalling as is present in some form in the framework document * a focus of proposed solutions to describe how they solve the path-coupled issue - I saw this statement "Making an overtly simple example. If A wants to signal B, on-path means he signals to B. Off path means he signals to C." With the risk of being nitpicky, I think the fundamental thing here is that A doesn't care where he/she is siganlling as long as he gets the required reservations to B. If this can be achieved by signalling to C, that should be fine for him/her. Peer relationship between NSIS entities =============================== Several issues were raised regarding the peer relationship between NEs. I think the issues raised were - loss of self-healing properties - slow down reconfiguration - persistent connections - addressing I believe that the advantages lie in the aggregation of operations (that you can now do per entity pair instead of per-flow). I don't think that it would necessarily lead to slower response times since it is not precluded to keep state about neighbours that can potentially be used for backup. Discovery ======== I agree with the remark that the current specification does not call for a separate discovery protocol. I think there would be merit in having a separate discovery phase (which does not have to be per-flow). At this point, whether this is implemented as a separate protocol or as a set of specific messages or parameters in the protocol seems a secondary issue. Layer split ======== I was under the impression that the two-layer approach with transport and signalling was agreed by the majority of the group. The framework currently uses Service Description, NSIS Control Layer and Generic Signaling Transport Protocol. With that terminology, I think the requirement would apply to the combination of the NSIS Control Layer and the Generic Signaling Transport Protocol. Any QoS related aspects would need to go in the Service Description part. Apart from a client layer specification in the CASP proposal, I have not seen a lot on this (which makes sense since it would not be the focus of NSIS). However, in a complete architecture, a discussion on this aspect would be very useful. End-to-end ========= I didn't quite understand this statement from Melinda: "That's not to say that I think this is not IETF work - I do think it is. I just don't think that it could reasonably fit into an end-to-end signaling protocol. As it happens, there is a diagram in the framework document of how it could be done by NSIS working in conjunction with another protocol, and that's Figure 8." The diagram in my opinion does not refer to any other protocol than NSIS. I don't see what the figure shows NSIS could do together with another protocol and what this protocol would be. For discussion =========== - sender- vs receiver-initiated - multicast _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 21 05:57:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22555 for ; Mon, 21 Oct 2002 05:57:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9L9xIx18659 for nsis-archive@odin.ietf.org; Mon, 21 Oct 2002 05:59:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L9xGv18648; Mon, 21 Oct 2002 05:59:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9L9wev18609 for ; Mon, 21 Oct 2002 05:58:40 -0400 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22509 for ; Mon, 21 Oct 2002 05:56:25 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g9L9wYO20026; Mon, 21 Oct 2002 11:58:34 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id g9L9wXQ25089; Mon, 21 Oct 2002 11:58:33 +0200 (MEST) Reply-To: From: "Hannes Tschofenig" To: , Subject: [NSIS] "sessions" and discovery Date: Mon, 21 Oct 2002 11:59:38 +0200 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) Importance: Normal 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 melinda! thank you for your comments to the casp draft. you are right that casp separates the process of discovey and the delivery of signaling messages. please see my comments inline: > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Melinda Shore > Sent: Thursday, October 17, 2002 3:41 PM > To: nsis@ietf.org > Subject: [NSIS] "sessions" and discovery > > > I think that these are two of the most fundamental questions > that this working group needs to resolve, and while there's > been a suggestion to send the requirements draft through WG > last call both of these questions, along with some other > basic questions (like addressing) are still open. > > Frankly, I think that this is something that RSVP got very, > very right and that it might be difficult to improve on it. > In the framework draft it says that NSIS Entity discovery is > not to be included in an NSIS protocol, and in the CASP > draft discovery is a separate process. What concerns me is > that 1) it leads to a lack of robustness, and 2) it > increases the number of messages required to accomplish a > given task. could you please elaborate the reasoning behind your "lack of robustness" statement? i am not sure whether it really increases the message count. as the draft says if you already know your next peer (by some other means) then there is no need to use a discovery protocol. it however decreases the message size in comparison to idempotent messages. in fact rsvp does not always use pure idempotent messages: for example... - the refresh reduction rfc uses mechanisms to limit refreshes. - if kerberos is used to establish a security association then the session ticket might not always be included (to optimize both performance and message size) you have to assume that you contact the same peer (if known) furthermore there are security issues related to this procedure. whenever you do not know your next peer then you might experience difficulties selecting a security association to provide proper message protection. > Rerunning the discovery process every time > route moves or a node goes down seems to me to be far less > desirable than having discovery be implicit in the state > maintenance mechanism. > > Using a stand-alone discovery process becomes more > attractive when you have persistent, (hopefully) durable > connections between NEs. While I understand that the use of > persistent connections for QoS signaling *might* have better > scaling properties (although I'm not convinced of it), by > rerunning the discovery protocol and then introducing round > trips between entities it makes the system slower to respond > to changes in the network, we think that the discovery process makes it even faster to react on route changes since you can have independent timers for refreshing messages and for discovery related messages. additionally there are different discovery mechanisms available which allow a larger degree of freedom. in some cases you do not need to exchange additional messages if (a) some discovery procedure is used anyway (for example router advertisement, dhcp, etc.) or (b) if you know the next peer (for example based on the routing table). >increases the amount of local > traffic (between NEs), idempotent messages which have their discovery mechanism built-in also increase the amount of traffic. > and *requires* an external discovery > process. My preference would be to look for ways to > aggregate/multiplex messages over a protocol that looks more > like RSVP than it would to create persistent sessions among > NEs. > > There have been arguments for creating a stand-alone > RSVP-like discovery protocol that doesn't actually convey > requests or install state, and that's certainly what TED > does. from the last ietf meeting where you reported about the TED protocol i had the impression that you like the approach. you even mentioned that you did something like ted but with the help of rsvp. > I would argue that a correctly designed RSVPv2 could > do that very easily and is almost certainly preferable to > separate discovery/state processes. thank you for your comments and for starting a discussion in this area. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 21 08:21:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25166 for ; Mon, 21 Oct 2002 08:21:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LCNDQ25180 for nsis-archive@odin.ietf.org; Mon, 21 Oct 2002 08:23:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LCNBv25149; Mon, 21 Oct 2002 08:23:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LCM0v25053 for ; Mon, 21 Oct 2002 08:22:00 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25088 for ; Mon, 21 Oct 2002 08:19:43 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9LCLdot013809; Mon, 21 Oct 2002 05:21:40 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH19055; Mon, 21 Oct 2002 05:16:45 -0700 (PDT) Message-Id: <200210211216.AAH19055@mira-sjc5-4.cisco.com> To: sven.van_den_bosch@alcatel.be cc: nsis@ietf.org, Bob Braden , Ruediger.Geib@t-systems.com, brunner@ccrle.nec.de, robert.hancock@roke.co.uk From: Melinda Shore Subject: Re: [NSIS] framework discussion In-Reply-To: Message from sven.van_den_bosch@alcatel.be of "Mon, 21 Oct 2002 11:20:43 +0200." Date: Mon, 21 Oct 2002 08:21:37 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > "I think that we can leave hooks in for the off-path signaling, but I hope > we don't drive protocol work to accomplish it. I would prefer to get the > basic on-path signaling work well stablized before developing off-path > signaling." > I agree with this statement, but I think that it does not directly lead to > the conclusion that all path-decoupled issues should be removed from > requirements and framework (in fact, I see it as contradictory: how can you > leave hooks for something that you do not otherwise describe in any of the > documents). The WG has clearly decided to focus on an path-coupled solution > first. Actually, the WG was told to focus on a path-coupled solution. It is still unclear to me that the signaling protocol used for on-path signaling is the same one that should be used for off-path signaling - you should use a protocol that's appropriate for the architecture, it seems to me. If an off-path signaling protocol can be done easily or inexpensively with the same protocol that's being used for on-path signaling that's great, but it it would be difficult, perverse, or unnecessarily complex we'd be better off looking for a more appropriate approach. I've used screwdrivers as hammers but frankly I would have been better off using a hammer. > I think there would be merit in having a > separate discovery phase (which does not have to be > per-flow). This working group is very focused on QoS. There are other applications for which the protocol will be used, and for some of those protocols topology is an important issue (if not the defining issue). Examples include firewall/NAT traversal and tunnel endpoint discovery/communication. Indeed, any NSIS protocol which is expected to be able to talk to NATs and traverse them intelligently is going to have to concern itself with topology. Accretion of topological information and returning it to the NSIS initiator to sort through and build appropriate messages is not going to be as effective, I would argue, as the current RSVP model where each node has information about adjacent hops and the message's success is not dependent on someone having knowledge of the entire end-to-end path. At a very minimum it's going to need adjacent hope information, anyway. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 21 08:25:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25368 for ; Mon, 21 Oct 2002 08:25:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LCR4325439 for nsis-archive@odin.ietf.org; Mon, 21 Oct 2002 08:27:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LCR2v25432; Mon, 21 Oct 2002 08:27:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LCQqv25412 for ; Mon, 21 Oct 2002 08:26:52 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25345 for ; Mon, 21 Oct 2002 08:24:35 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9LCQoot015866; Mon, 21 Oct 2002 05:26:50 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH19136; Mon, 21 Oct 2002 05:21:57 -0700 (PDT) Message-Id: <200210211221.AAH19136@mira-sjc5-4.cisco.com> To: Hannes.Tschofenig@siemens.com cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] "sessions" and discovery In-Reply-To: Message from "Hannes Tschofenig" of "Mon, 21 Oct 2002 11:59:38 +0200." Date: Mon, 21 Oct 2002 08:26:49 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > you are right that casp separates the process of discovey and the delivery > of signaling messages. please see my comments inline: To be honest I am not very comfortable with a discussion of CASP when 1) it is not the NSIS protocol this week, either, and 2) neither the NSIS framework document nor the NSIS requirements document are even close to completion. > from the last ietf meeting where you reported about the TED protocol i had > the impression that you like the approach. > you even mentioned that you did something like ted but with the help of > rsvp. TED could be done with an NSIS protocol (I did a version using RSVP), and I would argue that it could be done better than the current IKE-based implementation. This is where topology enters into it. As things currently stand the first node that receives the TED request answers it and doesn't forward the TED message any further. This means that the tunnel that's created is the *shortest* possible one. RSVP (or something like it) allows us to find the last appropriate endpoint and create the *longest* possible tunnel. I think we can improve upon TED. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 21 16:18:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13810 for ; Mon, 21 Oct 2002 16:18:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LKKal21089 for nsis-archive@odin.ietf.org; Mon, 21 Oct 2002 16:20:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LKKXv21082; Mon, 21 Oct 2002 16:20:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LKJtv21036 for ; Mon, 21 Oct 2002 16:19:55 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13797 for ; Mon, 21 Oct 2002 16:17:33 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT61MW>; Mon, 21 Oct 2002 21:19:44 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5B50@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden , nsis@ietf.org Subject: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt Date: Mon, 21 Oct 2002 21:19:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Bob, some comments on (a very few of) your comments, mainly from a framework perspective: *> 11. Handoff decision and trigger sources: An NSIS protocol is not *> used to trigger handoffs in mobile IP, nor is it used to decide > > Why not, and who says? > *> whether to handoff or not. As soon as or in some situation even *> before a handoff happened, an NSIS protocol might be used for *> signaling for QoS again. However, NSIS MUST interwork with several *> protocols for mobility management. *> this question pops up periodically in some form (see also threads on route pinning and bidirectional reservations). i think the basic (simplifying) assumption has been that the route comes first (defining the path) and the signalling comes after it (following the path). [this doesn't prevent a signalling application at some node interacting with something that modifies the path, but the requirement is then just for NSIS to live with that possibility.] since a handoff is a basically a route change, it comes into this category; if we don't make some assumption like this it's impossible to see where nsis stops and things like seamoby CARD start. i certainly used to think this was a reasonable restriction (and still do, for the 'NSIS base protocol'). but if we are trying to broaden our minds to think of possible NSIS uses (cf. your initial comments) should we also be thinking about signalling applications that set up or modify routes? *> 5.4.3 Independence of reservation identifier *> *> A reservation identifier, which is independent of the flow *> identifier (flow end-points), MUST be used. Various scenarios in the *> mobility area require this independence because flows resulting from *> handoff might have changed end-points etc. but still have the same *> service requirement. Also several proxy-based signaling methods *> might profit from such as independence. > > The semantics of this identifier needs to be precisely defined. It is > unclear whether it needs to be used E-E, or only in the mobile domain. > we agonised about precisely this detail in the framework document (current status: we don't know.) one point to make is that i don't think you can restrict the scope of the identifier to a 'mobile domain' because route changes due to mobility may have an impact anywhere along the data path (all the way up to the correspondent). i'd like to imagine, however, that these details could be covered in the framework, provided the requirements document states abstractly why such a capability is a Good Thing. (maybe the requirement should be a SHOULD, because I'm still not clear such an identifier can be practically secured.) *> 5.9.6 MAY interwork with non-traditional routing *> *> NSIS assumes traditional routing, but networks, which do non- > traditional L3 routing, should not break it. > > Please give me an example of non-traditional L3 routing; I don't know > what you mean. > i have to take some responsibility for this slang. it just means [unicast] routing not based deterministically only on L3 destination address (e.g. QoS routing or very fine grained load balancing). probably the requirements document should use more formal language. Cheers, Robert H. ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 21 17:01:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15477 for ; Mon, 21 Oct 2002 17:01:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LL3WF23792 for nsis-archive@odin.ietf.org; Mon, 21 Oct 2002 17:03:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LL3Jv23783; Mon, 21 Oct 2002 17:03:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LL2xv23762 for ; Mon, 21 Oct 2002 17:02:59 -0400 Received: from rsys000a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15438 for ; Mon, 21 Oct 2002 17:00:37 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4DQT61NP>; Mon, 21 Oct 2002 22:01:48 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5B58@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Melinda Shore , sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] framework discussion Date: Mon, 21 Oct 2002 22:01:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi melinda, [snip] > > [sven] I think there would be merit in having a > > separate discovery phase (which does not have to be > > per-flow). > > [melinda] This working group is very focused on QoS. There are other > applications for which the protocol will be used, and for > some of those protocols topology is an important issue (if > not the defining issue). Examples include firewall/NAT > traversal and tunnel endpoint discovery/communication. > Indeed, any NSIS protocol which is expected to be able to > talk to NATs and traverse them intelligently is going to > have to concern itself with topology. Accretion of > topological information and returning it to the NSIS > initiator to sort through and build appropriate messages > is not going to be as effective, I would argue, as the > current RSVP model where each node has information about > adjacent hops and the message's success is not dependent on > someone having knowledge of the entire end-to-end path. At > a very minimum it's going to need adjacent hope information, > anyway. > > Melinda > [robert] actually, i'm not clear that there's any disagreement here. as i understand it, all discussions involving the term 'discovery' are about peer (next-NSIS-hop) discovery, not complete-path-discovery - i.e. essentially the same as what the RSVP PATH mechanism does. i've certainly never seen an explicit suggestion that all this information should get sent back to the NI. have i been deluding myself? cheers, robert h. ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit 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. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 21 22:02:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21901 for ; Mon, 21 Oct 2002 22:02:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9M24P304401 for nsis-archive@odin.ietf.org; Mon, 21 Oct 2002 22:04:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M24Mv04396; Mon, 21 Oct 2002 22:04:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M23gv04352 for ; Mon, 21 Oct 2002 22:03:42 -0400 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21883 for ; Mon, 21 Oct 2002 22:01:18 -0400 (EDT) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g9M23RM05046; Mon, 21 Oct 2002 19:03:27 -0700 (PDT) Date: Mon, 21 Oct 2002 19:03:27 -0700 (PDT) From: Bob Braden Message-Id: <200210220203.g9M23RM05046@boreas.isi.edu> To: braden@ISI.EDU, robert.hancock@roke.co.uk Subject: RE: [NSIS] on-path versus off-path discussion Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> [reh] there is no intended difference, just an attempt to pin down some of the corner cases which some people were unclear about. (the only reason for using 'path-coupled' is that 'path-decoupled' sounds OK as a term for the opposite, which we also needed.) *> > *> > Bob Braden *> > Robert, I guess the opposite to "path-oriented" would be "path-disoriented", eh? ;-) I take you point. Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 22 03:42:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07889 for ; Tue, 22 Oct 2002 03:42:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9M7i8I27645 for nsis-archive@odin.ietf.org; Tue, 22 Oct 2002 03:44:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M7huv27633; Tue, 22 Oct 2002 03:43:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M7gXv27562 for ; Tue, 22 Oct 2002 03:42:35 -0400 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07871 for ; Tue, 22 Oct 2002 03:40:05 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g9M7gJi27593; Tue, 22 Oct 2002 09:42:19 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id g9M7gJQ27658; Tue, 22 Oct 2002 09:42:19 +0200 (MEST) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" Cc: Subject: RE: [NSIS] "sessions" and discovery Date: Tue, 22 Oct 2002 09:43:19 +0200 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: <200210211221.AAH19136@mira-sjc5-4.cisco.com> Importance: Normal 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 melinda! > To be honest I am not very comfortable with a discussion of > CASP when 1) it is not the NSIS protocol this week, either, > and 2) neither the NSIS framework document nor the NSIS > requirements document are even close to completion. i fully agree with you that we should keep requirements/framework discussions separate from protocols. i submitted my comment to your question not to start a protocol discussion. instead i thought that it might be very helpful to discuss the security implications of the two addressing approaches which are related to the process of discovery. i personally think that the two lead to the same procedure from a security perspective since you always need to know who will process your message next to provide efficient security protection. (see also confidentiality protection). rsvp also works this way. for the path message this is more difficult because of its nature. for a resv message which is backwards routed along the already pinned path selecting a security association is not a problem. hence you can treat the path message also as a discovery message in some sense. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 23 02:39:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09890 for ; Wed, 23 Oct 2002 02:39:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9N6fdL09498 for nsis-archive@odin.ietf.org; Wed, 23 Oct 2002 02:41:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N6fav09490; Wed, 23 Oct 2002 02:41:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N6cxv09405 for ; Wed, 23 Oct 2002 02:38:59 -0400 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09870 for ; Wed, 23 Oct 2002 02:36:28 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g9N6V4k08909; Wed, 23 Oct 2002 08:31:20 +0200 Subject: RE: [NSIS] framework discussion To: "Hancock, Robert" Cc: Melinda Shore , nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 23 Oct 2002 08:38:08 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/23/2002 08:38:26 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C1256C5B002452B98f9e8a93df938690918cC1256C5B002452B9" Content-Disposition: inline Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --0__=C1256C5B002452B98f9e8a93df938690918cC1256C5B002452B9 Content-type: text/plain; charset=us-ascii Hi Robert, Melinda, Please see inline. Sven. "Hancock, Robert" @ietf.org on 21/10/2002 23:01:48 Sent by: nsis-admin@ietf.org To: Melinda Shore , Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: RE: [NSIS] framework discussion hi melinda, [snip] > > [sven] I think there would be merit in having a > > separate discovery phase (which does not have to be > > per-flow). > > [melinda] This working group is very focused on QoS. There are other > applications for which the protocol will be used, and for > some of those protocols topology is an important issue (if > not the defining issue). Examples include firewall/NAT > traversal and tunnel endpoint discovery/communication. > Indeed, any NSIS protocol which is expected to be able to > talk to NATs and traverse them intelligently is going to > have to concern itself with topology. Accretion of > topological information and returning it to the NSIS > initiator to sort through and build appropriate messages > is not going to be as effective, I would argue, as the > current RSVP model where each node has information about > adjacent hops and the message's success is not dependent on > someone having knowledge of the entire end-to-end path. At > a very minimum it's going to need adjacent hope information, > anyway. > > Melinda > [robert] actually, i'm not clear that there's any disagreement here. as i understand it, all discussions involving the term 'discovery' are about peer (next-NSIS-hop) discovery, not complete-path-discovery - i.e. essentially the same as what the RSVP PATH mechanism does. i've certainly never seen an explicit suggestion that all this information should get sent back to the NI. [Sven] I have the same understanding as you have (just peer discovery, not path/NI discovery). If this resolves the issue that would be great. have i been deluding myself? cheers, robert h. ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. (See attached file: RMRL-Disclaimer.txt) --0__=C1256C5B002452B98f9e8a93df938690918cC1256C5B002452B9 Content-type: application/octet-stream; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: base64 UmVnaXN0ZXJlZCBPZmZpY2U6IFJva2UgTWFub3IgUmVzZWFyY2ggTHRkLCBTaWVtZW5zIEhvdXNl LCBPbGRidXJ5LCBCcmFja25lbGwsIA0KQmVya3NoaXJlLiBSRzEyIDhGWg0KDQpUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29u ZmlkZW50aWFsIHRvIFJva2UgDQpNYW5vciBSZXNlYXJjaCBMdGQgYW5kIG11c3Qgbm90IGJlIHBh c3NlZCB0byBhbnkgdGhpcmQgcGFydHkgd2l0aG91dCBwZXJtaXNzaW9uLiBUaGlzIA0KY29tbXVu aWNhdGlvbiBpcyBmb3IgaW5mb3JtYXRpb24gb25seSBhbmQgc2hhbGwgbm90IGNyZWF0ZSBvciBj aGFuZ2UgYW55IGNvbnRyYWN0dWFsIA0KcmVsYXRpb25zaGlwLg0K --0__=C1256C5B002452B98f9e8a93df938690918cC1256C5B002452B9-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 08:38:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04305 for ; Thu, 24 Oct 2002 08:38:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OCeOS13329 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 08:40:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OCdsv13281; Thu, 24 Oct 2002 08:39:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OCc4v13216 for ; Thu, 24 Oct 2002 08:38:04 -0400 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04240 for ; Thu, 24 Oct 2002 08:35:43 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9OCbmxF017752; Thu, 24 Oct 2002 05:37:48 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI43283; Thu, 24 Oct 2002 05:32:59 -0700 (PDT) Message-Id: <200210241232.AAI43283@mira-sjc5-4.cisco.com> To: sven.van_den_bosch@alcatel.be cc: "Hancock, Robert" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] framework discussion In-Reply-To: Message from of "Wed, 23 Oct 2002 08:38:08 +0200." Date: Thu, 24 Oct 2002 08:37:49 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > [Sven] I have the same understanding as you have (just peer discovery, not > path/NI discovery). If this resolves the issue that would be great. Routing problems tend to be very difficult, and in the context of this protocol I'm unclear on what it means to talk about peer discovery without also talking about path discovery. Peer relationships *by themselves* really aren't very meaningful. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 11:02:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10779 for ; Thu, 24 Oct 2002 11:02:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OF4S322274 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 11:04:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OF4Pv22267; Thu, 24 Oct 2002 11:04:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OF38v22218 for ; Thu, 24 Oct 2002 11:03:08 -0400 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10703 for ; Thu, 24 Oct 2002 11:00:47 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Oct 2002 16:03:03 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA62C@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Melinda Shore'" , sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] framework discussion Date: Thu, 24 Oct 2002 16:02:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi melinda, > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 24 October 2002 13:38 > To: sven.van_den_bosch@alcatel.be > Cc: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] framework discussion > > > > [Sven] I have the same understanding as you have (just peer > discovery, not > > path/NI discovery). If this resolves the issue that would be great. > > Routing problems tend to be very difficult, and in the > context of this protocol I'm unclear on what it means to > talk about peer discovery without also talking about path > discovery. Peer relationships *by themselves* really aren't > very meaningful. > > Melinda > obviously (?) we are talking about finding the appropriate peer within the context of talking about a particular flow (as defined by the flow identification information within the messages). you can regard that as implicitly discovering the path as a result (if you want). i (and i think sven) were simply reacting to the sentence in your original email: "Accretion of topological information and returning it to the NSIS initiator to sort through and build appropriate messages is not going to be as effective, I would argue, as the current RSVP model where each node has information about adjacent hops and the message's success is not dependent on someone having knowledge of the entire end-to-end path." if you change your phrase "each node has information about adjacent hops" --> something about an NSIS entity talking to its peer, i think we're saying the same thing, and no one's suggesting the approach indicated in the first part of your sentence. (or should i say, i _think_ we're saying the same thing.) cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 11:19:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11595 for ; Thu, 24 Oct 2002 11:19:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OFL9P23699 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 11:21:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OFL6v23690; Thu, 24 Oct 2002 11:21:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OFKTv23654 for ; Thu, 24 Oct 2002 11:20:29 -0400 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11528 for ; Thu, 24 Oct 2002 11:18:08 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9OFKFIm026577; Thu, 24 Oct 2002 08:20:15 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI47198; Thu, 24 Oct 2002 08:15:23 -0700 (PDT) Message-Id: <200210241515.AAI47198@mira-sjc5-4.cisco.com> To: "Hancock, Robert" cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] framework discussion In-Reply-To: Message from "Hancock, Robert" of "Thu, 24 Oct 2002 16:02:54 BST." <76C92FBBFB58D411AE760090271ED4181EA62C@rsys002a.roke.co.uk> Date: Thu, 24 Oct 2002 11:20:14 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > if you change your phrase "each node has information about > adjacent hops" --> something about an NSIS entity talking > to its peer, i think we're saying the same thing, and no > one's suggesting the approach indicated in the first part > of your sentence. I'm not sure that we are talking about the same thing. I do think that this needs to be clarified in both documents so that we have a simple description of what's intended. I've seen quite a few proposals, both in midcom and in discussion of off-path QoS signaling, that place IP-layer route information in the application, so when you say that "obviously (?) we are talking about finding the appropriate peer within the context of talking about a particular flow" it is actually not that obvious (although in an ideal world it would be). Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 11:40:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12704 for ; Thu, 24 Oct 2002 11:40:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OFgFH25350 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 11:42:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OFgCv25339; Thu, 24 Oct 2002 11:42:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OFfBv25297 for ; Thu, 24 Oct 2002 11:41:11 -0400 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12687 for ; Thu, 24 Oct 2002 11:38:49 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Oct 2002 16:41:06 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA62E@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Melinda Shore'" Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org Subject: RE: [NSIS] framework discussion Date: Thu, 24 Oct 2002 16:41:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi melinda, ok: i thought it was obvious, but if you asked me to point at the precise place in the framework where it said so i would struggle. so, i suggest we add a short statement in the 'basic assumptions' section (3.3.1) which says something about all the routing information being managed in the basic NSIS protocol (not visible to applications, anyway), and messages being routed peer-by-peer. we can point to some later subsections for more details (which i think are there, it's just the basic starting point that's missing). would that be a step in the right direction? robert ps. i also owe you responses on your other more detailed framework comments, but just recently i've been trying to get my head round the sender/receiver question which seems to be one of the primary headaches. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 24 October 2002 16:20 > To: Hancock, Robert > Cc: sven.van_den_bosch@alcatel.be; nsis@ietf.org > Subject: Re: [NSIS] framework discussion > > > > if you change your phrase "each node has information about > > adjacent hops" --> something about an NSIS entity talking > > to its peer, i think we're saying the same thing, and no > > one's suggesting the approach indicated in the first part > > of your sentence. > > I'm not sure that we are talking about the same thing. I do > think that this needs to be clarified in both documents so > that we have a simple description of what's intended. I've > seen quite a few proposals, both in midcom and in discussion > of off-path QoS signaling, that place IP-layer route > information in the application, so when you say that > "obviously (?) we are talking about finding the appropriate > peer within the context of talking about a particular flow" > it is actually not that obvious (although in an ideal world > it would be). > > Melinda > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 12:50:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15425 for ; Thu, 24 Oct 2002 12:50:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OGqjO29501 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 12:52:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OGqgv29494; Thu, 24 Oct 2002 12:52:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OGpPv29450 for ; Thu, 24 Oct 2002 12:51:25 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15366 for ; Thu, 24 Oct 2002 12:49:02 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9OGpJa22356; Thu, 24 Oct 2002 09:51:19 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA00720; Thu, 24 Oct 2002 16:51:18 GMT Date: Thu, 24 Oct 2002 16:51:18 GMT Message-Id: <200210241651.QAA00720@gra.isi.edu> To: mshore@cisco.com Subject: Re: [NSIS] framework discussion Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org, braden@ISI.EDU X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> > [Sven] I have the same understanding as you have (just peer discovery, not *> > path/NI discovery). If this resolves the issue that would be great. *> *> Routing problems tend to be very difficult, and in the *> context of this protocol I'm unclear on what it means to *> talk about peer discovery without also talking about path *> discovery. Peer relationships *by themselves* really aren't *> very meaningful. *> *> Melinda Melinda, Hmmm. I believe that Sven was using the term "peer" for what we in the Internet world customarily call a "neighbor". Neighbor discovery is pretty fundamental to many routing protocols, right? And I believe it will be fundamental to a signaling protocol. (See my earlier message about "session"). Perhaps we are talking about different things here, or am I just misunderstanding? Bob Braden *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 13:05:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15917 for ; Thu, 24 Oct 2002 13:05:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OH79O30359 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 13:07:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OH77v30263; Thu, 24 Oct 2002 13:07:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OH6qv30040 for ; Thu, 24 Oct 2002 13:06:52 -0400 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15880 for ; Thu, 24 Oct 2002 13:04:29 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9OH6bIm009734; Thu, 24 Oct 2002 10:06:37 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI52003; Thu, 24 Oct 2002 10:01:46 -0700 (PDT) Message-Id: <200210241701.AAI52003@mira-sjc5-4.cisco.com> To: Bob Braden cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] framework discussion In-Reply-To: Message from Bob Braden of "Thu, 24 Oct 2002 16:51:18 GMT." <200210241651.QAA00720@gra.isi.edu> Date: Thu, 24 Oct 2002 13:06:36 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > Hmmm. I believe that Sven was using the term "peer" for what we > in the Internet world customarily call a "neighbor". Neighbor > discovery is pretty fundamental to many routing protocols, right? And > I believe it will be fundamental to a signaling protocol. (See my > earlier message about "session"). Perhaps we are talking about > different things here, or am I just misunderstanding? See my answer to Robert. I think we may be having some terminological problems, plus I was responding to Sven's comment that we need peer discovery but not path/NI discovery. It seems to me that we need both. It may (or may not!) be useful to think about policy-based routing when sorting this through. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 13:08:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15999 for ; Thu, 24 Oct 2002 13:08:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OHA8130789 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 13:10:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OHA5v30782; Thu, 24 Oct 2002 13:10:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OH9dv30733 for ; Thu, 24 Oct 2002 13:09:39 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15950 for ; Thu, 24 Oct 2002 13:07:16 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9OH9Xa00376; Thu, 24 Oct 2002 10:09:33 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA00752; Thu, 24 Oct 2002 17:09:33 GMT Date: Thu, 24 Oct 2002 17:09:33 GMT Message-Id: <200210241709.RAA00752@gra.isi.edu> To: braden@ISI.EDU, mshore@cisco.com Subject: Re: [NSIS] framework discussion Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Melinda, I apologize for reading the NSIS email sporadically; I have not had time to catch up. I will go back and read your reply. Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 13:33:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16873 for ; Thu, 24 Oct 2002 13:33:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OHZCq31660 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 13:35:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OHZ9v31653; Thu, 24 Oct 2002 13:35:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OHYsv31631 for ; Thu, 24 Oct 2002 13:34:54 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16863 for ; Thu, 24 Oct 2002 13:32:30 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9OHYma14169; Thu, 24 Oct 2002 10:34:48 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA00786; Thu, 24 Oct 2002 17:34:48 GMT Date: Thu, 24 Oct 2002 17:34:48 GMT Message-Id: <200210241734.RAA00786@gra.isi.edu> To: braden@ISI.EDU, mshore@cisco.com Subject: Re: [NSIS] framework discussion Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> See my answer to Robert. I think we may be having some *> terminological problems, Melinda, Yup. Looking broadly at the recent discussions, I would suggest that we should generally unqualified words like "path" and "discovery". Thus, I think we can all agree that "neighbor discovery" and "path discovery" are two different issues with different requirements (and probably different mechanisms.) I think I hear some saying that *neighbor discovery* might need a separate phase while others say (as I implied in the 2-level document) that neighbor discovery will generally happen without any additional packet exchanges. I hear you saying the the RVSP scheme of *path discovery* works very well (which *I* certainly won't disagree with ;-)). Does this make sense? Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 13:48:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17358 for ; Thu, 24 Oct 2002 13:48:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OHo9N00354 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 13:50:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OHo6v00347; Thu, 24 Oct 2002 13:50:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OHnkv00324 for ; Thu, 24 Oct 2002 13:49:46 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17345 for ; Thu, 24 Oct 2002 13:47:23 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9OHnea22139; Thu, 24 Oct 2002 10:49:40 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA00813; Thu, 24 Oct 2002 17:49:40 GMT Date: Thu, 24 Oct 2002 17:49:40 GMT Message-Id: <200210241749.RAA00813@gra.isi.edu> To: nsis@ietf.org, AAvella@carrieraccess.com Subject: Re: [NSIS] [Requirements draft] Scenarios X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> I believe the Appendix of the [Requirements draft] could be enhanced with *> scenarios from the ISC Reference Arquitecture. *> *> http://www.softswitch.org/attachments/Reference_Architecture_5-02.pdf *> Well, maybe yes, maybe no. Voice over IP is certainly an important potential application of NSIS protocols, but by no means the only one, and in the long run it might not even be the most important. (Ask me sometime about my success in predicting the future of the Internet ;-)) However, I would note that driving NSIS from VoIP requiremetns would entangle the NSIS WG with a hugely complex telephone infrastructure. Trying too hard to accommodate its complexities is likely to distort our efforts and lead us away from the more important goals of generality and extensibility. I have the same uneasy feelinga about the wireless material in the Appendix, BTW. What we need is some abstraction of the requirements of VoIP and of wireless. In the Internet we want signaling protocols that are flexible, generel, and extensible. As you penetrate deep into wireless networks or into the phone network, I would expect special-purpose signaling protocols to be used. It seems to me that the right way to model these complex special environments is as individual link layers, with IP over top. Just as RSVP can invoke link layer signaling, e.g., ATM (RFC2382) or IEEE 802 (RFC 2814), so an Internet NSIS signaling protocol can invoke the wireless or phone network signaling protocol. I would rather see much less emphasis on telephony in the Appendx, and a broader range of Internet signaling applications. Bob Braden *> Network Examples *> ............................................................................ *> .......................13 *> Wireline Network *> ............................................................................ *> ...................................................13 *> All-IP Network....14 *> VoIP Tandem *> Switching................................................................... *> .................................................16 *> POTS Carried over IP *> ............................................................................ *> ...........................................16 *> Access Network (V5/ISDN) over *> IP.......................................................................... *> .........................17 *> Cable Network (e.g. PacketCable(tm)) over *> IP.......................................................................... *> ..........17 *> VoDSL and IAD over IP *> ............................................................................ *> ........................................18 *> Wireless (3GPP R99 Special Case NGN) *> ............................................................................ *> ............19 *> Wireless (3GPP R2000 General Case all IP) *> ............................................................................ *> .......19 *> WCDMA Mobile Network *> ............................................................................ *> ......................................20 *> *> Alejandro Avella *> *> [Requirements draft] *> http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-04.txt *> *> *> ************************************************************************* *> This e-mail transmission, and any documents, files, or previous *> e-mail messages attached to it may contain information that is *> confidential or legally privileged. If you are not the intended *> recipient, or a person responsible for delivering it to the *> intended recipient, you are hereby notified that you must not *> read this transmission and that any disclosure, copying, printing, *> distribution, or use of any of the information contained in or *> attached to this transmission is strictly prohibited. If you have *> received this transmission in error, please immediately notify the *> sender by telephone or return e-mail and delete the original *> transmission and its attachments without reading or saving them *> in any manner. Thank you. *> ************************************************************************* _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 14:01:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17736 for ; Thu, 24 Oct 2002 14:01:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OI3Cp00913 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 14:03:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OI3Av00906; Thu, 24 Oct 2002 14:03:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OI2Av00885 for ; Thu, 24 Oct 2002 14:02:10 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17711 for ; Thu, 24 Oct 2002 13:59:47 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9OI21a00090; Thu, 24 Oct 2002 11:02:01 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id SAA00820; Thu, 24 Oct 2002 18:02:01 GMT Date: Thu, 24 Oct 2002 18:02:01 GMT Message-Id: <200210241802.SAA00820@gra.isi.edu> To: braden@ISI.EDU, Ruediger.Geib@t-systems.com Subject: RE: [NSIS] New NSIS-related drafts Cc: nsis@ietf.org X-Sun-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: , *> Bob, *> *> if you use C-Type to identify a single service, *> I would agree with you. By single service I mean: *> - Less Than Best Effort -> own C-Type *> - IntServ Guaranteed -> own C-Type *> - IntServ Controlled -> own C-Type *> *> IntServ doesn't make this distinction in the *> C-Type, there's only one C-Type saying "IntServ". *> The two IntServ services are identified *> explicitely where required (Receiver FLOWSPEC, *> 9th octet). Prior to this separation IntServ *> signals information about policing and MTU sizes *> (Sender). Services specified in other ways than *> IntServ may not require signaling of this *> information. I continue to look at this as a *> major drawback of IntServ/RSVP (using IntServ *> signaling for one of these other services is *> somewhat unattractive). Please note that I've *> put "IntServ" in front of RSVP already in my *> first message. *> *> C-Type is an 8-bit field. Instead of *> identifying individual services it may be useful *> to identify "Meta services" only (e.g QoS, *> MidBox) and have the service ID / service *> descriptor there. I didn't read the RSVP related *> drafts yet, please don't critisise me if this is *> already proposed there. *> *> To me the "elements common" to all DiffServ *> based QoS services are a service name, a PHB, *> and a DSCP as part of a service ID. This allows *> flexible addition of a service specfic parameter *> TLV. If it is required. *> Examples: *> Service specific parameters are absent by *> definition the case of Less Than Best Effort. *> They must be the IntServ Guaranteed service *> parametrisation (like Flowspec etc.), should *> the latter be signaled that way. *> *> Regards, Rüdiger *> *> Rudiger, I'm sorry, I don't seem to have made myself clear. The Int-serv CType defines the format for an IntServ flowspec for a family of Intserv services. This format is very general. It includes some common fields like MTU sizes and policing, because in our judgment these will often be of concern to applications. [I suggest that you think very carefully about ignoring this wisdom and omitting these common fields; they are born out of quite a lot of Internet experience.] However, you are free to create a new format, say a DiffServ flowspec format. That's fine, you define that format (which presumably includes a service type number,a service name, a PHB, a DSCP, ... whatever you need. And for this format you get ONE new CType. I hope this is clearer. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 14:08:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18008 for ; Thu, 24 Oct 2002 14:08:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OIA7v01791 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 14:10:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OIA4v01771; Thu, 24 Oct 2002 14:10:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OI9Zv01730 for ; Thu, 24 Oct 2002 14:09:35 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17955 for ; Thu, 24 Oct 2002 14:07:11 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9OI9Ta06822; Thu, 24 Oct 2002 11:09:29 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id SAA00828; Thu, 24 Oct 2002 18:09:29 GMT Date: Thu, 24 Oct 2002 18:09:29 GMT Message-Id: <200210241809.SAA00828@gra.isi.edu> To: braden@ISI.EDU, Ruediger.Geib@t-systems.com Subject: RE: [NSIS] New NSIS-related drafts - L2 issue Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> Bob Braden wrote> *> > ...L2 properties may=20 *> > have a place in the general signaling regime (which *I* think=20 *> > is what the present NSIS WG should be addressing, not just a=20 *> > particular subset such as QoS). *> *> Do you have a preference how to continue on L2 issues? Assuming a *> single basic NSIS signaling protocol supporting different NSIS client *> protocols NSIS could: *> *> - Have a separate NSIS client protocol taking care of L2=20 *> related signaling *> *> - Insert L2 stuff into other NSIS client protocols (like=20 *> QoS, may be others too) *> *> I'd prefer the first attempt. The NSIS signaling transport protocol is *> IP however. So this would be limited to L2 services with an IP control *> plane. *> *> This would leave us with insertion into other client protocols as a *> solution. If support of L2 information is no more than an option, I *> think I could live with it. By "option" I mean: *> *> - A NSIS client protocols progress to standard is not=20 *> delayed by the specification state of its L2 information=20 *> elements.=20 *> *> - The L2 TLV(s) may be present in a signaling dialogue, *> but don't have to be. *> *> I favour to keep interworking and service mapping issues=20 *> out of signalling specifications. *> *> Regards, R=FCdiger *> Rudiger, You raise hard questions and I don't know the answers. As IANA expert on RSVP registration, I currently know of four separate requests for RSVP extensions, some of which are L2 specific. One extension defines a new object to carry two bits that are telephony-related; another defines a new option to carry 3 bits (the ATM service class). We must expect that NSIS will run into even more severe complexity explosion unless we figure out how to abstract this issue. Bob Braden *> =20 *> R=FCdiger Geib>*>=20 *> >*> Further, there's a parameter "L2 properties". It should=20 *> >*> be removed without replacement. Layer 2 issues are=20 *> >*> opaque to NSIS signalling. A network operator learns=20 *> >*> which service is required by NSIS signaling. The *> >*> operator then decides whether his network meets these service *> >*> requirements or whether it doesn't. If NSIS signaling=20 *> >*> will contain a Layer 2 specific service descriptor=20 *> >*> combining every possible layer 2 with every possible=20 *> >*> interpretation of service mapping per operator, we *> >*> don't need NSIS. by the way, didn't we agree to limit=20 *> >*> NSIS strictly to layer 3? *> > =20 *> Bob Braden>=20 *> > I would suggest that this issue needs more thought. I can tell you *> > that our ATM friends are adding a whole new object class to RSVP[-TE] *> > to carry one 3-bit integer encoding the ATM Qos class -- CBR, etc. I *> > know because the IANA asked me as RSVP expert to comment on the *> > assignment of an RSVP class number. I think that this particular *> > extension is severely brain-dead; it should rather be a single CType *> > for an L2 properties object (or be in a flowspec). Unfortunately this *> > work, like a lot of the stuff going on now, is outside the IETF so I *> > have no say. However, it does show that L2 properties may=20 *> > have a place in the general signaling regime (which *I* think=20 *> > is what the present NSIS WG should be addressing, not just a=20 *> > particular subset such as QoS). *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 14:24:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18564 for ; Thu, 24 Oct 2002 14:24:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OIQ7q02365 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 14:26:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OIQ5v02350; Thu, 24 Oct 2002 14:26:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OIPSv02325 for ; Thu, 24 Oct 2002 14:25:28 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18534 for ; Thu, 24 Oct 2002 14:23:04 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9OIPMa15057; Thu, 24 Oct 2002 11:25:22 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id SAA00851; Thu, 24 Oct 2002 18:25:22 GMT Date: Thu, 24 Oct 2002 18:25:22 GMT Message-Id: <200210241825.SAA00851@gra.isi.edu> To: brunner@ccrle.nec.de, mshore@cisco.com Subject: Re: [NSIS] WG Last call on the Requirements Draft? Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> > But as far as I have seen the list the consensus was to *> > not rule-out the off-path (what ever it is, see the E-Mail *> > thread on that), but focus on the on-path. And I hope that *> > the formulation does reflect this. Or in other words if *> > we find a protocol which works mainly on-path but also for *> > off-path we can still use it in NSIS and are not obliged *> > to throw it away. *> *> I think it would be a big mistake and could easily result in *> never producing a working protocol. It would be helpful if *> someone who thinks that it is in scope could scratch *> together a diagram of how they think it might work. *> *> That's not to say that I think this is not IETF work - I do *> think it is. I just don't think that it could reasonably *> fit into an end-to-end signaling protocol. As it happens, *> there is a diagram in the framework document of how it could *> be done by NSIS working in conjunction with another *> protocol, and that's Figure 8. *> *> Melinda Melinda, I assume this discussion is about the extent to which the NSIS WG should consider path-decoupled signaling, right? Here is a suggestion. Hopefully we can define a CSTP protocol layer that could be essentially [weasel word] the same for either path-coupled or path-decoupled signaling. So this moves the issue up to the ALSP layer. It is unclear to me exactly how NSIS is going to wrap itself around the 2-layer model, but I could imagine it defining the CSTP layer and one ALSP for path-coupled QoS signaling. Another WG could then tackle an ALSP (or multiple ALSPs if necessary) for path-decoupled signaling. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 14:57:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19726 for ; Thu, 24 Oct 2002 14:57:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OIx6o04068 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 14:59:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OIx3v04063; Thu, 24 Oct 2002 14:59:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OIuNv03961 for ; Thu, 24 Oct 2002 14:56:23 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19629 for ; Thu, 24 Oct 2002 14:53:58 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9OIuCa07981; Thu, 24 Oct 2002 11:56:12 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id SAA00860; Thu, 24 Oct 2002 18:56:12 GMT Date: Thu, 24 Oct 2002 18:56:12 GMT Message-Id: <200210241856.SAA00860@gra.isi.edu> To: nsis@ietf.org, nsobs@ccrle.nec.de, brunner@ccrle.nec.de Subject: Re: [NSIS] on-path versus off-path discussion Cc: sls@ist-tequila.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> There definitely are some pro and cons for both approaches. See "On path *> and off path signaling for NSIS", draft-schelen-nsis-opopsig-00.txt for a *> discussion on some of them. Furthermore, there are some implementations *> (experimentqal and products) available for centralized QoS provisioning. *> Well, so I just read this draft, and I don't quite get it. I am actually prepared to be persuaded about the suggested mixed model, although I note that some of the detailed arguments against path-coupled signaling seem to me of the form, "If you do something dumb, it won't work". However, the discussion seemed to gloss over a basic issue. I hope you can explain it to me. The purpose of signaling is not just to use up bandwidth, I hope; it actually exerts some control function on the routers along the path for some set of data packets. We customarily summarize that by saying that the purpose of signaling is to establish state in routers (and we mean of course the routers on the data path!). So suppose you have a set of distinct off-path signaling nodes that are happily chatting with each other doing path=decoupled signaling. Presumably, each of these control nodes then somehow sends control information to the routers in its own flock, to set up filters, packet queueing parameters, etc., to obtain the desired QoS. My question is, how is this off-path/on-path local signaling done? And doesn't this add a whole new dimension of complexity and fragility?? Looking forward to understanding, Bob Braden *> We need to clarify what the way forward is concerning off-path signaling. *> On-path is in the charter of the NSIS WG. Additionally, there are a number *> of issues for clarifying what on-path includes. In certain cases the *> boundary is not straight forward. *> *> Currently, there seam to be 3 positions in the community: *> 1) Forget about off-path, nobody will use it and it is architecturally *> problematic in IP networks *> 2) Form a new WG taking care of the off-path issue completely independent *> of NSIS. *> 3) Require NSIS to work for on- and off-path signaling, because data *> objects to be carried by the protocol should basically be the same in both *> cases, and a soft-state approach is worth for off-path as well. *> *> Current draft dealing with some of the issues *> "On path and off path signaling for NSIS", draft-schelen-nsis-opopsig-00.txt *> *> Discussion list: *> mailing list is called "nsobs", which stands for "Next Steps in Out-of-Band *> Signaling" is Majordomo list at ccrle.nec.de *> *> To subscribe send e-mail to nsobs-request@ccrle.nec.de with subscribe in *> the body. *> *> To send E-Mail to the list use nsobs@ccrle.nec.de *> *> *> -------------------------------------- *> 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 *> personal home page: http://www.brubers.org/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 *> 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 mailnull@www1.ietf.org Thu Oct 24 15:04:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20012 for ; Thu, 24 Oct 2002 15:04:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OJ6QJ04467 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 15:06:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OJ69v04423; Thu, 24 Oct 2002 15:06:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OJ54v04365 for ; Thu, 24 Oct 2002 15:05:04 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19917 for ; Thu, 24 Oct 2002 15:02:40 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9OJ4sa25355; Thu, 24 Oct 2002 12:04:54 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA00869; Thu, 24 Oct 2002 19:04:54 GMT Date: Thu, 24 Oct 2002 19:04:54 GMT Message-Id: <200210241904.TAA00869@gra.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, robert.hancock@roke.co.uk Subject: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> *> 11. Handoff decision and trigger sources: An NSIS protocol is not *> *> used to trigger handoffs in mobile IP, nor is it used to decide *> > *> > Why not, and who says? *> > *> *> whether to handoff or not. As soon as or in some situation even *> *> before a handoff happened, an NSIS protocol might be used for *> *> signaling for QoS again. However, NSIS MUST interwork with several *> *> protocols for mobility management. *> *> *> *> this question pops up periodically in some form (see also threads on *> route pinning and bidirectional reservations). *> *> i think the basic (simplifying) assumption has been that the route *> comes first (defining the path) and the signalling comes after it *> (following the path). [this doesn't prevent a signalling application at *> some node interacting with something that modifies the path, but the *> requirement is then just for NSIS to live with that possibility.] since *> a handoff is a basically a route change, it comes into this category; *> if we don't make some assumption like this it's impossible to see where *> nsis stops and things like seamoby CARD start. Robert, OK, now I understand what you meant. I think the paragraph should be more carefully worded. *> *> i certainly used to think this was a reasonable restriction (and still *> do, for the 'NSIS base protocol'). but if we are trying to broaden our *> minds to think of possible NSIS uses (cf. your initial comments) should *> we also be thinking about signalling applications that set up or modify *> routes? This is certainly a hard problem, which we struggled with in RSVP. We took the same approach you suggest, simply because to do anything else (like entangling QoS signaling with routing) seemed doomed to complexity death. *> *> *> 5.4.3 Independence of reservation identifier *> *> *> *> A reservation identifier, which is independent of the flow *> *> identifier (flow end-points), MUST be used. Various scenarios in the *> *> mobility area require this independence because flows resulting from *> *> handoff might have changed end-points etc. but still have the same *> *> service requirement. Also several proxy-based signaling methods *> *> might profit from such as independence. *> > *> > The semantics of this identifier needs to be precisely defined. It is *> > unclear whether it needs to be used E-E, or only in the mobile domain. *> > *> *> we agonised about precisely this detail in the framework document *> (current status: we don't know.) one point to make is that i don't *> think you can restrict the scope of the identifier to a 'mobile domain' *> because route changes due to mobility may have an impact anywhere along *> the data path (all the way up to the correspondent). *> Robert, I would like to understand myself what the issue is here. What function does the identifier serve? Exactly what will be done differently if you have the identifier? I can imagine that its function is to prevent "trading" reservations when end points move, i.e., it allows you to reuse the resources you already have for an ongoing call, rather than allocating new resources and freeing the old ones. Is that right? (If so, it seems like a second-order optimization that might be nice but is not critical.) Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 18:00:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25191 for ; Thu, 24 Oct 2002 18:00:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OM2JU14363 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 18:02:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OM2Gv14356; Thu, 24 Oct 2002 18:02:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OM1tv14337 for ; Thu, 24 Oct 2002 18:01:55 -0400 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25159 for ; Thu, 24 Oct 2002 17:59:31 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Oct 2002 23:01:48 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5BC4@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden , mshore@cisco.com Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org Subject: terminology: "peer" or "neighbo[u]r"? (was: RE: [NSIS] framework discussion) Date: Thu, 24 Oct 2002 23:01:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, The framework currently uses the term 'peer' to refer to an NSIS entity that is communicating directly with another NSIS entity. There is some desire to use the term 'neighbour' (or 'neighbor') instead. I'm not wedded to any particular terminology (although my suggestion to drop the term 'session' has so far met only with shocked silence). I think the term 'peer' is pretty widely used in IETF discussions (diameter, ntp, ldp, l2tp, ppp, bgp, beep, ike, ...) and emphasises that NSIS is not about client server architectures; also, 'neighbour' (to me) has a strong connotation of 'on the same link as' or generally 'topologically close to'. However, if the term 'peer' is causing obscurity/confusion, I can change it. (nearly the simplest change for an editor to make, after all.) views? robert h. > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: 24 October 2002 17:51 > To: mshore@cisco.com > Cc: sven.van_den_bosch@alcatel.be; nsis@ietf.org; braden@ISI.EDU > Subject: Re: [NSIS] framework discussion > > > *> > *> > [Sven] I have the same understanding as you have (just > peer discovery, not > *> > path/NI discovery). If this resolves the issue that > would be great. > *> > *> Routing problems tend to be very difficult, and in the > *> context of this protocol I'm unclear on what it means to > *> talk about peer discovery without also talking about path > *> discovery. Peer relationships *by themselves* really aren't > *> very meaningful. > *> > *> Melinda > > Melinda, > > Hmmm. I believe that Sven was using the term "peer" for what we > in the Internet world customarily call a "neighbor". Neighbor > discovery is pretty fundamental to many routing protocols, right? And > I believe it will be fundamental to a signaling protocol. (See my > earlier message about "session"). Perhaps we are talking about > different things here, or am I just misunderstanding? > > Bob Braden > > *> _______________________________________________ > *> nsis mailing list > *> nsis@ietf.org > *> https://www1.ietf.org/mailman/listinfo/nsis > *> > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 18:01:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25256 for ; Thu, 24 Oct 2002 18:01:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OM36x14457 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 18:03:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OM32v14430; Thu, 24 Oct 2002 18:03:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OM26v14346 for ; Thu, 24 Oct 2002 18:02:06 -0400 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25162 for ; Thu, 24 Oct 2002 17:59:41 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Oct 2002 23:01:58 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5BC5@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden , nsis@ietf.org Subject: nsis mobility interactions (was: RE: [NSIS] Some comments on draf t-ietf-nsis-req-04.txt) Date: Thu, 24 Oct 2002 23:01:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Bob, brief comments in line: > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: 24 October 2002 20:05 > To: braden@ISI.EDU; nsis@ietf.org; Hancock, Robert > Subject: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt > > > > *> > *> *> 11. Handoff decision and trigger sources: An NSIS > protocol is not > *> *> used to trigger handoffs in mobile IP, nor is it > used to decide > *> > > *> > Why not, and who says? > *> > > *> *> whether to handoff or not. As soon as or in some > situation even > *> *> before a handoff happened, an NSIS protocol might > be used for > *> *> signaling for QoS again. However, NSIS MUST > interwork with several > *> *> protocols for mobility management. > *> *> > *> > *> this question pops up periodically in some form (see > also threads on > *> route pinning and bidirectional reservations). > *> > *> i think the basic (simplifying) assumption has been that > the route > *> comes first (defining the path) and the signalling comes after it > *> (following the path). [this doesn't prevent a signalling > application at > *> some node interacting with something that modifies the > path, but the > *> requirement is then just for NSIS to live with that > possibility.] since > *> a handoff is a basically a route change, it comes into > this category; > *> if we don't make some assumption like this it's > impossible to see where > *> nsis stops and things like seamoby CARD start. > > Robert, > > OK, now I understand what you meant. I think the paragraph should be > more carefully worded. [reh] i'll leave that to marcus [emphatic grin] > > *> > *> i certainly used to think this was a reasonable > restriction (and still > *> do, for the 'NSIS base protocol'). but if we are trying > to broaden our > *> minds to think of possible NSIS uses (cf. your initial > comments) should > *> we also be thinking about signalling applications that > set up or modify > *> routes? > > This is certainly a hard problem, which we struggled with in RSVP. > We took the same approach you suggest, simply because to do anything > else (like entangling QoS signaling with routing) seemed doomed to > complexity death. [reh] i have to agree it is low on my list of priorities; maybe we should leave the door open. > > *> > *> *> 5.4.3 Independence of reservation identifier > *> *> > *> *> A reservation identifier, which is independent of the flow > *> *> identifier (flow end-points), MUST be used. > Various scenarios in the > *> *> mobility area require this independence because > flows resulting from > *> *> handoff might have changed end-points etc. but > still have the same > *> *> service requirement. Also several proxy-based > signaling methods > *> *> might profit from such as independence. > *> > > *> > The semantics of this identifier needs to be precisely > defined. It is > *> > unclear whether it needs to be used E-E, or only in > the mobile domain. > *> > > *> > *> we agonised about precisely this detail in the framework document > *> (current status: we don't know.) one point to make is > that i don't > *> think you can restrict the scope of the identifier to a > 'mobile domain' > *> because route changes due to mobility may have an impact > anywhere along > *> the data path (all the way up to the correspondent). > *> > > Robert, > > I would like to understand myself what the issue is here. What > function does the identifier serve? Exactly what will be done > differently if you have the identifier? > > I can imagine that its function is to prevent "trading" reservations > when end points move, i.e., it allows you to reuse the resources you > already have for an ongoing call, rather than allocating new resources > and freeing the old ones. Is that right? (If so, it seems like a > second-order optimization that might be nice but is not critical.) [reh] You have it precisely. Whether it is critical seems to be a matter for debate. Certainly, there seem to be strong proponents; particular aspects to consider are that teardown may be difficult in a hard handover situation, and it might also be nice to short circuit authorisation stages and so on. There are some interesting discussions in draft-thomas-seamoby-rsvp-analysis-00.txt (now sadly expired) and draft-westphal-nsis-qos-mobileip-00.txt. At the moment, my only opinion on this feature is that it is hard to support. > > Bob > cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 18:16:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25577 for ; Thu, 24 Oct 2002 18:16:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9OMIIk15492 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 18:18:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OMIDv15485; Thu, 24 Oct 2002 18:18:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OMHAv15465 for ; Thu, 24 Oct 2002 18:17:10 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25567 for ; Thu, 24 Oct 2002 18:14:45 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9OMGxa06667; Thu, 24 Oct 2002 15:16:59 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA01129; Thu, 24 Oct 2002 22:16:59 GMT Date: Thu, 24 Oct 2002 22:16:59 GMT Message-Id: <200210242216.WAA01129@gra.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, robert.hancock@roke.co.uk Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some comments on draf t-ietf-nsis-req-04.txt) X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> [reh] You have it precisely. Whether it is critical seems to be a matter for debate. Certainly, there seem to be strong proponents; particular aspects to consider are that teardown may be difficult in a hard handover situation, Robert, I don't grok the difficult teardown. If you are moving from node A to node B, you need to send a teardown message to node A and a new allocation message to node B, right? The only question is how you identify the resources in A -- do you use an identifier, or do you use the (old) source and destination IP addresses? I don't see that the identifier buys anything. What am I missing? Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 24 19:01:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26304 for ; Thu, 24 Oct 2002 19:01:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ON3Z117093 for nsis-archive@odin.ietf.org; Thu, 24 Oct 2002 19:03:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ON3Wv17085; Thu, 24 Oct 2002 19:03:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ON2Fv17042 for ; Thu, 24 Oct 2002 19:02:15 -0400 Received: from mailrelay1.alcatel.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26247 for ; Thu, 24 Oct 2002 18:59:49 -0400 (EDT) From: Axel.Kuttner@alcatel.de Received: from slsas5.stgl.netd.alcatel.de (slsas5.stgl.netd.alcatel.de [149.204.45.57]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id BAA00720 for ; Fri, 25 Oct 2002 01:02:04 +0200 (MET DST) To: nsis@ietf.org Message-ID: Date: Fri, 25 Oct 2002 01:02:02 +0200 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.9 |November 16, 2001) at 10/25/2002 01:02:05 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Subject: [NSIS] Axel KUTTNER/DE/ALCATEL is out of the office. Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I will be out of the office starting 25.10.2002 and will not return until 01.11.2002. Thank you for keeping me informed. I will respond to your message when I return. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 02:54:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14313 for ; Fri, 25 Oct 2002 02:54:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P6uWx14485 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 02:56:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P6uTv14478; Fri, 25 Oct 2002 02:56:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P6tLv14431 for ; Fri, 25 Oct 2002 02:55:21 -0400 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14302 for ; Fri, 25 Oct 2002 02:52:51 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 25 Oct 2002 08:54:45 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Oct 2002 08:54:17 +0200 Message-Id: From: "Geib, Ruediger" To: braden@ISI.EDU Cc: nsis@ietf.org Subject: RE: [NSIS] New NSIS-related drafts - L2 issue Date: Fri, 25 Oct 2002 08:54:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Bob, thanks for your reply. One more point I'd like to add: Obviously end to end signaling messages and the related data flows will cross a variety of different layer two technologies. If NSIS allows for L2 specific information, it will have to define where it is added for which L2, and who's allowed to add (and discard) it. I'm interested in a simple and stable signaling protocol to start with. I'd appreciate if NSIS tried to work out that, before it specifies more complex solutions. Regrads > You raise hard questions and I don't know the answers. As IANA expert > on RSVP registration, I currently know of four separate requests for > RSVP extensions, some of which are L2 specific. One extension defines > a new object to carry two bits that are telephony-related; another > defines a new option to carry 3 bits (the ATM service class). We must > expect that NSIS will run into even more severe complexity explosion > unless we figure out how to abstract this issue. > > Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 03:14:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14573 for ; Fri, 25 Oct 2002 03:14:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P7GZK15649 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 03:16:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P7GWv15642; Fri, 25 Oct 2002 03:16:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P7ERv15551 for ; Fri, 25 Oct 2002 03:14:27 -0400 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14508 for ; Fri, 25 Oct 2002 03:11:57 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 25 Oct 2002 09:14:09 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Oct 2002 09:13:15 +0200 Message-Id: From: "Geib, Ruediger" To: braden@ISI.EDU Cc: nsis@ietf.org Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draf t-ietf-nsis-req-04.txt) Date: Fri, 25 Oct 2002 09:13:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9P7ERv15552 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Bob, if node B gets a new allocation message with a different source address than the old one, the complete path will be reserved again and the old reservation will time out, doesn't it? The identifier may be used to prevent that, I think. Regards, Rüdiger > *> [reh] You have it precisely. Whether it is critical > seems to be a matter for debate. Certainly, there seem to be > strong proponents; particular aspects to consider are that > teardown may be difficult in a hard handover situation, > > [Bob] > I don't grok the difficult teardown. If you are moving from node A > to node B, you need to send a teardown message to node A and a new > allocation message to node B, right? The only question is how you > identify the resources in A -- do you use an identifier, or > do you use the (old) source and destination IP addresses? I don't > see that the identifier buys anything. What am I missing? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 04:57:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16356 for ; Fri, 25 Oct 2002 04:57:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P8xO420863 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 04:59:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P8xMv20849; Fri, 25 Oct 2002 04:59:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P8wDv20830 for ; Fri, 25 Oct 2002 04:58:13 -0400 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16336 for ; Fri, 25 Oct 2002 04:55:43 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Oct 2002 09:58:00 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA635@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Bob Braden'" , nsis@ietf.org Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) Date: Fri, 25 Oct 2002 09:57:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi Bob, > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: 24 October 2002 23:17 > To: braden@ISI.EDU; nsis@ietf.org; Hancock, Robert > Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some comments > on draf t-ietf-nsis-req-04.txt) > > > *> > *> [reh] You have it precisely. Whether it is critical > seems to be a matter for debate. Certainly, there seem to be > strong proponents; particular aspects to consider are that > teardown may be difficult in a hard handover situation, > > Robert, > > I don't grok the difficult teardown. If you are moving from node A > to node B, you need to send a teardown message to node A and a new > allocation message to node B, right? The only question is how you > identify the resources in A -- do you use an identifier, or > do you use the (old) source and destination IP addresses? I don't > see that the identifier buys anything. What am I missing? > > Bob > Whenever i think about this, i have to admit i get confused. (One of the reasons i like the thomas seamoby draft is the abstract, which starts "IP Mobility along with RSVP makes my head hurt".) But in the hard handover (break-before-make situation), the sort of reasoning is: *) if you send the tear before the handover, you will lose the whole e2e path (can't find the crossover point without signaling via the new router); *) if you wait until after the handover, you no longer have the ability to signal via the old router and you can't tear the dead branch down. So, what would be nice is if you could send some message after the handover which had a reference to the old reservation in a way which allowed the dead branch to be removed. (NB this path tear problem is only one of the problems, of course. the analysis documents contain several others.) This 'reference' is generically referred to as a reservation identifier, but I guess all sorts of other techniques could also be used (something dependent on a context transfer protocol - although that sort of dependency is objected to - or simply talking directly about the old reservation, but needing some token to establish that talking about it was authorised and the token is then the identifier or maybe the crossover point is behind a NAT, or ...) Maybe the requirement needs to be more abstractly phrased - the view that a "path-independent reservation identifier" is the right solution is pretty deep seated that it's kind of turned into a requirement in its own right, but our requirements document could be more problem oriented. Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 05:49:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17402 for ; Fri, 25 Oct 2002 05:49:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P9pEH23993 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 05:51:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P9pBv23935; Fri, 25 Oct 2002 05:51:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P9nwv23817 for ; Fri, 25 Oct 2002 05:49:58 -0400 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17241 for ; Fri, 25 Oct 2002 05:47:38 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9P9nYw05474 for ; Fri, 25 Oct 2002 12:49:34 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Oct 2002 12:49:55 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Oct 2002 12:49:53 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last call on the Requirements Draft? X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 25 Oct 2002 12:49:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0170AA36@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] WG Last call on the Requirements Draft? Thread-Index: AcJ7itjYRL1qGbD4Raud6Y8ZmXhQvgAY+aBg To: , , Cc: X-OriginalArrivalTime: 25 Oct 2002 09:49:53.0391 (UTC) FILETIME=[DE2F1FF0:01C27C0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9P9nwv23818 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, > Here is a suggestion. Hopefully we can define a CSTP protocol layer > that could be essentially [weasel word] the same for either > path-coupled or path-decoupled signaling. So this moves the issue up > to the ALSP layer. It is unclear to me exactly how NSIS is going to > wrap itself around the 2-layer model, but I could imagine it defining > the CSTP layer and one ALSP for path-coupled QoS signaling. Another > WG could then tackle an ALSP (or multiple ALSPs if necessary) for > path-decoupled signaling. I agree with you. This has been my thought all along. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 05:49:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17416 for ; Fri, 25 Oct 2002 05:49:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P9pFQ24024 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 05:51:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P9pCv23965; Fri, 25 Oct 2002 05:51:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P9nvv23815 for ; Fri, 25 Oct 2002 05:49:57 -0400 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17240 for ; Fri, 25 Oct 2002 05:47:38 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9P9nXw05443 for ; Fri, 25 Oct 2002 12:49:33 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Oct 2002 12:49:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Oct 2002 12:49:53 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] framework discussion X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 25 Oct 2002 12:49:50 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0170AA3A@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] framework discussion Thread-Index: AcJ7f+CnCXgeSZ2gS3CFX+PXMfzoPQAcAhwQ To: , Cc: , X-OriginalArrivalTime: 25 Oct 2002 09:49:53.0647 (UTC) FILETIME=[DE562FF0:01C27C0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9P9nwv23820 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, Sven and/or Bob, > > Hmmm. I believe that Sven was using the term "peer" for what we > > in the Internet world customarily call a "neighbor". Neighbor > > discovery is pretty fundamental to many routing protocols, > right? And > > I believe it will be fundamental to a signaling protocol. (See my > > earlier message about "session"). Perhaps we are talking about > > different things here, or am I just misunderstanding? > > See my answer to Robert. I think we may be having some > terminological problems, plus I was responding to Sven's > comment that we need peer discovery but not path/NI > discovery. It seems to me that we need both. It may (or > may not!) be useful to think about policy-based routing when > sorting this through. Please suggest text to go into the Framework document. rather than discussing the need for terminology, let's get some resolution. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 05:49:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17428 for ; Fri, 25 Oct 2002 05:49:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P9pGP24050 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 05:51:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P9pDv23980; Fri, 25 Oct 2002 05:51:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P9o0v23831 for ; Fri, 25 Oct 2002 05:50:00 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17246 for ; Fri, 25 Oct 2002 05:47:40 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9P9o9H10950 for ; Fri, 25 Oct 2002 12:50:09 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Oct 2002 12:49:55 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Oct 2002 12:49:54 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] framework discussion X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 25 Oct 2002 12:49:54 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0170AA3B@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] framework discussion Thread-Index: AcJ7g7l511Khn+BNQaC62JJxHq6BjgAbGdVA To: , Cc: , X-OriginalArrivalTime: 25 Oct 2002 09:49:54.0922 (UTC) FILETIME=[DF18BCA0:01C27C0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9P9o0v23833 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, > Yup. Looking broadly at the recent discussions, I would suggest that > we should generally unqualified words like "path" and "discovery". > > Thus, I think we can all agree that "neighbor discovery" and "path > discovery" are two different issues with different requirements (and > probably different mechanisms.) I think I hear some saying that > *neighbor discovery* might need a separate phase while others say (as I > implied in the 2-level document) that neighbor discovery will generally > happen without any additional packet exchanges. I hear you saying the > the RVSP scheme of *path discovery* works very well (which *I* > certainly won't disagree with ;-)). So, I propose that we add 'Neighbor Discover' (perhaps prefix it with NSIS, so we don't confuse it with IPv6 Neighbor Discovery) & 'Path Discovery' to the framework & requirements (if needed there) and use these. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 05:49:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17432 for ; Fri, 25 Oct 2002 05:49:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P9pGH24062 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 05:51:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P9pEv24007; Fri, 25 Oct 2002 05:51:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P9o0v23837 for ; Fri, 25 Oct 2002 05:50:00 -0400 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17247 for ; Fri, 25 Oct 2002 05:47:40 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9P9nZw05492 for ; Fri, 25 Oct 2002 12:49:35 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Oct 2002 12:49:55 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Oct 2002 12:49:54 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 25 Oct 2002 12:49:41 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0170AA37@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] Some comments on draft-ietf-nsis-req-04.txt Thread-Index: AcJ7kG+S0Kvi5o+nS8KgQwTf9/yguAAXqmjg To: , , X-OriginalArrivalTime: 25 Oct 2002 09:49:54.0485 (UTC) FILETIME=[DED60E50:01C27C0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9P9o0v23839 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, > I would like to understand myself what the issue is here. What > function does the identifier serve? Exactly what will be done > differently if you have the identifier? > > I can imagine that its function is to prevent "trading" reservations > when end points move, i.e., it allows you to reuse the resources you > already have for an ongoing call, rather than allocating new resources > and freeing the old ones. Is that right? (If so, it seems like a > second-order optimization that might be nice but is not critical.) Have you seen Michael Thomas' analysis of RSVP and Mobile IP? It is expired, but perhaps I should ask him to revise it. It brings forth some key problems when you mix RSVP & MIP. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 05:49:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17458 for ; Fri, 25 Oct 2002 05:49:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9P9pIh24074 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 05:51:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P9pFv24038; Fri, 25 Oct 2002 05:51:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P9o0v23838 for ; Fri, 25 Oct 2002 05:50:00 -0400 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17237 for ; Fri, 25 Oct 2002 05:47:36 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9P9o5H10869 for ; Fri, 25 Oct 2002 12:50:05 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Oct 2002 12:49:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Oct 2002 12:49:53 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] [Requirements draft] Scenarios X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 25 Oct 2002 12:49:34 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0170AA35@esebe004.ntc.nokia.com> Thread-Topic: [NSIS] [Requirements draft] Scenarios Thread-Index: AcJ7hdVVSRfIorWlQx+9pO2ZW6DBDQAaJXLg To: , , X-OriginalArrivalTime: 25 Oct 2002 09:49:53.0225 (UTC) FILETIME=[DE15CB90:01C27C0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9P9o0v23841 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, I agree with you. I think that after we do some basic work on NSIS (Requirements & Framework last called & a good start on the protocol work) discussing how to apply NSIS for solutions or applying to networks would be an appropriate time. John > -----Original Message----- > From: ext Bob Braden [mailto:braden@ISI.EDU] > Sent: 24 October, 2002 20:50 > To: nsis@ietf.org; AAvella@carrieraccess.com > Subject: Re: [NSIS] [Requirements draft] Scenarios > > > *> > *> I believe the Appendix of the [Requirements draft] could > be enhanced with > *> scenarios from the ISC Reference Arquitecture. > *> > *> > http://www.softswitch.org/attachments/Reference_Architecture_5-02.pdf > *> > > Well, maybe yes, maybe no. Voice over IP is certainly an important > potential application of NSIS protocols, but by no means the only one, > and in the long run it might not even be the most important. (Ask > me sometime about my success in predicting the future of the > Internet ;-)) > > However, I would note that driving NSIS from VoIP requiremetns would > entangle the NSIS WG with a hugely complex > telephone infrastructure. Trying too hard to accommodate its > complexities is likely to distort our efforts and lead us away from > the more important goals of generality and extensibility. I > have the same uneasy > feelinga about the wireless material in the Appendix, BTW. > What we need > is some abstraction of the requirements of VoIP and of > wireless. In the > Internet we want signaling protocols that are flexible, generel, and > extensible. As you penetrate deep into wireless networks or into the > phone network, I would expect special-purpose signaling protocols to > be used. It seems to me that the right way to model these complex > special environments is as individual link layers, with IP over top. > Just as RSVP can invoke link layer signaling, e.g., ATM (RFC2382) or > IEEE 802 (RFC 2814), so an Internet NSIS signaling protocol can invoke > the wireless or phone network signaling protocol. > > I would rather see much less emphasis on telephony in the Appendx, > and a broader range of Internet signaling applications. > > Bob Braden > > > *> Network Examples > *> > .............................................................. > .............. > *> .......................13 > *> Wireline Network > *> > .............................................................. > .............. > *> ...................................................13 > *> All-IP Network....14 > *> VoIP Tandem > *> > Switching..................................................... > .............. > *> .................................................16 > *> POTS Carried over IP > *> > .............................................................. > .............. > *> ...........................................16 > *> Access Network (V5/ISDN) over > *> > IP............................................................ > .............. > *> .........................17 > *> Cable Network (e.g. PacketCable(tm)) over > *> > IP............................................................ > .............. > *> ..........17 > *> VoDSL and IAD over IP > *> > .............................................................. > .............. > *> ........................................18 > *> Wireless (3GPP R99 Special Case NGN) > *> > .............................................................. > .............. > *> ............19 > *> Wireless (3GPP R2000 General Case all IP) > *> > .............................................................. > .............. > *> .......19 > *> WCDMA Mobile Network > *> > .............................................................. > .............. > *> ......................................20 > *> > *> Alejandro Avella > *> > *> [Requirements draft] > *> http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-04.txt > *> > *> > *> > ************************************************************** > *********** > *> This e-mail transmission, and any documents, files, or previous > *> e-mail messages attached to it may contain information that is > *> confidential or legally privileged. If you are not the intended > *> recipient, or a person responsible for delivering it to the > *> intended recipient, you are hereby notified that you must not > *> read this transmission and that any disclosure, copying, > printing, > *> distribution, or use of any of the information contained in or > *> attached to this transmission is strictly prohibited. > If you have > *> received this transmission in error, please immediately > notify the > *> sender by telephone or return e-mail and delete the original > *> transmission and its attachments without reading or saving them > *> in any manner. Thank you. > *> > ************************************************************** > *********** > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 08:15:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22086 for ; Fri, 25 Oct 2002 08:15:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PCHLp32646 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 08:17:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PCHIv32635; Fri, 25 Oct 2002 08:17:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PCG1v32550 for ; Fri, 25 Oct 2002 08:16:01 -0400 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22018 for ; Fri, 25 Oct 2002 08:13:39 -0400 (EDT) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g9PCFu801753 for ; Fri, 25 Oct 2002 15:15:57 +0300 Date: Fri, 25 Oct 2002 15:15:56 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA635@rsys002a.roke.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , (mobility discussions, my favorite! :) Hi, Removing the old reservation is definitely an interesting question, but couldn't you rely on the refresh timers and set them "short enough" for the MN<->AR link? What I am getting at is the following two scenarios: a) IF you have a context transfer (CT) mechanism, once the QoS requirements at set up on the new AR (& path), the CT mechanisms can trigger the NSIS daemon running on the old AR to remove the reservation on the old path b) If you DON'T have CT at hand, you can rely on the soft state mechanism to remove the old reservation. How quickly this happens is a question of refresh timers and QoS allocation strategies. I could image having a Tear-message that has a timer associated with it: "Remove this reservation when the time comes". Well, to be honest, this does sound like a needless hack, so let's stay with the "simple" soft state mechanisms... for now... Regards, Jukka On Fri, 25 Oct 2002, Hancock, Robert wrote: > hi Bob, > > > -----Original Message----- > > From: Bob Braden [mailto:braden@ISI.EDU] > > Sent: 24 October 2002 23:17 > > To: braden@ISI.EDU; nsis@ietf.org; Hancock, Robert > > Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some comments > > on draf t-ietf-nsis-req-04.txt) > > > > > > *> > > *> [reh] You have it precisely. Whether it is critical > > seems to be a matter for debate. Certainly, there seem to be > > strong proponents; particular aspects to consider are that > > teardown may be difficult in a hard handover situation, > > > > Robert, > > > > I don't grok the difficult teardown. If you are moving from node A > > to node B, you need to send a teardown message to node A and a new > > allocation message to node B, right? The only question is how you > > identify the resources in A -- do you use an identifier, or > > do you use the (old) source and destination IP addresses? I don't > > see that the identifier buys anything. What am I missing? > > > > Bob > > > > Whenever i think about this, i have to admit i get confused. (One of the reasons i like the thomas seamoby draft is the abstract, which starts "IP Mobility along with RSVP makes my head hurt".) > > But in the hard handover (break-before-make situation), the sort of reasoning is: > *) if you send the tear before the handover, you will lose the whole e2e path (can't find the crossover point without signaling via the new router); > *) if you wait until after the handover, you no longer have the ability to signal via the old router and you can't tear the dead branch down. > So, what would be nice is if you could send some message after the handover which had a reference to the old reservation in a way which allowed the dead branch to be removed. > (NB this path tear problem is only one of the problems, of course. the analysis documents contain several others.) > > This 'reference' is generically referred to as a reservation identifier, but I guess all sorts of other techniques could also be used (something dependent on a context transfer protocol - although that sort of dependency is objected to - or simply talking directly about the old reservation, but needing some token to establish that talking about it was authorised and the token is then the identifier or maybe the crossover point is behind a NAT, or ...) > > Maybe the requirement needs to be more abstractly phrased - the view that a "path-independent reservation identifier" is the right solution is pretty deep seated that it's kind of turned into a requirement in its own right, but our requirements document could be more problem oriented. > > Cheers, > > Robert H. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 08:53:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23263 for ; Fri, 25 Oct 2002 08:53:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PCtCv02278 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 08:55:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PCtAv02271; Fri, 25 Oct 2002 08:55:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PCslv02227 for ; Fri, 25 Oct 2002 08:54:47 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23246 for ; Fri, 25 Oct 2002 08:52:25 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9PCsWot000499; Fri, 25 Oct 2002 05:54:32 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI91626; Fri, 25 Oct 2002 05:49:40 -0700 (PDT) Message-Id: <200210251249.AAI91626@mira-sjc5-4.cisco.com> To: "Hancock, Robert" cc: Bob Braden , sven.van_den_bosch@alcatel.be, nsis@ietf.org From: Melinda Shore Subject: Re: terminology: "peer" or "neighbo[u]r"? (was: RE: [NSIS] framework discussion) In-Reply-To: Message from "Hancock, Robert" of "Thu, 24 Oct 2002 23:01:46 BST." <76C92FBBFB58D411AE760090271ED41805DF5BC4@rsys002a.roke.co.uk> Date: Fri, 25 Oct 2002 08:54:30 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > I'm not wedded to any particular terminology (although my > suggestion to drop the term 'session' has so far met only > with shocked silence). I find the word "session" a little misleading when used to describe traffic that's simply in transit. It may be applicable for a CASP-type protocol but not for an RSVP- type protocol. > However, if the term 'peer' is causing > obscurity/confusion, I can change it. (nearly the simplest > change for an editor to make, after all.) I'm not that fond of "peer," but I think that its use in this context could be explained fairly easily (while it would take some contortions to explain the use of the word "session," as above). "Neighbor" is easily understood in the context of the NSIS layer and might become confusing *only* if you have trouble keeping your layers straight (however, of course, people involved with the IETF never have trouble keeping their layers sorted out, right? :-)). Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 10:34:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26471 for ; Fri, 25 Oct 2002 10:34:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PEaax07707 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 10:36:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PEaXv07669; Fri, 25 Oct 2002 10:36:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PEZIv07627 for ; Fri, 25 Oct 2002 10:35:18 -0400 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26426 for ; Fri, 25 Oct 2002 10:32:57 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9PEZAgM023387; Fri, 25 Oct 2002 07:35:10 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAK62946; Fri, 25 Oct 2002 07:29:13 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA10800; Fri, 25 Oct 2002 07:35:09 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15801.22172.731511.33601@thomasm-u1.cisco.com> Date: Fri, 25 Oct 2002 07:35:08 -0700 (PDT) To: Bob Braden Cc: nsis@ietf.org, robert.hancock@roke.co.uk Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some comments on draf t-ietf-nsis-req-04.txt) In-Reply-To: <200210242216.WAA01129@gra.isi.edu> References: <200210242216.WAA01129@gra.isi.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bob Braden writes: > *> > *> [reh] You have it precisely. Whether it is critical seems to be a matter for debate. Certainly, there seem to be strong proponents; particular aspects to consider are that teardown may be difficult in a hard handover situation, > > Robert, > > I don't grok the difficult teardown. If you are moving from node A > to node B, you need to send a teardown message to node A and a new > allocation message to node B, right? The only question is how you > identify the resources in A -- do you use an identifier, or > do you use the (old) source and destination IP addresses? I don't > see that the identifier buys anything. What am I missing? Bob, I've been following things even less closely than you so I'm even more out to lunch here, but if I understand the jist of some of this thread, I believe that what could be useful is the general concept of reservations which are friendly to changes in the endpoint address (either from mobility or multihoming). As I recall, what would be quire nice is to be able to patch up to the local join point when the endpoint of a reservation changes without requiring (expensive) e2e round trips. John's asked me to repost my RSVP/MIP draft which has some of these kinds of consideration highlighted. After I correct a mistake in it, I'll get it out to the repository. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 12:31:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00859 for ; Fri, 25 Oct 2002 12:31:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PGXac15141 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 12:33:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PGXWv15131; Fri, 25 Oct 2002 12:33:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PGUNv15006 for ; Fri, 25 Oct 2002 12:30:23 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00681 for ; Fri, 25 Oct 2002 12:28:00 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9PGUHa16628; Fri, 25 Oct 2002 09:30:18 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA01385; Fri, 25 Oct 2002 16:30:17 GMT Date: Fri, 25 Oct 2002 16:30:17 GMT Message-Id: <200210251630.QAA01385@gra.isi.edu> To: braden@ISI.EDU, Ruediger.Geib@t-systems.com Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draf t-ietf-nsis-req-04.txt) Cc: nsis@ietf.org X-Sun-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: , *> *> Bob, *> *> if node B gets a new allocation message with a different *> source address than the old one, the complete path will *> be reserved again and the old reservation will time out, *> doesn't it? *> The identifier may be used to prevent that, I think. *> *> Regards, Rüdiger *> Well, yes, that's the obvious approach, and it does not seem to use a reservation identifier. I was trying (and failing) to constuct an argument for why the identifier would help. Thanks, Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 12:51:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01816 for ; Fri, 25 Oct 2002 12:51:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PGrHn16325 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 12:53:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PGrEv16317; Fri, 25 Oct 2002 12:53:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PGowv16254 for ; Fri, 25 Oct 2002 12:50:58 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01627 for ; Fri, 25 Oct 2002 12:48:35 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9PGooa29764; Fri, 25 Oct 2002 09:50:50 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA01419; Fri, 25 Oct 2002 16:50:50 GMT Date: Fri, 25 Oct 2002 16:50:50 GMT Message-Id: <200210251650.QAA01419@gra.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, robert.hancock@roke.co.uk Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> Whenever i think about this, i have to admit i get confused. (One of *> the reasons i like the thomas seamoby draft is the abstract, which *> starts "IP Mobility along with RSVP makes my head hurt".) *> *> But in the hard handover (break-before-make situation), the sort of *> reasoning is: *) if you send the tear before the handover, you will *> lose the whole e2e path (can't find the crossover point without *> signaling via the new router); *) if you wait until after the handover, *> you no longer have the ability to signal via the old router and you *> can't tear the dead branch down. So, what would be nice is if you *> could send some message after the handover which had a reference to the *> old reservation in a way which allowed the dead branch to be removed. *> (NB this path tear problem is only one of the problems, of course. the *> analysis documents contain several others.) Robert, OK, you win, now my head hurts too ;-) The problem, I guess, is that mobile IP breaks the Internet architecture in a fundamental way, so to understand how QoS signaling will work you have to look at the details of how mobile IP works. That's just philosophy, but it does suggest that we need to put the bandage where the wound is -- we probably need a solution that is local to the mobile region, not E2E. Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 13:33:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03527 for ; Fri, 25 Oct 2002 13:33:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PHZFl18551 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 13:35:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PHZ7v18543; Fri, 25 Oct 2002 13:35:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PHX0v18483 for ; Fri, 25 Oct 2002 13:33:00 -0400 Received: from dm3cn8.bell.ca (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03418 for ; Fri, 25 Oct 2002 13:30:35 -0400 (EDT) Received: from 142.122.115.62 by dm3cn8.bell.ca with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Fri, 25 Oct 2002 13:32:53 -0400 X-Server-Uuid: b85f21a3-cfd1-11d3-8401-00104bf46ab7 Received: from bell.ca ([142.122.129.95]) by bt5c69.on.bell.ca (Netscape Messaging Server 4.15 BESI_Messaging_7 Apr 29 2002 13:22:02) with ESMTP id H4JSQT00.9V8 for ; Fri, 25 Oct 2002 13:32:53 -0400 Message-ID: <3DB98043.9C5C381C@bell.ca> Date: Fri, 25 Oct 2002 13:32:51 -0400 From: "PIECHOCINSKI, MACIEJ" Organization: Bell Canada X-Mailer: Mozilla 4.75 [en]C-BESI (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some commentson draft-ietf-nsis-req-04.txt) References: <200210251650.QAA01419@gra.isi.edu> X-WSS-ID: 11A75FCF36008-01-01 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 draft-shen-rsvp-mobileipv6-interop-00.txt addressed some of the issues with RSVP & MIP: -using Home Address as a constant flow/reservation identification -localizing reservation updates -explicit teardown of old path after handoff Maciej Bob Braden wrote: > > *> > *> Whenever i think about this, i have to admit i get confused. (One of > *> the reasons i like the thomas seamoby draft is the abstract, which > *> starts "IP Mobility along with RSVP makes my head hurt".) > *> > *> But in the hard handover (break-before-make situation), the sort of > *> reasoning is: *) if you send the tear before the handover, you will > *> lose the whole e2e path (can't find the crossover point without > *> signaling via the new router); *) if you wait until after the handover, > *> you no longer have the ability to signal via the old router and you > *> can't tear the dead branch down. So, what would be nice is if you > *> could send some message after the handover which had a reference to the > *> old reservation in a way which allowed the dead branch to be removed. > *> (NB this path tear problem is only one of the problems, of course. the > *> analysis documents contain several others.) > > Robert, > > OK, you win, now my head hurts too ;-) The problem, I guess, is that > mobile IP breaks the Internet architecture in a fundamental way, so to > understand how QoS signaling will work you have to look at the details > of how mobile IP works. That's just philosophy, but it does suggest > that we need to put the bandage where the wound is -- we probably > need a solution that is local to the mobile region, not E2E. > > Bob > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 14:08:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05122 for ; Fri, 25 Oct 2002 14:08:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PIAP320922 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 14:10:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PIAMv20912; Fri, 25 Oct 2002 14:10:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PI9Ov20868 for ; Fri, 25 Oct 2002 14:09:24 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05035 for ; Fri, 25 Oct 2002 14:06:59 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9PI9Fa21761; Fri, 25 Oct 2002 11:09:15 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id SAA01495; Fri, 25 Oct 2002 18:09:15 GMT Date: Fri, 25 Oct 2002 18:09:15 GMT Message-Id: <200210251809.SAA01495@gra.isi.edu> To: nsis@ietf.org, maciej.piechocinski@bell.ca Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some commentson draft-ietf-nsis-req-04.txt) X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> draft-shen-rsvp-mobileipv6-interop-00.txt addressed some of the issues *> with RSVP & MIP: *> -using Home Address as a constant flow/reservation identification *> -localizing reservation updates *> -explicit teardown of old path after handoff *> *> Maciej *> Thanks, I will read it on the plane tomorrow. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 18:12:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13682 for ; Fri, 25 Oct 2002 18:12:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PMEJc03389 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 18:14:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PMEGv03384; Fri, 25 Oct 2002 18:14:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PME0v03357 for ; Fri, 25 Oct 2002 18:14:00 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13648 for ; Fri, 25 Oct 2002 18:11:34 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9PMDja07553; Fri, 25 Oct 2002 15:13:46 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA01712; Fri, 25 Oct 2002 22:13:45 GMT Date: Fri, 25 Oct 2002 22:13:45 GMT Message-Id: <200210252213.WAA01712@gra.isi.edu> To: nsis@ietf.org, jmanner@cs.Helsinki.FI Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> Removing the old reservation is definitely an interesting *> question, but couldn't you rely on the refresh timers and set them "short *> enough" for the MN<->AR link? What I am getting at is the following *> two scenarios: *> *> a) IF you have a context transfer (CT) mechanism, once the QoS *> requirements at set up on the new AR (& path), the CT mechanisms can *> trigger the NSIS daemon running on the old AR to remove the reservation on *> the old path *> Jukka, This sounds like the sort of local (not E2E) mobility-specific mechanism that I had in mind in an earlier message. Maybe the details are not right, but the principle sounds right. *> b) If you DON'T have CT at hand, you can rely on the soft state mechanism *> to remove the old reservation. How quickly this happens is a question of *> refresh timers and QoS allocation strategies. *> If you don't have CT, or if CT fails. It may simplify engineering of the CT mechanism if it is allowed to occasionally fail... the soft state will regardless clean up eventually. *> I could image having a Tear-message that has a timer associated *> with it: "Remove this reservation when the time comes". Well, to be *> honest, this does sound like a needless hack, so let's stay with the *> "simple" soft state mechanisms... for now... Ugh! ;-) Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 18:14:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13720 for ; Fri, 25 Oct 2002 18:14:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PMG6s03453 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 18:16:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PMG3v03446; Fri, 25 Oct 2002 18:16:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PMF9v03421 for ; Fri, 25 Oct 2002 18:15:09 -0400 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13697 for ; Fri, 25 Oct 2002 18:12:43 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g9PMF0a08198; Fri, 25 Oct 2002 15:15:00 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA01715; Fri, 25 Oct 2002 22:15:00 GMT Date: Fri, 25 Oct 2002 22:15:00 GMT Message-Id: <200210252215.WAA01715@gra.isi.edu> To: robert.hancock@roke.co.uk, mshore@cisco.com Subject: Re: terminology: "peer" or "neighbo[u]r"? (was: RE: [NSIS] framework discussion) Cc: braden@ISI.EDU, sven.van_den_bosch@alcatel.be, nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> "session," as above). "Neighbor" is easily understood in *> the context of the NSIS layer and might become confusing "NSIS layer"? Does that mean the CSTP layer? Bob *> *only* if you have trouble keeping your layers straight *> (however, of course, people involved with the IETF never *> have trouble keeping their layers sorted out, right? :-)). *> *> Melinda *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 18:50:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14493 for ; Fri, 25 Oct 2002 18:50:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PMqF004886 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 18:52:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PMqCv04875; Fri, 25 Oct 2002 18:52:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PMpsv04858 for ; Fri, 25 Oct 2002 18:51:54 -0400 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14410 for ; Fri, 25 Oct 2002 18:49:28 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9PMpaPP018834; Fri, 25 Oct 2002 15:51:36 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAJ18549; Fri, 25 Oct 2002 15:46:44 -0700 (PDT) Message-Id: <200210252246.AAJ18549@mira-sjc5-4.cisco.com> To: Bob Braden cc: robert.hancock@roke.co.uk, sven.van_den_bosch@alcatel.be, nsis@ietf.org From: Melinda Shore Subject: Re: terminology: "peer" or "neighbo[u]r"? (was: RE: [NSIS] framework discussion) In-Reply-To: Message from Bob Braden of "Fri, 25 Oct 2002 22:15:00 GMT." <200210252215.WAA01715@gra.isi.edu> Date: Fri, 25 Oct 2002 18:51:34 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > "NSIS layer"? Does that mean the CSTP layer? How about "appropriate"? You might say that an application neighbor or node is invisible to the layer above it and irrelevant to the layer below it, where by "application" we can mean anything from IP to NSIS to VoIP. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Oct 25 21:12:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17410 for ; Fri, 25 Oct 2002 21:12:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9Q1ENl11489 for nsis-archive@odin.ietf.org; Fri, 25 Oct 2002 21:14:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9Q1EKv11482; Fri, 25 Oct 2002 21:14:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9Q1Dmv11429 for ; Fri, 25 Oct 2002 21:13:48 -0400 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17378 for ; Fri, 25 Oct 2002 21:11:21 -0400 (EDT) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g9Q1DSn29958; Fri, 25 Oct 2002 18:13:28 -0700 (PDT) Date: Fri, 25 Oct 2002 18:13:28 -0700 (PDT) From: Bob Braden Message-Id: <200210260113.g9Q1DSn29958@boreas.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, robert.hancock@roke.co.uk Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some comments on draf t-ietf-nsis-req-04.txt) X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> > *> > I can imagine that its function is to prevent "trading" reservations *> > when end points move, i.e., it allows you to reuse the resources you *> > already have for an ongoing call, rather than allocating new resources *> > and freeing the old ones. Is that right? (If so, it seems like a *> > second-order optimization that might be nice but is not critical.) *> *> [reh] You have it precisely. Well, actually, subsequent messages have enlightened me somewhat so now I think I was dead wrong ;-) There certainly is a lot of confusion around this point. Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Oct 26 17:23:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12573 for ; Sat, 26 Oct 2002 17:23:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9QLP2L02166 for nsis-archive@odin.ietf.org; Sat, 26 Oct 2002 17:25:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QLP0v02145; Sat, 26 Oct 2002 17:25:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QLMNv02075 for ; Sat, 26 Oct 2002 17:22:23 -0400 Received: from iramx1.ira.uni-karlsruhe.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12527 for ; Sat, 26 Oct 2002 17:19:56 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iramx1.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 185YNq-0003gd-00; Sat, 26 Oct 2002 23:22:14 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 185YNq-0003li-00; Sat, 26 Oct 2002 23:22:14 +0200 Received: (from bless@localhost) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.6/SuSE Linux 0.5) id g9QLMEi04817; Sat, 26 Oct 2002 23:22:14 +0200 Date: Sat, 26 Oct 2002 23:22:13 +0200 From: Roland Bless To: Bob Braden Cc: nsis@ietf.org, nsobs@ccrle.nec.de, brunner@ccrle.nec.de, sls@ist-tequila.org Subject: Re: [NSIS] on-path versus off-path discussion Message-ID: <20021026232213.A4772@tpce10.ipv6.tm.uka.de> References: <200210241856.SAA00860@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210241856.SAA00860@gra.isi.edu> User-Agent: Mutt/1.3.22.1i Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , On Thu, Oct 24, 2002 at 06:56:12PM +0000, Bob Braden wrote: > > Well, so I just read this draft, and I don't quite get it. I am actually Currently, a new version of the draft is prepared, hopefully with some clearer structure and discussion. > prepared to be persuaded about the suggested mixed model, although I note The basic idea of a "combined" model is that an NSIS protocol should be flexible enough to allow both kinds of signaling without causing real drawbacks for one particular solution. It should work flawlessly with path-coupled signaling, but also allow to add path-decoupled signaling later without the need to redefine the basic protocol format. > that some of the detailed arguments against path-coupled signaling seem > to me of the form, "If you do something dumb, it won't work". > > However, the discussion seemed to gloss over a basic issue. I hope you > can explain it to me. > > The purpose of signaling is not just to use up bandwidth, I > hope; it actually exerts some control function on the routers > along the path for some set of data packets. We customarily > summarize that by saying that the purpose of signaling is to > establish state in routers (and we mean of course the routers > on the data path!). So suppose you have a set of distinct I'm not sure why signaling must always establish state in routers. Wouldn't it be more general to say that signaling is to do something in some sort of "control" plane, e.g. perform admission control, reserve resources, install or update states, change configurations, etc... Typically, in a transit DiffServ domain I can let routers just do their packet forwarding and only need to adapt the profiles in boundary routers once a while. If a BB takes care of admission control etc., there is no need to install state in core routers... Furthermore, you'll need some possibility to store persistent state for managing policy-based admission control and accounting. Routers are usually not able to store persistent states (except their basic config). So why not take all burdens of control processing off the routers and let a real powerful system do the control job? > off-path signaling nodes that are happily chatting with each > other doing path=decoupled signaling. Presumably, each of > these control nodes then somehow sends control information to > the routers in its own flock, to set up filters, packet > queueing parameters, etc., to obtain the desired QoS. My > question is, how is this off-path/on-path local signaling > done? And doesn't this add a whole new dimension of > complexity and fragility?? Usually, it is a local decision how the signaling to routers will be done, so autonomy of a domain is kept. However, there are many possibilities, such as using COPS (I know that opinions will diverge here..), SNMP or even CLIs. Basically, you need a protocol that will be able to transport configuration information, fast, robust and reliable. Maybe we need something new. > Looking forward to understanding, I hope it helps a little bit, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de WWW: www.tm.uka.de/~bless Institute of Telematics, University of Karlsruhe, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Oct 26 21:58:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16993 for ; Sat, 26 Oct 2002 21:58:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9R20qR13793 for nsis-archive@odin.ietf.org; Sat, 26 Oct 2002 22:00:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9R20lv13786; Sat, 26 Oct 2002 22:00:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9R1vnv13731 for ; Sat, 26 Oct 2002 21:57:49 -0400 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16970 for ; Sat, 26 Oct 2002 21:55:20 -0400 (EDT) Received: from pog.isi.edu (ras02.isi.edu [128.9.176.102]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9R1vYC29472; Sat, 26 Oct 2002 18:57:34 -0700 (PDT) Message-Id: <5.1.0.14.2.20021026183942.00a6ce60@boreas.isi.edu> X-Sender: braden@boreas.isi.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 26 Oct 2002 18:55:19 -0700 To: Roland Bless From: Bob Braden Subject: Re: [NSIS] on-path versus off-path discussion Cc: nsis@ietf.org, nsobs@ccrle.nec.de, brunner@ccrle.nec.de, sls@ist-tequila.org In-Reply-To: <20021026232213.A4772@tpce10.ipv6.tm.uka.de> References: <200210241856.SAA00860@gra.isi.edu> <200210241856.SAA00860@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > > > > > However, the discussion seemed to gloss over a basic issue. I hope you > > can explain it to me. > > > > The purpose of signaling is not just to use up bandwidth, I > > hope; it actually exerts some control function on the routers > > along the path for some set of data packets. We customarily > > summarize that by saying that the purpose of signaling is to > > establish state in routers (and we mean of course the routers > > on the data path!). So suppose you have a set of distinct > >I'm not sure why signaling must always establish state in routers. >Wouldn't it be more general to say that signaling is to do something >in some sort of "control" plane, e.g. perform admission control, reserve >resources, install or update states, change configurations, etc... Unnh,,, it sets some bits somewhere in the network, in fact, somewhere on the data path, right? In the Internet model, everything "in the network" is a router, but I don''t need to insist on that. But signaling DOES set control bits SOMEWHERE in the network, right? Those bits are STATE. QED. (else it's not signaling?) >Typically, in a transit DiffServ domain I can let routers just do >their packet forwarding and only need to adapt the profiles in >boundary routers once a while. If a BB takes care of admission control >etc., there is no need to install state in core routers... I didn't say WHICH routers. But the "core routers" are either statically provisioned or else there is some sort of signaling going on to set up their state >Furthermore, you'll need some possibility to store persistent state >for managing policy-based admission control and accounting. Routers >are usually not able to store persistent states (except their basic >config). So why not take all burdens of control processing off the >routers and let a real powerful system do the control job? Well, the statement "real powerful system" seems to ignore Moore's law and the current state of the technology. A high-end router may have processing power equal to any specialized control processor. So your statement seems like a bogus argument. However, it is fundamentally the wrong argument for NSIS -- the right argument would be about architecture, not current technology. > > off-path signaling nodes that are happily chatting with each > > other doing path=decoupled signaling. Presumably, each of > > these control nodes then somehow sends control information to > > the routers in its own flock, to set up filters, packet > > queueing parameters, etc., to obtain the desired QoS. My > > question is, how is this off-path/on-path local signaling > > done? And doesn't this add a whole new dimension of > > complexity and fragility?? > >Usually, it is a local decision how the signaling to routers >will be done, so autonomy of a domain is kept. However, there You mean there will be no interoperable standards? Pooh. >are many possibilities, such as using COPS (I know that opinions >will diverge here..), SNMP or even CLIs. Basically, you need a >protocol that will be able to transport configuration information, >fast, robust and reliable. Maybe we need something new. Yes, and it is signaling. So path-decoupled signaling has added a new source of complexity and fragility, as I suspected. Bob Braden > > > Looking forward to understanding, > >I hope it helps a little bit, > Roland > >-- >Roland Bless -- e-Mail: bless@tm.uka.de WWW: www.tm.uka.de/~bless >Institute of Telematics, University of Karlsruhe, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Oct 27 04:45:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00648 for ; Sun, 27 Oct 2002 04:45:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9R9lXb10826 for nsis-archive@odin.ietf.org; Sun, 27 Oct 2002 04:47:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9R9lTv10819; Sun, 27 Oct 2002 04:47:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9R9kmv10802 for ; Sun, 27 Oct 2002 04:46:48 -0500 Received: from iramx1.ira.uni-karlsruhe.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00645 for ; Sun, 27 Oct 2002 04:44:14 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iramx1.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 185k09-0003M5-00; Sun, 27 Oct 2002 10:46:33 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 185k09-0007Qk-00; Sun, 27 Oct 2002 10:46:33 +0100 Received: (from bless@localhost) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.6/SuSE Linux 0.5) id g9R9kX906610; Sun, 27 Oct 2002 10:46:33 +0100 Date: Sun, 27 Oct 2002 10:46:33 +0100 From: Roland Bless To: Bob Braden Cc: Roland Bless , nsis@ietf.org, nsobs@ccrle.nec.de, brunner@ccrle.nec.de, sls@ist-tequila.org Subject: Re: [NSIS] on-path versus off-path discussion Message-ID: <20021027104633.A6585@tpce10.ipv6.tm.uka.de> References: <200210241856.SAA00860@gra.isi.edu> <200210241856.SAA00860@gra.isi.edu> <5.1.0.14.2.20021026183942.00a6ce60@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20021026183942.00a6ce60@boreas.isi.edu> User-Agent: Mutt/1.3.22.1i Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 Bob, On Sat, Oct 26, 2002 at 06:55:19PM -0700, Bob Braden wrote: > Unnh,,, it sets some bits somewhere in the network, in fact, somewhere > on the data path, right? In the Internet > model, everything "in the network" is a router, but I don''t need to insist > on that. But signaling DOES set control bits SOMEWHERE in the > network, right? Those bits are STATE. QED. (else it's not signaling?) Ok, SOMEWHERE has to be state installed, but not in every router along the data path (which was probably my misunderstanding here) for every signaling process. > >Typically, in a transit DiffServ domain I can let routers just do > >their packet forwarding and only need to adapt the profiles in > >boundary routers once a while. If a BB takes care of admission control > >etc., there is no need to install state in core routers... > > I didn't say WHICH routers. But the "core routers" are either > statically provisioned or else there is some sort of signaling > going on to set up their state Yup. > >Furthermore, you'll need some possibility to store persistent state > >for managing policy-based admission control and accounting. Routers > >are usually not able to store persistent states (except their basic > >config). So why not take all burdens of control processing off the > >routers and let a real powerful system do the control job? > > Well, the statement "real powerful system" seems to ignore > Moore's law and the current state of the technology. A high-end > router may have processing power equal to any specialized > control processor. So your statement seems like a bogus argument. Sure, routers are fast powerful with respect to data forwarding tasks, which is really nice. The argument aimed at a separation of data forwarding and some more complex control functions which can be outsourced to other entities (and which actually were, e.g., for RSVP policy-based admission control). > However, it is fundamentally the wrong argument for NSIS -- the right > argument would be about architecture, not current technology. Sorry, what I meant was that a separation of control plane and forwarding plane, which is an architectural issue. Let routers have a minimal set of control functions and let other entities perform more complex control functions. The separation of forwarding and routing algorithms within routers is one example where separation worked quite well and added the necessary flexibility. > >Usually, it is a local decision how the signaling to routers > >will be done, so autonomy of a domain is kept. However, there > > You mean there will be no interoperable standards? Pooh. No, I didn't say they shouldn't be interoperable. It makes perfectly sense to have non-vendor specific protocols for configuration such as SNMP or COPS (although, in practice the CLI interface is still widely used for actual router configuration). It is more in the spirit of flexibility as envisioned in the DiffServ architecture. For instance, as a provider you're free to choose how you realize PHBs, which DSCPs you use for them and how you actually provide a PDB. So as a first step a provider may choose his preferred way of configuration that works for him at best. This will usually not influence inter-domain signaling, and thus, interoperability at inter-domain level. NSIS currently doesn't deal with the question of how QoS is provided within a domain, different approaches should be possible, as well as applications other than QoS. > >are many possibilities, such as using COPS (I know that opinions > >will diverge here..), SNMP or even CLIs. Basically, you need a > >protocol that will be able to transport configuration information, > >fast, robust and reliable. Maybe we need something new. > > Yes, and it is signaling. So path-decoupled signaling has > added a new source of complexity and fragility, as I > suspected. Yes, it is some sort of signaling, but whether it's good or bad depends on the view. If we outsource some more complex functions from routers, we'll have to use an interface for the lower level control functions. With SNMP and COPS two such basic interfaces exist. Basically, such a design adds flexibility, but not necessarily fragility if we engineer prudently. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de WWW: www.tm.uka.de/~bless Institute of Telematics, University of Karlsruhe, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Oct 27 11:32:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06251 for ; Sun, 27 Oct 2002 11:32:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9RGYU925233 for nsis-archive@odin.ietf.org; Sun, 27 Oct 2002 11:34:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9RGYSv25210; Sun, 27 Oct 2002 11:34:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9RGXSv25185 for ; Sun, 27 Oct 2002 11:33:28 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06228 for ; Sun, 27 Oct 2002 11:31:02 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9RGXMY56609; Sun, 27 Oct 2002 17:33:23 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 9B6A670C6B; Sun, 27 Oct 2002 17:33:19 +0100 (CET) Cc: nsis@ietf.org, nsobs@ccrle.nec.de, sls@ist-tequila.org X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.18 references: <200210241856.SAA00860@gra.isi.edu> <20021026232213.A4772@tpce10.ipv6.tm.uka.de> From: "Marcus Brunner" MIME-Version: 1.0 subject: Re: [NSIS] on-path versus off-path discussion To: "Roland Bless" , braden@ISI.EDU content-type: text/plain; charset="iso-8859-1" date: Sun, 27 Oct 2002 17:33:19 +0100 content-transfer-encoding: 7bit Message-Id: <20021027163319.9B6A670C6B@imap.heidelberg.ccrle.nec.de> 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 Roland, Bob, [...] > The basic idea of a "combined" model is that an NSIS protocol should > be flexible enough to allow both kinds of signaling without causing > real drawbacks for one particular solution. It should work flawlessly > with path-coupled signaling, but also allow to add path-decoupled > signaling later without the need to redefine the basic protocol format. Probably, I got too much confused about the whole discussion myself. But isn't the main, and probably only difference, the interaction with routing? I think the question boils down to whether an NSIS protocol should "hard code" the use of IP routing/forwarding state or whether we allow also other routing/forwarding mechnisms to be used for signaling. > > > that some of the detailed arguments against path-coupled signaling seem > > to me of the form, "If you do something dumb, it won't work". > > > > However, the discussion seemed to gloss over a basic issue. I hope you > > can explain it to me. > > > > The purpose of signaling is not just to use up bandwidth, I > > hope; it actually exerts some control function on the routers > > along the path for some set of data packets. We customarily > > summarize that by saying that the purpose of signaling is to > > establish state in routers (and we mean of course the routers > > on the data path!). So suppose you have a set of distinct > > I'm not sure why signaling must always establish state in routers. > Wouldn't it be more general to say that signaling is to do something > in some sort of "control" plane, e.g. perform admission control, reserve > resources, install or update states, change configurations, etc... IMHO it is all about state. But NSIS should care about state setup along a set of nodes. Setting up state/config/etc via management protocols is more client-server type of state setup. Marcus [...] ------- Marcus Brunner Network Labs NEC Europe Ltd Heidelberg, Germany E-Mail: brunner@ccrle.nec.de WWW: www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Oct 27 11:39:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06389 for ; Sun, 27 Oct 2002 11:39:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9RGf5N25949 for nsis-archive@odin.ietf.org; Sun, 27 Oct 2002 11:41:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9RGf3v25942; Sun, 27 Oct 2002 11:41:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9RGecv25928 for ; Sun, 27 Oct 2002 11:40:38 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06383 for ; Sun, 27 Oct 2002 11:38:13 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9RGeIY56719; Sun, 27 Oct 2002 17:40:22 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id C698870C6C; Sun, 27 Oct 2002 17:40:15 +0100 (CET) Cc: nsis@ietf.org, "Melinda Shore" , sven.van_den_bosch@alcatel.be X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.18 references: <76C92FBBFB58D411AE760090271ED41805DF5B58@rsys002a.roke.co.uk> From: "Marcus Brunner" MIME-Version: 1.0 subject: RE: [NSIS] framework discussion To: "Hancock, Robert" content-type: text/plain; charset="iso-8859-1" date: Sun, 27 Oct 2002 17:40:15 +0100 content-transfer-encoding: 7bit Message-Id: <20021027164015.C698870C6C@imap.heidelberg.ccrle.nec.de> 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] actually, i'm not clear that there's any disagreement here. > > as i understand it, all discussions involving the term 'discovery' are about peer (next-NSIS-hop) discovery, not complete-path-discovery - i.e. essentially the same as what the RSVP PATH mechanism does. i've certainly never seen an explicit suggestion that all this information should get sent back to the NI. I think the disagreement is whether we only use IP routing tables/forwarding table to find the next hop, or whether there are other mechnisms allowed. Other mechnisms naturally need another type of topology discovery. For IP address based nesxt hop discovery we have the mechnisms already in place. Marcus > > have i been deluding myself? > > cheers, > > robert h. > > > > > > ================================================================================ ======== > Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. > ------- Marcus Brunner Network Labs NEC Europe Ltd Heidelberg, Germany E-Mail: brunner@ccrle.nec.de WWW: www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Oct 27 11:56:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06607 for ; Sun, 27 Oct 2002 11:56:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9RGwAH26221 for nsis-archive@odin.ietf.org; Sun, 27 Oct 2002 11:58:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9RGw8v26214; Sun, 27 Oct 2002 11:58:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9RGvgv26193 for ; Sun, 27 Oct 2002 11:57:42 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06592 for ; Sun, 27 Oct 2002 11:55:18 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9RGvcY56919; Sun, 27 Oct 2002 17:57:38 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id EFA9170C91; Sun, 27 Oct 2002 17:57:34 +0100 (CET) Cc: "Bob Braden" , nsis@ietf.org X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.18 references: <76C92FBBFB58D411AE760090271ED41805DF5BC5@rsys002a.roke.co.uk> From: "Marcus Brunner" MIME-Version: 1.0 subject: Re: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) To: "Hancock, Robert" content-type: text/plain; charset="iso-8859-1" date: Sun, 27 Oct 2002 17:57:34 +0100 content-transfer-encoding: 7bit Message-Id: <20021027165734.EFA9170C91@imap.heidelberg.ccrle.nec.de> 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 [...] > > possibility.] since > > *> a handoff is a basically a route change, it comes into > > this category; > > *> if we don't make some assumption like this it's > > impossible to see where > > *> nsis stops and things like seamoby CARD start. > > > > Robert, > > > > OK, now I understand what you meant. I think the paragraph should be > > more carefully worded. > > [reh] i'll leave that to marcus [emphatic grin] Please not too many [emphatic grin]. I will try to get this into the paragraph. > > > > *> > > *> i certainly used to think this was a reasonable > > restriction (and still > > *> do, for the 'NSIS base protocol'). but if we are trying > > to broaden our > > *> minds to think of possible NSIS uses (cf. your initial > > comments) should > > *> we also be thinking about signalling applications that > > set up or modify > > *> routes? > > > > This is certainly a hard problem, which we struggled with in RSVP. > > We took the same approach you suggest, simply because to do anything > > else (like entangling QoS signaling with routing) seemed doomed to > > complexity death. > > [reh] i have to agree it is low on my list of priorities; maybe we should leave the door open. I aggree. We should stay away from combining signaling and routing. But we should still keep the door open to use different routing mechnisms. > > > > *> > > *> *> 5.4.3 Independence of reservation identifier > > *> *> > > *> *> A reservation identifier, which is independent of the flow > > *> *> identifier (flow end-points), MUST be used. > > Various scenarios in the > > *> *> mobility area require this independence because > > flows resulting from > > *> *> handoff might have changed end-points etc. but > > still have the same > > *> *> service requirement. Also several proxy-based > > signaling methods > > *> *> might profit from such as independence. > > *> > > > *> > The semantics of this identifier needs to be precisely > > defined. It is > > *> > unclear whether it needs to be used E-E, or only in > > the mobile domain. > > *> > > > *> > > *> we agonised about precisely this detail in the framework document > > *> (current status: we don't know.) one point to make is > > that i don't > > *> think you can restrict the scope of the identifier to a > > 'mobile domain' > > *> because route changes due to mobility may have an impact > > anywhere along > > *> the data path (all the way up to the correspondent). > > *> > > > > Robert, > > > > I would like to understand myself what the issue is here. What > > function does the identifier serve? Exactly what will be done > > differently if you have the identifier? > > > > I can imagine that its function is to prevent "trading" reservations > > when end points move, i.e., it allows you to reuse the resources you > > already have for an ongoing call, rather than allocating new resources > > and freeing the old ones. Is that right? (If so, it seems like a > > second-order optimization that might be nice but is not critical.) > > [reh] You have it precisely. Whether it is critical seems to be a matter for debate. Certainly, there seem to be strong proponents; particular aspects to consider are that teardown may be difficult in a hard handover situation, and it might also be nice to short circuit authorisation stages and so on. There are some interesting discussions in draft-thomas-seamoby-rsvp-analysis-00.txt (now sadly expired) and draft-westphal-nsis-qos-mobileip-00.txt. > > At the moment, my only opinion on this feature is that it is hard to support. > I am a proponent for this type of feature. It allows for more independence from the topology (mobility case) and gives better identification of the reservation for policy/security/AAA functionality. Marcus [...] ------- Marcus Brunner Network Labs NEC Europe Ltd Heidelberg, Germany E-Mail: brunner@ccrle.nec.de WWW: www.brubers.org/marcus  _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Oct 27 18:36:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11713 for ; Sun, 27 Oct 2002 18:36:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9RNc3R09019 for nsis-archive@odin.ietf.org; Sun, 27 Oct 2002 18:38:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9RNbvv08990; Sun, 27 Oct 2002 18:37:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9RNZgv08366 for ; Sun, 27 Oct 2002 18:35:42 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11668 for ; Sun, 27 Oct 2002 18:33:15 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 27 Oct 2002 23:35:33 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5BE6@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Jukka MJ Manner , nsis@ietf.org Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) Date: Sun, 27 Oct 2002 23:35:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi jukka, some background points: > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.helsinki.fi] > Sent: 25 October 2002 13:16 > To: nsis@ietf.org > Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments > on draft-ietf-nsis-req-04.txt) > > > > (mobility discussions, my favorite! :) then i am very happy for you, since i am sure there will be lots more... > > Hi, > > Removing the old reservation is definitely an interesting > question, but couldn't you rely on the refresh timers and set > them "short > enough" for the MN<->AR link? What I am getting at is the following > two scenarios: > > a) IF you have a context transfer (CT) mechanism, once the QoS > requirements at set up on the new AR (& path), the CT mechanisms can > trigger the NSIS daemon running on the old AR to remove the > reservation on > the old path during some initial framework discussions and mailing list discussions around the same time (cross posted to seamoby, IIRC) there were considerable objections from some quarters about making the interactions between NSIS and CT too 'intimate'. i think what you are suggesting is respectable, but doesn't necessarily solve the whole problem (see next point). > > b) If you DON'T have CT at hand, you can rely on the soft > state mechanism > to remove the old reservation. How quickly this happens is a > question of > refresh timers and QoS allocation strategies. > > I could image having a Tear-message that has a timer associated > with it: "Remove this reservation when the time comes". Well, to be > honest, this does sound like a needless hack, so let's stay with the > "simple" soft state mechanisms... for now... my initial reaction is: isn't a 'timed Tear' effectively the same as just resetting the refresh timer to the same (small) timer value? but then: *) i assume the scope of that refresh timer would just be the MN-AR link, you might not be able to control it on interior links where you would typically configure larger values to reduce the refresh load. so you wouldn't be preventing resource wastage on those interior links. or rather... *) when the state times out at the AR, maybe it would decide to send a Tear-like message into the network anyway. But in that case, what prevents it running wild and tearing the whole e2e path (most of which you want to keep)? it's identifying and doing the processing at the crossover router (for both traffic directions) which is the hard thing. maybe my throwaway comment about hard handovers should be thrown away. cheers, robert > > Regards, > > Jukka [old stuff snipped] _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Oct 27 18:36:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11726 for ; Sun, 27 Oct 2002 18:36:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9RNc5C09031 for nsis-archive@odin.ietf.org; Sun, 27 Oct 2002 18:38:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9RNc1v09007; Sun, 27 Oct 2002 18:38:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9RNZgv08368 for ; Sun, 27 Oct 2002 18:35:42 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11669 for ; Sun, 27 Oct 2002 18:33:15 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 27 Oct 2002 23:35:33 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5BE5@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "PIECHOCINSKI, MACIEJ" , nsis@ietf.org Date: Sun, 27 Oct 2002 23:35:23 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] RE: nsis mobility interactions Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, i discussed these issues with Charles (Shen) at Yokohama. He (& colleagues) have produced newer drafts: draft-shen-nsis-rsvp-mobileipv6-00.txt draft-shen-nsis-mobility-fw-00.txt which I think change some of the previous conclusions or at least emphasis. since this is now effectively a framework discussion, i can recommend the second of these, as well as (I hope) section 5.3 of draft-ietf-nsis-fw-00.txt. with the momentum behind the discussion, i'd like to highlight some of the more general questions: *) can we agree the assumption that flow identification should be based on 'normal' header fields (i.e. not the HA e.g. in HAO). Note: this has some interesting implications for host implementations. *) is the HA a suitable value to use as the basis of a reservation identifier (basically, does the way it gets secured provide sufficient protection from the point of view of devices which aren't the MN & CN)? *) should we restrict the scope of NSIS considerations to MIP, or consider other mobility scenarios (e.g. SIP-based mobility solutions, or stuff as in draft-westberg-rmd-cellular-issues-01.txt) - where there wouldn't be a constant HA anyway? *) actually, what are the re-authentication/re-authorisation requirements in such mobility scenarios? how much authority can be devolved to the interior nodes in the network? plenty of others, of course... cheers, robert h. > -----Original Message----- > From: PIECHOCINSKI, MACIEJ [mailto:maciej.piechocinski@bell.ca] > Sent: 25 October 2002 18:33 > To: nsis@ietf.org > Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some > commentson > draft-ietf-nsis-req-04.txt) > > > draft-shen-rsvp-mobileipv6-interop-00.txt addressed some of the issues > with RSVP & MIP: > -using Home Address as a constant flow/reservation identification > -localizing reservation updates > -explicit teardown of old path after handoff > > Maciej > > Bob Braden wrote: > > > > *> > > *> Whenever i think about this, i have to admit i get > confused. (One of > > *> the reasons i like the thomas seamoby draft is the > abstract, which > > *> starts "IP Mobility along with RSVP makes my head hurt".) > > *> > > *> But in the hard handover (break-before-make > situation), the sort of > > *> reasoning is: *) if you send the tear before the > handover, you will > > *> lose the whole e2e path (can't find the crossover point without > > *> signaling via the new router); *) if you wait until > after the handover, > > *> you no longer have the ability to signal via the old > router and you > > *> can't tear the dead branch down. So, what would be > nice is if you > > *> could send some message after the handover which had a > reference to the > > *> old reservation in a way which allowed the dead branch > to be removed. > > *> (NB this path tear problem is only one of the > problems, of course. the > > *> analysis documents contain several others.) > > > > Robert, > > > > OK, you win, now my head hurts too ;-) The problem, I > guess, is that > > mobile IP breaks the Internet architecture in a fundamental > way, so to > > understand how QoS signaling will work you have to look at > the details > > of how mobile IP works. That's just philosophy, but it does suggest > > that we need to put the bandage where the wound is -- we probably > > need a solution that is local to the mobile region, not E2E. > > > > Bob > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 28 01:48:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19142 for ; Mon, 28 Oct 2002 01:48:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9S6oWJ27306 for nsis-archive@odin.ietf.org; Mon, 28 Oct 2002 01:50:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S6oTv27294; Mon, 28 Oct 2002 01:50:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S6nMv27250 for ; Mon, 28 Oct 2002 01:49:22 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19075 for ; Mon, 28 Oct 2002 01:46:51 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9S6mlb10867 for ; Mon, 28 Oct 2002 08:48:47 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 28 Oct 2002 08:49:09 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 08:49:09 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 08:49:08 +0200 content-class: urn:content-classes:message Subject: RE: terminology: "peer" or "neighbo[u]r"? (was: RE: [NSIS] framework discussion) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Oct 2002 08:49:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: Thread-Topic: terminology: "peer" or "neighbo[u]r"? (was: RE: [NSIS] framework discussion) Thread-Index: AcJ8eS87mqVq/AQ5SpOWLrfz1B6uuwB1OM6w To: , Cc: , , X-OriginalArrivalTime: 28 Oct 2002 06:49:08.0927 (UTC) FILETIME=[1D9E7CF0:01C27E4E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9S6nMv27251 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, > > "NSIS layer"? Does that mean the CSTP layer? > > How about "appropriate"? You might say that an application > neighbor or node is invisible to the layer above it and > irrelevant to the layer below it, where by "application" we > can mean anything from IP to NSIS to VoIP. I think that would be a fine term. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 28 02:55:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29809 for ; Mon, 28 Oct 2002 02:55:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9S7vTP06526 for nsis-archive@odin.ietf.org; Mon, 28 Oct 2002 02:57:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S7vQv06505; Mon, 28 Oct 2002 02:57:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S7uAv06465 for ; Mon, 28 Oct 2002 02:56:10 -0500 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29725 for ; Mon, 28 Oct 2002 02:53:38 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g9S7ts818661; Mon, 28 Oct 2002 09:55:57 +0200 Date: Mon, 28 Oct 2002 09:55:53 +0200 (EET) From: Jukka MJ Manner To: "Hancock, Robert" cc: nsis@ietf.org Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) In-Reply-To: <76C92FBBFB58D411AE760090271ED41805DF5BE6@rsys002a.roke.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , (some snipping done...:) (warning: this is getting solution-oriented...) On Sun, 27 Oct 2002, Hancock, Robert wrote: > > Removing the old reservation is definitely an interesting > > question, but couldn't you rely on the refresh timers and set them > > "short enough" for the MN<->AR link? What I am getting at is the > > following two scenarios: > > > > b) If you DON'T have CT at hand, you can rely on the soft state > > mechanism to remove the old reservation. How quickly this happens is a > > question of refresh timers and QoS allocation strategies. > > > > I could image having a Tear-message that has a timer associated > > with it: "Remove this reservation when the time comes". Well, to be > > honest, this does sound like a needless hack, so let's stay with the > > "simple" soft state mechanisms... for now... > > my initial reaction is: isn't a 'timed Tear' effectively the same as > just resetting the refresh timer to the same (small) timer value? but > then: > *) i assume the scope of that refresh timer would just be the MN-AR > link, you might not be able to control it on interior links where you > would typically configure larger values to reduce the refresh load. so > you wouldn't be preventing resource wastage on those interior links. or > rather... > *) when the state times out at the AR, maybe it would decide to send a > Tear-like message into the network anyway. But in that case, what > prevents it running wild and tearing the whole e2e path (most of which > you want to keep)? > > it's identifying and doing the processing at the crossover router (for > both traffic directions) which is the hard thing. maybe my throwaway > comment about hard handovers should be thrown away. > Unfortunately, I am not familiar enough with RSVP to know the following thing for sure, but would suspect something along: if one host of a multicast group wants to stop receiving a flow, the application closes the rapi session which causes a Resv Tear to be sent, right? Now, if there are other receivers in the multicast tree and the tear arrives at a cross-over router, it should not send the tear further to the sender but rather stop it there, since there are other flows still wanting to receive the flow. So, in the mobility scenario, once the MN has changed ARs, it re-reserves the resources, which should create a cross-over router somewhere. A timeout at the old AR could create a tear-event. The new cross-over router eventually, hopefully soon, gets a tear from the old path, but since there is reservation active on the new path, it will not forward the tear further on, thus keeping the reservation intact. Wouldn't this work for both upstream and downstream flows? A timeout creates a Tear-event, which would remove the reservation up to a cross-over NSIS-router? A second point to consider is, whether actual data could be used as an indication of a refresh: If the reservation has not been explicitly removed and there is data coming, keep the reservation active. To allow for different strategies in refreshes, allowing data to be used as refresh could be indicated to the previous hop on a hop by hop basis - some hops want to have explicit indications of refresh, some (especially on the wireless link) can do with actual data. A node not receiving data for a period of time but still wanting to keep the reservation could use explicit refresh messages for that. (well, this is an early monday morning idea, and may need some deeper thinking first, but still...?) (Isn't the PDP context in GPRS/3GPP nets removed if there is no data flowing for some time?) Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 28 07:08:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04935 for ; Mon, 28 Oct 2002 07:08:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SCAbe19321 for nsis-archive@odin.ietf.org; Mon, 28 Oct 2002 07:10:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SCAZv19306; Mon, 28 Oct 2002 07:10:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SBU7v16653 for ; Mon, 28 Oct 2002 06:30:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03226; Mon, 28 Oct 2002 06:27:44 -0500 (EST) Message-Id: <200210281127.GAA03226@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 28 Oct 2002 06:27:44 -0500 Subject: [NSIS] I-D ACTION:draft-fu-rsvp-multicast-analysis-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 : Analysis on RSVP Regarding Multicast Author(s) : X. Fu, C. Kappler, H. Tschofenig Filename : draft-fu-rsvp-multicast-analysis-01.txt Pages : 14 Date : 2002-10-25 RSVP version 1 has been designed for optimum support multicast. However, in reality multicast is being used much less frequently than anticipated. Still, even for unicast (one sender, one receiver) full-fledged multicast-enabled RSVP signaling must be used. As pointed out in the NSIS requirement draft, multicast would not be necessarily required for an NSIS signaling protocol. This draft analyses ingredients of RSVP Version 1 which are affected by multicast, and derives how these ingredients may look like if multicast is not supported in the generic RSVP signaling protocol and adapt related functionalities accordingly - we call the resulting feature set 'RSVP Lite', a potentially more light-weight version of RSVP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fu-rsvp-multicast-analysis-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-fu-rsvp-multicast-analysis-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-fu-rsvp-multicast-analysis-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: <2002-10-25110327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fu-rsvp-multicast-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-fu-rsvp-multicast-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-25110327.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 28 08:43:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08764 for ; Mon, 28 Oct 2002 08:43:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SDjKn23976 for nsis-archive@odin.ietf.org; Mon, 28 Oct 2002 08:45:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SDjIv23969; Mon, 28 Oct 2002 08:45:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SDiTv23914 for ; Mon, 28 Oct 2002 08:44:29 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08752 for ; Mon, 28 Oct 2002 08:42:06 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Oct 2002 13:44:25 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA648@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Mon, 28 Oct 2002 13:44:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] yet another terminology proposal Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, I suppose it's best to get these firmly settled before the real work starts... I believe we have general consensus to look at a 2 layer (or 'level') architecture for NSIS signalling, as prefigured in draft-braden-2level-signal-arch-00.txt, and reflected (I hope) in the 00 framework draft (e.g. section 4.3.1), and some other protocol proposals. However, we don't have good names for these layers. The framework avoided using terms from any existing work, to ensure there was no danger that we were prejudging the protocol choice or even prejudging the inter-layer split. If you accept this argument, we need new terms. The following have been proposed (for framework use, and "what role is protocol XXXP supposed to perform?" type discussions): NSIS Transport Layer Protocol (NTLP): the lower layer, responsible for moving messages around, for which we hope there will be a single protocol (at least in any network type); may or may not be based on or include underlying 'standard' transport protocols; independent of the signalling application. NSIS Signalling Layer Protocol (NSLP): the upper layer, which defines messages (and maybe states or message sequences) which are specific to a particular signalling application. We therefore expect there to be several of these (e.g. 1 or even >1 per signalling application). Comments? Objections? Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 28 08:58:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09565 for ; Mon, 28 Oct 2002 08:58:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SE0QN24406 for nsis-archive@odin.ietf.org; Mon, 28 Oct 2002 09:00:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SE0Kv24399; Mon, 28 Oct 2002 09:00:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SDxev24345 for ; Mon, 28 Oct 2002 08:59:40 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09417 for ; Mon, 28 Oct 2002 08:57:16 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9SDxRxF005661; Mon, 28 Oct 2002 05:59:32 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAK28778; Mon, 28 Oct 2002 05:54:36 -0800 (PST) Message-Id: <200210281354.AAK28778@mira-sjc5-4.cisco.com> To: "Hancock, Robert" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] yet another terminology proposal In-Reply-To: Message from "Hancock, Robert" of "Mon, 28 Oct 2002 13:44:24 GMT." <76C92FBBFB58D411AE760090271ED4181EA648@rsys002a.roke.co.uk> Date: Mon, 28 Oct 2002 08:59:24 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , NTLP is fine with me (and has a precedent in secsh's "transport layer protocol"). It may be worth pointing out that there will be no such protocol as "NSIS Signaling Layer Protocol" - it's a generic term to describe what the NSIS Transport Layer Protocol carries. As such it may be sufficient to either refer to it as the NSIS Signaling Layer or to just put the whole thing in lower case, it being not quite a proper noun. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 28 11:18:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16750 for ; Mon, 28 Oct 2002 11:18:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SGKPo00443 for nsis-archive@odin.ietf.org; Mon, 28 Oct 2002 11:20:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SGKKv00424; Mon, 28 Oct 2002 11:20:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SGJdv00346 for ; Mon, 28 Oct 2002 11:19:39 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16675 for ; Mon, 28 Oct 2002 11:17:14 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9SGJYKV006292; Mon, 28 Oct 2002 17:19:35 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VSVGT78X; Mon, 28 Oct 2002 17:19:35 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Oct 2002 17:19:34 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE153@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'Bob Braden'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] WG Last call on the Requirements Draft? Date: Mon, 28 Oct 2002 17:12:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Bob I agree with your suggestion on having a common CSTP for different signaling purposes. However, the number of ALSPs, that could be used in combination with the CSTP, for path coupled QoS signaling might be more than one. Best Regards, Georgios -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: donderdag 24 oktober 2002 20:25 To: brunner@ccrle.nec.de; mshore@cisco.com Cc: nsis@ietf.org Subject: Re: [NSIS] WG Last call on the Requirements Draft? *> *> > But as far as I have seen the list the consensus was to *> > not rule-out the off-path (what ever it is, see the E-Mail *> > thread on that), but focus on the on-path. And I hope that *> > the formulation does reflect this. Or in other words if *> > we find a protocol which works mainly on-path but also for *> > off-path we can still use it in NSIS and are not obliged *> > to throw it away. *> *> I think it would be a big mistake and could easily result in *> never producing a working protocol. It would be helpful if *> someone who thinks that it is in scope could scratch *> together a diagram of how they think it might work. *> *> That's not to say that I think this is not IETF work - I do *> think it is. I just don't think that it could reasonably *> fit into an end-to-end signaling protocol. As it happens, *> there is a diagram in the framework document of how it could *> be done by NSIS working in conjunction with another *> protocol, and that's Figure 8. *> *> Melinda Melinda, I assume this discussion is about the extent to which the NSIS WG should consider path-decoupled signaling, right? Here is a suggestion. Hopefully we can define a CSTP protocol layer that could be essentially [weasel word] the same for either path-coupled or path-decoupled signaling. So this moves the issue up to the ALSP layer. It is unclear to me exactly how NSIS is going to wrap itself around the 2-layer model, but I could imagine it defining the CSTP layer and one ALSP for path-coupled QoS signaling. Another WG could then tackle an ALSP (or multiple ALSPs if necessary) for path-decoupled signaling. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Oct 28 15:21:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28062 for ; Mon, 28 Oct 2002 15:21:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SKNLX15368 for nsis-archive@odin.ietf.org; Mon, 28 Oct 2002 15:23:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SKNGv15357; Mon, 28 Oct 2002 15:23:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SKMqv15291 for ; Mon, 28 Oct 2002 15:22:52 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28040 for ; Mon, 28 Oct 2002 15:20:25 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9SKMgxF018384 for ; Mon, 28 Oct 2002 12:22:42 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAL12168; Mon, 28 Oct 2002 12:16:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA11569; Mon, 28 Oct 2002 12:22:46 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15805.40086.24896.814760@thomasm-u1.cisco.com> Date: Mon, 28 Oct 2002 12:22:46 -0800 (PST) To: nsis@ietf.org X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [NSIS] rsvp analysis draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As requested from John, I've resubmitted my rsvp/mip analysis draft. I knew of one error in the draft I previously submitted, but it seems that I fixed it (this has been over a year, so those brain cells are long since recycled). I won't vouch for the correctness of the rest of it :) Until it shows up in the draft directory, it's available at: http://www.mtcc.com/standards/draft-thomas-nsis-rsvp-analysis-00.txt Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 29 02:30:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23677 for ; Tue, 29 Oct 2002 02:30:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9T7WVO24787 for nsis-archive@odin.ietf.org; Tue, 29 Oct 2002 02:32:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T7WSv24780; Tue, 29 Oct 2002 02:32:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T7Vlv24738 for ; Tue, 29 Oct 2002 02:31:47 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23589 for ; Tue, 29 Oct 2002 02:29:15 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9T7VrB12973 for ; Tue, 29 Oct 2002 09:31:53 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 29 Oct 2002 09:31:31 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 09:31:30 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 09:31:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] rsvp analysis draft Date: Tue, 29 Oct 2002 09:31:29 +0200 Message-ID: Thread-Topic: [NSIS] rsvp analysis draft Thread-Index: AcJ+v9/k0t99B/qVTi+7glEe8CzdhwAXTr7Q To: , X-OriginalArrivalTime: 29 Oct 2002 07:31:29.0753 (UTC) FILETIME=[327B8490:01C27F1D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9T7Vlv24739 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Michael, > Until it shows up in the draft directory, it's > available at: > > http://www.mtcc.com/standards/draft-thomas-nsis-rsvp-analysis-00.txt Thanks for submitting this. Hopefully, it will serve as good input into developing NSIS work. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 29 04:13:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25704 for ; Tue, 29 Oct 2002 04:13:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9T9FQr31595 for nsis-archive@odin.ietf.org; Tue, 29 Oct 2002 04:15:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T9FKv31582; Tue, 29 Oct 2002 04:15:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9T9D1v31511 for ; Tue, 29 Oct 2002 04:13:01 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25626 for ; Tue, 29 Oct 2002 04:10:27 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g9T9Clc19531 for ; Tue, 29 Oct 2002 10:12:47 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g9T9ClJ04948 for ; Tue, 29 Oct 2002 10:12:47 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: Date: Tue, 29 Oct 2002 10:13:43 +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.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <15805.40086.24896.814760@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [NSIS] new drafts Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 have submitted a few new drafts (draft updates). in case you want to read them now please look at the links provided below: RSVP Security Properties http://www.ersue.de/nsis/draft-ietf-nsis-rsvp-sec-properties-00.txt NSIS Threats http://www.ersue.de/nsis/draft-ietf-nsis-threats-00.txt A Firewall/NAT Traversal Client for CASP http://www.ersue.de/nsis/draft-tschofenig-nsis-casp-midcom-00.txt http://www.ersue.de/nsis/draft-tschofenig-nsis-casp-midcom-00.pdf please send me comments if you have some. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 29 09:26:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05253 for ; Tue, 29 Oct 2002 09:26:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TESOu15698 for nsis-archive@odin.ietf.org; Tue, 29 Oct 2002 09:28:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TESKv15683; Tue, 29 Oct 2002 09:28:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TER8v15633 for ; Tue, 29 Oct 2002 09:27:08 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05160 for ; Tue, 29 Oct 2002 09:24:43 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9TER3Q1000981; Tue, 29 Oct 2002 15:27:03 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VSVG5A4L; Tue, 29 Oct 2002 15:27:03 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Oct 2002 15:24:38 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE15E@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'Melinda Shore'" , nsis@ietf.org Cc: "'Hancock, Robert'" Subject: RE: [NSIS] Comments on framework draft Date: Tue, 29 Oct 2002 15:27:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Melinda Thank you very much for your comments! Below some remarks (after [georgios]) on your comments (after [Melinda]): [Melinda] 3.2.4 What's the difference between local objects and opaque data? [georgios] Local objects are part of the NSIS protocol, while opaque data is not. Local objects can be inserted, used and removed by one single domain. Robert maybe we could enlarge the definition of local objects! ------------------------------------------------------------- [melinda] 3.2.6 Disagree that error reporting is faster for sender- [melinda] oriented reservations - it need not be if you allow an nsis [melinda] device to send an error report back to the sender [melinda] immediately, rather than continuing to forward the message. [georgios] this statement is not about error reporting, but it is about the reporting of an unsuccessful reservation, i.e., a reservation that cannot be supported due to the fact that there are not enough bandwidth resources (Admission Control failure due to unavailable resources). In a receiver initiated approach, e.g., RSVPv1, the receiver of the data path confirms and starts installing the reservation on the path from receiver to sender. During this procedure (receiver to sender) the reservation can be accepted or rejected. In RSVPv1 an Admission Control failure (due to unavailable resources) can only be notified by a ResvErr, with an Error_Spec object that carries the Error Code = 01: Admission Control failure. In a sender initiated approach the sender of the data path is actually installing the reservation on the path from sender to receiver, giving the possibility to any node in this path to reject the request. Robert maybe we could elaborate more in the definition of an unsuccessful reservation (see above). ----------------------------------------- [melinda] The definition of receiver initiated signaling is [melinda] incorrect. In receiver-initiated signaling the [melinda] *reservation* is confirmed and installed in response to a [melinda] message from the receiver to the sender, but the data still [melinda] originate with the sender. [georgios] I think that there is a misunderstanding, maybe Robert could explain this term in more detail. Your definition is in my opinion better! ------------------------------------- [melinda] There may be cases in which you're looking for the last [melinda] appropriate NE on the path, for example when you use the [melinda] protocol for tunnel endpoint discovery. Receiver-oriented [melinda] signaling works better for this case. Sender-oriented [melinda] signaling would work but would require more messages. [georgios] good addition! ------------------------------------------- [Melinda] 7.5 Split Figure 9 into two? Does two things: 1) provides [Melinda] picture of proxies, and 2) shows multilayer [Melinda] architecture. Probably should do (2) before (1), or [Melinda] else move (1) up to section 3 somewhere [georgios] The intention of introducing this picture (Figure 9) was to emphasise that the NSIS signaling protocol can be separated into more than one hierarchical levels. For example, level 1 can be seen as a CSTP (NSTP) level and levels 2 and level 3 can be parts of an ALSP (NSLP). Best Regards, Georgios -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: donderdag 17 oktober 2002 0:32 To: nsis@ietf.org Subject: [NSIS] Comments on framework draft I've appended some comments on the framework draft. As with the requirements draft, some are substantive and others are just nitpicky. However, this document does raise some significant issues that I think need resolution before the requirements draft can be wrapped up, and I've listed those towards the top (and I have absolutely no doubt that I've missed some). One thing that particularly concerns me is that while in some places these issues are treated as open in others they're treated as settled, and settled in the direction of the CASP protocol. Let's not do that. Melinda ISSUES TO RESOLVE ----------------- 1) Addressing - hop-by-hop or end-to-end? If hop-by-hop, how is it routed? 2) Are "sessions" established between NSIS Entities? Note that they don't eliminate state, but just move it to another layer - what advantages does this have over the more stateless RSVP protocol machinery? 3) Is multicast really out of scope? 4) receiver-oriented vs. sender-oriented 5) Will NFs be able to request, release, or modify reservations (either initiate requests or modify existing requests in transit)? 6) Is the use of periodic refresh messages the primary means of installing state? Should these messages be idempotent? 7) Rely on internal or external security mechanisms? (Can we punt on this until we know more about the protocol?) =============== This document reads more like a framework for discussion than as a framework for a protocol. Need to talk about the protocol rather than the working group (Section 1, first sentence, for example) The document is clear about distinctions between protocol layer and application layer. 1.1 "This document will provide a framework for the NSIS protocol, both an architecture for the protocol itself and potential use scenarios. It is not intended to define an overarching resource management architecture for the Internet." Terminology: "Classifier" - small nit but decision may be based on something other than packet header - I'd say "packet contents." "Resource Management Function": set of functions within an NSIS Entity ... " I don't think it's that abstract. Maybe need to clean up use in this document; later it seems to be used to describe a policy function rather than specifically resource management. "peer session" - "session" implies some sort of persistence in the connection between two nsis forwarders that's not yet agreed upon. The use of double-headed arrows in Figure 1 implies (nsis) hop-by-hop signaling (addressing). Need to be clear that NSIS Forwarders and NSIS Receivers MUST be on the data path. NSIS Initiators MUST be placed somewhere topologically appropriate. This may be a deployment issue rather than a protocol design issue, but off-path signaling is out-of-scope and we shouldn't design for it (unless it's "free" - i.e. it doesn't complicate the protocol). 3.2 should be clearer that these are *NOT* nsis modes of operation, but rather a discussion of possible modes of operation and tradeoffs. Out-of-band is out of scope, and discussion of it in sections other than 3.2.1 should be deleted. 3.2.2 Maybe definition should say crosses more than one administrative domain. I would be more concerned with issues of authorization, etc. What's the real difference between functioning within one domain and functioning across more than one domain? Also, some of this discussion is specific to QoS application. 3.2.4 What's the difference between local objects and opaque data? 3.2.6 Disagree that error reporting is faster for sender- oriented reservations - it need not be if you allow an nsis device to send an error report back to the sender immediately, rather than continuing to forward the message. The definition of receiver initiated signaling is incorrect. In receiver-initiated signaling the *reservation* is confirmed and installed in response to a message from the receiver to the sender, but the data still originate with the sender. There may be cases in which you're looking for the last appropriate NE on the path, for example when you use the protocol for tunnel endpoint discovery. Receiver-oriented signaling works better for this case. Sender-oriented signaling would work but would require more messages. 3.3 contains requirements and those should be excerpted once there's agreement and the material is consolidated elsewhere. 3.3.1 "Optimized for unicast" is not the same thing as "not doing multicast" - can this decision be either finalized or tabled and revisited later? I'd put in some language about two-layer model here. 3.3.2 The first sentence is *excellent* - IETF documents need more of this kind of thing. Otherwise section needs to be aligned with requirements document - currently they're somewhat out of alignment 3.3.3 Need to clarify what's meant by "maintaining relations". We haven't agreed to session model. Think it would be helpful to reframe some of the discussion in terms of policy and authorization - helps to modularize architecture. 3.3.4 "Peer session" and "hop-by-hop" are not the same thing, and this section desribes hop-by-hop. "Peer session" implies a connection model that's orthogonal to the addressing model. (we could have end-to-end sessions, too) 3.3.5 I don't understand what the problem being addressed is 4.1 Feel quite strongly that interface selection should be handled by IP routing 4.2 control primitives seem to assume sender-oriented signaling (para 3). Writing in para starting "We have a basic design goal" is a little unclear - why not simply state that we assume the following functions will be available by other means and are therefore will not be included in the NSIS protocol? 4.3.2 depends entirely on whether sender-oriented or receiver-oriented signaling is used. 4.4 Idempotent refresh messages allow routes to be changed transparently to the NSIS protocol machinery 4.5.1 Why do you want to identify "flows" at the NSIS protocol layer? The text doesn't make a good case for it. This belongs in the application 4.5.2 Text describes application use of reservation ids. The actual NSIS control layer use of application ids would be in manipulation of existing reservations (teardown, modification, etc.) 5.2 Some of this would fall under the rubric "policy routing," which could be mentioned 5.2.4 The old path may no longer exist 6.1 seems to assume the use of an external security protocol aside from key management (IPSec, SSL). Does it need to? What about authenticating individual elements? 6.2 I'd restate question as "Does the requestor have permission?" Payment, etc. may very well not enter into it. No negotiation! Request has a yes/no/"no but" answer with possibility of additional information ("these are the nodes that would not satisfy the request and this is the reason they gave"), but negotiation introduces complexity with no real advantages. 6.3 Accounting also includes auditing 6.5 Not always reasonable to assume hop-by-hop protection, but is reasonable to assume "session" (if that's what we're doing) protection. There are many situations in which you cannot assume transitivity of trust (financial institutions, for example, hate it). Could this be a group keying application? If so, how would that affect arguments here? 7.4 For a framework for middlebox signaling, see my "Network-friendlier Midcom" draft 7.5 Split Figure 9 into two? Does two things: 1) provides picture of proxies, and 2) shows multilayer architecture. Probably should do (2) before (1), or else move (1) up to section 3 somewhere _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 29 14:57:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21982 for ; Tue, 29 Oct 2002 14:57:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TJxKN02525 for nsis-archive@odin.ietf.org; Tue, 29 Oct 2002 14:59:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TJxHv02513; Tue, 29 Oct 2002 14:59:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TJwpv02471 for ; Tue, 29 Oct 2002 14:58:51 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21970 for ; Tue, 29 Oct 2002 14:56:24 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9TJx4B14812 for ; Tue, 29 Oct 2002 21:59:04 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 29 Oct 2002 21:58:44 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 21:58:44 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 21:58:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] new drafts Date: Tue, 29 Oct 2002 21:58:43 +0200 Message-ID: Thread-Topic: [NSIS] new drafts Thread-Index: AcJ/K7xVXEgJxfzMTYCywWUiXSbNkwANRJBA To: , X-OriginalArrivalTime: 29 Oct 2002 19:58:44.0042 (UTC) FILETIME=[95CD1AA0:01C27F85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9TJwpv02472 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Hannes, > i have submitted a few new drafts (draft updates). > > in case you want to read them now please look at the links > provided below: > > RSVP Security Properties > http://www.ersue.de/nsis/draft-ietf-nsis-rsvp-sec-properties-00.txt > > NSIS Threats > http://www.ersue.de/nsis/draft-ietf-nsis-threats-00.txt > > A Firewall/NAT Traversal Client for CASP > http://www.ersue.de/nsis/draft-tschofenig-nsis-casp-midcom-00.txt > http://www.ersue.de/nsis/draft-tschofenig-nsis-casp-midcom-00.pdf > > please send me comments if you have some. It would be helpful if you could send a list of what has changes (for updated documents) and list of open issues to discuss on all of the drafts. Thanks! John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 29 14:59:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22143 for ; Tue, 29 Oct 2002 14:59:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TK1i002668 for nsis-archive@odin.ietf.org; Tue, 29 Oct 2002 15:01:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TK1gv02661; Tue, 29 Oct 2002 15:01:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TJwsv02475 for ; Tue, 29 Oct 2002 14:58:54 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21973 for ; Tue, 29 Oct 2002 14:56:27 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9TJwQb11007 for ; Tue, 29 Oct 2002 21:58:26 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 29 Oct 2002 21:58:48 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 21:58:48 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 21:58:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] yet another terminology proposal Date: Tue, 29 Oct 2002 21:58:47 +0200 Message-ID: Thread-Topic: [NSIS] yet another terminology proposal Thread-Index: AcJ+imUFH+I5qpnDTa2EsELygSlzuAA13PIQ To: , Cc: X-OriginalArrivalTime: 29 Oct 2002 19:58:47.0693 (UTC) FILETIME=[97FA33D0:01C27F85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9TJwsv02476 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, > NTLP is fine with me (and has a precedent in secsh's > "transport layer protocol"). It may be worth pointing out > that there will be no such protocol as "NSIS Signaling Layer > Protocol" - it's a generic term to describe what the NSIS > Transport Layer Protocol carries. As such it may be > sufficient to either refer to it as the NSIS Signaling Layer > or to just put the whole thing in lower case, it being not > quite a proper noun. I forget if I replied or not, but I agree. Perhaps we should use the term 'a NSIS signaling layer' to mean a generic one. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 29 15:00:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22160 for ; Tue, 29 Oct 2002 15:00:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TK22102707 for nsis-archive@odin.ietf.org; Tue, 29 Oct 2002 15:02:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TK20v02700; Tue, 29 Oct 2002 15:02:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TJx1v02479 for ; Tue, 29 Oct 2002 14:59:01 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21977 for ; Tue, 29 Oct 2002 14:56:34 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9TJwWb11046 for ; Tue, 29 Oct 2002 21:58:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 29 Oct 2002 21:58:54 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 21:58:54 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 21:58:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: terminology: "peer" or "neighbo[u]r"? (was: RE: [NSIS] framework discussion) Date: Tue, 29 Oct 2002 21:58:53 +0200 Message-ID: Thread-Topic: terminology: "peer" or "neighbo[u]r"? (was: RE: [NSIS] framework discussion) Thread-Index: AcJ7qRdNwhiXRpQ1QGmilAMcpeaW4ADua8BQ To: , , Cc: , X-OriginalArrivalTime: 29 Oct 2002 19:58:54.0106 (UTC) FILETIME=[9BCCBFA0:01C27F85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9TJx1v02480 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, > However, if the term 'peer' is causing obscurity/confusion, I > can change it. (nearly the simplest change for an editor to > make, after all.) I'm a big fan of splitting the difference. If 'peer' is causing some confusing, using the term 'NSIS peer' would be an appropriate compromise. An NSIS peer would be a node that has a direct NSIS transport connection with the node in question. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 29 15:19:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23042 for ; Tue, 29 Oct 2002 15:19:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TKLAP03883 for nsis-archive@odin.ietf.org; Tue, 29 Oct 2002 15:21:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TKL8v03875; Tue, 29 Oct 2002 15:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TKKvv03853 for ; Tue, 29 Oct 2002 15:20:57 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23030 for ; Tue, 29 Oct 2002 15:18:30 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9TKKmgM002480; Tue, 29 Oct 2002 12:20:48 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAK84194; Tue, 29 Oct 2002 12:16:01 -0800 (PST) Message-Id: <200210292016.AAK84194@mira-sjc5-4.cisco.com> To: john.loughney@nokia.com cc: Hannes.Tschofenig@siemens.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] new drafts In-Reply-To: Message from john.loughney@nokia.com of "Tue, 29 Oct 2002 21:58:43 +0200." Date: Tue, 29 Oct 2002 15:20:48 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > It would be helpful if you could send a list of what has changes (for > updated documents) and list of open issues to discuss on all of the > drafts. Not all of them, I hope. I apologize for continuing to harp on this but CASP is *not* the NSIS protocol. It's being marketed a little too enthusiastically, and frankly I find it rather off-putting. Let's save CASP for consideration *after* we have agreed-upon requirements and framework documents (and let's not tailor the framework and requirements to CASP, either). Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 29 16:06:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25431 for ; Tue, 29 Oct 2002 16:06:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TL8aU06764 for nsis-archive@odin.ietf.org; Tue, 29 Oct 2002 16:08:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TL8Xv06757; Tue, 29 Oct 2002 16:08:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TL7cv06723 for ; Tue, 29 Oct 2002 16:07:38 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25367 for ; Tue, 29 Oct 2002 16:05:10 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9TL8MX16834 for ; Tue, 29 Oct 2002 15:08:24 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 29 Oct 2002 15:07:26 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 15:06:45 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [NSIS] RE: nsis mobility interactions Date: Tue, 29 Oct 2002 16:06:44 -0500 Message-ID: Thread-Topic: [NSIS] RE: nsis mobility interactions Thread-Index: AcJ+Ee0QS+WVMEabRy+HX22Ei6YsOgBfAEiw To: , X-OriginalArrivalTime: 29 Oct 2002 21:06:45.0540 (UTC) FILETIME=[16904640:01C27F8F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9TL7cv06724 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi: The "draft-ietf-ipv6-flow-label-03.txt" recommends classification based on triplet (src adr, dest adr, flow label). We should not deviate from it unless it is essential. Also, what are those interesting implications on host implementations that you were referring to? Hemant -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Sunday, October 27, 2002 6:35 PM To: PIECHOCINSKI, MACIEJ; nsis@ietf.org Subject: [NSIS] RE: nsis mobility interactions hi all, i discussed these issues with Charles (Shen) at Yokohama. He (& colleagues) have produced newer drafts: draft-shen-nsis-rsvp-mobileipv6-00.txt draft-shen-nsis-mobility-fw-00.txt which I think change some of the previous conclusions or at least emphasis. since this is now effectively a framework discussion, i can recommend the second of these, as well as (I hope) section 5.3 of draft-ietf-nsis-fw-00.txt. with the momentum behind the discussion, i'd like to highlight some of the more general questions: *) can we agree the assumption that flow identification should be based on 'normal' header fields (i.e. not the HA e.g. in HAO). Note: this has some interesting implications for host implementations. *) is the HA a suitable value to use as the basis of a reservation identifier (basically, does the way it gets secured provide sufficient protection from the point of view of devices which aren't the MN & CN)? *) should we restrict the scope of NSIS considerations to MIP, or consider other mobility scenarios (e.g. SIP-based mobility solutions, or stuff as in draft-westberg-rmd-cellular-issues-01.txt) - where there wouldn't be a constant HA anyway? *) actually, what are the re-authentication/re-authorisation requirements in such mobility scenarios? how much authority can be devolved to the interior nodes in the network? plenty of others, of course... cheers, robert h. > -----Original Message----- > From: PIECHOCINSKI, MACIEJ [mailto:maciej.piechocinski@bell.ca] > Sent: 25 October 2002 18:33 > To: nsis@ietf.org > Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some > commentson > draft-ietf-nsis-req-04.txt) > > > draft-shen-rsvp-mobileipv6-interop-00.txt addressed some of the issues > with RSVP & MIP: > -using Home Address as a constant flow/reservation identification > -localizing reservation updates > -explicit teardown of old path after handoff > > Maciej > > Bob Braden wrote: > > > > *> > > *> Whenever i think about this, i have to admit i get > confused. (One of > > *> the reasons i like the thomas seamoby draft is the > abstract, which > > *> starts "IP Mobility along with RSVP makes my head hurt".) > > *> > > *> But in the hard handover (break-before-make > situation), the sort of > > *> reasoning is: *) if you send the tear before the > handover, you will > > *> lose the whole e2e path (can't find the crossover point without > > *> signaling via the new router); *) if you wait until > after the handover, > > *> you no longer have the ability to signal via the old > router and you > > *> can't tear the dead branch down. So, what would be > nice is if you > > *> could send some message after the handover which had a > reference to the > > *> old reservation in a way which allowed the dead branch > to be removed. > > *> (NB this path tear problem is only one of the > problems, of course. the > > *> analysis documents contain several others.) > > > > Robert, > > > > OK, you win, now my head hurts too ;-) The problem, I > guess, is that > > mobile IP breaks the Internet architecture in a fundamental > way, so to > > understand how QoS signaling will work you have to look at > the details > > of how mobile IP works. That's just philosophy, but it does suggest > > that we need to put the bandage where the wound is -- we probably > > need a solution that is local to the mobile region, not E2E. > > > > Bob > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 29 17:02:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28820 for ; Tue, 29 Oct 2002 17:02:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TM4Ff09539 for nsis-archive@odin.ietf.org; Tue, 29 Oct 2002 17:04:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TM4Cv09532; Tue, 29 Oct 2002 17:04:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TM3Fv09507 for ; Tue, 29 Oct 2002 17:03:15 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28624 for ; Tue, 29 Oct 2002 17:00:46 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Oct 2002 22:03:07 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5C63@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, mshore@cisco.com Cc: nsis@ietf.org Subject: RE: [NSIS] yet another terminology proposal Date: Tue, 29 Oct 2002 22:03:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , ok, let's go for it. at the moment, i can easily imagine a nice diagram which showed an 'NSIS signalling layer' above the NTLP, with the NSIS signalling layer containing a small herd of NSLPs. i'm not certain my ascii-art talents are up to it before the 01 cutoff, but you can only hope. robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 29 October 2002 19:59 > To: mshore@cisco.com; Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: [NSIS] yet another terminology proposal > > > Hi all, > > > NTLP is fine with me (and has a precedent in secsh's > > "transport layer protocol"). It may be worth pointing out > > that there will be no such protocol as "NSIS Signaling Layer > > Protocol" - it's a generic term to describe what the NSIS > > Transport Layer Protocol carries. As such it may be > > sufficient to either refer to it as the NSIS Signaling Layer > > or to just put the whole thing in lower case, it being not > > quite a proper noun. > > I forget if I replied or not, but I agree. Perhaps we should > use the term 'a NSIS signaling layer' to mean a generic one. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 29 18:02:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00634 for ; Tue, 29 Oct 2002 18:02:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TN4KP12794 for nsis-archive@odin.ietf.org; Tue, 29 Oct 2002 18:04:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TN4Iv12768; Tue, 29 Oct 2002 18:04:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TN3iv12746 for ; Tue, 29 Oct 2002 18:03:44 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00608 for ; Tue, 29 Oct 2002 18:01:15 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Oct 2002 23:03:36 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5C65@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "Georgios Karagiannis (ELN)" , "'Melinda Shore'" , nsis@ietf.org Subject: RE: [NSIS] Comments on framework draft Date: Tue, 29 Oct 2002 23:03:35 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, see inline: > > Hi Melinda > > Thank you very much for your comments! > Below some remarks (after [georgios]) on your > comments (after [Melinda]): > > [Melinda] 3.2.4 What's the difference between local objects and opaque > data? > > [georgios] Local objects are part of the NSIS protocol, while > opaque data is not. Local objects can be inserted, used and > removed by one single domain. > Robert maybe we could enlarge the definition of local objects! [reh] seems reasonable. we could also clarify (i think) that 3.2.4 mainly applies in the NSIS signalling layer (as we are now calling it) rather than to the NTLP ("NSIS Transport Layer Protocol"). > > ------------------------------------------------------------- > > [melinda] 3.2.6 Disagree that error reporting is faster for sender- > [melinda] oriented reservations - it need not be if you allow an nsis > [melinda] device to send an error report back to the sender > [melinda] immediately, rather than continuing to forward the message. > > [georgios] this statement is not about error reporting, but > it is about > the reporting of an unsuccessful reservation, i.e., a reservation > that cannot be supported due to the fact that there are not enough > bandwidth resources (Admission Control failure due to unavailable > resources). > In a receiver initiated approach, e.g., RSVPv1, the receiver of the > data path confirms and starts installing the reservation on the path > from receiver to sender. During this procedure (receiver to sender) > the reservation can be accepted or rejected. In RSVPv1 an Admission > Control failure (due to unavailable resources) can only be > notified by a ResvErr, with an Error_Spec object that carries > the Error Code = 01: Admission Control failure. > > In a sender initiated approach the sender of the data path is actually > installing the reservation on the path from sender to > receiver, giving the > possibility to any node in this path to reject the request. > > Robert maybe we could elaborate more in the definition of an > unsuccessful reservation (see above). [reh] i think we should expand on the various conditions and possibilities for reject/error reporting in section 3.3.6. there are several issues which are all intertwined, not only related to sender/receiver initiation. for example: *) if there is a NAT between the initiator and notification generator, the notification almost certainly can't be directly sent. should NSIS adapt its behaviour around this? *) how do you protect against false notifications? *) etc. thoughts/text are welcome. > > > ----------------------------------------- > [melinda] The definition of receiver initiated signaling is > [melinda] incorrect. In receiver-initiated signaling the > [melinda] *reservation* is confirmed and installed in response to a > [melinda] message from the receiver to the sender, but the data still > [melinda] originate with the sender. > > [georgios] I think that there is a misunderstanding, maybe Robert > could explain this term in more detail. Your definition is in my > opinion better! [reh] the difference is too subtle for my grasp. currently we have "In a receiver-initiated approach the receiver of the data flow initiates and maintains the resource reservation used for the data flow." I think we have used "sender" consistently to mean "data flow sender" regardless of whether signalling is sender or receiver initiated; maybe we should add that definition (and "receiver") explicitly. [however, we have spotted an error in the last paragraph: "incoming" should--> "outgoing", and 3.2.7 is possibly ambiguous.] > ------------------------------------- > > [melinda] There may be cases in which you're looking for the last > [melinda] appropriate NE on the path, for example when you use the > [melinda] protocol for tunnel endpoint discovery. Receiver-oriented > [melinda] signaling works better for this case. Sender-oriented > [melinda] signaling would work but would require more messages. > > [georgios] good addition! [reh] we can add this comment to 3.2.6. there is also an i-d imminent trying to summarise sender/receiver issues (which misses this point, however...) > > Best Regards, > Georgios > > cheers, robert _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Oct 29 18:02:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00647 for ; Tue, 29 Oct 2002 18:02:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TN4L812807 for nsis-archive@odin.ietf.org; Tue, 29 Oct 2002 18:04:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TN4Jv12787; Tue, 29 Oct 2002 18:04:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TN3kv12750 for ; Tue, 29 Oct 2002 18:03:46 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00611 for ; Tue, 29 Oct 2002 18:01:17 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Oct 2002 23:03:38 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5C66@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: RE: [NSIS] RE: nsis mobility interactions Date: Tue, 29 Oct 2002 23:03:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi hemant, see below: > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: 29 October 2002 21:07 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] RE: nsis mobility interactions > > > Hi: > > The "draft-ietf-ipv6-flow-label-03.txt" recommends > classification based on triplet (src adr, dest adr, flow > label). We should not deviate from it unless it is essential. [reh] Broadly, I like the current flow label draft, having read it several times. However, I think it's specifically about the flow label scope issues, rather than trying to restrict possible flow classifiers. (Would we ban classifiers that included the DSCP, for example?) I'm certainly not in favour of using lots of higher layer fields, and I'd personally be happy for NSIS to restrict itself in this area. > > Also, what are those interesting implications on host > implementations that you were referring to? [reh] This is based on conversations I have had with people who have implementation experience with MIP and RSVP. As I understand it (and I pre-emptively claim simple ignorance as a defence if I have got it wrong), an assumption that underlies several RSVP implementations is that the application on the host conveys its opinion on the packet classifier to some user space RSVP daemon which then uses them directly in RSVP protocol messages. (draft-shen-rsvp-mobileipv6-interop-00.txt described precisely this behaviour.) The filter spec in these messages then doesn't match MIP-processed packets. So, what is needed instead is for the RSVP daemon to know *exactly* how user-space visible packets are going to be re-encapsulated as they go over virtual interfaces (MIP,IPsec,L2TP,...), which probably requires more knowledge of IP-layer internals than may be trivially available. The RSVP daemon can't just take the application's view of the flow identification, wrap it in some headers, and chuck it at the host IP stack. OK, maybe it wasn't that interesting. But it seems worth keeping in mind. The framework alludes to these points (in 4.1 and 5.3.1, IIRC), but only briefly. > > Hemant cheers, robert h. > > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Sunday, October 27, 2002 6:35 PM > To: PIECHOCINSKI, MACIEJ; nsis@ietf.org > Subject: [NSIS] RE: nsis mobility interactions > > > hi all, > > i discussed these issues with Charles (Shen) at Yokohama. He > (& colleagues) have produced newer drafts: > draft-shen-nsis-rsvp-mobileipv6-00.txt > draft-shen-nsis-mobility-fw-00.txt > which I think change some of the previous conclusions or at > least emphasis. > > since this is now effectively a framework discussion, i can > recommend the second of these, as well as (I hope) section > 5.3 of draft-ietf-nsis-fw-00.txt. > > with the momentum behind the discussion, i'd like to > highlight some of the more general questions: > *) can we agree the assumption that flow identification > should be based on 'normal' header fields (i.e. not the HA > e.g. in HAO). Note: this has some interesting implications > for host implementations. > *) is the HA a suitable value to use as the basis of a > reservation identifier (basically, does the way it gets > secured provide sufficient protection from the point of view > of devices which aren't the MN & CN)? > *) should we restrict the scope of NSIS considerations to > MIP, or consider other mobility scenarios (e.g. SIP-based > mobility solutions, or stuff as in > draft-westberg-rmd-cellular-issues-01.txt) - where there > wouldn't be a constant HA anyway? > *) actually, what are the re-authentication/re-authorisation > requirements in such mobility scenarios? how much authority > can be devolved to the interior nodes in the network? > > plenty of others, of course... > > cheers, > > robert h. > [snipped] _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 02:56:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04993 for ; Wed, 30 Oct 2002 02:56:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9U7wxJ15531 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 02:58:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9U7wuv15509; Wed, 30 Oct 2002 02:58:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9U7vHv15458 for ; Wed, 30 Oct 2002 02:57:17 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04968 for ; Wed, 30 Oct 2002 02:54:44 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g9U7v5S20059; Wed, 30 Oct 2002 08:57:05 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g9U7v5J10941; Wed, 30 Oct 2002 08:57:05 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , Date: Wed, 30 Oct 2002 08:57:56 +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.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [NSIS] nsis threat issues Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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! thanks for mentioning the open issues in the nsis threat draft. i was asked to whether a separation between the transport and the application part should be made. currently the nsis threat document is focused on the application layer part and not on transport issues. i can add an additional threat covering this issue. two examples: - an adversary would modify ip headers of the signaling messages (if ip used used for message transport) - in case of a transport protocol: an adversary could terminate an established tcp connection. however these threats are not special for nsis signaling protocols. an important issue i see is that some people have no opinion on particular security issues. for example: - is non-repudiation necessary/required or not important at all. - how important is a threat caused by a malicious nsis entity? - is network topology hiding a desired property? - what about signaling message confidentiality? - do we worry about the reservation (or session) ownership problem? - etc. if someone is aware of additional threats currently not mentioned in the draft please let me know. in the next version i try to classify some threats as deployment threats (for example cost control) i also saw an issue about sending errors/notifications directly from an intermediate node to the source. this would also be a deployment threat since it will be quite difficult to have the security associations in place. ciao hannes > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, October 29, 2002 8:59 PM > To: Hannes.Tschofenig@siemens.com; nsis@ietf.org > Subject: RE: [NSIS] new drafts > -- snip - snip -- > > It would be helpful if you could send a list of what has changes (for > updated documents) and list of open issues to discuss on all of the > drafts. > > Thanks! > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 02:57:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05008 for ; Wed, 30 Oct 2002 02:57:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9U7x1B15557 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 02:59:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9U7wxv15524; Wed, 30 Oct 2002 02:58:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9U7vIv15462 for ; Wed, 30 Oct 2002 02:57:18 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04969 for ; Wed, 30 Oct 2002 02:54:45 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g9U7v5T11210; Wed, 30 Oct 2002 08:57:05 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g9U7v5J10948; Wed, 30 Oct 2002 08:57:05 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , , Subject: RE: [NSIS] RE: nsis mobility interactions Date: Wed, 30 Oct 2002 08:57:56 +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.2416 (9.0.2911.0) Importance: Normal In-Reply-To: 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 hemant! i saw that "draft-ietf-ipv6-flow-label-03.txt" recommends classification based on triplet (src adr, dest adr, flow label). in case of mobility it would be much better to use the home address instead of the source address. with a source address as part of the classifier all nodes along the path require an update after the src address changed due to mobility. ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Hemant.Chaskar@nokia.com > Sent: Tuesday, October 29, 2002 10:07 PM > To: robert.hancock@roke.co.uk; nsis@ietf.org > Subject: RE: [NSIS] RE: nsis mobility interactions > > > Hi: > > The "draft-ietf-ipv6-flow-label-03.txt" recommends classification > based on triplet (src adr, dest adr, flow label). We should not > deviate from it unless it is essential. > > Also, what are those interesting implications on host > implementations that you were referring to? > > Hemant > > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Sunday, October 27, 2002 6:35 PM > To: PIECHOCINSKI, MACIEJ; nsis@ietf.org > Subject: [NSIS] RE: nsis mobility interactions > > > hi all, > > i discussed these issues with Charles (Shen) at Yokohama. He (& > colleagues) have produced newer drafts: > draft-shen-nsis-rsvp-mobileipv6-00.txt > draft-shen-nsis-mobility-fw-00.txt > which I think change some of the previous conclusions or at least > emphasis. > > since this is now effectively a framework discussion, i can > recommend the second of these, as well as (I hope) section 5.3 of > draft-ietf-nsis-fw-00.txt. > > with the momentum behind the discussion, i'd like to highlight > some of the more general questions: > *) can we agree the assumption that flow identification should be > based on 'normal' header fields (i.e. not the HA e.g. in HAO). > Note: this has some interesting implications for host implementations. > *) is the HA a suitable value to use as the basis of a > reservation identifier (basically, does the way it gets secured > provide sufficient protection from the point of view of devices > which aren't the MN & CN)? > *) should we restrict the scope of NSIS considerations to MIP, or > consider other mobility scenarios (e.g. SIP-based mobility > solutions, or stuff as in > draft-westberg-rmd-cellular-issues-01.txt) - where there wouldn't > be a constant HA anyway? > *) actually, what are the re-authentication/re-authorisation > requirements in such mobility scenarios? how much authority can > be devolved to the interior nodes in the network? > > plenty of others, of course... > > cheers, > > robert h. > > > > -----Original Message----- > > From: PIECHOCINSKI, MACIEJ [mailto:maciej.piechocinski@bell.ca] > > Sent: 25 October 2002 18:33 > > To: nsis@ietf.org > > Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some > > commentson > > draft-ietf-nsis-req-04.txt) > > > > > > draft-shen-rsvp-mobileipv6-interop-00.txt addressed some of the issues > > with RSVP & MIP: > > -using Home Address as a constant flow/reservation identification > > -localizing reservation updates > > -explicit teardown of old path after handoff > > > > Maciej > > > > Bob Braden wrote: > > > > > > *> > > > *> Whenever i think about this, i have to admit i get > > confused. (One of > > > *> the reasons i like the thomas seamoby draft is the > > abstract, which > > > *> starts "IP Mobility along with RSVP makes my head hurt".) > > > *> > > > *> But in the hard handover (break-before-make > > situation), the sort of > > > *> reasoning is: *) if you send the tear before the > > handover, you will > > > *> lose the whole e2e path (can't find the crossover point without > > > *> signaling via the new router); *) if you wait until > > after the handover, > > > *> you no longer have the ability to signal via the old > > router and you > > > *> can't tear the dead branch down. So, what would be > > nice is if you > > > *> could send some message after the handover which had a > > reference to the > > > *> old reservation in a way which allowed the dead branch > > to be removed. > > > *> (NB this path tear problem is only one of the > > problems, of course. the > > > *> analysis documents contain several others.) > > > > > > Robert, > > > > > > OK, you win, now my head hurts too ;-) The problem, I > > guess, is that > > > mobile IP breaks the Internet architecture in a fundamental > > way, so to > > > understand how QoS signaling will work you have to look at > > the details > > > of how mobile IP works. That's just philosophy, but it does suggest > > > that we need to put the bandage where the wound is -- we probably > > > need a solution that is local to the mobile region, not E2E. > > > > > > Bob > > > > > > _______________________________________________ > > > 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 mailnull@www1.ietf.org Wed Oct 30 06:00:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08028 for ; Wed, 30 Oct 2002 06:00:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UB2na25407 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 06:02:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UB2hv25398; Wed, 30 Oct 2002 06:02:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UB1pv25370 for ; Wed, 30 Oct 2002 06:01:51 -0500 Received: from zeus.di.uoa.gr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07998 for ; Wed, 30 Oct 2002 05:59:26 -0500 (EST) Received: from gallagher.di.uoa.gr (gallagher.di.uoa.gr [195.134.67.52]) by zeus.di.uoa.gr (8.12.3/8.12.3) with ESMTP id g9UB1Jal019602; Wed, 30 Oct 2002 13:01:19 +0200 (EET) Received: from gallagher.di.uoa.gr (localhost [127.0.0.1]) by gallagher.di.uoa.gr (8.12.5/8.12.5) with ESMTP id g9UB1JOL020185; Wed, 30 Oct 2002 13:01:19 +0200 Received: (from sarantis@localhost) by gallagher.di.uoa.gr (8.12.5/8.12.5/Submit) id g9UB1Hgl020183; Wed, 30 Oct 2002 13:01:17 +0200 Date: Wed, 30 Oct 2002 13:01:17 +0200 From: Sarantis Paskalis To: Hannes Tschofenig Cc: Hemant.Chaskar@nokia.com, robert.hancock@roke.co.uk, nsis@ietf.org Subject: Re: [NSIS] RE: nsis mobility interactions Message-ID: <20021030110117.GA20032@gallagher.di.uoa.gr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner: Found to be clean Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, On Wed, Oct 30, 2002 at 08:57:56AM +0100, Hannes Tschofenig wrote: > i saw that "draft-ietf-ipv6-flow-label-03.txt" recommends classification > based on triplet (src adr, dest adr, flow label). in case of mobility it > would be much better to use the home address instead of the source address. > with a source address as part of the classifier all nodes along the path > require an update after the src address changed due to mobility. Or better Home Addresses, since both the source and the destination may be mobile nodes. Home Addresses remain constant at least throughout a session, so they can be used to identify the same flow. -- Sarantis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 06:14:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08275 for ; Wed, 30 Oct 2002 06:14:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UBGEI26501 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 06:16:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UBGBv26494; Wed, 30 Oct 2002 06:16:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UBFPv26476 for ; Wed, 30 Oct 2002 06:15:25 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08262 for ; Wed, 30 Oct 2002 06:13:01 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 11:15:23 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA661@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Sarantis Paskalis'" , Hannes Tschofenig Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: RE: [NSIS] RE: nsis mobility interactions Date: Wed, 30 Oct 2002 11:15:21 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, will someone explain to me how the security (validation of HA ownership in the network interior) and performance (required complexity of packet classifier) issues with this approach would be addressed? (no pun intended.) robert h. > -----Original Message----- > From: Sarantis Paskalis [mailto:sarantis@cnl.di.uoa.gr] > Sent: 30 October 2002 11:01 > To: Hannes Tschofenig > Cc: Hemant.Chaskar@nokia.com; Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] RE: nsis mobility interactions > > > Hi all, > > On Wed, Oct 30, 2002 at 08:57:56AM +0100, Hannes Tschofenig wrote: > > i saw that "draft-ietf-ipv6-flow-label-03.txt" recommends > classification > > based on triplet (src adr, dest adr, flow label). in case > of mobility it > > would be much better to use the home address instead of the > source address. > > with a source address as part of the classifier all nodes > along the path > > require an update after the src address changed due to mobility. > > Or better Home Addresses, since both the source and the > destination may > be mobile nodes. Home Addresses remain constant at least throughout a > session, so they can be used to identify the same flow. > > -- Sarantis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 06:32:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09782 for ; Wed, 30 Oct 2002 06:32:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UBYbk27704 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 06:34:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UBYYv27680; Wed, 30 Oct 2002 06:34:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UBIqv26587 for ; Wed, 30 Oct 2002 06:18:52 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08440; Wed, 30 Oct 2002 06:16:28 -0500 (EST) Message-Id: <200210301116.GAA08440@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 30 Oct 2002 06:16:27 -0500 Subject: [NSIS] I-D ACTION:draft-tschofenig-nsis-casp-midcom-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Firewall/NAT Traversal Client for CASP Author(s) : H. Tschofenig, H. Schulzrinne Filename : draft-tschofenig-nsis-casp-midcom-00.txt Pages : 38 Date : 2002-10-29 This document describes a CASP client protocol that allows nodes to signal information to firewalls mainly in an in-path fashion. The protocol furthermore allows the signaling initiator to establish and/or learn a NAT binding. This information can then be used within other protocols such as SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-tschofenig-nsis-casp-midcom-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-tschofenig-nsis-casp-midcom-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-29125721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tschofenig-nsis-casp-midcom-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-tschofenig-nsis-casp-midcom-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-29125721.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 06:32:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09795 for ; Wed, 30 Oct 2002 06:32:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UBYd327720 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 06:34:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UBYav27695; Wed, 30 Oct 2002 06:34:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UBLkv26724 for ; Wed, 30 Oct 2002 06:21:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09089; Wed, 30 Oct 2002 06:19:20 -0500 (EST) Message-Id: <200210301119.GAA09089@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 30 Oct 2002 06:19:20 -0500 Subject: [NSIS] I-D ACTION:draft-hancock-nsis-sender-receiver-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Sender and Receiver Orientation Issues in NSIS Author(s) : R. Hancock et al. Filename : draft-hancock-nsis-sender-receiver-00.txt Pages : 16 Date : 2002-10-29 The NSIS working group is considering protocols for signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in [2] and a framework in [3]. It is clear from existing work that there are many interrelated issues with NSIS signaling, concerning the respective roles of the two ends of the communication path. These issues include route finding, authorisation, state management requirements, localization of negotiation, and so on. The wide variety of problems involved hinders progress in deciding what approach NSIS should adopt. This Internet Draft attempts to provide a summary of these issues and suggests a way of structuring further analysis. It is not expected that this document should have a long term existence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hancock-nsis-sender-receiver-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hancock-nsis-sender-receiver-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hancock-nsis-sender-receiver-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-29130335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hancock-nsis-sender-receiver-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hancock-nsis-sender-receiver-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-29130335.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 06:55:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10502 for ; Wed, 30 Oct 2002 06:55:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UBvCW29112 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 06:57:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UBvAv29103; Wed, 30 Oct 2002 06:57:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UBurv29082 for ; Wed, 30 Oct 2002 06:56:53 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10484 for ; Wed, 30 Oct 2002 06:54:28 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9UBv9B19987 for ; Wed, 30 Oct 2002 13:57:09 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 30 Oct 2002 13:56:49 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Oct 2002 13:56:48 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Oct 2002 13:56:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] on-path versus off-path discussion Date: Wed, 30 Oct 2002 13:56:45 +0200 Message-ID: Thread-Topic: [NSIS] on-path versus off-path discussion Thread-Index: AcJ91r/1z6vp3CHPQBSpB54LdroVUwBknEUw To: , , Cc: , , X-OriginalArrivalTime: 30 Oct 2002 11:56:47.0888 (UTC) FILETIME=[6CD7E900:01C2800B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9UBurv29083 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marcus, > I think the question boils down to whether an NSIS protocol > should "hard code" > the use of IP routing/forwarding state or whether we allow also other > routing/forwarding mechnisms to be used for signaling. The assumption from our ADs is that NSIS will be using IP routing / forwarding state. It is also the opinion of the ADs that we will not be working on any other routing/forwarding mechnisms to be used for signaling in NSIS. This does not mean that they think this work is unimportant, they just see it as not part of the NSIS charter. Does this answer the question? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 07:17:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11192 for ; Wed, 30 Oct 2002 07:17:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UCJLq30421 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 07:19:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UCJEv30414; Wed, 30 Oct 2002 07:19:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UCIJv30387 for ; Wed, 30 Oct 2002 07:18:19 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11155 for ; Wed, 30 Oct 2002 07:15:54 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g9UCIFT29924; Wed, 30 Oct 2002 13:18:15 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g9UCIFJ08937; Wed, 30 Oct 2002 13:18:15 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Hancock, Robert" , "'Sarantis Paskalis'" Cc: , Subject: RE: [NSIS] RE: nsis mobility interactions Date: Wed, 30 Oct 2002 13:19:05 +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.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA661@rsys002a.roke.co.uk> 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 robert the mobile ipv6 address ownership problem (establishing end-to-end security associations between two arbitrary hosts) is independent from the session ownership issues in nsis. i think that an nsis protocol does not care whether it has to install/update a flow identitifer with a care-of address or something different (home address, flow label). the performance aspect is worth a consideration. however, i do not have performance numbers. does someone else know something? ciao hannes > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Wednesday, October 30, 2002 12:15 PM > To: 'Sarantis Paskalis'; Hannes Tschofenig > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org > Subject: RE: [NSIS] RE: nsis mobility interactions > > > hi all, > > will someone explain to me how the security (validation of HA > ownership in the network interior) and performance (required > complexity of packet classifier) issues with this approach would > be addressed? (no pun intended.) > > robert h. > > > -----Original Message----- > > From: Sarantis Paskalis [mailto:sarantis@cnl.di.uoa.gr] > > Sent: 30 October 2002 11:01 > > To: Hannes Tschofenig > > Cc: Hemant.Chaskar@nokia.com; Hancock, Robert; nsis@ietf.org > > Subject: Re: [NSIS] RE: nsis mobility interactions > > > > > > Hi all, > > > > On Wed, Oct 30, 2002 at 08:57:56AM +0100, Hannes Tschofenig wrote: > > > i saw that "draft-ietf-ipv6-flow-label-03.txt" recommends > > classification > > > based on triplet (src adr, dest adr, flow label). in case > > of mobility it > > > would be much better to use the home address instead of the > > source address. > > > with a source address as part of the classifier all nodes > > along the path > > > require an update after the src address changed due to mobility. > > > > Or better Home Addresses, since both the source and the > > destination may > > be mobile nodes. Home Addresses remain constant at least throughout a > > session, so they can be used to identify the same flow. > > > > -- Sarantis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 07:43:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11970 for ; Wed, 30 Oct 2002 07:43:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UCjDE32108 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 07:45:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UCjAv32101; Wed, 30 Oct 2002 07:45:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UCiTv32072 for ; Wed, 30 Oct 2002 07:44:29 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11955 for ; Wed, 30 Oct 2002 07:42:03 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 12:44:25 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA662@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Hannes.Tschofenig@siemens.com'" , "'Sarantis Paskalis'" Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: RE: [NSIS] RE: nsis mobility interactions Date: Wed, 30 Oct 2002 12:44:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com] > Sent: 30 October 2002 12:19 > To: Hancock, Robert; 'Sarantis Paskalis' > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org > Subject: RE: [NSIS] RE: nsis mobility interactions > > > hi robert > > the mobile ipv6 address ownership problem (establishing > end-to-end security > associations between two arbitrary hosts) is independent from > the session > ownership issues in nsis. i think that an nsis protocol does not care > whether it has to install/update a flow identitifer with a > care-of address > or something different (home address, flow label). quite right. in other words: *) mobile ip only protects ownership at the endpoints; *) nsis doesn't care what the identifiers are. so, to have my packets benefit from the reservation (qos treatment, f/w pinhole, etc) that another [mobile] user has set up, all i need to to is incorporate their HA options in my packet header and ignore them at the endpoints. is that a good idea? (IIRC, the HA options don't otherwise affect packet treatment within the network, so the sort of return routability checking that MIP uses to protect the endpoints can't be applied. but i'd defer to a MIP expert on this.) > > the performance aspect is worth a consideration. however, i > do not have > performance numbers. does someone else know something? i think you would even struggle to find a classifier prepared to recognise the option fields (certainly a hardware one). > > ciao > hannes > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Wednesday, October 30, 2002 12:15 PM > > To: 'Sarantis Paskalis'; Hannes Tschofenig > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org > > Subject: RE: [NSIS] RE: nsis mobility interactions > > > > > > hi all, > > > > will someone explain to me how the security (validation of HA > > ownership in the network interior) and performance (required > > complexity of packet classifier) issues with this approach would > > be addressed? (no pun intended.) > > > > robert h. > > > > > -----Original Message----- > > > From: Sarantis Paskalis [mailto:sarantis@cnl.di.uoa.gr] > > > Sent: 30 October 2002 11:01 > > > To: Hannes Tschofenig > > > Cc: Hemant.Chaskar@nokia.com; Hancock, Robert; nsis@ietf.org > > > Subject: Re: [NSIS] RE: nsis mobility interactions > > > > > > > > > Hi all, > > > > > > On Wed, Oct 30, 2002 at 08:57:56AM +0100, Hannes Tschofenig wrote: > > > > i saw that "draft-ietf-ipv6-flow-label-03.txt" recommends > > > classification > > > > based on triplet (src adr, dest adr, flow label). in case > > > of mobility it > > > > would be much better to use the home address instead of the > > > source address. > > > > with a source address as part of the classifier all nodes > > > along the path > > > > require an update after the src address changed due to mobility. > > > > > > Or better Home Addresses, since both the source and the > > > destination may > > > be mobile nodes. Home Addresses remain constant at least > throughout a > > > session, so they can be used to identify the same flow. > > > > > > -- Sarantis > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 09:01:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15070 for ; Wed, 30 Oct 2002 09:01:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UE3P603961 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 09:03:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UE3Mv03910; Wed, 30 Oct 2002 09:03:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UDwvv03668 for ; Wed, 30 Oct 2002 08:58:57 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14848 for ; Wed, 30 Oct 2002 08:56:30 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g9UDwqZ21310; Wed, 30 Oct 2002 14:58:53 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g9UDwqJ20124; Wed, 30 Oct 2002 14:58:52 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Hancock, Robert" , "'Sarantis Paskalis'" Cc: , Subject: RE: [NSIS] RE: nsis mobility interactions Date: Wed, 30 Oct 2002 14:59:42 +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.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA662@rsys002a.roke.co.uk> 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 robert. > > hi robert > > > > the mobile ipv6 address ownership problem (establishing > > end-to-end security > > associations between two arbitrary hosts) is independent from > > the session > > ownership issues in nsis. i think that an nsis protocol does not care > > whether it has to install/update a flow identitifer with a > > care-of address > > or something different (home address, flow label). > > quite right. in other words: > *) mobile ip only protects ownership at the endpoints; > *) nsis doesn't care what the identifiers are. sounds ok to me. but to avoid confusion, nsis cares about identifiers but should not care about what particular identifier is used. for example: if you do not use mip then obviously it would not be a good idea to have nsis only to support a home address based identifier. > so, to have my packets benefit from the reservation (qos > treatment, f/w pinhole, etc) that another [mobile] user has set > up, all i need to to is incorporate their HA options in my packet > header and ignore them at the endpoints. is that a good idea? unfortunately this is true. this threat is also described in the threat document. if you would have an identifier which is independent of addresses then there would be a clear advantage from a mobility perspective but unfortunately a security "disadvantage". > > (IIRC, the HA options don't otherwise affect packet treatment > within the network, so the sort of return routability checking > that MIP uses to protect the endpoints can't be applied. but i'd > defer to a MIP expert on this.) true. it this does not seem to be possible or from a performance perspective advisable. the same is true for an spi: an spi does not cause packet treatment within the network as well. still it has to be used as a packet classfier for qos (if the ip traffic is ipsec protected). only the end-points use the security association. verification is done only at end points. > > > > > the performance aspect is worth a consideration. however, i > > do not have > > performance numbers. does someone else know something? > > i think you would even struggle to find a classifier prepared to > recognise the option fields (certainly a hardware one). true. there is certainly room for improvement. ciao hannes > > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: Wednesday, October 30, 2002 12:15 PM > > > To: 'Sarantis Paskalis'; Hannes Tschofenig > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org > > > Subject: RE: [NSIS] RE: nsis mobility interactions > > > > > > > > > hi all, > > > > > > will someone explain to me how the security (validation of HA > > > ownership in the network interior) and performance (required > > > complexity of packet classifier) issues with this approach would > > > be addressed? (no pun intended.) > > > > > > robert h. > > > > > > > -----Original Message----- > > > > From: Sarantis Paskalis [mailto:sarantis@cnl.di.uoa.gr] > > > > Sent: 30 October 2002 11:01 > > > > To: Hannes Tschofenig > > > > Cc: Hemant.Chaskar@nokia.com; Hancock, Robert; nsis@ietf.org > > > > Subject: Re: [NSIS] RE: nsis mobility interactions > > > > > > > > > > > > Hi all, > > > > > > > > On Wed, Oct 30, 2002 at 08:57:56AM +0100, Hannes Tschofenig wrote: > > > > > i saw that "draft-ietf-ipv6-flow-label-03.txt" recommends > > > > classification > > > > > based on triplet (src adr, dest adr, flow label). in case > > > > of mobility it > > > > > would be much better to use the home address instead of the > > > > source address. > > > > > with a source address as part of the classifier all nodes > > > > along the path > > > > > require an update after the src address changed due to mobility. > > > > > > > > Or better Home Addresses, since both the source and the > > > > destination may > > > > be mobile nodes. Home Addresses remain constant at least > > throughout a > > > > session, so they can be used to identify the same flow. > > > > > > > > -- Sarantis > > > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 09:39:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16683 for ; Wed, 30 Oct 2002 09:39:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UEfEn07088 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 09:41:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEfBv07081; Wed, 30 Oct 2002 09:41:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEehv07058 for ; Wed, 30 Oct 2002 09:40:43 -0500 Received: from zeus.di.uoa.gr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16645 for ; Wed, 30 Oct 2002 09:38:17 -0500 (EST) Received: from gallagher.di.uoa.gr (gallagher.di.uoa.gr [195.134.67.52]) by zeus.di.uoa.gr (8.12.3/8.12.3) with ESMTP id g9UEe3al007883; Wed, 30 Oct 2002 16:40:03 +0200 (EET) Received: from gallagher.di.uoa.gr (localhost [127.0.0.1]) by gallagher.di.uoa.gr (8.12.5/8.12.5) with ESMTP id g9UEe5OL021442; Wed, 30 Oct 2002 16:40:05 +0200 Received: (from sarantis@localhost) by gallagher.di.uoa.gr (8.12.5/8.12.5/Submit) id g9UEe3RL021440; Wed, 30 Oct 2002 16:40:03 +0200 Date: Wed, 30 Oct 2002 16:40:03 +0200 From: Sarantis Paskalis To: Hannes Tschofenig Cc: "Hancock, Robert" , "'Sarantis Paskalis'" , Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: Re: [NSIS] RE: nsis mobility interactions Message-ID: <20021030144003.GA21261@gallagher.di.uoa.gr> References: <76C92FBBFB58D411AE760090271ED4181EA662@rsys002a.roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner: Found to be clean Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, On Wed, Oct 30, 2002 at 02:59:42PM +0100, Hannes Tschofenig wrote: To summarize the thread, the following alternatives exist for the flow identifier (in my understanding): + Use the Home Address option (or spi field or any other unique identifier) -Pros: Supports mobility (change of endpoint IP address) -Cons: Possible theft of service (the authentication of the HA or spi happens only at the endpoints), suboptimal classifying performance + Use src and dest addresses (combined with flow labels) -Pros: Performance tuned, qos allocations are for the actual flow (no theft of service). -Cons: The classification filter must change after a mobile IP handoff (end point address modification). The filter modification must happen throughout the path, not only in the locally affected area. Is there any other alternative? -- Sarantis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 09:47:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17029 for ; Wed, 30 Oct 2002 09:47:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UEn7a07454 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 09:49:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEn4v07413; Wed, 30 Oct 2002 09:49:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEmMv07370 for ; Wed, 30 Oct 2002 09:48:22 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16986 for ; Wed, 30 Oct 2002 09:45:56 -0500 (EST) Received: from pog.isi.edu (ras36.isi.edu [128.9.176.136]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9UEmBC16384; Wed, 30 Oct 2002 06:48:12 -0800 (PST) Message-Id: <5.1.0.14.2.20021029185633.00a04500@boreas.isi.edu> X-Sender: braden@boreas.isi.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 19:07:30 -0800 To: "Marcus Brunner" , "Roland Bless" From: Bob Braden Subject: Re: [NSIS] on-path versus off-path discussion Cc: nsis@ietf.org, nsobs@ccrle.nec.de, sls@ist-tequila.org In-Reply-To: <20021027163319.9B6A670C6B@imap.heidelberg.ccrle.nec.de> References: <200210241856.SAA00860@gra.isi.edu> <20021026232213.A4772@tpce10.ipv6.tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , At 05:33 PM 10/27/2002 +0100, Marcus Brunner wrote: >Roland, Bob, >[...] > > The basic idea of a "combined" model is that an NSIS protocol should > > be flexible enough to allow both kinds of signaling without causing > > real drawbacks for one particular solution. It should work flawlessly > > with path-coupled signaling, but also allow to add path-decoupled > > signaling later without the need to redefine the basic protocol format. > >Probably, I got too much confused about the whole discussion myself. But isn't >the main, and probably only difference, the interaction with routing? I said it a little differently in an earlier message -- it is a question of whether or not the signaling is performed by a network entity that has an IP address different from the IP address of the corresponding router. But I suspect that is just another way to say "interaction with routing". >I think the question boils down to whether an NSIS protocol should "hard code" >the use of IP routing/forwarding state or whether we allow also other >routing/forwarding mechnisms to be used for signaling. My answer is: "yes and no""! I suggest that the CSTP level of the two-level model should be general enough to support either path coupled or path-decoupled signaling. However, when NSIS considers developing an ALSP for QoS signaling, I have the serious doubts I expressed previously about the architectural wisdom of path-decoupled operation. I hope the WG will at least require a convincing technical argument (which I have not yet heard) in favor of the path- decoupled model before including it in the (first) ALSP. Thanks, Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 09:47:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17042 for ; Wed, 30 Oct 2002 09:47:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UEn9h07467 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 09:49:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEn5v07428; Wed, 30 Oct 2002 09:49:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEmRv07374 for ; Wed, 30 Oct 2002 09:48:27 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16993 for ; Wed, 30 Oct 2002 09:46:02 -0500 (EST) Received: from pog.isi.edu (ras36.isi.edu [128.9.176.136]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9UEmEC16515; Wed, 30 Oct 2002 06:48:14 -0800 (PST) Message-Id: <5.1.0.14.2.20021029190938.00af8e90@boreas.isi.edu> X-Sender: braden@boreas.isi.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 19:18:35 -0800 To: "Marcus Brunner" , "Hancock, Robert" From: Bob Braden Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) Cc: nsis@ietf.org In-Reply-To: <20021027165734.EFA9170C91@imap.heidelberg.ccrle.nec.de> References: <76C92FBBFB58D411AE760090271ED41805DF5BC5@rsys002a.roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 certainly a hard problem, which we struggled with in RSVP. > > > We took the same approach you suggest, simply because to do anything > > > else (like entangling QoS signaling with routing) seemed doomed to > > > complexity death. > > > > [reh] i have to agree it is low on my list of priorities; maybe we should >leave the door open. > >I aggree. We should stay away from combining signaling and routing. But we >should still keep the door open to use different routing mechnisms. There is a subtle difference between neighbor discovery and routing. Discovery allows a node to find all the neighbor nodes to which signaling messages might be forwarded. Routing determines which actual next hops are used for forwarding a particular signaling message. Neighbor discovery involves only local information,\ while routing involves global information in general. I can imagine that the new QoS signaling protocol [I refuse to call it "NSIS", because I think that's a dumb name for a protocol] might want to have a neighbor discovery mechanism (roughly an "up/down" protocol), but it might still want to route signaling packets using the same routing that is used for data packets. Note that if you use "some different routing mechanism", you almost certainly have times when data routing differs from signal routing, which is busted. Thanks, Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 09:47:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17044 for ; Wed, 30 Oct 2002 09:47:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UEnAQ07479 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 09:49:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEn6v07443; Wed, 30 Oct 2002 09:49:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEmSv07378 for ; Wed, 30 Oct 2002 09:48:28 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16996 for ; Wed, 30 Oct 2002 09:46:02 -0500 (EST) Received: from pog.isi.edu (ras36.isi.edu [128.9.176.136]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9UEmGC16560; Wed, 30 Oct 2002 06:48:16 -0800 (PST) Message-Id: <5.1.0.14.2.20021029192635.00a745f8@boreas.isi.edu> X-Sender: braden@boreas.isi.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 19:31:56 -0800 To: "Hancock, Robert" , nsis@ietf.org From: Bob Braden Subject: Re: [NSIS] yet another terminology proposal In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA648@rsys002a.roke.co.uk > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > > > >NSIS Transport Layer Protocol (NTLP): the lower layer, responsible for >moving messages around, for which we hope there will be a single protocol >(at least in any network type); may or may not be based on or include >underlying 'standard' transport protocols; independent of the signalling >application. > >NSIS Signalling Layer Protocol (NSLP): the upper layer, which defines >messages (and maybe states or message sequences) which are specific to a >particular signalling application. We therefore expect there to be several >of these (e.g. 1 or even >1 per signalling application). OK, except I think the N is dumb. How about: ISTP Internet signaling transport protocol ISCP Internet signaling control protocol ?? Any takers? >(Choosing a good name is not an idle exercise) Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 10:08:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18267 for ; Wed, 30 Oct 2002 10:08:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UFAJY08958 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 10:10:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UFAGv08951; Wed, 30 Oct 2002 10:10:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UF9gv08905 for ; Wed, 30 Oct 2002 10:09:42 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18219 for ; Wed, 30 Oct 2002 10:07:17 -0500 (EST) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g9UF9ZT00753; Wed, 30 Oct 2002 07:09:35 -0800 (PST) Date: Wed, 30 Oct 2002 07:09:35 -0800 (PST) From: Bob Braden Message-Id: <200210301509.g9UF9ZT00753@boreas.isi.edu> To: john.loughney@nokia.com Subject: RE: [NSIS] on-path versus off-path discussion Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> Hi Marcus, *> *> > I think the question boils down to whether an NSIS protocol *> > should "hard code" *> > the use of IP routing/forwarding state or whether we allow also other *> > routing/forwarding mechnisms to be used for signaling. *> *> The assumption from our ADs is that NSIS will be using IP routing *> / forwarding state. It is also the opinion of the ADs that we will *> not be working on any other routing/forwarding mechnisms to be used *> for signaling in NSIS. This does not mean that they think this work *> is unimportant, they just see it as not part of the NSIS charter. *> *> Does this answer the question? *> John, With all respect to you and the ADs, I suggest again that the answer might be different at the signaling transport (ST) and the signaling application (SA) layers. Bob *> John *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 10:09:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18296 for ; Wed, 30 Oct 2002 10:09:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UFB4g09021 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 10:11:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UFB1v09009; Wed, 30 Oct 2002 10:11:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UFA1v08939 for ; Wed, 30 Oct 2002 10:10:01 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18244 for ; Wed, 30 Oct 2002 10:07:34 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9UF9tQ1001630; Wed, 30 Oct 2002 16:09:55 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VS6CVRTG; Wed, 30 Oct 2002 16:09:55 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 16:03:12 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE166@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'Bob Braden'" , "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] yet another terminology proposal Date: Wed, 30 Oct 2002 16:09:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi I think Bob is right on the issue of "N is dumb". Best Regards, Georgios -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: woensdag 30 oktober 2002 4:32 To: Hancock, Robert; nsis@ietf.org Subject: Re: [NSIS] yet another terminology proposal > > > >NSIS Transport Layer Protocol (NTLP): the lower layer, responsible for >moving messages around, for which we hope there will be a single protocol >(at least in any network type); may or may not be based on or include >underlying 'standard' transport protocols; independent of the signalling >application. > >NSIS Signalling Layer Protocol (NSLP): the upper layer, which defines >messages (and maybe states or message sequences) which are specific to a >particular signalling application. We therefore expect there to be several >of these (e.g. 1 or even >1 per signalling application). OK, except I think the N is dumb. How about: ISTP Internet signaling transport protocol ISCP Internet signaling control protocol ?? Any takers? >(Choosing a good name is not an idle exercise) Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 10:18:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18763 for ; Wed, 30 Oct 2002 10:18:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UFK7S09408 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 10:20:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UFK5v09397; Wed, 30 Oct 2002 10:20:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UFJtv09339 for ; Wed, 30 Oct 2002 10:19:55 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18731 for ; Wed, 30 Oct 2002 10:17:29 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 15:19:50 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA666@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org, "Melinda Shore (E-mail)" Subject: RE: [NSIS] Comments on framework draft Date: Wed, 30 Oct 2002 15:19:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi melinda, i've gone through the less technically demanding of the framework comments, and have some suggestions/questions. (i've left out ones which have already been covered in other threads, or which are sufficiently technically interesting to deserve their own threads. in other words, what follows is mainly clarification/editorial changes - i hope). robert h. ============================================================ [MS] Terminology: "Classifier" - small nit but decision may be based on something other than packet header - I'd say "packet contents." [reh] I suggest just 'packet'. [MS] "Resource Management Function": set of functions within an NSIS Entity ... " I don't think it's that abstract. Maybe need to clean up use in this document; later it seems to be used to describe a policy function rather than specifically resource management. [reh] We had a lot (I mean a *lot*) of discussions about this. The main point was we wanted a name for the thing the protocol (in fact, any NSLP) interacted with to actually do stuff, so we could separate all discussions of whether 'do stuff' was e.g. a centralised or distributed function. So, abstraction was actually a goal - but I'm open to alternative/better definitions. [MS} "peer session" - "session" implies some sort of persistence in the connection between two nsis forwarders that's not yet agreed upon. The use of double-headed arrows in Figure 1 implies (nsis) hop-by-hop signaling (addressing). [reh] We're proposing to drop the term session anyway now. For the "<====>", the meaning is just supposed to be "this is how big an NSIS hop/peer-relationship is" (either addressing model possible). maybe we can separate these arrows off somehow and have a better caption. [MS] Need to be clear that NSIS Forwarders and NSIS Receivers MUST be on the data path. NSIS Initiators MUST be placed somewhere topologically appropriate. This may be a deployment issue rather than a protocol design issue, but off-path signaling is out-of-scope and we shouldn't design for it (unless it's "free" - i.e. it doesn't complicate the protocol). [reh] The terminology section (if this is what you are referring to) can be cleaned up about placement issues w.r.t. path-[de]coupled signalling. [MS} 3.2 should be clearer that these are *NOT* nsis modes of operation, but rather a discussion of possible modes of operation and tradeoffs. Out-of-band is out of scope, and discussion of it in sections other than 3.2.1 should be deleted. [reh] On the first point I agree. On the second point I propose for now to try to localise discussion of the path-decoupled case in paragraphs beginning "Note: In the case of path-decoupled signalling..." or something (or I may get more pointed advice from the management). [MS] 3.2.2 Maybe definition should say crosses more than one administrative domain. I would be more concerned with issues of authorization, etc. What's the real difference between functioning within one domain and functioning across more than one domain? Also, some of this discussion is specific to QoS application. [reh] I don't really understand your point here. Are you looking for more detailed discussion? [MS] 3.2.6 Disagree that error reporting is faster for sender- oriented reservations - it need not be if you allow an nsis device to send an error report back to the sender immediately, rather than continuing to forward the message. [reh] We will probably try to have a better section covering notification issues in more detail (as discussed in a separate email, covering also the next snipped points). [MS] 3.3 contains requirements and those should be excerpted once there's agreement and the material is consolidated elsewhere. [reh] I agree, in the long term. [MS] 3.3.3 Need to clarify what's meant by "maintaining relations". We haven't agreed to session model. Think it would be helpful to reframe some of the discussion in terms of policy and authorization - helps to modularize architecture. [reh] I think this will be cleared up by the session terminology changes. (At least, it will be a start.) [MS] 3.3.4 "Peer session" and "hop-by-hop" are not the same thing, and this section desribes hop-by-hop. "Peer session" implies a connection model that's orthogonal to the addressing model. (we could have end-to-end sessions, too) [reh] Same comment as above. [MS] 3.3.5 I don't understand what the problem being addressed is [reh] OK, partly, this is historical overhang from the Minneapolis side discussions when we were still very much QoS focussed and were just making the discovery that issues like pre-emption could be pushed up out of the protocol into opaque service-specific data. (Recording this insight didn't prevent some tedious discussions at a later date on pre-emption issues, but that now seems to be past.) Now, this is pretty much overtaken by the 2 layer approach, and this section should probably be replaced by one describing it and the isssue that we don't know where the split between them should go. Suggestions for text for such a section are welcome. We can take some of draft-braden-2-... as a starting point for the issues. [MS] 7.4 For a framework for middlebox signaling, see my "Network-friendlier Midcom" draft [reh] I'll add the reference. Would you propose to incorporate any of it directly? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 11:10:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22253 for ; Wed, 30 Oct 2002 11:10:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UGC0C13413 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 11:12:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UGBpv13396; Wed, 30 Oct 2002 11:11:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UG8Vv13257 for ; Wed, 30 Oct 2002 11:08:31 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22007 for ; Wed, 30 Oct 2002 11:06:05 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9UG8LxF023488; Wed, 30 Oct 2002 08:08:21 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAL63069; Wed, 30 Oct 2002 08:02:33 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA12076; Wed, 30 Oct 2002 08:08:25 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15808.1017.296889.929712@thomasm-u1.cisco.com> Date: Wed, 30 Oct 2002 08:08:25 -0800 (PST) To: Cc: , , Subject: RE: [NSIS] RE: nsis mobility interactions In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hannes Tschofenig writes: > hi hemant! > > i saw that "draft-ietf-ipv6-flow-label-03.txt" recommends classification > based on triplet (src adr, dest adr, flow label). in case of mobility it > would be much better to use the home address instead of the source address. > with a source address as part of the classifier all nodes along the path > require an update after the src address changed due to mobility. This is not at all clear. Fishing out the home address option for flow classification is onerous. Nor is it always available as it could be invisible due to encryption. I'm not offering a solution here, just pointing out that this is not obvious. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 11:19:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22880 for ; Wed, 30 Oct 2002 11:19:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UGLEI14054 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 11:21:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UGL8v14040; Wed, 30 Oct 2002 11:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UGKav13995 for ; Wed, 30 Oct 2002 11:20:36 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22775 for ; Wed, 30 Oct 2002 11:18:09 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9UGKHPP029271; Wed, 30 Oct 2002 08:20:22 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAL63312; Wed, 30 Oct 2002 08:14:25 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA12079; Wed, 30 Oct 2002 08:20:17 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15808.1728.924745.642298@thomasm-u1.cisco.com> Date: Wed, 30 Oct 2002 08:20:16 -0800 (PST) To: "Hancock, Robert" Cc: "'Sarantis Paskalis'" , Hannes Tschofenig , Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: RE: [NSIS] RE: nsis mobility interactions In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA661@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED4181EA661@rsys002a.roke.co.uk> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hancock, Robert writes: > hi all, > > will someone explain to me how the security (validation of HA ownership in the network interior) and performance (required complexity of packet classifier) issues with this approach would be addressed? (no pun intended.) Robert, How is it done today? BCP 38 gives some guidence but is far from perfect. The Home Address Option, however, makes edge ingress filtering essentially impossible as BCP 38 counts on edge routers understanding their local topology such that they can perform RPF checks, etc. This cannot be done with the Home Address Option as the addresss... isn't necessarily topologically local. Thus, it seems to me that expecting security properties to be enforced based on arbitrary home addresses is a hopeless task. However, I'm not convinced that that is even needed as the relationships in RSVP (and assumedly NSIS) are always hopwise, and given the desire for ingress filtering I'd expect that topologically correct CoA's to be the norm. This entire discussion is very reminiscent of HIP discussions and RFC 2207 considerations. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 11:49:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24626 for ; Wed, 30 Oct 2002 11:49:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UGpGV16740 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 11:51:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UGpEv16731; Wed, 30 Oct 2002 11:51:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UGoAv16631 for ; Wed, 30 Oct 2002 11:50:10 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24562 for ; Wed, 30 Oct 2002 11:47:43 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g9UGo3r05644; Wed, 30 Oct 2002 17:50:03 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g9UGo3J06891; Wed, 30 Oct 2002 17:50:03 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Michael Thomas" Cc: , , Subject: RE: [NSIS] RE: nsis mobility interactions Date: Wed, 30 Oct 2002 17:50:53 +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.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <15808.1017.296889.929712@thomasm-u1.cisco.com> 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 mike! > Hannes Tschofenig writes: > > hi hemant! > > > > i saw that "draft-ietf-ipv6-flow-label-03.txt" recommends > classification > > based on triplet (src adr, dest adr, flow label). in case of > mobility it > > would be much better to use the home address instead of the > source address. > > with a source address as part of the classifier all nodes > along the path > > require an update after the src address changed due to mobility. > > This is not at all clear. there are two cases for flow classification and mobility (in this context): a) home address is not used for flow classification if you roam and obtain a new care-of address then your new packets leaving your host do not receive qos treatment because - you have no reservation from your host to the cross-over router - your installed flow classifiers contain the wrong addresses (i.e. old care-of address - not the new one) you have to make a new reservation from up to the cross-over router. unfortunately you cannot stop there since the rest of the nodes along the path still need a flow classifier update (old coa -> new coa). b) home address is used packet classification is established for your home address. a new reservation needs to be created along the path up to the cross-over router. the flow classifier for the path after the cross-over router might already contain the home address and does not require an update. what do you think? i am not proposing that one should change the definition of the flow label. my intention was only to point to some issues. the flow label might be for example useful as a replacement of the 5-tuple. > Fishing out the home address > option for flow classification is onerous. that might be true. however, there are however some implications if you do not use it. it would be great if someone could provide performance figures (performance penalty compared to other flow identifiers) > Nor is it > always available as it could be invisible due to > encryption. this is always true. if you have tunnels somewhere along the path, end-to-end ipsec, nested ipsec tunnels then your flow classification has to respect it. > I'm not offering a solution here, just > pointing out that this is not obvious. thanks for pointing to it. there are definitely some issued which deserve further consideration. ciao hannes > > Mike > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 11:56:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25122 for ; Wed, 30 Oct 2002 11:56:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UGwBg17094 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 11:58:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UGw6v17080; Wed, 30 Oct 2002 11:58:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UGvfv17030 for ; Wed, 30 Oct 2002 11:57:41 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25028 for ; Wed, 30 Oct 2002 11:55:13 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9UGvBb19670 for ; Wed, 30 Oct 2002 18:57:11 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 30 Oct 2002 18:57:34 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Oct 2002 18:57:34 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Oct 2002 10:57:27 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [NSIS] RE: nsis mobility interactions Date: Wed, 30 Oct 2002 11:57:25 -0500 Message-ID: Thread-Topic: [NSIS] RE: nsis mobility interactions Thread-Index: AcJ/n4pnRg3vsB7tRe6q07VwO5B5+AAlPSsA To: X-OriginalArrivalTime: 30 Oct 2002 16:57:27.0837 (UTC) FILETIME=[6D7DACD0:01C28035] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9UGvfv17031 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Robert: See below as [HMC]: -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Tuesday, October 29, 2002 6:04 PM To: Chaskar Hemant (NRC/Boston); nsis@ietf.org Subject: RE: [NSIS] RE: nsis mobility interactions hi hemant, see below: > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: 29 October 2002 21:07 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] RE: nsis mobility interactions > > > Hi: > > The "draft-ietf-ipv6-flow-label-03.txt" recommends > classification based on triplet (src adr, dest adr, flow > label). We should not deviate from it unless it is essential. [reh] Broadly, I like the current flow label draft, having read it several times. However, I think it's specifically about the flow label scope issues, rather than trying to restrict possible flow classifiers. (Would we ban classifiers that included the DSCP, for example?) I'm certainly not in favour of using lots of higher layer fields, and I'd personally be happy for NSIS to restrict itself in this area. > > Also, what are those interesting implications on host > implementations that you were referring to? [reh] This is based on conversations I have had with people who have implementation experience with MIP and RSVP. As I understand it (and I pre-emptively claim simple ignorance as a defence if I have got it wrong), an assumption that underlies several RSVP implementations is that the application on the host conveys its opinion on the packet classifier to some user space RSVP daemon which then uses them directly in RSVP protocol messages. (draft-shen-rsvp-mobileipv6-interop-00.txt described precisely this behaviour.) The filter spec in these messages then doesn't match MIP-processed packets. So, what is needed instead is for the RSVP daemon to know *exactly* how user-space visible packets are going to be re-encapsulated as they go over virtual interfaces (MIP,IPsec,L2TP,...), which probably requires more knowledge of IP-layer internals than may be trivially available. [HMC] RSVP daemon has to be triggered when MN's point of attachment changes, in order to create reservations along the new path. The process that has the knowledge of change in point of attachment is Mobile IP (other than link layers of course). So, MIP process has to create trigger for RSVP daemon. In other words, in mobile environment, RSVP daemon cannot be receiving triggers only from applications, but has to receive them from IP stack as well. Hence, an API between IP and RSVP is needed anyway. What do you think? The RSVP daemon can't just take the application's view of the flow identification, wrap it in some headers, and chuck it at the host IP stack. OK, maybe it wasn't that interesting. But it seems worth keeping in mind. The framework alludes to these points (in 4.1 and 5.3.1, IIRC), but only briefly. > > Hemant cheers, robert h. > > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Sunday, October 27, 2002 6:35 PM > To: PIECHOCINSKI, MACIEJ; nsis@ietf.org > Subject: [NSIS] RE: nsis mobility interactions > > > hi all, > > i discussed these issues with Charles (Shen) at Yokohama. He > (& colleagues) have produced newer drafts: > draft-shen-nsis-rsvp-mobileipv6-00.txt > draft-shen-nsis-mobility-fw-00.txt > which I think change some of the previous conclusions or at > least emphasis. > > since this is now effectively a framework discussion, i can > recommend the second of these, as well as (I hope) section > 5.3 of draft-ietf-nsis-fw-00.txt. > > with the momentum behind the discussion, i'd like to > highlight some of the more general questions: > *) can we agree the assumption that flow identification > should be based on 'normal' header fields (i.e. not the HA > e.g. in HAO). Note: this has some interesting implications > for host implementations. > *) is the HA a suitable value to use as the basis of a > reservation identifier (basically, does the way it gets > secured provide sufficient protection from the point of view > of devices which aren't the MN & CN)? > *) should we restrict the scope of NSIS considerations to > MIP, or consider other mobility scenarios (e.g. SIP-based > mobility solutions, or stuff as in > draft-westberg-rmd-cellular-issues-01.txt) - where there > wouldn't be a constant HA anyway? > *) actually, what are the re-authentication/re-authorisation > requirements in such mobility scenarios? how much authority > can be devolved to the interior nodes in the network? > > plenty of others, of course... > > cheers, > > robert h. > [snipped] _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 12:06:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26102 for ; Wed, 30 Oct 2002 12:06:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UH8P118621 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 12:08:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UH8Nv18601; Wed, 30 Oct 2002 12:08:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UH6Sv17806 for ; Wed, 30 Oct 2002 12:06:28 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25665 for ; Wed, 30 Oct 2002 12:04:00 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 17:06:17 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA667@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Hemant.Chaskar@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] RE: nsis mobility interactions Date: Wed, 30 Oct 2002 17:06:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi hemant, see below: > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: 30 October 2002 16:57 > To: nsis@ietf.org > Subject: RE: [NSIS] RE: nsis mobility interactions > > > Hi Robert: > > See below as [HMC]: > > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Tuesday, October 29, 2002 6:04 PM > To: Chaskar Hemant (NRC/Boston); nsis@ietf.org > Subject: RE: [NSIS] RE: nsis mobility interactions > [snip] > > Also, what are those interesting implications on host > > implementations that you were referring to? > > [reh] This is based on conversations I have had with people > who have implementation experience with MIP and RSVP. As I > understand it (and I pre-emptively claim simple ignorance as > a defence if I have got it wrong), an assumption that > underlies several RSVP implementations is that the > application on the host conveys its opinion on the packet > classifier to some user space RSVP daemon which then uses > them directly in RSVP protocol messages. > (draft-shen-rsvp-mobileipv6-interop-00.txt described > precisely this behaviour.) The filter spec in these messages > then doesn't match MIP-processed packets. > > So, what is needed instead is for the RSVP daemon to know > *exactly* how user-space visible packets are going to be > re-encapsulated as they go over virtual interfaces > (MIP,IPsec,L2TP,...), which probably requires more knowledge > of IP-layer internals than may be trivially available. > > [HMC] RSVP daemon has to be triggered when MN's point of > attachment changes, in order to create reservations along the > new path. The process that has the knowledge of change in > point of attachment is Mobile IP (other than link layers of > course). So, MIP process has to create trigger for RSVP > daemon. In other words, in mobile environment, RSVP daemon > cannot be receiving triggers only from applications, but has > to receive them from IP stack as well. Hence, an API between > IP and RSVP is needed anyway. What do you think? > [snip] [reh] This is a good additional point. Are there examples of such APIs in existence? (Jukka, are you out there?) Maybe the same API could be used by [M]IP to tell the signalling process "you are using this packet classifier, but you should probably use this one instead" (although this would imply [M]IP inspecting each packet for this condition, which seems a bit unpleasant; seems nicer to have the signalling daemon get it right first time, i.e. a query capability would be better.) cheers, robert _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Oct 30 12:14:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26599 for ; Wed, 30 Oct 2002 12:14:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UHG1D19221 for nsis-archive@odin.ietf.org; Wed, 30 Oct 2002 12:16:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UHFwv19183; Wed, 30 Oct 2002 12:15:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UHEpv19015 for ; Wed, 30 Oct 2002 12:14:51 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26446 for ; Wed, 30 Oct 2002 12:12:18 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 17:14:39 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA668@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Michael Thomas'" Cc: "'Sarantis Paskalis'" , Hannes Tschofenig , Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: RE: [NSIS] RE: nsis mobility interactions Date: Wed, 30 Oct 2002 17:14:39 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Mike, > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 30 October 2002 16:20 > To: Hancock, Robert > Cc: 'Sarantis Paskalis'; Hannes Tschofenig; Hemant.Chaskar@nokia.com; > nsis@ietf.org > Subject: RE: [NSIS] RE: nsis mobility interactions > > > Hancock, Robert writes: > > hi all, > > > > will someone explain to me how the security (validation of HA > ownership in the network interior) and performance (required > complexity of packet classifier) issues with this approach would be > addressed? (no pun intended.) > > Robert, > > How is it done today? BCP 38 gives some guidence > but is far from perfect. The Home Address Option, > however, makes edge ingress filtering essentially > impossible as BCP 38 counts on edge routers > understanding their local topology such that they > can perform RPF checks, etc. This cannot be done > with the Home Address Option as the addresss... > isn't necessarily topologically local. > > Thus, it seems to me that expecting security > properties to be enforced based on arbitrary home > addresses is a hopeless task. However, I'm not > convinced that that is even needed as the > relationships in RSVP (and assumedly NSIS) are > always hopwise, and given the desire for ingress > filtering I'd expect that topologically correct > CoA's to be the norm. > > This entire discussion is very reminiscent of > HIP discussions and RFC 2207 considerations. > > Mike > Exactly. I can't see any practical way of ensuring only legitimate packets are associated to the reservation that has been set up for them, other than topological address based checks, namely: *) ingress filtering (weak assurance that the topological source address is valid) *) the fact that routing works (means there is no point forging the topological destination address) *) therefore, using the topological source and destination in a classifier is a Good Thing *) you can add other identifiers (SPI, FL, ports...) if you want for finer grained signalling, but this is ok since they're interpreted within the scope of an (SA,DA) pair anyway. It might be nice to use the HA, but it seems so impractical that I think a better question is: given that the packet classifiers are going to have to be updated on the unchanged path anyway, how can we make this as fast as possible (e.g. avoid re-authorisation, renegotiation of services and so on). *In addition* in terms of overall latency, are we punishing ourselves for no gain trying to avoid this refresh on the common path, given that change-of-address signalling must be being used e2e anyway (after all, the correspondent didn't just guess the new CoA). If we can trigger the classifier update at the same time as this mobility-related signalling, we don't lose anything. (And, IIRC, this is precisely the sort of question that your seamoby draft considers. It makes my head hurt too.) Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 01:31:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28708 for ; Thu, 31 Oct 2002 01:31:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9V6Xjv31960 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 01:33:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V6Xgv31935; Thu, 31 Oct 2002 01:33:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V6WDv31891 for ; Thu, 31 Oct 2002 01:32:13 -0500 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28608 for ; Thu, 31 Oct 2002 01:29:38 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g9V6Vx815032; Thu, 31 Oct 2002 08:32:00 +0200 Date: Thu, 31 Oct 2002 08:31:59 +0200 (EET) From: Jukka MJ Manner To: "Hancock, Robert" cc: "'Hemant.Chaskar@nokia.com'" , Subject: RE: [NSIS] RE: nsis mobility interactions In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA667@rsys002a.roke.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , On Wed, 30 Oct 2002, Hancock, Robert wrote: > > -----Original Message----- > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > Sent: 30 October 2002 16:57 > > To: nsis@ietf.org > > Subject: RE: [NSIS] RE: nsis mobility interactions > > > > [HMC] RSVP daemon has to be triggered when MN's point of > > attachment changes, in order to create reservations along the > > new path. The process that has the knowledge of change in > > point of attachment is Mobile IP (other than link layers of > > course). So, MIP process has to create trigger for RSVP > > daemon. In other words, in mobile environment, RSVP daemon > > cannot be receiving triggers only from applications, but has > > to receive them from IP stack as well. Hence, an API between > > IP and RSVP is needed anyway. What do you think? > > > [snip] > [reh] This is a good additional point. Are there examples of such APIs > in existence? (Jukka, are you out there?) [JM] "Mr. reh calling?" :) Well, currently I have such a thing implemented and running as we speak. Actually, I have an LMM process signalling applications, which in turn trigger the daemon, but you could do it (with more effort :) with your MIP process towards the daemon. Still, some could argue that applications might also want to know about changes in network state (=handovers), especially vertical ones. Regards, Jim _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 03:27:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10168 for ; Thu, 31 Oct 2002 03:26:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9V8T4t14088 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 03:29:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V8Swv14079; Thu, 31 Oct 2002 03:28:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V8R3v14028 for ; Thu, 31 Oct 2002 03:27:03 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10157 for ; Thu, 31 Oct 2002 03:24:27 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 31 Oct 2002 09:26:34 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 09:26:29 +0100 Message-Id: From: "Geib, Ruediger" To: braden@ISI.EDU, brunner@ccrle.nec.de, robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) Date: Thu, 31 Oct 2002 09:26:27 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9V8R3v14029 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi John, I support Bob's suggestion and would like to ask you about your and the AD's position. Regards, Rüdiger Bob Braden wrote: There is a subtle difference between neighbor discovery and routing. Discovery allows a node to find all the neighbor nodes to which signaling messages might be forwarded. Routing determines which actual next hops are used for forwarding a particular signaling message. Neighbor discovery involves only local information,\ while routing involves global information in general. I can imagine that the new QoS signaling protocol [I refuse to call it "NSIS", because I think that's a dumb name for a protocol] might want to have a neighbor discovery mechanism (roughly an "up/down" protocol), but it might still want to route signaling packets using the same routing that is used for data packets. Note that if you use "some different routing mechanism", you almost certainly have times when data routing differs from signal routing, which is busted. Thanks, Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 04:41:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11222 for ; Thu, 31 Oct 2002 04:41:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9V9h5Z19021 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 04:43:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V9h3v19014; Thu, 31 Oct 2002 04:43:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9V9ewv18889 for ; Thu, 31 Oct 2002 04:40:58 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11146 for ; Thu, 31 Oct 2002 04:38:23 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9V9eiKV011043; Thu, 31 Oct 2002 10:40:44 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VS6C506X; Thu, 31 Oct 2002 10:40:44 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 10:40:44 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE16A@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: nsis@ietf.org Cc: "'Bob Braden'" Subject: RE: [NSIS] yet another terminology proposal Date: Thu, 31 Oct 2002 10:38:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all I think that the suggestions of Bob and Melinda could help us in finalizing the framework draft. Particularly, it will be very useful if Bob could help us on describing and writing why and how the protocol should be separated in protocol levels. Best Regards, Georgios -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: woensdag 30 oktober 2002 4:32 To: Hancock, Robert; nsis@ietf.org Subject: Re: [NSIS] yet another terminology proposal > > > >NSIS Transport Layer Protocol (NTLP): the lower layer, responsible for >moving messages around, for which we hope there will be a single protocol >(at least in any network type); may or may not be based on or include >underlying 'standard' transport protocols; independent of the signalling >application. > >NSIS Signalling Layer Protocol (NSLP): the upper layer, which defines >messages (and maybe states or message sequences) which are specific to a >particular signalling application. We therefore expect there to be several >of these (e.g. 1 or even >1 per signalling application). OK, except I think the N is dumb. How about: ISTP Internet signaling transport protocol ISCP Internet signaling control protocol ?? Any takers? >(Choosing a good name is not an idle exercise) Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 10:52:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26731 for ; Thu, 31 Oct 2002 10:52:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VFsHF08141 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 10:54:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VFsEv08134; Thu, 31 Oct 2002 10:54:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VFqnv08103 for ; Thu, 31 Oct 2002 10:52:49 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26611 for ; Thu, 31 Oct 2002 10:50:23 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 15:52:44 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA670@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Thu, 31 Oct 2002 15:52:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Subject: [NSIS] RE: I-D ACTION:draft-hancock-nsis-sender-receiver-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, I'd just like to re-affirm the existence of the draft below. It's basically an attempt to review the overall issue of sender/receiver orientation (what is it? which do we need? which do we really need?) and to outline perceived pros & cons of some very broad categories of approach to the problem. It therefore has a sort of requirementsy/frameworky feel. A particular issue is how these concepts apply to which layer (called nbp/asap in the draft, what we might soon call ntlp/nslp or even itlp/islp), which we have not really considered in this w.g. up to now. Comments welcome, of course. Cheers, Robert H. ps. For those interested in path-decoupled issues, there is a quick discussion at the end. Interestingly (for me), the conclusion - that the coupled/decoupled difference should be handled in the ntlp, with signalling applications unchanged - seems to be the complete opposite of what Bob & John have suggested recently. So I guess there's scope for exploration there, at some point. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 30 October 2002 11:19 > Cc: nsis@ietf.org > Subject: I-D ACTION:draft-hancock-nsis-sender-receiver-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Sender and Receiver Orientation Issues in NSIS > Author(s) : R. Hancock et al. > Filename : draft-hancock-nsis-sender-receiver-00.txt > Pages : 16 > Date : 2002-10-29 > > The NSIS working group is considering protocols for signaling for > resources for a traffic flow along its path in the network. The > requirements for such signaling are being developed in [2] and a > framework in [3]. > It is clear from existing work that there are many interrelated > issues with NSIS signaling, concerning the respective roles of the > two ends of the communication path. These issues include route > finding, authorisation, state management requirements, localization > of negotiation, and so on. The wide variety of problems involved > hinders progress in deciding what approach NSIS should adopt. This > Internet Draft attempts to provide a summary of these issues and > suggests a way of structuring further analysis. It is not expected > that this document should have a long term existence. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hancock-nsis-sender- receiver-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hancock-nsis-sender-receiver-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hancock-nsis-sender-receiver-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 13:51:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07799 for ; Thu, 31 Oct 2002 13:51:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VIqwJ21474 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 13:52:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIqXv21455; Thu, 31 Oct 2002 13:52:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VIp9v21403 for ; Thu, 31 Oct 2002 13:51:09 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07590 for ; Thu, 31 Oct 2002 13:48:39 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9VIovI21955; Thu, 31 Oct 2002 12:50:57 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 12:50:43 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E067575A1@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Bob Braden , "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] yet another terminology proposal Date: Thu, 31 Oct 2002 12:50:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2810E.68FC0FB0" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2810E.68FC0FB0 Content-Type: text/plain I'd like to suggest: NSTP - Network Services Transport Protocol NSCP - Network Services Control Protocol and I mean "network" in that services that layer 3 network entities have to be involved in order to provide the service. -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: Tuesday, October 29, 2002 9:32 PM To: Hancock, Robert; nsis@ietf.org Subject: Re: [NSIS] yet another terminology proposal > > > >NSIS Transport Layer Protocol (NTLP): the lower layer, responsible for >moving messages around, for which we hope there will be a single protocol >(at least in any network type); may or may not be based on or include >underlying 'standard' transport protocols; independent of the signalling >application. > >NSIS Signalling Layer Protocol (NSLP): the upper layer, which defines >messages (and maybe states or message sequences) which are specific to a >particular signalling application. We therefore expect there to be several >of these (e.g. 1 or even >1 per signalling application). OK, except I think the N is dumb. How about: ISTP Internet signaling transport protocol ISCP Internet signaling control protocol ?? Any takers? >(Choosing a good name is not an idle exercise) Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C2810E.68FC0FB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [NSIS] yet another terminology proposal

I'd like to suggest:

NSTP - Network Services Transport Protocol
NSCP - Network Services Control Protocol

and I mean "network" in that services that = layer 3 network entities have to be involved in order to provide the = service.

-----Original Message-----
From: Bob Braden [mailto:braden@ISI.EDU]
Sent: Tuesday, October 29, 2002 9:32 PM
To: Hancock, Robert; nsis@ietf.org
Subject: Re: [NSIS] yet another terminology = proposal



>
>
>
>NSIS Transport Layer Protocol (NTLP): the lower = layer, responsible for
>moving messages around, for which we hope there = will be a single protocol
>(at least in any network type); may or may not = be based on or include
>underlying 'standard' transport protocols; = independent of the signalling
>application.
>
>NSIS Signalling Layer Protocol (NSLP): the upper = layer, which defines
>messages (and maybe states or message sequences) = which are specific to a
>particular signalling application. We therefore = expect there to be several
>of these (e.g. 1 or even >1 per signalling = application).


OK, except I think the N is dumb.  How = about:

ISTP  Internet signaling transport = protocol
ISCP Internet signaling control protocol

?? Any takers?

>(Choosing a good name is not an idle = exercise)

Bob Braden



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

------_=_NextPart_001_01C2810E.68FC0FB0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 17:00:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17095 for ; Thu, 31 Oct 2002 17:00:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VM21v00879 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 17:02:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM1xv00857; Thu, 31 Oct 2002 17:01:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM0ov00577 for ; Thu, 31 Oct 2002 17:00:50 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17032 for ; Thu, 31 Oct 2002 16:58:20 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9VM13B22206 for ; Fri, 1 Nov 2002 00:01:03 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Nov 2002 00:00:42 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:00:42 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:00:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) Date: Fri, 1 Nov 2002 00:00:40 +0200 Message-ID: Thread-Topic: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) Thread-Index: AcKAJE0Ao2yd0rYOS3ahj6kBbhaRRQAqy3sQ To: , , Cc: X-OriginalArrivalTime: 31 Oct 2002 22:00:41.0418 (UTC) FILETIME=[F41F92A0:01C28128] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VM0ov00578 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, > I can imagine that the new QoS signaling protocol [I refuse to call it "NSIS", > because I think that's a dumb name for a protocol] I haven't seriously meant that NSIS is the protocol name, I have only suggested using it as a place holder until we start protocol work, in the WG. > might want to have a neighbor discovery mechanism (roughly an "up/down" protocol), > but it might still want to route signaling packets using the same routing that > is used for data packets. I think that is reasonable. > Note that if you use "some different routing mechanism", you almost certainly have > times when data routing differs from signal routing, which is busted. What do you mean by this - I think I know what you mean - do you mean that at a conceptual level having data routing different from signaling routing would be a 'broken' concept or something else? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 17:00:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17110 for ; Thu, 31 Oct 2002 17:00:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VM24X00908 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 17:02:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM21v00874; Thu, 31 Oct 2002 17:02:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM0pv00581 for ; Thu, 31 Oct 2002 17:00:51 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17035 for ; Thu, 31 Oct 2002 16:58:21 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9VM15B22253 for ; Fri, 1 Nov 2002 00:01:05 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Nov 2002 00:00:43 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:00:43 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:00:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] on-path versus off-path discussion Date: Fri, 1 Nov 2002 00:00:42 +0200 Message-ID: Thread-Topic: [NSIS] on-path versus off-path discussion Thread-Index: AcKAJqNFZWaj7snMTJq8UJSYci16oQAqTixg To: Cc: X-OriginalArrivalTime: 31 Oct 2002 22:00:43.0232 (UTC) FILETIME=[F5345E00:01C28128] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VM0pv00582 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, > With all respect to you and the ADs, I suggest again that the answer > might be different at the signaling transport (ST) and the signaling > application (SA) layers. I agree. I can easily see the SA being used for different things. What I think is important for us, as a WG, would be to start bounding the problem. I think we have greatly exploded the possible areas to investigate in the WG - and we are getting no closer to meeting our deliverables. Additionally, we have to meet certain requirements in order to actually begin protocol work. A 'simplified' RSVP needs to be shown to be infeasible before we can do anything. I have yet to see a convincing argument why an off-path signaling protocol is needed - though a lot of people would like to use such a protocol. I will suggest that 'off-path' signaling discussion be closed, until someone can produce a good document explaining why it is imperative that it be considered by the NSIS WG. Further more, I think that the requirements document can be somewhat simplified, and generalized (covering both the ST & SA layers you mention above). We need some good analysis of existing solutions (Mike Thomas' MIP & RSVP document is a good start). So, in summary, I will reserve some time in Atlanta to discuss these bigger picture issues & how to move forward with this work. My initial feeling is that we need to restrict the scope of what we are trying to do - because at this point we are diverging. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 17:00:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17123 for ; Thu, 31 Oct 2002 17:00:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VM25t00920 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 17:02:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM22v00901; Thu, 31 Oct 2002 17:02:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM0uv00585 for ; Thu, 31 Oct 2002 17:00:56 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17043 for ; Thu, 31 Oct 2002 16:58:26 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9VM0NO01070 for ; Fri, 1 Nov 2002 00:00:23 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Nov 2002 00:00:47 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:00:47 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:00:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] nsis threat issues Date: Fri, 1 Nov 2002 00:00:47 +0200 Message-ID: Thread-Topic: [NSIS] nsis threat issues Thread-Index: AcJ/6jnYGARG9G2sQ9WWk6lYBZEYWABKEc2w To: , X-OriginalArrivalTime: 31 Oct 2002 22:00:47.0525 (UTC) FILETIME=[F7C36D50:01C28128] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VM0uv00586 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Hannes, > i was asked to whether a separation between the transport and the > application part should be made. currently the nsis threat document is > focused on the application layer part and not on transport issues. i can add > an additional threat covering this issue. > two examples: > - an adversary would modify ip headers of the signaling > messages (if ip used > used for message transport) > - in case of a transport protocol: an adversary could terminate an > established tcp connection. > however these threats are not special for nsis signaling protocols. That would be good to add, just to be complete. > an important issue i see is that some people have no opinion > on particular security issues. > for example: > - is non-repudiation necessary/required or not important at all. dunno > - how important is a threat caused by a malicious nsis entity? Do you mean a compromised entity? I think it is an important threat . > - is network topology hiding a desired property? No. > - what about signaling message confidentiality? > - do we worry about the reservation (or session) ownership problem? > - etc. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 17:01:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17201 for ; Thu, 31 Oct 2002 17:01:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VM3Bb01054 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 17:03:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM37v00988; Thu, 31 Oct 2002 17:03:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM1Av00821 for ; Thu, 31 Oct 2002 17:01:10 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17057 for ; Thu, 31 Oct 2002 16:58:40 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9VM0cO01344 for ; Fri, 1 Nov 2002 00:00:38 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Nov 2002 00:01:02 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:01:02 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:01:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] on-path versus off-path discussion Date: Fri, 1 Nov 2002 00:01:01 +0200 Message-ID: Thread-Topic: [NSIS] on-path versus off-path discussion Thread-Index: AcKAI4pLQS1MfBd1SXuSNBTa1J++SAA8h5Vw To: , , Cc: , , X-OriginalArrivalTime: 31 Oct 2002 22:01:01.0910 (UTC) FILETIME=[00566760:01C28129] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VM1Av00822 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, > My answer is: "yes and no""! I suggest that the CSTP level > of the two-level model should be general enough to support either > path coupled or path-decoupled signaling. However, when NSIS > considers developing an ALSP for QoS signaling, > I have the serious doubts I expressed previously about the > architectural wisdom of path-decoupled operation. I hope the > WG will at least require a convincing technical argument (which > I have not yet heard) in favor of the path- > decoupled model before including it in the (first) ALSP. My current thinking (to be discussed/resolved in Atlanta) would be to work on two AL (application layer) protocols - one providing an 'rsvp v2' type of service and another one for NAT traversal. As both of these consider things-on-the-path of the data, the path de-coupled case is out of scope. Now, I do think we may be clever enough that the transport layer protocol we design could be used for path decoupled signaling, I don't think that is something we are work on (yet). John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 17:01:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17223 for ; Thu, 31 Oct 2002 17:01:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VM3CK01066 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 17:03:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM39v01003; Thu, 31 Oct 2002 17:03:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM1Dv00825 for ; Thu, 31 Oct 2002 17:01:13 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17060 for ; Thu, 31 Oct 2002 16:58:44 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9VM1RB22673 for ; Fri, 1 Nov 2002 00:01:27 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Nov 2002 00:01:05 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:01:05 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:01:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Comments on framework draft Date: Fri, 1 Nov 2002 00:01:05 +0200 Message-ID: Thread-Topic: [NSIS] Comments on framework draft Thread-Index: AcJ3qyIUf/yG+9gvQVmdBJbQYrfJUgJa/6vA To: , , , X-OriginalArrivalTime: 31 Oct 2002 22:01:05.0602 (UTC) FILETIME=[0289C220:01C28129] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VM1Ev00826 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, > I suggest that the solution is to simply eliminate the term. It does > not seem necessary, and perhaps not useful. Note that in routing > protocols, neighboring routers announce their presence to each other > and may even exchange security information, but these neighbor > announcements are not said to create sessions. My 2-level signaling > draft simply says: > > > A CSTP module must maintain state that lists the node's neighbors. > This state includes the IP address of the neighbor and the local > interface used to reach it. This per-neighbor state also includes > two Boolean flags giving important properties of the neighbor, > e.g., ISPS-capable and Direct-Neighbor. A node builds the > neighbor list as a result of receiving CSTP messages. The > neighbor list should be implemented as soft state that is deleted > if it is not refreshed. > > Introducing a term like "session" for this neighbor state does not > seem to me to add any clarity. I completely agree. I think that this terminology simplifies things. I think your text has a particular 'solution' so at least for now, perhas we could take the concept into the framework. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 17:01:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17240 for ; Thu, 31 Oct 2002 17:01:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VM3DT01079 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 17:03:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM3Av01020; Thu, 31 Oct 2002 17:03:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VM1Hv00829 for ; Thu, 31 Oct 2002 17:01:17 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17063 for ; Thu, 31 Oct 2002 16:58:47 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9VM0jO01480 for ; Fri, 1 Nov 2002 00:00:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Nov 2002 00:01:09 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:01:08 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:01:08 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 00:01:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] on-path versus off-path discussion Date: Fri, 1 Nov 2002 00:01:07 +0200 Message-ID: Thread-Topic: [NSIS] on-path versus off-path discussion Thread-Index: AcJ2pHaO0nWkmTNqRjOk81kBQgYI1QKcwhjA To: Cc: X-OriginalArrivalTime: 31 Oct 2002 22:01:07.0638 (UTC) FILETIME=[03C06D60:01C28129] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9VM1Hv00830 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, > [JL] My feeling is that they don't want us to work on discovery. > Discovery should come automatically, due to the signaling. > > Is this feeling part of the requirements doc or the charter > or wherever it fits well to? Or would it be a bad idea to > put it down somewhere? I'll tack this on to my things to discuss in Atlanta ;) John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 18:45:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20443 for ; Thu, 31 Oct 2002 18:45:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VNlS907220 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 18:47:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNlPv07182; Thu, 31 Oct 2002 18:47:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNkKv07134 for ; Thu, 31 Oct 2002 18:46:20 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20393 for ; Thu, 31 Oct 2002 18:43:49 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 23:46:11 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5CB7@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, braden@ISI.EDU, brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) Date: Thu, 31 Oct 2002 23:46:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, [NB please note that this mail has nothing to do with either mobility interactions or the requirements draft, it's just framework terminology stuff. It also relates to other emails.] 1. I still like NTLP and NSLP (NSIS [Transport|Signalling] Layer Protocol) as terms. The fact that the N is dumb doesn't stop them being good placeholders, rather like IPng was used as a placeholder term (rfc1454, 1550, 1726 and so on). With any luck, the dumb-ness will discourage anyone from actually calling a proposed protocol 'NTLP', which is probably a good thing. 2. I think the unqualified term 'routing' should be reserved for 'what the IP layer does to work out where to forward an IP packet', and I sincerely hope there's no proposals to have different versions of this for data and signalling packets. 3. I could imagine a term like 'message routing' for 'what happens within the NTLP level to get a message to the right [NSIS] peer', which might be 'put it in an IP packet with the flow destination address and rely on the network' or 'send it explicitly to a known peer' or conceivably something else. Would that be a useful concept? (It's obviously closely related to the NSIS addressing question.) 4. I've proposed to add the term 'peer discovery' to denote 'finding implicitly or explicitly the NSIS peer to which a message for a given flow should be sent'. (Note that this is different from using the term 'discovery' to mean 'find all the NSIS entities I can talk to directly, mainly because I can't see that being easy or useful, especially in a world with a low density of NSIS-aware routers. Maybe there is a need for a different word for one of these.) 5. The proposal in the framework is then that the NTLP should do message routing by incorporating peer discovery capability based on what for shorthand I could call RSVP-like mechanisms ("Discovery should come automatically, due to the signaling." [JL]), BUT that the framework should include hooks to allow the same information to be obtained from other sources (and, I suppose, that we can discuss example mechanisms to make sure we put these hooks in the right place). Would people object to that (and would it match the charter?) Note: 'object' would mean either 'ignore the possibility, no external peer discovery mechanisms should be considered' or 'demand to incorporate the details of the external mechanisms in the framework'. input before the -01 deadline appreciated (if we can get at least a stable and universally comprehensible terminology baseline, maybe that will count as progress), cheers, robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 31 October 2002 22:01 > To: braden@ISI.EDU; brunner@ccrle.nec.de; Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments > on draft-ietf-nsis-req-04.txt) > > > Hi Bob, > > > I can imagine that the new QoS signaling protocol [I refuse > to call it "NSIS", > > because I think that's a dumb name for a protocol] > > I haven't seriously meant that NSIS is the protocol name, I > have only suggested > using it as a place holder until we start protocol work, in the WG. > > > might want to have a neighbor discovery mechanism (roughly > an "up/down" protocol), > > but it might still want to route signaling packets using > the same routing that > > is used for data packets. > > I think that is reasonable. > > > Note that if you use "some different routing mechanism", > you almost certainly have > > times when data routing differs from signal routing, which > is busted. > > What do you mean by this - I think I know what you mean - do you mean > that at a conceptual level having data routing different from > signaling routing > would be a 'broken' concept or something else? > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 18:45:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20457 for ; Thu, 31 Oct 2002 18:45:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VNlTp07232 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 18:47:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNlQv07197; Thu, 31 Oct 2002 18:47:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNkVv07146 for ; Thu, 31 Oct 2002 18:46:31 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20398 for ; Thu, 31 Oct 2002 18:44:00 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 23:46:23 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5CBA@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, braden@ISI.EDU, mshore@cisco.com, nsis@ietf.org Subject: RE: [NSIS] Comments on framework draft Date: Thu, 31 Oct 2002 23:46:14 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , john: > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 31 October 2002 22:01 > To: braden@ISI.EDU; mshore@cisco.com; nsis@ietf.org; Hancock, Robert > Subject: RE: [NSIS] Comments on framework draft > > > Hi Bob, > > > I suggest that the solution is to simply eliminate the > term. It does > > not seem necessary, and perhaps not useful. Note that in routing > > protocols, neighboring routers announce their presence to each other > > and may even exchange security information, but these neighbor > > announcements are not said to create sessions. My 2-level signaling > > draft simply says: > > > > > > A CSTP module must maintain state that lists the > node's neighbors. > > This state includes the IP address of the neighbor > and the local > > interface used to reach it. This per-neighbor state > also includes > > two Boolean flags giving important properties of the neighbor, > > e.g., ISPS-capable and Direct-Neighbor. A node builds the > > neighbor list as a result of receiving CSTP messages. The > > neighbor list should be implemented as soft state > that is deleted > > if it is not refreshed. > > > > Introducing a term like "session" for this neighbor state does not > > seem to me to add any clarity. > > I completely agree. I think that this terminology simplifies things. > I think your text has a particular 'solution' so at least for now, > perhas we could take the concept into the framework. ^^^^^^^^^^^ which concept? (recall we are proposing to drop the term 'session' anyway, the last proposal was just to talk about 'peer relationship' and not say anything that could be thought of as implying a 'session model' as melinda calls it.) PS I'm also still in a state of preferring 'peer' over 'neighbo[u]r', do people really find the term unbearable? > > John > robert _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Oct 31 18:45:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20470 for ; Thu, 31 Oct 2002 18:45:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9VNlVm07247 for nsis-archive@odin.ietf.org; Thu, 31 Oct 2002 18:47:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNlSv07213; Thu, 31 Oct 2002 18:47:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9VNkVv07144 for ; Thu, 31 Oct 2002 18:46:31 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20397 for ; Thu, 31 Oct 2002 18:44:00 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 23:46:23 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5CBB@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, Hannes.Tschofenig@siemens.com, nsis@ietf.org Subject: RE: [NSIS] nsis threat issues Date: Thu, 31 Oct 2002 23:46:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi hannes, you asked for opinions, here are mine: [> > = you; > = john; [reh] = me] > > an important issue i see is that some people have no opinion > > on particular security issues. > > for example: > > - is non-repudiation necessary/required or not important at all. > dunno [reh] definitely only a property of a particular NSLP (signalling application) that wants it, not a general NSIS requirement. how would needing to support it in an NSLP impact the rest of NSIS work? > > - how important is a threat caused by a malicious nsis entity? > Do you mean a compromised entity? I think it is an important > threat . [reh] I agree; however, we need analysis to see whether the NSIS-specific element of the threat is additional to whatever else the entity can do. (e.g. If someone has a malicious router in the data path, the fact that they can compromise NSIS signalling may be overshadowed by all the other terrible things they can do - obviously it is a hard analysis problem to weigh these up.) > > - is network topology hiding a desired property? > No. [reh] I would say 'desired but not essential'. If nothing else, I think making it possible to hide the topology introduces a discipline in users of the protocol (i.e. they don't abuse the protocol by finding out about the topology when they shouldn't be trying to). Maybe a MAY is appropriate. > > - what about signaling message confidentiality? [reh] yes please > > - do we worry about the reservation (or session) ownership problem? [reh] this is a vital issue as I see it. We need to know how much manipulation can be done at the NTLP level (and hence IMHO independently of authorisation issues) and how much can only be done within the specific signalling application (listen to the sound of "mobility interaction" in the background). > > - etc. > > thanks, > John > cheers, robert h _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis