From exim@www1.ietf.org Mon Mar 1 05:56:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09406 for ; Mon, 1 Mar 2004 05:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl5g-0005RH-Mt for nsis-archive@odin.ietf.org; Mon, 01 Mar 2004 05:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Au493020856 for nsis-archive@odin.ietf.org; Mon, 1 Mar 2004 05:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl5g-0005QH-0c; Mon, 01 Mar 2004 05:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl5H-0005OS-9y for nsis@optimus.ietf.org; Mon, 01 Mar 2004 05:55:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09363 for ; Mon, 1 Mar 2004 05:55:36 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axl5D-0005FC-00 for nsis@ietf.org; Mon, 01 Mar 2004 05:55:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axl4P-00056b-00 for nsis@ietf.org; Mon, 01 Mar 2004 05:54:45 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Axl3C-0004oS-00 for nsis@ietf.org; Mon, 01 Mar 2004 05:53:31 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21ArUT15872; Mon, 1 Mar 2004 12:53:31 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 12:52:03 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i21Aq3gi000971; Mon, 1 Mar 2004 12:52:03 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00pdlaX9; Mon, 01 Mar 2004 12:52:02 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21Aq1723349; Mon, 1 Mar 2004 12:52:01 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 12:51:56 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 12:51:56 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 12:51:50 +0200 Message-ID: Thread-Topic: NSIS Session Documentation thread-index: AcP/ehYXroSJFFx0TQSjGaJnI7MODwAANLLQ To: Cc: X-OriginalArrivalTime: 01 Mar 2004 10:51:57.0128 (UTC) FILETIME=[375B0C80:01C3FF7B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [NSIS] RE: NSIS Session Documentation Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgSGFucywNCg0KPiBjb3VsZCB5b3UgdGVsbCBtZSAodXMpIGF0IHdjaGljaCBVUkwgYWxsIHRo ZSBkb2N1bWVudHMgb2YgdGhlIA0KPiBJRVRGIHNlc3Npb25zIGFyZSBsb2NhdGVkLCBwbGVhc2U/ DQoNClRoZXkgY2FuIGJlIGZvdW5kIGF0Og0KDQpodHRwOi8vd3d3LW5yYy5ub2tpYS5jb20vc3Vh L25zaXMvaWV0ZjU5Lw0KDQpOb3QgbXVjaCBpcyB0aGVyZSB5ZXQuDQoNClByZXNlbnRlcnMsIHBs ZWFzZSBzZW5kIHlvdXIgcHJlc2VudGF0aW9ucyBBU0FQIQ0KDQpKb2huDQo= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 1 06:42:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12213 for ; Mon, 1 Mar 2004 06:42:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxloB-0001ok-Ou for nsis-archive@odin.ietf.org; Mon, 01 Mar 2004 06:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Bg3oR006983 for nsis-archive@odin.ietf.org; Mon, 1 Mar 2004 06:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axlo9-0001o3-SV; Mon, 01 Mar 2004 06:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axlnj-0001nE-TL for nsis@optimus.ietf.org; Mon, 01 Mar 2004 06:41:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12197 for ; Mon, 1 Mar 2004 06:41:32 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axlnf-0002ii-00 for nsis@ietf.org; Mon, 01 Mar 2004 06:41:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axlmh-0002db-00 for nsis@ietf.org; Mon, 01 Mar 2004 06:40:32 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Axllj-0002Vq-00 for nsis@ietf.org; Mon, 01 Mar 2004 06:39:31 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21BdVT22165 for ; Mon, 1 Mar 2004 13:39:31 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 13:39:18 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i21BdI4U015621 for ; Mon, 1 Mar 2004 13:39:18 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00BHtTHp; Mon, 01 Mar 2004 13:39:16 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21BdBO23580 for ; Mon, 1 Mar 2004 13:39:11 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 13:39:07 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 13:39:07 +0200 Message-ID: Thread-Topic: Dave Oran's comments thread-index: AcP/gc4slsrXy5bOTSao0YPv+/JOMQ== To: X-OriginalArrivalTime: 01 Mar 2004 11:39:07.0864 (UTC) FILETIME=[CE9B1580:01C3FF81] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Dave Oran's comments Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable These are Dave Oran's comments. thanks, John This covers my overall impressions and my comments on GIMPS. Comments on = QoS and NATFW to follow. General: - I'm still not comfortable with the delicate tradeoffs of = responsiveness=20 to routing changes and message overhead. This is fundamental to the = whole=20 C-mode/D-mode operation and hence we may just have to live with the=20 tradeoffs - Don't feel comfortable that the ordering properties among the = signaling=20 applications carried by GIMPS are captured in the design. For example, = QoS=20 signaling depends on prior establishment of NAT and FW state. What = enforces=20 this ordering, and if so, does it require extra RTTs to set up the=20 dependent state? NTLP Comments: - Definition of data flow excludes multicast. OK, but should this be = part=20 of the definition? - Definition of data flow enforces "unique path". Does this mean path=20 splitting is not ok even for flows where delivery order doesn't matter? - How does path coupling work if proxies are not on the path? - What led to the decision to use a hop count rather than a VIA-style = path=20 recording? - The D-mode gimps message needs to truly mimic the actual data flow in=20 order to guarantee congruent routing. This is particularly important = where=20 routers may be doing their own flow routing based on things like DSCP. - If NATs have to be GIMPS-aware then aren't we punting a big part of = the=20 application scope for NSIS? - NIT on tunneling - it's the outer header of the tunneled packets which = doesn't have RAO, not the tunneled packet itself. - section 8.3 says raw IP ruled out by section 8.2 but I see nothing in = 8.2=20 which argues for ruling out raw ip encapsulation. Just confused here... - small point on aggregation - its the exit interface which defines the=20 aggregation level, not the router. A router could have interfaces at=20 different aggregation levels. Comments on NSLP - in general this doc is not as well written as NTLP and needs some=20 editorial work. Parts are pretty hard to understand. - Policy control may involve "envelope resource utilitzation" policy in=20 addition to simple AAA. This means that hard synchronization with the = AAA=20 policy state and the NSLP element may be necessary. - Is there a need for explicit teardown invoked by the AAA element? - How is receiver selection based on ADSPEC done if resources are = reserved=20 in the forward direction with RESERVE? - some talk about 2-phase operation for RSVP. Any thought of the same = for=20 NSLP? - Didn't see any way to do resource sharing across flows. - Ditto for fate-sharing across flows (if you tear one down you tear the = fate-shared ones down) - Reservation priority is declared out of scope but is critically=20 important. We can't just punt this. One thought is to have it be part of = a=20 set of "common facilities" that go across all the GIMPS applications. I = bet=20 there are a number of such common things which are not part of the=20 transport but aren't specific to a particular signaling appication. - Is there any capability for make-before-break so that reservations can = be=20 installed on multiple paths at the same time to deal with graceful=20 mobility? It seems that the notion of flow/session separation captures = part=20 of this, but I don't see how it solves the double-booking problems on = the=20 common links. - how does bi-dir reservation enforce symmetric routing? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 1 07:04:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13176 for ; Mon, 1 Mar 2004 07:04:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axm9T-0003oj-TD for nsis-archive@odin.ietf.org; Mon, 01 Mar 2004 07:04:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21C43Y2014617 for nsis-archive@odin.ietf.org; Mon, 1 Mar 2004 07:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axm9R-0003na-JD; Mon, 01 Mar 2004 07:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axm8f-0003dm-KN for nsis@optimus.ietf.org; Mon, 01 Mar 2004 07:03:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13017 for ; Mon, 1 Mar 2004 07:03:09 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axm8b-0004jZ-00 for nsis@ietf.org; Mon, 01 Mar 2004 07:03:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axm7O-0004ZK-00 for nsis@ietf.org; Mon, 01 Mar 2004 07:01:54 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1Axm6a-0004S9-00 for nsis@ietf.org; Mon, 01 Mar 2004 07:01:04 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21C14L10960 for ; Mon, 1 Mar 2004 14:01:05 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 14:00:56 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i21C0u2w022546 for ; Mon, 1 Mar 2004 14:00:56 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00CQGzN3; Mon, 01 Mar 2004 14:00:55 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21C0oO03215 for ; Mon, 1 Mar 2004 14:00:50 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 14:00:44 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 14:00:43 +0200 Message-ID: Thread-Topic: Updated presentations available thread-index: AcP/hNIPDirrnNxBQ1WnV6uI/fYSnA== To: X-OriginalArrivalTime: 01 Mar 2004 12:00:44.0551 (UTC) FILETIME=[D37DD170:01C3FF84] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Updated presentations available Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I've updated the presentations. http://www-nrc.nokia.com/sua/nsis/ietf59/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 2 00:12:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02133 for ; Tue, 2 Mar 2004 00:12:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2CI-0004s9-AY for nsis-archive@odin.ietf.org; Tue, 02 Mar 2004 00:12:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i225C26C018713 for nsis-archive@odin.ietf.org; Tue, 2 Mar 2004 00:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2CH-0004rf-Eh; Tue, 02 Mar 2004 00:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2BV-0004qZ-5M for nsis@optimus.ietf.org; Tue, 02 Mar 2004 00:11:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02049 for ; Tue, 2 Mar 2004 00:11:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2BS-00048f-00 for nsis@ietf.org; Tue, 02 Mar 2004 00:11:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2AW-00042f-00 for nsis@ietf.org; Tue, 02 Mar 2004 00:10:13 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2A9-0003s7-00 for nsis@ietf.org; Tue, 02 Mar 2004 00:09:49 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMLZSS>; Tue, 2 Mar 2004 05:08:57 -0000 Message-ID: From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Dave Oran's comments Date: Tue, 2 Mar 2004 05:09:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dave, all, Many thanks for these comments. I've made some (brief) replies on the specific NTLP issues below. Mostly I think these are clarifications, but in some cases there will need to be some more detailed work. (I think John will capture these bigger points somehow and we'll work out how to address them.) There is a general question: a number of these questions really ask for more design rationale to be recorded about the protocol. Where is the right place to put this? > NTLP Comments: > > - Definition of data flow excludes multicast. OK, but should > this be part of the definition? We could rephrase the text in section 2 to say that flows can be uni/multi/any-cast but that our scope for this document is restricted to unicast flows. And maybe put the scoping stuff further up in section. > - Definition of data flow enforces "unique path". Does this mean path > splitting is not ok even for flows where delivery order > doesn't matter? My current assumption is: yes, unfortunately. It would (probably) be possible for GIMPS to find most or all of the branches of a split flow path. However, it would be hard to work out what to tell the NSLPs about this situation - would it be necessary (for example) to estimate traffic percentages on each branch and so on. So, a first guess (in the interests of simplicity) is to just to say 'NSIS won't give the full picture if path splitting happens'. This could change if - we start to think path splitting is a more common problem - we think it's easy to tell the NSLPs something sensible (it's easier for NATFW than QoS). More feedback on either of these (from anyone) would be helpful. > - How does path coupling work if proxies are not on the path? It doesn't; or rather, we only consider proxies that are on the path. This can be fixed in section 2. > - What led to the decision to use a hop count rather than a > VIA-style path recording? That's something that hasn't been analysed in detail, IIRC. There may be a question about where between the layers loop prevention and path recording should be done in general. (So, I suspect we should make an action to analyse this for the next version.) > - The D-mode gimps message needs to truly mimic the actual > data flow in order to guarantee congruent routing. > This is particularly important where > routers may be doing their own flow routing based on things like DSCP. This is quite right. We could emphasise this more in the text (i.e. explain the motivation). Probably the right place would be 5.3 (it already comments on setting the DSCP to address this problem), with some more information on how things can go wrong if higher layer routing is done. > - If NATs have to be GIMPS-aware then aren't we punting a big > part of the application scope for NSIS? There are different levels of 'awareness'. The minimal level of awareness that is needed is for a NAT to know that a particular packet has header field information inside it and that something should be done to add some further information about existing bindings or say there are no applicable bindings. This is a lot less than the full set of features that a NATFW application might/should have. Precisely where the division of responsibility between GIMPS and the NATFW should be is still open. > - NIT on tunneling - it's the outer header of the tunneled > packets which doesn't have RAO, not the tunneled packet itself. True. > - section 8.3 says raw IP ruled out by section 8.2 but I see > nothing in 8.2 which argues for ruling out raw ip encapsulation. Just > confused here... Basically they are NAT traversal issues. - Raw IP (according to several reports) won't go through some (many?) existing low end NATs. This would seem to be a show stopper. - If you are in an address sharing scenario, there needs to be some other identifier to demultiplex messages into the internal network. Using UDP provides the port number, but with a raw encapsulation GIMPS would have to provide its own. We could spell this out in more detail (and then people could say if this is enough to draw a conclusion). > - small point on aggregation - its the exit interface which defines the > aggregation level, not the router. A router could have interfaces at > different aggregation levels. True. And there could be different levels for different applications (and it could get more complex still). We can extend 8.4 to address this. Thanks again, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 2 03:18:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25489 for ; Tue, 2 Mar 2004 03:18:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay55u-0005ib-VI for nsis-archive@odin.ietf.org; Tue, 02 Mar 2004 03:17:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i228HcQQ021965 for nsis-archive@odin.ietf.org; Tue, 2 Mar 2004 03:17:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay55m-0005fe-Pb; Tue, 02 Mar 2004 03:17:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay54n-0005au-Ha for nsis@optimus.ietf.org; Tue, 02 Mar 2004 03:16:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25359 for ; Tue, 2 Mar 2004 03:16:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay54l-0004VR-00 for nsis@ietf.org; Tue, 02 Mar 2004 03:16:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay53t-0004M7-00 for nsis@ietf.org; Tue, 02 Mar 2004 03:15:33 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1Ay531-00042y-00 for nsis@ietf.org; Tue, 02 Mar 2004 03:14:39 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Tue, 2 Mar 2004 09:14:11 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 09:14:08 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF5FA@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] Path Splitting Date: Tue, 2 Mar 2004 09:14:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Robert, as people may expect I support your position on trading=20 perfection for simplicity. By working path coupled, NSIS=20 should be able to deal with some load-balancing=20 implementations. I don't think it is a good idea to=20 design NSIS to be able to deal with all types of route=20 change mechanisms. I'd consider a simple protocol working=20 with 95% of all networks as a success. Advanced solutions=20 may follow. Regards, R=FCdiger [Dave] |> - Definition of data flow enforces "unique path". Does this=20 |> mean path splitting is not ok even for flows where=20 |> delivery order doesn't matter? [Robert] |My current assumption is: yes, unfortunately. |It would (probably) be possible for GIMPS to find most or all of=20 |the branches of a split flow path. However, it would be hard to |work out what to tell the NSLPs about this situation - would it |be necessary (for example) to estimate traffic percentages on=20 |each branch and so on. | |So, a first guess (in the interests of simplicity) is to just |to say 'NSIS won't give the full picture if path splitting |happens'. | |This could change if |- we start to think path splitting is a more common problem |- we think it's easy to tell the NSLPs something sensible |(it's easier for NATFW than QoS). | |More feedback on either of these (from anyone) would be helpful. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 2 03:55:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27486 for ; Tue, 2 Mar 2004 03:55:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5gD-0000zd-GO for nsis-archive@odin.ietf.org; Tue, 02 Mar 2004 03:55:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i228t9Mp003793 for nsis-archive@odin.ietf.org; Tue, 2 Mar 2004 03:55:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5g8-0000yE-Fn; Tue, 02 Mar 2004 03:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5fa-0000v5-5P for nsis@optimus.ietf.org; Tue, 02 Mar 2004 03:54:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27418 for ; Tue, 2 Mar 2004 03:54:28 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5fX-0001zM-00 for nsis@ietf.org; Tue, 02 Mar 2004 03:54:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay5eg-0001re-00 for nsis@ietf.org; Tue, 02 Mar 2004 03:53:35 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5ds-0001iC-00 for nsis@ietf.org; Tue, 02 Mar 2004 03:52:44 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i228qgT04536; Tue, 2 Mar 2004 10:52:42 +0200 (EET) X-Scanned: Tue, 2 Mar 2004 10:52:13 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i228qDG0026254; Tue, 2 Mar 2004 10:52:13 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00DLL6yM; Tue, 02 Mar 2004 10:52:11 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i228qA700372; Tue, 2 Mar 2004 10:52:10 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Mar 2004 10:52:07 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Path Splitting Date: Tue, 2 Mar 2004 10:52:07 +0200 Message-ID: Thread-Topic: [NSIS] Path Splitting thread-index: AcQALxoVFj0HJUHvTTSvCF4M7grSbwABHh3w To: , Cc: X-OriginalArrivalTime: 02 Mar 2004 08:52:07.0904 (UTC) FILETIME=[A4A84600:01C40033] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi R=FCdiger, > as people may expect I support your position on trading=20 > perfection for simplicity. By working path coupled, NSIS=20 > should be able to deal with some load-balancing=20 > implementations. I don't think it is a good idea to=20 > design NSIS to be able to deal with all types of route=20 > change mechanisms. I'd consider a simple protocol working=20 > with 95% of all networks as a success. Advanced solutions=20 > may follow. I agree & would could note in the document the cases that may not work. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 2 06:10:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03013 for ; Tue, 2 Mar 2004 06:10:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay7ml-0006Pw-Jr for nsis-archive@odin.ietf.org; Tue, 02 Mar 2004 06:10:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22BA30A024652 for nsis-archive@odin.ietf.org; Tue, 2 Mar 2004 06:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay7mk-0006P0-1b; Tue, 02 Mar 2004 06:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay7m8-0006Gv-RQ for nsis@optimus.ietf.org; Tue, 02 Mar 2004 06:09:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02985 for ; Tue, 2 Mar 2004 06:09:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay7m5-0003bf-00 for nsis@ietf.org; Tue, 02 Mar 2004 06:09:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay7l6-0003V4-00 for nsis@ietf.org; Tue, 02 Mar 2004 06:08:21 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay7kC-0003JY-00 for nsis@ietf.org; Tue, 02 Mar 2004 06:07:24 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2004 03:19:04 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i22B6pY6023005; Tue, 2 Mar 2004 03:06:52 -0800 (PST) Received: from oranpb.wireless.ietf59.or.kr (sjc-vpn3-148.cisco.com [10.21.64.148]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMU99390; Tue, 2 Mar 2004 03:06:49 -0800 (PST) Date: Tue, 02 Mar 2004 06:06:49 -0500 From: David Oran To: john.loughney@nokia.com, Ruediger.Geib@t-systems.com, robert.hancock@roke.co.uk cc: nsis@ietf.org Subject: RE: [NSIS] Path Splitting Message-ID: <2147483647.1078207609@[172.16.43.227]> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I'm ok with this tradeoff too. The original comment was more to have the=20 documents not encode requirements (or the lack thereof) in the guise of=20 definitions. --On Tuesday, March 2, 2004 10:52 AM +0200 john.loughney@nokia.com wrote: > Hi R=FCdiger, > >> as people may expect I support your position on trading >> perfection for simplicity. By working path coupled, NSIS >> should be able to deal with some load-balancing >> implementations. I don't think it is a good idea to >> design NSIS to be able to deal with all types of route >> change mechanisms. I'd consider a simple protocol working >> with 95% of all networks as a success. Advanced solutions >> may follow. > > I agree & would could note in the document the cases that may > not work. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 2 23:44:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29379 for ; Tue, 2 Mar 2004 23:44:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOEp-0008Rp-Kx for nsis-archive@odin.ietf.org; Tue, 02 Mar 2004 23:44:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i234i7AX032457 for nsis-archive@odin.ietf.org; Tue, 2 Mar 2004 23:44:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOEj-0008QX-39; Tue, 02 Mar 2004 23:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOE4-0008JW-17 for nsis@optimus.ietf.org; Tue, 02 Mar 2004 23:43:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29177 for ; Tue, 2 Mar 2004 23:43:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOE1-0005ap-00 for nsis@ietf.org; Tue, 02 Mar 2004 23:43:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyOCx-0005Ns-00 for nsis@ietf.org; Tue, 02 Mar 2004 23:42:12 -0500 Received: from bay8-f89.bay8.hotmail.com ([64.4.27.89] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AyOBz-00055p-00 for nsis@ietf.org; Tue, 02 Mar 2004 23:41:11 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Mar 2004 20:40:41 -0800 Received: from 218.37.230.136 by by8fd.bay8.hotmail.msn.com with HTTP; Wed, 03 Mar 2004 04:40:41 GMT X-Originating-IP: [218.37.230.136] X-Originating-Email: [hannestschofenig@hotmail.com] X-Sender: hannestschofenig@hotmail.com From: "Hannes Tschofenig" To: nsis@ietf.org Date: Wed, 03 Mar 2004 05:40:41 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 03 Mar 2004 04:40:41.0577 (UTC) FILETIME=[AEEB3590:01C400D9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [NSIS] review slides Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 placed the slides on the nsis document review of alex and james at: http://www.tschofenig.priv.at/nsis/IETF59/nsis-zinin-ietf59.ppt http://www.tschofenig.priv.at/nsis/IETF59/NSISMobility-James-Kempf.ppt additionally, i have copied the following draft " IP Mobility and the CDMA Radio Access Network: Applicability Statement for Soft Handoff " mentioned by james during the nsis meeting to: http://www.tschofenig.priv.at/nsis/IETF59/draft-kempf-cdma-appl-02.txt ciao hannes _________________________________________________________________ E-Mails sind Ihnen nicht schnell genug? http://www.msn.de/messenger MSN Messenger - Kommunikation in Echtzeit _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Mar 4 17:38:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17678 for ; Thu, 4 Mar 2004 17:38:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1Tg-0004lx-IR for nsis-archive@odin.ietf.org; Thu, 04 Mar 2004 17:38:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24Mc4f8018326 for nsis-archive@odin.ietf.org; Thu, 4 Mar 2004 17:38:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1Tc-0004jl-N3; Thu, 04 Mar 2004 17:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoIC-0002gp-0X for nsis@optimus.ietf.org; Thu, 04 Mar 2004 03:33:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28931 for ; Thu, 4 Mar 2004 03:33:17 -0500 (EST) From: karagian@ewi.utwente.nl Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoI9-0000e9-00 for nsis@ietf.org; Thu, 04 Mar 2004 03:33:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoHE-0000Uk-00 for nsis@ietf.org; Thu, 04 Mar 2004 03:32:21 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AyoGT-0000Kd-00 for nsis@ietf.org; Thu, 04 Mar 2004 03:31:34 -0500 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with ESMTP id i248VSCi014178; Thu, 4 Mar 2004 09:31:28 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id i248VRWW026697; Thu, 4 Mar 2004 09:31:27 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id i248VRY16828; Thu, 4 Mar 2004 09:31:27 +0100 (MET) Date: Thu, 4 Mar 2004 09:31:27 +0100 (MET) Message-Id: <200403040831.i248VRY16828@janus.cs.utwente.nl> X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@ewi.utwente.nl using -f To: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.txt Received: from 218.37.216.101 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 04 Mar 2004 08:31:26 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.10 (On: webmail.cs.utwente.nl) In-Reply-To: Bounce-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamd / ClamAV version 0.67, clamav-milter version 0.66n X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=MSGID_FROM_MTA_HEADER, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello John I have read the NSIS threats document and in my opinion is usefull for NSIS and good enough to pass the WG last call. Best Regards, Georgios On 2/24/2004, "john.loughney@nokia.com" wrote: >Hello all, > >During IESG evaluation of the Framework, it has come-up that security >isn't given enough consideration in the FW document. That is mostly >because the information is split off into the NSIS Threats document. > >In order progress the FW document in the IESG, we should also submit >the NSIS Threats document. Therefore, I'd like to kick-off a >2 week WG Last Call on the current threats document. The WGLC >will run until March 9th. > >The updated document can be found here: > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-04.txt > >thanks, >John > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 8 20:27:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15432 for ; Mon, 8 Mar 2004 20:27:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0W1Y-0006lY-Vl for nsis-archive@odin.ietf.org; Mon, 08 Mar 2004 20:27:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i291RCHL026005 for nsis-archive@odin.ietf.org; Mon, 8 Mar 2004 20:27:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0W1N-0006kW-P6; Mon, 08 Mar 2004 20:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0W0U-0006PL-NY for nsis@optimus.ietf.org; Mon, 08 Mar 2004 20:26:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15401 for ; Mon, 8 Mar 2004 20:26:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0W0S-0005k4-00 for nsis@ietf.org; Mon, 08 Mar 2004 20:26:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0VzU-0005bN-00 for nsis@ietf.org; Mon, 08 Mar 2004 20:25:05 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1B0VzG-0005SV-00 for nsis@ietf.org; Mon, 08 Mar 2004 20:24:51 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN16HP>; Tue, 9 Mar 2004 01:24:11 -0000 Message-ID: From: "Hancock, Robert" To: "'Hannes Tschofenig'" Cc: "Nsis (E-mail)" Date: Tue, 9 Mar 2004 01:24:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1252" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] last call comments on threats doc Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, here are some last call comments on the threats document. (i actually wrote them last week but then fell out of the net. it must be 9th march somewhere, though.) General Despite the introductory text, I found it hard to work out sometimes whether the document was talking about the overall signalling problem or the different bits of NSIS (and whether it was supposed to be doing one or the other or both). Apart from anything else, someone less familiar than me with NSIS terminology could get easily lost at various stages. A readability check by someone with *no* NSIS background might be a good thing. There is an important question of whether this document should attempt to allocate responsibility for various threats between the NSIS layers. My view is that - apart from high-level statements about whether something is (for example) application related or transport related - it should not. Many details of the layer split (including details which are very relevant from the security perspective) are left open in the framework, so the layer split will only be well enough defined to analyse as the protocol designs firm up. This document will serve as an input to that design process, but it will still need interpretation during that process. Editorial comments have been sent separately. > Abstract > > This threats document provides a detailed analysis of the security > threats relevant for the NSIS protocol. It calls attention to and Protocol or protocol suite? (and so on, also during the introduction, mentions of NTLP/NSLP and so on) > 1. Introduction [snip] > - NSIS Analysis Activities (e.g., RSVP Security Properties) > - Security Threats for NSIS > - NSIS Requirements > - NSIS Framework > - NSIS Protocol Proposals Would be nice to add references here. > This interaction is also a > subject of discussion within the NSIS Framework. The particular interaction you mention is not discussed in much detail, in fact. > > We use the NSIS terms defined in [Brun03]. You also use some framework terms (e.g. in the preceding paragraph!) > 2. Relevant Communications Models I think something should be added to this section to say that these different models are not hard and fast statements about exactly how communications in the Internet actually work, but convenient names for different 'typical' scenarios. For example: - is an on-path proxy a first peer or not? (according to the pictures it is if it initiates NSIS signalling, but it could actually be anywhere in the network) - if I have a personal area network, is the device in it which provides the gateway to the infrastructure a first peer or not? (according to the pictures it is not if some other device in the PAN initiates the signalling, but the security issues are probably more first-peer like) Also, this section talks a lot about 'trust relationships' without saying what they are. (It may be that this is a standard formal term, but I've just seen in another project a case where several security experts realised they were all using it in a set of unsubtly different ways.) It could mean - some commonality of purpose (having the same goal) - the ability to authenticate (because shared keys or validated certificates are available) - an existing security association - something else Another point is that the level of detail in various subsections is not consistent. Some include scenarios, some describe security concepts, some provide threats information, and so on. This is slightly disorienting for the reader. > 2.1 First-Peer Communications > Usually there is > a fairly strong (pre-established) trust relationship between the > peers. Enterprise network administrators usually have some degree of > freedom to select the appropriate security protection and to enforce > it. This sound perilously like talking about a 'trusted domain' (which is apparently a red-flag word in some quarters ...) > 2.4 Inter-Domain Communications > > The number of neighboring domains > is usually rather limited (compared with first-peer communications), > which substantially reduces the key management considerations for > securing inter-domain NSIS signaling. OTOH the increased volume of traffic probably means that automatic rekeying is a must in such environments. > 2.5 End-to-End Communications > > The following example illustrates a possible application of end-to- > end protection for objects carried within the NSIS signaling > protocol. Alice, the data sender, wants Bob, the data receiver, to > pay for a QoS reservation (reverse charging). Bob wants to be ^^ "that Alice has made"? > Typical threats in such a scenario range from modification of QoS > objects or price information (i.e., making Bob pay too much), to > fraud (i.e., forcing Bob always to pay for the reservations), to > identity spoofing (i.e., an impostor claiming to be Alice). Also, modifying the reservation so it can be used by someone else. > Regarding end-to-end security, one additional issue needs to be > addressed: delegation. Whenever signaling is addressed end to end > and an arbitrary node along the path acts as a proxy on behalf of > the other endpoint, a delegation mechanism is required to provide > secure interaction. This might lead to additional complexity. But why mention these (generic) threats here and not any of the other communications models (they apply widely, e.g. middle-middle, end-middle). > 3. Generic Threats > 3.1 Man-in-the-Middle Attacks > > Note also that a > denial of service attack on a signaling protocol exists when no > separation between SA establishment and signaling protection takes > place. I don't know whether this is just saying that SA establishment needs DoS protection (true), or a more subtle point about DoS protection being harder without the separation because the first stage is more expensive (as you say later). In either case, the text doesn't seem to be needed here. > The discovery procedure, in particular, is vulnerable to a > number of such attacks. You haven't defined what a discovery procedure is. And even if the protocols do have discovery procedures (which is not fixed, at least at this threats stage of the lifecycle), the vulnerability is more fundamental in the functionality. > 3.4 Insecure Parameter Exchange and Negotiation I think this threat is very important to consider. But is there any way to handle it except in the context of a security protocol (unless you rely on static policies)? You can always mount a downgrading attack on the authentication process itself, at which point you are finished. > 4. NSIS-Specific Threat Scenarios > 4.2 Combining Signaling and SA Establishment > > When a signaling message arrives at an NSIS-aware network element, ... > protection are described in [AN97] and in [ALN00]. I found this paragraph quite hard to follow (even though I think I know what you are trying to say). Part of the problem is that you are talking about the *threat* of flooding but the section title is referring to imperfections in a particular class of solution. There is room for a more structured analysis of the flooding problem (especially in the light of concerns about RAO handling expressed on Monday). Flooding needs a layered defence and protection happens at several levels. > 4.4 Identity Spoofing > > The ability for an adversary to inject data traffic that matches a > certain flow identifier established by a legitimate user often > requires the ability also to receive the data traffic. This is, > however, true only if the flow identifier consists of values that > contain addresses used for routing. If we imagine using attributes > of a flow identifier that do not require such a property, then > identity spoofing and injecting traffic are much easier. An > adversary can use a nearly arbitrary endpoint identifier to achieve > the desired result. Obviously, though, the endpoint identifiers are > not irrelevant, because the messages have to travel the same path > through the network. This implication of this is that flow identifiers should be hard to spoof usefully (e.g. they should contain destination addresses). This would be an important point to capture and propagate through into the signalling protocol security analysis. > 4.5 Unprotected Authorization Information > > Returning an unprotected authorization token to > the end host might allow an adversary (for example an eavesdropper) > to steal resources. An adversary might also use the token to monitor > communication patterns. Finally, an untrustworthy end host might > also modify the token content. Doesn't this just mean that the token passing protocol is broken? (i.e. shouldn't we be able to avoid this happening by using strong protocols? or are these protocols particularly hard to secure?) > 4.8 Denial of Service Attacks > > - Path Finding > > This threat scenario includes potential DoS attacks that exist when > the reservation setup is split into two phases, i.e., path and > reservation (as used, for example, in receiver-based reservation > setup). In this case, assuming that the node transmitting the path > message is not charged for the path message itself, it may be able > to generate a large number of reservation requests (possibly in a Is this really specifically about reservation requests? It sounds generically like a threat caused by any message which can be sent without direct cost. (In particular, referring to reservation requests rather than messsages in general makes it sound like this is a threat to the resource pool, whereas I think it is a threat to the control plane.) > 4.11 Attacks against the Transport Mechanism > I think we can now refer to the split layer architecture as a decision within the group (after all, it's in the charter) and is as defined in the framework. A reference to RFC2385 might be helpful background. --end _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 9 02:28:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12067 for ; Tue, 9 Mar 2004 02:28:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ben-00048S-Id for nsis-archive@odin.ietf.org; Tue, 09 Mar 2004 02:28:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i297S5FY015855 for nsis-archive@odin.ietf.org; Tue, 9 Mar 2004 02:28:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0bek-00046m-4d; Tue, 09 Mar 2004 02:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0be5-0003vr-SG for nsis@optimus.ietf.org; Tue, 09 Mar 2004 02:27:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11872 for ; Tue, 9 Mar 2004 02:27:19 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0be2-0001Hc-00 for nsis@ietf.org; Tue, 09 Mar 2004 02:27:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0bd9-00017i-00 for nsis@ietf.org; Tue, 09 Mar 2004 02:26:24 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1B0bcC-0000xe-00 for nsis@ietf.org; Tue, 09 Mar 2004 02:25:24 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i297PNJb022295; Tue, 9 Mar 2004 08:25:23 +0100 Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.txt To: john.loughney@nokia.com Cc: X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 9 Mar 2004 08:25:21 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/09/2004 08:25:22 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John, all, I have read the draft and found it useful. I would like to see it move forward. Best regards, Sven john.loughney@nokia.com@ietf.org on 24/02/2004 13:35:28 Sent by: nsis-admin@ietf.org To: cc: Subject: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.txt Hello all, During IESG evaluation of the Framework, it has come-up that security isn't given enough consideration in the FW document. That is mostly because the information is split off into the NSIS Threats document. In order progress the FW document in the IESG, we should also submit the NSIS Threats document. Therefore, I'd like to kick-off a 2 week WG Last Call on the current threats document. The WGLC will run until March 9th. The updated document can be found here: http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-04.txt thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Mar 10 04:26:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28635 for ; Wed, 10 Mar 2004 04:26:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zyY-0007vS-80 for nsis-archive@odin.ietf.org; Wed, 10 Mar 2004 04:26:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A9Q6ON030466 for nsis-archive@odin.ietf.org; Wed, 10 Mar 2004 04:26:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zyU-0007uw-E5; Wed, 10 Mar 2004 04:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zyD-0007u8-Fh for nsis@optimus.ietf.org; Wed, 10 Mar 2004 04:25:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28629 for ; Wed, 10 Mar 2004 04:25:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0zyA-0001cf-00 for nsis@ietf.org; Wed, 10 Mar 2004 04:25:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0zwy-0001S9-00 for nsis@ietf.org; Wed, 10 Mar 2004 04:24:29 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B0zwI-0001JA-00 for nsis@ietf.org; Wed, 10 Mar 2004 04:23:46 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2A9NhYG014943 for ; Wed, 10 Mar 2004 10:23:47 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Mar 2004 10:23:42 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Mar 2004 10:24:50 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.txt Date: Wed, 10 Mar 2004 10:23:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 10 Mar 2004 09:23:42.0837 (UTC) FILETIME=[616E1A50:01C40681] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John, Yes, I think the draft is in a good shape and is a useful document, Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > john.loughney@nokia.com > Sent: Tuesday, February 24, 2004 1:35 PM > To: nsis@ietf.org > Subject: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.txt > > > Hello all, > > During IESG evaluation of the Framework, it has come-up that security > isn't given enough consideration in the FW document. That is mostly > because the information is split off into the NSIS Threats document. > > In order progress the FW document in the IESG, we should also submit > the NSIS Threats document. Therefore, I'd like to kick-off a > 2 week WG Last Call on the current threats document. The WGLC > will run until March 9th. > > The updated document can be found here: > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-04.txt > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Mar 11 04:32:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21613 for ; Thu, 11 Mar 2004 04:32:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MXt-0002eO-AO for nsis-archive@odin.ietf.org; Thu, 11 Mar 2004 04:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B9W4rE010159 for nsis-archive@odin.ietf.org; Thu, 11 Mar 2004 04:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MXp-0002dd-Db; Thu, 11 Mar 2004 04:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MXc-0002cP-07 for nsis@optimus.ietf.org; Thu, 11 Mar 2004 04:31:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21599 for ; Thu, 11 Mar 2004 04:31:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1MXY-0001sh-00 for nsis@ietf.org; Thu, 11 Mar 2004 04:31:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1MWg-0001jX-00 for nsis@ietf.org; Thu, 11 Mar 2004 04:30:50 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1B1MVg-0001YK-00 for nsis@ietf.org; Thu, 11 Mar 2004 04:29:48 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i2B9Tkd16114; Thu, 11 Mar 2004 10:29:47 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i2B9Tjx20101; Thu, 11 Mar 2004 10:29:45 +0100 (MET) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id KAA09072; Thu, 11 Mar 2004 10:29:23 +0100 (MET) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 10:29:44 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A022C7C54@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: john.loughney@nokia.com, nsis@ietf.org Subject: AW: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.txt Date: Thu, 11 Mar 2004 10:29:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi John,=20 I find the threats doc very useful however have some comments on it. = May be I already missed the deadline (too many things to work on after = returning from Seoul)... I'd be able to write down my comments until = end of this week. Cornelia > -----Urspr=FCngliche Nachricht----- > Von: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] Im=20 > Auftrag von karagian@ewi.utwente.nl > Gesendet: Donnerstag, 4. M=E4rz 2004 09:31 > An: john.loughney@nokia.com; nsis@ietf.org > Betreff: Re: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.txt >=20 >=20 >=20 > Hello John >=20 > I have read the NSIS threats document and in my opinion is usefull = for > NSIS > and good enough to pass the WG last call. >=20 > Best Regards, > Georgios >=20 > On 2/24/2004, "john.loughney@nokia.com"=20 > wrote: >=20 > >Hello all, > > > >During IESG evaluation of the Framework, it has come-up that = security > >isn't given enough consideration in the FW document. That is mostly > >because the information is split off into the NSIS Threats document. > > > >In order progress the FW document in the IESG, we should also submit > >the NSIS Threats document. Therefore, I'd like to kick-off a > >2 week WG Last Call on the current threats document. The WGLC > >will run until March 9th. > > > >The updated document can be found here: > > > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-04.txt > > > >thanks, > >John > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Mar 11 10:29:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06448 for ; Thu, 11 Mar 2004 10:29:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1S7R-0003Qs-Af for nsis-archive@odin.ietf.org; Thu, 11 Mar 2004 10:29:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BFT94O013183 for nsis-archive@odin.ietf.org; Thu, 11 Mar 2004 10:29:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1S7K-0003Q2-LH; Thu, 11 Mar 2004 10:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1S6v-0003O2-SW for nsis@optimus.ietf.org; Thu, 11 Mar 2004 10:28:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06408 for ; Thu, 11 Mar 2004 10:28:34 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1S6t-0000P8-00 for nsis@ietf.org; Thu, 11 Mar 2004 10:28:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1S5x-0000Hs-00 for nsis@ietf.org; Thu, 11 Mar 2004 10:27:37 -0500 Received: from [211.162.118.214] (helo=lspc) by ietf-mx with smtp (Exim 4.12) id 1B1S55-0000Ab-00 for nsis@ietf.org; Thu, 11 Mar 2004 10:26:43 -0500 Date: Thu, 11 Mar 2004 23:39:55 +0800 To: nsis@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------pnalxaxidhcywfbfufew" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME,YOU_WON autolearn=no version=2.60 Subject: [NSIS] Weah, hello! :-) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , ----------pnalxaxidhcywfbfufew Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.GEN-1 in file AttachedFile.zip The file is deleted. --------------------------------------------------------- ----------pnalxaxidhcywfbfufew Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit You have won!!! ..btw, "67375" is a password for archive ----------pnalxaxidhcywfbfufew Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) AttachedFile.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------pnalxaxidhcywfbfufew-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Mar 11 15:56:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24797 for ; Thu, 11 Mar 2004 15:56:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XDs-00085i-1k for nsis-archive@odin.ietf.org; Thu, 11 Mar 2004 15:56:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BKu7el031085 for nsis-archive@odin.ietf.org; Thu, 11 Mar 2004 15:56:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XDm-000820-1s; Thu, 11 Mar 2004 15:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1WYu-0001Vb-P6 for nsis@optimus.ietf.org; Thu, 11 Mar 2004 15:13:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19679 for ; Thu, 11 Mar 2004 15:13:47 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1WYt-0002G5-00 for nsis@ietf.org; Thu, 11 Mar 2004 15:13:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1WY0-00028j-00 for nsis@ietf.org; Thu, 11 Mar 2004 15:12:52 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B1WXF-00021s-00 for nsis@ietf.org; Thu, 11 Mar 2004 15:12:05 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2BKC3p15849; Thu, 11 Mar 2004 22:12:04 +0200 (EET) X-Scanned: Thu, 11 Mar 2004 22:11:26 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2BKBQNZ022368; Thu, 11 Mar 2004 22:11:26 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00GHRR5C; Thu, 11 Mar 2004 22:09:37 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2BK9a126153; Thu, 11 Mar 2004 22:09:36 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Mar 2004 22:09:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.txt Date: Thu, 11 Mar 2004 22:09:36 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.txt Thread-Index: AcQHTAwgF/6IC3tNS6uU9vbnNOmY0wAWLKAw To: , X-OriginalArrivalTime: 11 Mar 2004 20:09:35.0901 (UTC) FILETIME=[C67824D0:01C407A4] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Please do send comments ASAP. thanks, John > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of ext > Kappler Cornelia > Sent: 11 March, 2004 11:30 > To: Loughney John (Nokia-NRC/Helsinki); nsis@ietf.org > Subject: AW: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.txt >=20 >=20 > Hi John,=20 >=20 > I find the threats doc very useful however have some comments=20 > on it. May be I already missed the deadline (too many things=20 > to work on after returning from Seoul)... I'd be able to=20 > write down my comments until end of this week. >=20 > Cornelia >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] Im=20 > > Auftrag von karagian@ewi.utwente.nl > > Gesendet: Donnerstag, 4. M=E4rz 2004 09:31 > > An: john.loughney@nokia.com; nsis@ietf.org > > Betreff: Re: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.txt > >=20 > >=20 > >=20 > > Hello John > >=20 > > I have read the NSIS threats document and in my opinion is=20 > usefull for > > NSIS > > and good enough to pass the WG last call. > >=20 > > Best Regards, > > Georgios > >=20 > > On 2/24/2004, "john.loughney@nokia.com"=20 > > wrote: > >=20 > > >Hello all, > > > > > >During IESG evaluation of the Framework, it has come-up=20 > that security > > >isn't given enough consideration in the FW document. That=20 > is mostly > > >because the information is split off into the NSIS Threats=20 > document. > > > > > >In order progress the FW document in the IESG, we should=20 > also submit > > >the NSIS Threats document. Therefore, I'd like to kick-off a > > >2 week WG Last Call on the current threats document. The WGLC > > >will run until March 9th. > > > > > >The updated document can be found here: > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-04.txt > > > > > >thanks, > > >John > > > > > >_______________________________________________ > > >nsis mailing list > > >nsis@ietf.org > > >https://www1.ietf.org/mailman/listinfo/nsis > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Mar 12 05:43:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12866 for ; Fri, 12 Mar 2004 05:43:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1k8C-00021G-70 for nsis-archive@odin.ietf.org; Fri, 12 Mar 2004 05:43:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CAh8jB007761 for nsis-archive@odin.ietf.org; Fri, 12 Mar 2004 05:43:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1k85-00020c-4K; Fri, 12 Mar 2004 05:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1k7i-00020I-4Q for nsis@optimus.ietf.org; Fri, 12 Mar 2004 05:42:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12836 for ; Fri, 12 Mar 2004 05:42:34 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1k7e-0003bL-00 for nsis@ietf.org; Fri, 12 Mar 2004 05:42:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1k72-0003TH-00 for nsis@ietf.org; Fri, 12 Mar 2004 05:41:58 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1B1k6B-0003JU-00 for nsis@ietf.org; Fri, 12 Mar 2004 05:41:04 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2CAex406511; Fri, 12 Mar 2004 12:40:59 +0200 (EET) X-Scanned: Fri, 12 Mar 2004 12:40:49 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2CAenu7007113; Fri, 12 Mar 2004 12:40:49 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00iidybo; Fri, 12 Mar 2004 12:40:47 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2CAelH01033; Fri, 12 Mar 2004 12:40:47 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 12 Mar 2004 12:40:47 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 12 Mar 2004 12:40:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Mar 2004 12:40:45 +0200 Message-ID: Thread-Topic: draft-ietf-nsis-signalling-analysis-03.txt Thread-Index: AcQH8MlFlYikFB2hScCug5bvI30gYgALXBQg To: Cc: , X-OriginalArrivalTime: 12 Mar 2004 10:40:47.0446 (UTC) FILETIME=[7ABCEF60:01C4081E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] FW: draft-ietf-nsis-signalling-analysis-03.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, Here is text that I recieved from Kireeti Kompella & Adrian Farrel. Please review and comment if anyone disagrees. thanks! John =3D=3D forwarded text =3D=3D Here is the text that Adrian had in replacement of sections 2.2.10 through 2.2.12, with minor mods from me. As a whole, this document seems primarily to be more of a "Compendium of Extensions to RSVP and Other Quality of Service Signaling Protocols" rather than an Analysis of the same. It is useful as such, but one might consider a change of title. Kireeti. ------- =3D=3D BEGIN ORIGINAL TEXT =3D=3D 2.2.10. MPLS Traffic Engineering RSVP-TE [RFC3209] specifies the extension to RSVP for establishing explicitly routed LSPs in MPLS networks using RSVP as a signaling protocol. RSVP-TE is intended for use by label switching routers (as well as hosts) to establish and maintain LSP-tunnels and to reserve network resources for such LSP-tunnels. RFC3209 defines a new Hello message (for rapid node failure detection), new C-Types (LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION (here a session is implicitly defined as the set of packets that are assigned the same MPLS label value at the originating node of an LSP-tunnel), SENDER_TEMPLATE, and FILTER_SPEC objects, and the following 5 new objects: 1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path messages, encapsulating a concatenation of hops which constitutes the explicitly routed path. Using this object, the paths taken by label-switched RSVP-MPLS flows can be pre-determined, independent of conventional IP routing. 2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can create a Path message with a LABEL_REQUEST object. A node that sends a LABEL_REQUEST object MUST be ready to accept and correctly process a LABEL object in the corresponding Resv messages. 3) LABEL object. Each node that receives a Resv message containing a LABEL object uses that label for outgoing traffic associated with this LSP tunnel. 4) SESSION_ATTRIBUTE object, which can be added to Path messages to aid in session identification and diagnostics. Additional control information, such as setup and hold priorities, resource affinities and local-protection, are also included in this object. 5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object may appear in both Path and Resv messages. It is used to collect detailed path information and is useful for loop detection and for diagnostics. Section 5 of RFC3270 further specifies the extensions to RSVP to establish LSPs supporting DiffServ in MPLS networks, introducing a new DIFFSERV Object (applicable in the Path messages) and using pre- configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping". 2.2.11. GMPLS RSVP: Provision Optical Networks [RFC3473] is developed on top of RSVP-TE. It enables network operations to provision data-path within optical networks. It defines a Notify message (for general event notification), which may contain notifications being sent, with respect to each listed session, both upstream and downstream. Notify messages can be used together with Notify Request object for expedited notification of failures and other events to nodes responsible for restoring failed LSPs. A Notify message is sent without the router alert option. Besides, a number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for general uses of MPLS: (for label management:) - a Generalized Label Request Object; - Bandwidth Encoding carried in SENDER_TSPEC and FLOWSPEC objects, Generalized Label Object; - a Waveband Switching Object; - a Suggested Label Object; - a Label Set Object; (to support bidirectional LSP setup:) - an Upstream_Label object; (to support uni- and bi-directional Explicit Label Control:) - a Label ERO subobject; - a Label RRO subobject, which is included in RROs as described in [RFC3209]; (To Control Channel Separation:) - IF_ID RSVP_HOP objects (IPv4 & v6); - IF_ID ERROR_SPEC objects (IPv4 & v6); (to support rapid failure notification:) - a Acceptable Label Set object to support Notification on Label Error; - a Notify Request object, which may be inserted in Path or Resv messages to indicate where a notification of LSP failure is to be sent; (for fault handling:) - a Restart_Cap Object; (for administrative purposes:) - an Admin Status Object, which is used to notify each node along the path of the status of the LSP. Since RSVP-TE does not provide a way to indicate an unnumbered link in its Explicit Route and Record Route Objects, [KoRe03] specifies extensions to RSVP-TE to support (point-to-point) unnumbered links, namely, - an Unnumbered Interface ID Subobject, which is a new subobject of the Explicit Route Object (ERO) used to specify unnumbered links; - an LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to form or use an identifier for the Forwarding Adjacency; - a new subobject of the Record Route Object, used to record that the LSP path traversed an unnumbered link. 2.2.12. GMPLS Interworking with ITU and OIF [LiPe02] proposes additional extensions to GMPLS RSVP-TE to support the capabilities of an Automatically Switched Optical Network (ASON, an architecture developed by ITU-T SG15). To support Soft Permanent Connection (SPC), it uses GENERALIZED_UNI object defined by [OIF- UNI-1.0] but introduces a new subtype: SPC_LABEL. In addition, a Call identifier (CALL_ID) object is used in logical call/connection separation, which are used together with a new Call capability (CALL_OPS) object for complete call/connection separation. Besides new error codes, 3 new C-types are defined for the SESSION object: UNI_IPv6 SESSION, ENNI_IPv4 SESSION and ENNI_IPv6 SESSION. Optical Internetworking Forum (OIF) UNI 1.0 signaling ([OIF-UNI-1.0]) supports [RFC2205, RFC2961, RFC3209, Berg03] in a limited way. 10 types of RSVP(-TE) messages are supported, but used in a slightly different way. For example, only FF style is supported; States are always deleted explicitly; a state timer expiration will not deleted the state, rather triggers a tear down message; any RSVP message must be dropped silently when fails security validation. Besides new error codes, a few new (sub)objects are introduced, including [Berg03]: - a new C-type for ACCEPTABLE_LABEL_SET; - a new C-type for ADMIN_STATUS; - a new C-type for LABEL_SET; - a new C-type for RECOVER_LABEL; - a new C-type for RESTART_CAP; - a new C-type for UPSTEAM_LABEL; - a UNI_IPv4_SESSION object, combined with LSP_TUNNEL_IPv4_SENDER_TEMPLATE object to uniquely identify a connection at a local UNI; - a GENERALIZED_LABEL_REQUEST object; - a GENERALIZED_UNI_ATTRIBUTES object, which contains one or more new SOURCE_TNA, DESTINATION_TNA, DIVERSITY, EGRESS_LABEL, SERVICE_LEVEL subobjects. EGRESS_LABEL can be used to specify either uni- or bi-directional connections; - a SONET/SDH_SENDER_TSPEC object. =3D=3D END ORIGINAL TEXT =3D=3D =3D=3D BEGIN NEW TEXT =3D=3D 2.2.10. MPLS Traffic Engineering RSVP-TE [RFC3209] specifies the core extensions to RSVP for establishing constraint-based explicitly routed LSPs in MPLS networks using RSVP as a signaling protocol. RSVP-TE is intended for use by label switching routers (as well as hosts) to establish and maintain LSP-tunnels and to reserve network resources for such LSP-tunnels. RFC3209 defines a new Hello message (for rapid node failure detection). RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects. Here a session is the association of LSPs that support the LSP-tunnel. The traffic on an LSP can be classified as the set of packets that are assigned the same MPLS label value at the originating node of an LSP-tunnel. The following 5 new objects are also defined. 1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path messages, encapsulating a concatenation of hops which constitutes the explicitly routed path. Using this object, the paths taken by label-switched RSVP-MPLS flows can be pre-determined, independent of conventional IP routing. 2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can create a Path message with a LABEL_REQUEST object. A node that sends a LABEL_REQUEST object MUST be ready to accept and correctly process a LABEL object in the corresponding Resv messages. 3) LABEL object. Each node that receives a Resv message containing a LABEL object uses that label for outgoing traffic associated with this LSP tunnel. 4) SESSION_ATTRIBUTE object, which can be added to Path messages to aid in session identification and diagnostics. Additional control information, such as setup and holding priorities, resource affinities and local-protection, are also included in this object. 5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object may appear in both Path and Resv messages. It is used to collect detailed path information and is useful for loop detection and for diagnostics. Section 5 of [RFC3270] further specifies the extensions to RSVP to establish LSPs supporting DiffServ in MPLS networks, introducing a new DIFFSERV Object (applicable in the Path messages) and using pre- configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping". RSVP-TE provides a way to indicate an unnumbered link in its Explicit Route and Record Route Objects through [RFC3477]. This specifies the following extensions. - An Unnumbered Interface ID Subobject, which is a subobject of the Explicit Route Object (ERO) used to specify unnumbered links; - An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to form or use an identifier for an unnumbered Forwarding Adjacency; - A new subobject of the Record Route Object, used to record that the LSP path traversed an unnumbered link. 2.2.11. GMPLS RSVP: Provisioning for Multiple Switching Types GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE. It enables the provisioning of data-paths within networks supporting a variety of switching types including packet and cell switching networks, layer two networks, TDM networks and photonic networks. It defines the new Notify message (for general event notification), which may contain notifications being sent, with respect to each listed LSP, both upstream and downstream. Notify messages can be used for expedited notification of failures and other events to nodes responsible for restoring failed LSPs. A Notify message is sent without the router alert option. A number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for general uses of MPLS: - a Generalized Label Request Object; - a Generalized Label Object; - a Suggested Label Object; - a Label Set Object; (to restrict label choice) - an Upstream_Label object; (to support bi-directional LSPs) - a Label ERO subobject; - IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in out of band signaling or in bundled links); - IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify interfaces in out of band signaling or in bundled links); - an Acceptable Label Set object (to support negotiation of label values in particular for bidirecitonal LSPs) - a Notify Request object (may be inserted in a Path or Resv message to indicate to where a notification of LSP failure is to be sent) - a Restart_Cap Object (used on Hello messages to identify recovery capabilities) - an Admin Status Object (to notify each node along the path of the status of the LSP, and to control that state). 2.2.12. GMPLS Operation at UNI and E-NNI Reference Points The ITU-T defines nework reference points that separate administrative or operational parts of the network. The reference points are designated as: - User to Network Interfaces (UNIs) if they lie between the user or user network and the core network. - External Network to Network Interfaces (E-NNIs) if they lie between peer networks, network domains, or subnetworks. GMPLS is applicable to the UNI and E-NNI without further modification, and no new messages, objects or C-Types are required. See [OVERLAY]. 2.2.13. MPLS and GMPLS Future Extensions At the time of writing MPLS and GMPLS are being extended by the MPLS and CCAMP Working Groups to support additional sophisticated functions. This will inevitably lead to the introduction of new C-Types for existing objects, and to the requirement for new objects (CNums). It is possible that new messages will also be introduced. Some of the key features and functions being introduced include: - Protection and restoration. Features will be developed to provide - end-to-end protection - segment protection - various protection schemes (1+1, 1:1, 1:n) - support of extra traffic on backup LSPs - Diverse path establishment for protection and load sharing - Point-to-mulitpoint path establishment - Inter-area and inter-AS path establishment - with explicit path control - with bandwidth reservation - with path diversity - Support for the requirements of ASON signaling as defined by the ITU-T, including call and connection separation - Crankback during LSP setup. Additional references [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource Reservation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y., "GMPLS UNI: RSVP Support for the Overlay Model", draft-ietf-ccamp-gmpls-overlay- 03.txt, February 2004, work in progress. =3D=3D END NEW TEXT =3D=3D _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Mar 12 08:26:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19690 for ; Fri, 12 Mar 2004 08:26:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mfz-0005KQ-AF for nsis-archive@odin.ietf.org; Fri, 12 Mar 2004 08:26:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CDQBQn020481 for nsis-archive@odin.ietf.org; Fri, 12 Mar 2004 08:26:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mfr-0005Je-1l; Fri, 12 Mar 2004 08:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mfG-0005Is-VZ for nsis@optimus.ietf.org; Fri, 12 Mar 2004 08:25:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19646 for ; Fri, 12 Mar 2004 08:25:24 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1mfF-0002NY-00 for nsis@ietf.org; Fri, 12 Mar 2004 08:25:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1meH-0002Gh-00 for nsis@ietf.org; Fri, 12 Mar 2004 08:24:28 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B1mdF-00023a-00 for nsis@ietf.org; Fri, 12 Mar 2004 08:23:21 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2CDNKp05845 for ; Fri, 12 Mar 2004 15:23:20 +0200 (EET) X-Scanned: Fri, 12 Mar 2004 15:22:51 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2CDMpun028073 for ; Fri, 12 Mar 2004 15:22:51 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00XkKGwM; Fri, 12 Mar 2004 15:22:50 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2CDMo120614 for ; Fri, 12 Mar 2004 15:22:50 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 12 Mar 2004 15:22:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Mar 2004 15:22:48 +0200 Message-ID: Thread-Topic: nsis meeting minutes Thread-Index: AcQIDCejNcF4hkJ4Sg+R8dpVu7OQFAAKNPBg To: X-OriginalArrivalTime: 12 Mar 2004 13:22:49.0503 (UTC) FILETIME=[1D891AF0:01C40835] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] NSIS Meeting Minutes Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, Here are the meeting minutes from IETF 59, thanks to Hannes for putting this together. The minutes are also available from: http://www.tschofenig.priv.at/nsis/IETF59/ NSIS Working Group Meeting (IETF#59)NSIS Working Group Meeting IETF#59 (Seoul) CHAIR:=20 John Loughney =20 Minute Taker/Jabber Scribe:=20 Hannes Tschofenig=20 Abbreviations: Henning (Henning Schulzrinne)=20 John (John Loughney) =20 Allison (Allison Mankin)=20 Dave (Dave Oran)=20 Georgios (Georgios Karagiannis)=20 Robert (Robert Hancock)=20 Hannes (Hannes Tschofenig)=20 Cedric (Cedric Aoun) =20 Jukka (Jukka Manner)=20 Alex (Alex Zinin)=20 Martin (Martin Stiemerling)=20 Fred (Fred Baker)=20 Steve (Steve Bellovin)=20 Lou (Lou Berger)=20 James (James Kempf)=20 =20 MONDAY, March 1, 2004 (1930-2200) Many of the presentation slides can be found at: http://www-nrc.nokia.com/sua/nsis/ietf59/ Backups are stored at:=20 http://www.tschofenig.priv.at/nsis/IETF59/ Links to additional slides are available as links in the meeting = minutes.=20 Unofficial IETF NSIS Weblog: http://www.tschofenig.priv.at/cgi-bin/nsis.cgi WG Update - 5 min=20 John: http://www-nrc.nokia.com/sua/nsis/ietf59/NSIS-agenda.ppt=20 Agenda bashing & Charter Overview John: Minor modifications to the agenda as indicated below.=20 http://www-nrc.nokia.com/sua/nsis/ietf59/NSIS-agenda.ppt NSIS Documents updates - 30 min=20 Document editors http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.txt=20 http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-02.txt=20 http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-01.txt=20 Allison comments on the NSIS analysis document; interesting document of = the way=20 rsvp is used, on requirements and some problems. some of them are more = related=20 to the framework;=20 there is a problem with the tcp discussion: it talks about the fact that = ldp is=20 used successfully with tcp. but there is a relative low number of = deployments=20 and implementations; not a careful analysis; fairly shallow number of = comments=20 on fragmentation. it does not elaborate all issues in detail. it is not = good=20 enough to get published.=20 John: Could you write a few lines of text? Jukka: The TCP part was pretty much the part of Henning & Ping.=20 Giving more proof into the document requires the authors.=20 NTLP: Robert Hancock=20 Roberts slides can be found at:=20 http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-01-v1.ppt Robert describes several issues of the draft:=20 - Issue: Intermediary/Topology/Layer Binding=20 - Issue: Messaging Details - Issue: Route Change Handling - Issue: Security - Issue: Open Issues Nary Trah provides comments on the congestion control mechanism = described in the=20 GIMPS draft.=20 QoS NSLP: Andrew McDonald=20 Andrews slides can be found at: = http://nsis.srmr.co.uk/~adm/qos-nslp-ietf59.ppt Significant restructuring was done. =20 NATFW NSLP: Martin Stiemerling=20 Martins slides can be found at:=20 http://diana.zam.fh-koeln.de/~mstiemerling/nsis_natfw_ietf59.ppt Issue: Stacking; Timer handling;=20 Henning: We should avoid that each comes up with a different packet = format.=20 NSIS Early Review - 60 min =20 Review Team (Allison Mankin, Alex Zinin and Dave Oran) Comments by Dave can be found at:=20 http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg03809.ht= ml Comments by Alex can be found at:=20 http://www.tschofenig.priv.at/nsis/IETF59/nsis-zinin-ietf59.ppt Allison provides an introduction to work done by the review team. =20 Alex: The document assumes that QoS routing is used.=20 Re-route identification: local interface state monitoring is not enough re-routing: delaying route installation on re-routing may be a bad idea = because=20 of loops certain drop/delay sensitive apps may require reestablished back-up = state Henning: the last issue is discussed in the nsis mobility documents. it = might be=20 too tight with mobility and also too complex. it may be possible without = mobility (if we can discover the alternative route) Alex: State refresh must be done; qos nslp document does not discuss it=20 Alex: NTLP: Why per-flow routing state at the ntlp level? are you suggesting flow-based routing?=20 Henning: That was not the intention. Alex: NAT traversal:=20 I had the impression that the document says that no integrity protection = is=20 required. Furthermore, it says that the routing/forwarding state is = changed.=20 Hannes, Henning and Martin try to clarify=20 Martin: Terminology needs to be fixed. Georgios: Do you refer to aggregation to perform the state reduction? Alex: State aggregation and refresh reduction are two different issues Dave starts with his review on the NTLP work.=20 =20 Dave: This is awful complicated. Do we want to get beyond the energy = barrier to=20 deploy this?=20 Henning: There is opportunity to simplify it. We have done a prototype = running=20 which is simple enough for students to implement it.=20 Dave: It would be really good to have some simulations here. There is = c-mode and=20 d-mode and the protocol is very complicated.=20 Henning: Simulations - work in progress.=20 Dave: We have this layering. Are these applications orthogonal to each = other?=20 Example:=20 In order to install QoS state the NAT binding has to be installed. = First, you=20 install the NAT state, then you install the QoS state but what happens = if one=20 state is deleted? John: We have discussed this and said that the protocols should be = developed=20 first before considering their interaction.=20 Robert: This is a very good point. Is NAT a very special case here?=20 Dave: We only have two applications? Building NAT into the transport = might be a=20 possibility.=20 Dave: Why have you developed a hop-count? To build an explicit path = discovery=20 mechanism instead of a hop count is much better.=20 Dave: The D-mode has to accurately mimic the data flow. This was simple = with=20 destination based forwarding. Today people consider the source IP = address, DSCP,=20 etc.=20 Robert: We have thought about this detail a lot (including load = balancing). If=20 there are better ways todo it then we should change it.=20 Fred: People asked us to route data traffic different than data.=20 Henning: We exhaustively enumerated the possibilities. Allison: Why does this issue not applied to D-mode?=20 Dave: The C-mode uses the D-mode to perform the discovery.=20 Dave switched to the QoS signaling work.=20 Dave: People often want to envelope authorization. Radius is no tightly=20 synchronized to provide this functionality ; COPS is.=20 Dave: Can you teardown state somewhere along the path? (inside out = instead of=20 outside in).=20 Henning: I have thought about this problem of sending the end points a = teardown=20 message.=20 Dave: Let us take this offline.=20 Dave: I don't understand how the adspec functionality works. Perhaps the = equivalent mechanism is the query mechanism. Take this as a 'the = reviewer does=20 not understand' issue.=20 Dave: People have discussed a two-phase commit in context of RSVP.=20 Dave: I didn't see a number of things: resource sharing across flows = (e.g.,=20 voice over ip signaling);=20 marking multiple flows doing fade sharing. the document currently says = outside=20 of scope. Priority preemption is important.=20 Fred: This is important.=20 Dave: Priority preemption: It might be useful to have a layer (or a data = structure) which is common to all signaling applications. Replace some = set of=20 state with a high set of state. Do not let every application define its = own=20 mechanism.=20 Henning: I don't want to nuke your connection, in case of a NAT binding. = Dave: You could allow an application to control whether you would like = to do=20 fate sharing. In case of NAT you would not perform this.=20 Dave: Multiple QoS model scared me a lot. The notion you could stack = these=20 things. There is a lot of evidence that it is difficult to map one qos = model to=20 another (docsis, ethernet). Dave: Comments on the NAT/Firewall will be addressed later. I haven't = finished=20 the document yet.=20 Fred: You mentioned that there are some reasons that RSVP did not get = deployed.=20 There are political reasons and technical reasons. The concept of a = router alert=20 option is a concern for administrators. There is concern about their = routing=20 behavior.=20 Fred: The original approach in RSVP was that all routers look in all = packets.=20 If there is a way to target the messages to these machines then we would = be a=20 lot happier.=20 John: A discovery message with a peer-to-peer addressing mechanism is = there. =20 Fred: The perceived complexity caused them not todo that. I am looking = at this :=20 3 protocols, stacking, etc.=20 That could give me the same perception.=20 And then there is the fundamental question of scaling. It took us a long = time to=20 get RSVP to scale. You have to think very early about scaling.=20 Steve: A short comment on the load. We spend a lot of time on channel = security=20 (off-the-shelf product).=20 A harder problem is authorization which is often not considered. There = are=20 authorization problems in many different layers: - Am I allowed to make a QoS reservation?=20 - Am I allowed to look at this packet? Providing this across provider = boundary=20 with different policies is very hard. =20 Allison: The ability to to have Intserv at the access network and = Diffserv at=20 the edge to the core is very important.=20 It needs to be considered how this functionality should be included into = NSIS=20 from the beginning.=20 Hannes: The layer split model allows nodes in the middle of the network = to=20 signal different QoS models . We seem to have a requirement that = different QoS=20 models are required for different behavior in the core than in the = access=20 networks.=20 John: The authors have considered this issue with scoping. IPv6 comes in = mind.=20 If there are some simple ways todo it then please state it.=20 Robert: At the protocol level we try our best to support different QoS = model.=20 The nsis charter does not consider qos models.=20 Allison: There is certainly a difference between per-flow QoS and = per-aggregate.=20 Alex: Abstracting the QoS model might be a good idea but we should not = forget=20 scalability.=20 Henning: We have done RSVP implementations and the source of the problem = are=20 per-flow reservations. The state storage once you do refresh reduction = was not=20 something which couldn't be handled. I would be much more concerned = about the=20 authorization aspects where AAA interaction is required.=20 Alex: There are multiple points in a design where assumptions make = problems=20 later.=20 Georgios: There is a need to support different QoS models. It is good to = define=20 some common functionality and to provide information which is QoS model = specific=20 in a separate document.=20 There are IETF QoS models, some defined by other organizations and even = private=20 ones.=20 Allison: I am not sure whether vendors are happy to implement private = QoS=20 models. I am not sure whether private QoS models are difficult but they = could=20 be. John: If other standardization models (such as 3GPP) come to request QoS = models=20 then this is fine with me.=20 Dave: If I think about mapping one QoS model to another then I am = scared. If you=20 think about re-routing events then you need to define a least-common=20 denominator.=20 Fred: Do a traceroute and you will note that you go through several = different=20 providers. If you have QoS model based on a provider-basis then you will = fail.=20 Henning: People are often taking about different submodels of IntServ. = We need a=20 precise notion of what a QoS model is. Before we get too worried we = should look=20 at some QoS models. There seem to be that there is a single parameter = bandwidth=20 model (not even per-flow / per-aggregate distinction) (queuing = parameters and=20 bandwidth parameters). This might be a way to avoid some of the = problems.=20 Allison: It seems to be useful to define some minimal set of parameters. = Can we=20 agree that we would like to get close to things which we know already? Henning: Most people in the real world do not know how to set the = parameters for=20 the IntServ model.=20 Lou: The biggest RSVP deployment is in the MPLS area. How does NSIS fit = in=20 there?=20 Allison: Is there a reason to replace RSVP with NSIS in the MPLS area? Lou: Why do you want to deploy NSIS at all? The problem of RSVP wasn't = really=20 NAT and Firewall.=20 Lou: What was the reason RSVP to fail?=20 John: What we try to do with NSIS is path-coupled signaling. We keep the = properties of RSVP.=20 Allison: In NSIS we do per-flow signaling without multicast stuff. Some=20 additional things have been introduced (such as mobility handling).=20 Lixia Zhang: This argument is flawed. RSVP flawed due to the = insufficient need=20 for micro-flow reservations.=20 Allison: People from the telecommunications claim that they need = per-flow=20 reservations.=20 Henning: Now we actually have real numbers using voice over ip = applications.=20 John: We should get back to the review.=20 Lou: I am pretty happy to hear that MPLS signaling is off the table from = NSIS.=20 You need a QoS analysis before starting. You cannot start solving the = problem=20 only because IP telephone needs Xiaobao Chen: We setup 3GPP networks with UMTS and use QoS reservations. = The=20 general feeling is to use per-flow signaling in the access network and = diffserv=20 model in the core. =20 Lou: Why don't you use RSVP?=20 Xiaobao Chen: This is a long story. We have a per-flow session, = resources,=20 charging and billing integration. We want to reuse IETF protocols.=20 Lou:=20 a) Does the NSIS documents cover the functionality the current RSVP? b) What is NSIS fundamentally giving us to make it more successful for a = real-world deployment? In 3GPP2 we have already standardized RSVP for QoS signaling. Robert: Everyone addresses the router alert option. There are tradeoffs = that=20 have to be made. Routing signaling messages by interception is needed. = Have we=20 got the tradeoff right? Is there something better?=20 Dave: Router alert message gives a way to cause routers to perform more=20 processing. Can we filter bad guys easily than processing a packet? Fred: We didn't want to 5-tuple analysis and hence we came up with the = router=20 alert option.=20 In RSVP only two messages (path, path-tear) have this router alert = option set.=20 Fred: One might think of a discovery phase in NSIS.=20 Dave: That is what NSIS already does.=20 Dave: If you have proxies in the protocol then you need to specify how = they=20 work. Fred: .. and they need to be trusted.=20 Dave: How does a proxy start signaling if it is not along the path?=20 Robert: There are no proxies which are not along the path. An edge = router could=20 be a proxy and it is not the end system.=20 Dave: You should specify this since people have raised other comments in = the=20 past where these proxies are not along the path.=20 Allison: A comment to preemption as a service in an intermediate layer: = Perhaps=20 the lower layer (NTLP) should be labeled differently. Maybe it should be = given=20 more functionality.=20 Dave: We should have more design options.=20 Allison: Regarding the security at both layers: Would the transport and = the=20 application layer both have to be secured? The lower layer would provide generic security services such as general = security=20 functionality. The application layer would provide enhanced security=20 functionality.=20 Robert: If you provide channel security then there is question whether = you could=20 use it for security.=20 Is there a channel binding between lower and upper layer?=20 Do we have to go back and think about cross-layer security issues? We don't know how the process looks like here For example: If a node is authorized to make QoS reservation can it = flood me=20 with NAT/FW signaling messages?=20 Allison: They are different players. It is ok to have different security = services at different layers.=20 Steve: Two different security layers might be that you have two = different things=20 to protect. Example: Email we protect end-to-end on the other hand you = use smtp=20 with between different nodes to protect the smtp traffic.=20 TUESDAY, March 2, 2004 (1300-1400 Afternoon Sessions I)=20 =20 Security Discussion - 20 minutes=20 Hannes Tschofenig=20 Drafts: http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-04.txt http://www.ietf.org/internet-drafts/draft-martin-nsis-nslp-security-01.tx= t Hannes went through his presentation. His slides can be found at:=20 http://www.tschofenig.priv.at/nsis/IETF59/Security_Threats_for_NSIS_ietf59.pp= t=20 http://www.tschofenig.priv.at/nsis/IETF59/NAT-Firewall-Security_ietf59.ppt=20 =20 QoS Model Discussion - 20 minutes=20 =20 Slides for the presentation can be found at:=20 http://www.tschofenig.priv.at/nsis/IETF59/qos-model-intro-ietf59a.ppt=20 Cornelia Kappler started her presentation on goals.=20 Attila Bader continued with the presentation (same slide set):=20 Draft: = http://www.ietf.org/internet-drafts/draft-bader-rmd-qos-model-00.txt=20 Jerry Ash continued with the presentation (same slide set):=20 Draft:=20 http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-= concept-01.txt=20 John: I have a proposal. The QoS NSLP needs to define a basic QSPEC.=20 Additionally there are issues which the NTLP might need to take a look = at such=20 as priority handling and fade sharing. An applicability statement for = certain=20 signaling models might be useful. It should tell how a person which uses = the=20 NSIS protocols how to use a certain QoS model. Does this sound sensible? = A=20 common QSPEC format? Maximize communality! Dave: There are a set of QoS properties that can describe the properties = of a=20 QoS reservation.=20 We should pick one and use it. We have parameters which are looser one = than=20 others.=20 Henning: I fully agree. There is one description of the traffic itself. = The=20 other one is performance: delay is no problem or bounded delays That does not necessarily imply one or the other. RSVP made this = decision.=20 John: We need to work this out.=20 Dave: I agree with Henning.=20 John: The presenters should work out the next steps. Would this be a way = forward?=20 Cornelia: If we only work out the QSPecs then what about the = applicability=20 statements? NSIS Mobility Discussion - 20 minutes=20 =20 John: I try to figure out what topics we really need to concentrate on = in this=20 area. James: I have read the drafts. What state are we talking about? = Everything looks=20 very high-level. =20 Some comments by James are available at:=20 http://www.tschofenig.priv.at/nsis/IETF59/NSISMobility-James-Kempf.ppt=20 First presentation on mobility in NSIS by Jukka Manner: Mobility and = Internet=20 Signaling Protocols=20 Draft: http://www.ietf.org/internet-drafts/draft-manyfolks-signaling-protocol-mo= bility-00.txt=20 Presentation:=20 http://www.cs.helsinki.fi/u/jmanner/nsis-mob-ietf59.pdf=20 Next presentation on mobility in NSIS by Takako Sanda: Pre CRN discovery = from=20 proxy on candidate new path Draft:=20 http://www.ietf.org/internet-drafts/draft-sanda-nsis-mobility-qos-proxy-0= 1.txt=20 Presentation: http://www.tschofenig.priv.at/nsis/IETF59/IETF59_NSIS_mob_PreCRND.ppt=20 Next presentation on mobility in NSIS by Kim Hui Ling: Mobility related = issues=20 for the QoS NSLP=20 Presentation: =20 http://www.tschofenig.priv.at/nsis/IETF59/IETF_59_NSIS_Mobility_related_issue= s_for_the_QoS_NSLP.ppt=20 Draft: =20 http://www.tschofenig.priv.at/cache/draft-cheng-mobility-issues-01.txt=20 James: Have you ever looked at the CDMA2000? Soft-handover is never seen at the IP layer. We (Phil Roberts & James) = wrote a=20 draft about soft handovers a few years ago covering this issue.=20 The draft can be found at:=20 http://www.tschofenig.priv.at/nsis/IETF59/draft-kempf-cdma-appl-02.txt=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Mar 12 14:40:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14018 for ; Fri, 12 Mar 2004 14:40:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sVs-0002v9-43 for nsis-archive@odin.ietf.org; Fri, 12 Mar 2004 14:40:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CJe7qT011210 for nsis-archive@odin.ietf.org; Fri, 12 Mar 2004 14:40:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sVn-0002ty-GF; Fri, 12 Mar 2004 14:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sV1-0002si-FY for nsis@optimus.ietf.org; Fri, 12 Mar 2004 14:39:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13796 for ; Fri, 12 Mar 2004 14:39:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1sUy-0002IQ-00 for nsis@ietf.org; Fri, 12 Mar 2004 14:39:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1sT7-0001q3-00 for nsis@ietf.org; Fri, 12 Mar 2004 14:37:20 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1B1sRP-0001N4-00 for nsis@ietf.org; Fri, 12 Mar 2004 14:35:32 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i2CJZVv13064 for ; Fri, 12 Mar 2004 20:35:31 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i2CJZUV09411 for ; Fri, 12 Mar 2004 20:35:30 +0100 (MET) Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id UAA08229 for ; Fri, 12 Mar 2004 20:35:36 +0100 (MET) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Mar 2004 20:35:30 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A022C7C66@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: Tschofenig Hannes , nsis@ietf.org Date: Fri, 12 Mar 2004 20:35:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40869.2B2EEB60" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [NSIS] comments on NSIS Security Threats ID Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , 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_01C40869.2B2EEB60 Content-Type: text/plain Hi Hannes, my comments mostly relate to the structure of Sec 4 (along similar lines as Robert was suggesting), and to problems I have understanding identity spoofing of flow identifieres. See below. Cornelia ---------------------- *4. NSIS Specific Threat Scenarios This Section describes "threat scenarios in terms of attacks on and security deficiencies in the NSIS signaling protocol". I find it hard sometimes in subsequent subsections to pick out what the attack is, and (particularly) what the security deficiencies allowing the attack are. May be you could add sentences clearly stating this, rather than mentioning it in passing. In addition to Theats and Security Deficiencies may be you should add (in a structured fashion) what possible remedies are. In most subsections this is mentioned but not everywhere. Also I think the fact that you also discuss remedies should be mentioned in the intro to Sec 4. Subsection headings sometimes contain possible security deficiencies ("Combined Signaling and SA Establishment") and sometimes threats ("Eavesdropping and Traffic Analysis"). Could you streamline this (i.e. either one or the other) * 4.2 "Combined Signaling and SA Establishment" It took me some time to understand the problem. To my current understanding it is the assumption that one doesnt want to introduce extra roundtrip times to establish SAs. I.e. somehow the SA needs to be established as soon as an NSIS message arrives from an unknown NE, without further interaction wiht this NE. But is this assumption valid? Do we expect the number of possible peer-NEs is so large that the costs for an additional roundtrip to establish the SA is too big? I dont understand the sentence "For this to work, specific classes of cryptographic mechanisms supporting this type of behaviour are needed". What is "this to work"? Do you mean (previous sentence) "allow refresh messages to create new state along a new path" to work _in a secure way_? Furthermore what specifically is "this type of behaviour"? In the text above no "behaviour" was described. * 4.3 "Eavesdropping and Traffic Analysis" I cant find what the security deficiencies are that allow this kind of threat. It only says integrity protection does NOT help against it. But why would anybody think it does??? Adding a kind of secured checksum (that is what integrity protection does, doesnt it?) of course doesnt help. The 3rd paragraph introduces exploitation of the spoofing of flow identifiers. The remaining paragraphs of 4.3 all seem to discuss this problem in more detail. It took me some time to realize this, may be you could add an explaining sentence. 2nd last paragraph of 4.3: "The ability...to inject data atraffic..requires the ability to also receive the data traffic. This is, however, true only if the flow identifier consists of a value that contains addresses used for routing." Doesnt seem to make sense. I can picture various scenarios where I am able to receive data traffic not really destined to me, independent of the structure of the flow identifier...!? The same paragraph continues: "If ... using...a flow identifier that do not require such a property (CK: i.e. addresses used for routing I assume?? Or ability to receive data traffic? But this I think is independent of the structure of the flow identifier) then ...injecting traffic are much easier." Doesnt make sense to me either (I may just have problems catching on...) The final paragraph contains the DiffServ example but I dont see how it relates to the rest. Where is the spoofed flow identifier in the example? May be you could be more explicit... * 4.6 Missing Non-Repudiation last paragraph "because it public-key" -> "because public-key" * 4.8 Denial of Service Attacks In the "path-finding" scenario, what is a possible remedy? ------_=_NextPart_001_01C40869.2B2EEB60 Content-Type: text/html Content-Transfer-Encoding: quoted-printable comments on NSIS Security Threats ID

Hi Hannes,

my comments mostly relate to the = structure of Sec 4 (along similar lines as Robert was suggesting), and = to problems I have understanding identity spoofing of flow = identifieres. See below.

Cornelia
----------------------

*4. NSIS Specific Threat = Scenarios

This Section describes "threat = scenarios in terms of attacks on and security deficiencies in the NSIS = signaling protocol". I find it hard sometimes in subsequent = subsections to pick out what the attack is, and (particularly) what the = security deficiencies allowing the attack are. May be you could add = sentences clearly stating this, rather than mentioning it in passing. =

In addition to Theats and Security = Deficiencies may be you should add (in a structured fashion) what = possible remedies are. In most subsections this is mentioned but not = everywhere. Also I think the fact that you also discuss remedies should = be mentioned in the intro to Sec 4.

Subsection headings sometimes contain = possible security deficiencies ("Combined Signaling and SA = Establishment") and sometimes threats ("Eavesdropping and = Traffic Analysis"). Could you streamline this (i.e. either one or = the other)

* 4.2 "Combined Signaling and SA = Establishment"

It took me some time to understand the = problem. To my current understanding it is the assumption that one = doesnt want to introduce extra roundtrip times to establish SAs. I.e. = somehow the SA needs to be established as soon as an NSIS message = arrives from an unknown NE, without further interaction wiht this NE. = But is this assumption valid? Do we expect the number of possible = peer-NEs is so large that the costs for an additional roundtrip to = establish the SA is too big?

I dont understand the sentence = "For this to work, specific classes of cryptographic mechanisms = supporting this type of behaviour are needed". What is "this = to work"? Do you mean (previous sentence) "allow refresh = messages to create new state along a new path" to work _in a = secure way_? Furthermore  what specifically is "this type of = behaviour"? In the text above no "behaviour" was = described.

* 4.3 "Eavesdropping and Traffic = Analysis"

I cant find what the security = deficiencies are that allow this kind of threat. It only says integrity = protection does NOT help against it. But why would anybody think it = does??? Adding a kind of secured checksum (that is what integrity = protection does, doesnt it?) of course doesnt help.

The 3rd paragraph introduces = exploitation of the spoofing of flow identifiers. The remaining = paragraphs of 4.3 all seem to discuss this problem in more detail. It = took me some time to realize this, may be you could add an explaining = sentence.

2nd last paragraph of 4.3: "The = ability...to inject data atraffic..requires the ability to also receive = the data traffic. This is, however, true only if the flow identifier = consists of a value that contains addresses used for routing." = Doesnt seem to make sense. I can picture various scenarios where I am = able to receive data traffic not really destined to me, independent of = the structure of the flow identifier...!?

The same paragraph continues: "If = ... using...a flow identifier that do not require such a property (CK: = i.e. addresses used for routing I assume?? Or ability to receive data = traffic? But this I think is independent of the structure of the flow = identifier) then ...injecting traffic are much easier." Doesnt = make sense to me either (I may just have problems catching = on...)

The final paragraph contains the = DiffServ example but I dont see how it relates to the rest. Where is = the spoofed flow identifier in the example? May be you could be more = explicit...

* 4.6 Missing Non-Repudiation
last paragraph "because it = public-key" -> "because public-key"

* 4.8 Denial of Service Attacks
In the "path-finding" = scenario, what is a possible remedy?

------_=_NextPart_001_01C40869.2B2EEB60-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Mar 13 11:19:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20084 for ; Sat, 13 Mar 2004 11:19:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BrH-0005GF-Ht for nsis-archive@odin.ietf.org; Sat, 13 Mar 2004 11:19:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DGJVRW020208 for nsis-archive@odin.ietf.org; Sat, 13 Mar 2004 11:19:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Bqn-0005Dk-0s; Sat, 13 Mar 2004 11:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Bq6-0005C2-1C for nsis@optimus.ietf.org; Sat, 13 Mar 2004 11:18:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20059 for ; Sat, 13 Mar 2004 11:18:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Bpw-0005wt-00 for nsis@ietf.org; Sat, 13 Mar 2004 11:18:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Bo8-0005tX-00 for nsis@ietf.org; Sat, 13 Mar 2004 11:16:17 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1B2BmJ-0005lf-00 for nsis@ietf.org; Sat, 13 Mar 2004 11:14:23 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN105F>; Sat, 13 Mar 2004 16:13:41 -0000 Message-ID: From: "Hancock, Robert" To: "'Kappler Cornelia'" , Tschofenig Hannes , nsis@ietf.org Subject: RE: [NSIS] comments on NSIS Security Threats ID Date: Sat, 13 Mar 2004 16:13:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, a comment on cornelia's comment (which in her email is targeted at 4.3 but which i think is actually about 4.4): > -----Original Message----- > From: Kappler Cornelia [mailto:cornelia.kappler@siemens.com] > Sent: Saturday, March 13, 2004 04:35 > To: Tschofenig Hannes; nsis@ietf.org > Subject: [NSIS] comments on NSIS Security Threats ID > > > Hi Hannes, > my comments mostly relate to the structure of Sec 4 (along > similar lines as Robert was suggesting), and to problems I > have understanding identity spoofing of flow identifieres. See below. [snip] > The 3rd paragraph introduces exploitation of the spoofing of > flow identifiers. The remaining paragraphs of 4.3 all seem to > discuss this problem in more detail. It took me some time to > realize this, may be you could add an explaining sentence. > 2nd last paragraph of 4.3: "The ability...to inject data > atraffic..requires the ability to also receive the data > traffic. This is, however, true only if the flow identifier > consists of a value that contains addresses used for > routing." the real point is more subtle. compared to the original "The ability for an adversary to inject data traffic that matches a certain flow identifier established by a legitimate user often requires the ability also to receive the data traffic. " one might emphasise "The ability for an adversary to inject data traffic that matches a certain flow identifier established by a legitimate user and to get some benefit from injecting that traffic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ often requires the ability also to receive the data traffic. or to have one's correspondent receive it. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^" > Doesnt seem to make sense. I can picture various > scenarios where I am able to receive data traffic not really > destined to me, independent of the structure of the flow > identifier...!? you can always try to receive on-link traffic for one of your neighbours, but that is not really the issue. the point is: a) a 'reservation' has an associated filter specification b) it also has an intended beneficiary c) all traffic that matches (a) will get the benefit, but d) that traffic may not be associated with the beneficiary (b) now, it is possible to write filter specifications which are similarly fine-grained, but which are very different in the possibilities they allow other users to generate traffic which is useful to them but not what the original user intended. hence the threat. apart from per-packet cryptographic authentication at each router, it's difficult to counter this type of threat. the approach being discussed here is to say that if you specify traffic some ways, the forwarding system itself (i.e. the most fundamental part of the network layer) will provide some protection. the arguments are similar to what was done for mip6 (see draft-nikander-mobileip-v6-ro-sec-02). some examples may be needed. *) reserve class X for traffic with SPI=fred ==> anyone can set SPI=fred in their own packets and get class X for them. *) reserve class X for traffic with proto/port=TCP/80 and source=myself ==> all my outgoing web traffic will get class X; but so will that from anyone else who spoofs my source address. (it's hard but not impossible for the spoofer to benefit from this.) if applied, ingress filtering on the traffic will make it harder. *) reserve class X for traffic with proto/port=TCP/80 and destination=myself ==> all my incoming traffic will get class X; if we assume destination address spoofing is impossible, we are just about done. [all these examples are slightly artificial, since the NTLP would have difficulty in routing messages about such vaguely specified flows, but they make the general point.] some master wordsmithing may be required. r. > The same paragraph continues: "If ... using...a flow > identifier that do not require such a property (CK: i.e. > addresses used for routing I assume?? Or ability to receive > data traffic? But this I think is independent of the > structure of the flow identifier) then ...injecting traffic > are much easier." Doesnt make sense to me either (I may just > have problems catching on...) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Mar 13 11:24:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20191 for ; Sat, 13 Mar 2004 11:24:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BvJ-0005WO-WF for nsis-archive@odin.ietf.org; Sat, 13 Mar 2004 11:23:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DGNfq0021208 for nsis-archive@odin.ietf.org; Sat, 13 Mar 2004 11:23:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Buf-0005Q6-BQ; Sat, 13 Mar 2004 11:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Bu7-0005PX-0S for nsis@optimus.ietf.org; Sat, 13 Mar 2004 11:22:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20153 for ; Sat, 13 Mar 2004 11:22:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Bu6-0006IH-00 for nsis@ietf.org; Sat, 13 Mar 2004 11:22:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2BtB-0006EW-00 for nsis@ietf.org; Sat, 13 Mar 2004 11:21:29 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1B2BsM-00066K-00 for nsis@ietf.org; Sat, 13 Mar 2004 11:20:38 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMPLC0>; Sat, 13 Mar 2004 16:20:03 -0000 Message-ID: From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] NSIS Meeting Minutes Date: Sat, 13 Mar 2004 16:20:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, one point i don't follow: > Fred: People asked us to route data traffic different than data. i remember Fred saying something on this topic, but I can't remember what it was (and i'm sure it wasn't this!) clues? r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Mar 14 14:59:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03405 for ; Sun, 14 Mar 2004 14:59:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bl4-00048q-6u for nsis-archive@odin.ietf.org; Sun, 14 Mar 2004 14:58:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2EJwo44015893 for nsis-archive@odin.ietf.org; Sun, 14 Mar 2004 14:58:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bka-0003mz-9x; Sun, 14 Mar 2004 14:58:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2YBp-0000cc-5n for nsis@optimus.ietf.org; Sun, 14 Mar 2004 11:10:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24909 for ; Sun, 14 Mar 2004 11:10:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2YBm-0007ie-00 for nsis@ietf.org; Sun, 14 Mar 2004 11:10:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2YAs-0007cu-00 for nsis@ietf.org; Sun, 14 Mar 2004 11:09:15 -0500 Received: from wompom.mcdonald.org.uk ([81.187.229.138]) by ietf-mx with esmtp (Exim 4.12) id 1B2YA5-0007Wk-00 for nsis@ietf.org; Sun, 14 Mar 2004 11:08:25 -0500 Received: from bifrons.mcdonald.org.uk ([81.187.229.139]) by wompom.mcdonald.org.uk with smtp (Exim 3.35 #1 (Debian)) id 1B2Y9x-00069o-00; Sun, 14 Mar 2004 16:08:17 +0000 Received: by bifrons.mcdonald.org.uk (sSMTP sendmail emulation); Sun, 14 Mar 2004 16:08:15 +0000 Date: Sun, 14 Mar 2004 16:08:15 +0000 From: Andrew McDonald To: "Hancock, Robert" Cc: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: Re: [NSIS] NSIS Meeting Minutes Message-ID: <20040314160815.GA22939@roke.co.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , On Sat, Mar 13, 2004 at 04:20:15PM -0000, Hancock, Robert wrote: > one point i don't follow: > > > Fred: People asked us to route data traffic different than data. > > i remember Fred saying something on this topic, but I can't > remember what it was (and i'm sure it wasn't this!) clues? I think it was something like: "People ask us to route voice traffic differently to other data". i.e. some people want voice to go over a different network (or, at least, via a different route) to other data, so the D-mode signalling needs to look enough like "voice" (rather than "other data") so it goes the right way. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Mar 14 14:59:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03464 for ; Sun, 14 Mar 2004 14:59:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2blD-0004HZ-AK for nsis-archive@odin.ietf.org; Sun, 14 Mar 2004 14:58:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2EJwxDQ016444 for nsis-archive@odin.ietf.org; Sun, 14 Mar 2004 14:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bkx-00044z-Uz; Sun, 14 Mar 2004 14:58:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Ydm-0002lg-Pr for nsis@optimus.ietf.org; Sun, 14 Mar 2004 11:39:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26388 for ; Sun, 14 Mar 2004 11:39:04 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Ydl-0003L8-00 for nsis@ietf.org; Sun, 14 Mar 2004 11:39:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Ycp-0003FU-00 for nsis@ietf.org; Sun, 14 Mar 2004 11:38:07 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B2YcU-0003Aa-00 for nsis@ietf.org; Sun, 14 Mar 2004 11:37:47 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2EGbiA29874; Sun, 14 Mar 2004 18:37:44 +0200 (EET) X-Scanned: Sun, 14 Mar 2004 18:37:37 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2EGbbsi005719; Sun, 14 Mar 2004 18:37:37 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00oPh8sZ; Sun, 14 Mar 2004 18:37:35 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2EGbZH22673; Sun, 14 Mar 2004 18:37:35 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 14 Mar 2004 18:37:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSIS Meeting Minutes Date: Sun, 14 Mar 2004 18:37:34 +0200 Message-ID: Thread-Topic: [NSIS] NSIS Meeting Minutes Thread-Index: AcQJ3q4oRVU9/EzxQBCf605KRiMAuwAA83OQ To: , Cc: X-OriginalArrivalTime: 14 Mar 2004 16:37:35.0029 (UTC) FILETIME=[A77A5E50:01C409E2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, > > > Fred: People asked us to route data traffic different than data.=20 > >=20 > > i remember Fred saying something on this topic, but I can't > > remember what it was (and i'm sure it wasn't this!) clues? >=20 > I think it was something like: "People ask us to route voice traffic > differently to other data". Yup, that's what I remember. John =20 > i.e. some people want voice to go over a different network (or, at > least, via a different route) to other data, so the D-mode signalling > needs to look enough like "voice" (rather than "other data")=20 > so it goes the right way. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 15 01:46:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28205 for ; Mon, 15 Mar 2004 01:46:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2lrS-00008f-NX for nsis-archive@odin.ietf.org; Mon, 15 Mar 2004 01:46:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F6k66D000516 for nsis-archive@odin.ietf.org; Mon, 15 Mar 2004 01:46:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2lrN-00007g-Mv; Mon, 15 Mar 2004 01:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2lqy-00007K-TC for nsis@optimus.ietf.org; Mon, 15 Mar 2004 01:45:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28193 for ; Mon, 15 Mar 2004 01:45:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2lqv-0002W8-00 for nsis@ietf.org; Mon, 15 Mar 2004 01:45:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2lpy-0002PU-00 for nsis@ietf.org; Mon, 15 Mar 2004 01:44:35 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1B2lp2-0002Dr-00 for nsis@ietf.org; Mon, 15 Mar 2004 01:43:36 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Mon, 15 Mar 2004 07:43:02 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Mar 2004 07:43:01 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF626@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: andrew.mcdonald@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] NSIS Meeting Minutes Date: Mon, 15 Mar 2004 07:43:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Maybe Fred referred to DiffServ aware Traffic engineering. While this is an MPLS protocol and therefore not (yet?) related to NSIS, it caused Intra Domain routing protocols to introduce a second SPF routing instance. With DS TE there's a "standard" metric and a "voice class" metric. DS TE allows for more routing instances (up to four) but AFAIK only one is implemented for the time being. Regards, Rudiger |-----Original Message----- |From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of |Andrew McDonald |Sent: Sunday, March 14, 2004 5:08 PM |To: Hancock, Robert |Cc: 'john.loughney@nokia.com'; nsis@ietf.org |Subject: Re: [NSIS] NSIS Meeting Minutes | | |On Sat, Mar 13, 2004 at 04:20:15PM -0000, Hancock, Robert wrote: |> one point i don't follow: |> |> > Fred: People asked us to route data traffic different than data. |> |> i remember Fred saying something on this topic, but I can't |> remember what it was (and i'm sure it wasn't this!) clues? | |I think it was something like: "People ask us to route voice traffic |differently to other data". | |i.e. some people want voice to go over a different network (or, at |least, via a different route) to other data, so the D-mode signalling |needs to look enough like "voice" (rather than "other data") so it goes |the right way. | |Andrew | |_______________________________________________ |nsis mailing list |nsis@ietf.org |https://www1.ietf.org/mailman/listinfo/nsis | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 15 03:02:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13775 for ; Mon, 15 Mar 2004 03:02:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2n2p-00045U-5S for nsis-archive@odin.ietf.org; Mon, 15 Mar 2004 03:02:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F81s8E015695 for nsis-archive@odin.ietf.org; Mon, 15 Mar 2004 03:01:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2n21-00042P-MO; Mon, 15 Mar 2004 03:01:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2n1g-00041L-8M for nsis@optimus.ietf.org; Mon, 15 Mar 2004 03:00:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13740 for ; Mon, 15 Mar 2004 03:00:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2n1c-0003K2-00 for nsis@ietf.org; Mon, 15 Mar 2004 03:00:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2n0h-0003Dz-00 for nsis@ietf.org; Mon, 15 Mar 2004 02:59:44 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1B2n0N-00037O-00 for nsis@ietf.org; Mon, 15 Mar 2004 02:59:23 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i2F7xNE24711; Mon, 15 Mar 2004 08:59:23 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i2F7xNV19775; Mon, 15 Mar 2004 08:59:23 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Mar 2004 08:58:40 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685E76@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Geib, Ruediger'" , andrew.mcdonald@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] NSIS Meeting Minutes Date: Mon, 15 Mar 2004 08:59:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, do you want me to change something in the meeting minutes? ciao hannes > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Monday, March 15, 2004 7:43 AM > To: andrew.mcdonald@roke.co.uk > Cc: nsis@ietf.org > Subject: RE: [NSIS] NSIS Meeting Minutes > > > Maybe Fred referred to DiffServ aware Traffic engineering. While > this is an MPLS protocol and therefore not (yet?) related to > NSIS, it caused Intra Domain routing protocols to introduce a > second SPF routing instance. With DS TE there's a "standard" metric > and a "voice class" metric. DS TE allows for more routing > instances (up to four) but AFAIK only one is implemented for > the time being. > > Regards, Rudiger > > |-----Original Message----- > |From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > |Andrew McDonald > |Sent: Sunday, March 14, 2004 5:08 PM > |To: Hancock, Robert > |Cc: 'john.loughney@nokia.com'; nsis@ietf.org > |Subject: Re: [NSIS] NSIS Meeting Minutes > | > | > |On Sat, Mar 13, 2004 at 04:20:15PM -0000, Hancock, Robert wrote: > |> one point i don't follow: > |> > |> > Fred: People asked us to route data traffic different than data. > |> > |> i remember Fred saying something on this topic, but I can't > |> remember what it was (and i'm sure it wasn't this!) clues? > | > |I think it was something like: "People ask us to route voice traffic > |differently to other data". > | > |i.e. some people want voice to go over a different network (or, at > |least, via a different route) to other data, so the D-mode signalling > |needs to look enough like "voice" (rather than "other data") > so it goes > |the right way. > | > |Andrew > | > |_______________________________________________ > |nsis mailing list > |nsis@ietf.org > |https://www1.ietf.org/mailman/listinfo/nsis > | > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 15 09:56:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00624 for ; Mon, 15 Mar 2004 09:56:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tVZ-0004HG-PJ for nsis-archive@odin.ietf.org; Mon, 15 Mar 2004 09:56:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FEu12b016442 for nsis-archive@odin.ietf.org; Mon, 15 Mar 2004 09:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tVY-0004Gt-Hu; Mon, 15 Mar 2004 09:56:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tVW-0004Gd-57 for nsis@optimus.ietf.org; Mon, 15 Mar 2004 09:55:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00613 for ; Mon, 15 Mar 2004 09:55:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2tVU-0002w9-00 for nsis@ietf.org; Mon, 15 Mar 2004 09:55:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2tUX-0002q2-00 for nsis@ietf.org; Mon, 15 Mar 2004 09:54:58 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1B2tTq-0002ch-00 for nsis@ietf.org; Mon, 15 Mar 2004 09:54:15 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMPZTA>; Mon, 15 Mar 2004 14:53:43 -0000 Message-ID: From: "Hancock, Robert" To: "'Tschofenig Hannes '" , "''Geib, Ruediger' '" , "McDonald, Andrew" Cc: "'nsis@ietf.org '" Subject: RE: [NSIS] NSIS Meeting Minutes Date: Mon, 15 Mar 2004 14:53:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, given the context in the rest of the minutes and other people's actual recollections, i would suggest something like... Fred: emphasised that people really do route some types of packet differently from other types of packet, i.e. not purely on IP destination address (e.g. voice vs. other data). I don't think this actually changes anything we are doing or have thought about in the past, but it does reassure me that we haven't been agonising over a non-issue. r. -----Original Message----- From: Tschofenig Hannes To: 'Geib, Ruediger'; McDonald, Andrew Cc: nsis@ietf.org Sent: 15/03/2004 7:59 AM Subject: RE: [NSIS] NSIS Meeting Minutes hi, do you want me to change something in the meeting minutes? ciao hannes > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Monday, March 15, 2004 7:43 AM > To: andrew.mcdonald@roke.co.uk > Cc: nsis@ietf.org > Subject: RE: [NSIS] NSIS Meeting Minutes > > > Maybe Fred referred to DiffServ aware Traffic engineering. While > this is an MPLS protocol and therefore not (yet?) related to > NSIS, it caused Intra Domain routing protocols to introduce a > second SPF routing instance. With DS TE there's a "standard" metric > and a "voice class" metric. DS TE allows for more routing > instances (up to four) but AFAIK only one is implemented for > the time being. > > Regards, Rudiger > > |-----Original Message----- > |From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > |Andrew McDonald > |Sent: Sunday, March 14, 2004 5:08 PM > |To: Hancock, Robert > |Cc: 'john.loughney@nokia.com'; nsis@ietf.org > |Subject: Re: [NSIS] NSIS Meeting Minutes > | > | > |On Sat, Mar 13, 2004 at 04:20:15PM -0000, Hancock, Robert wrote: > |> one point i don't follow: > |> > |> > Fred: People asked us to route data traffic different than data. > |> > |> i remember Fred saying something on this topic, but I can't > |> remember what it was (and i'm sure it wasn't this!) clues? > | > |I think it was something like: "People ask us to route voice traffic > |differently to other data". > | > |i.e. some people want voice to go over a different network (or, at > |least, via a different route) to other data, so the D-mode signalling > |needs to look enough like "voice" (rather than "other data") > so it goes > |the right way. > | > |Andrew > | > |_______________________________________________ > |nsis mailing list > |nsis@ietf.org > |https://www1.ietf.org/mailman/listinfo/nsis > | > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 16 03:24:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17565 for ; Tue, 16 Mar 2004 03:24:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B39rr-0006Tk-5V for nsis-archive@odin.ietf.org; Tue, 16 Mar 2004 03:24:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G8O6a6024885 for nsis-archive@odin.ietf.org; Tue, 16 Mar 2004 03:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B39rm-0006Sa-Ts; Tue, 16 Mar 2004 03:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B39rI-0006N6-Mb for nsis@optimus.ietf.org; Tue, 16 Mar 2004 03:23:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17511 for ; Tue, 16 Mar 2004 03:23:30 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B39rG-0000iM-00 for nsis@ietf.org; Tue, 16 Mar 2004 03:23:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B39qG-0000d2-00 for nsis@ietf.org; Tue, 16 Mar 2004 03:22:29 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B39pP-0000XL-00 for nsis@ietf.org; Tue, 16 Mar 2004 03:21:35 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2G8LVA24479 for ; Tue, 16 Mar 2004 10:21:34 +0200 (EET) X-Scanned: Tue, 16 Mar 2004 10:21:13 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2G8LDQp017072 for ; Tue, 16 Mar 2004 10:21:13 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 008Triw9; Tue, 16 Mar 2004 10:21:11 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2G8LBH26212 for ; Tue, 16 Mar 2004 10:21:11 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Mar 2004 10:21:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Mar 2004 10:21:02 +0200 Message-ID: Thread-Topic: Plans for the protocol drafts Thread-Index: AcQLL58iOBzQZmTjTwmbHZKqNxvJyQ== To: X-OriginalArrivalTime: 16 Mar 2004 08:21:02.0784 (UTC) FILETIME=[9EBE0C00:01C40B2F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Plans for the protocol 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: quoted-printable Hi all, I would like to get some feedback from the WG about the next steps for = the 3 protocol drafts. I would like to progress the drafts - it would = be reasonable to request the authors release an updated version of the = drafts sometime in May. Would it be helpful to arrange some conference = calls around this, or even an interim meeting before San Diego? thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 16 06:05:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23824 for ; Tue, 16 Mar 2004 06:05:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3CNc-0002KV-OF for nsis-archive@odin.ietf.org; Tue, 16 Mar 2004 06:05:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GB54tp008952 for nsis-archive@odin.ietf.org; Tue, 16 Mar 2004 06:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3CNb-0002Jx-5H; Tue, 16 Mar 2004 06:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3CNE-0002It-WC for nsis@optimus.ietf.org; Tue, 16 Mar 2004 06:04:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23783 for ; Tue, 16 Mar 2004 06:04:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3CNB-00067k-00 for nsis@ietf.org; Tue, 16 Mar 2004 06:04:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3CMN-000635-00 for nsis@ietf.org; Tue, 16 Mar 2004 06:03:48 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1B3CLK-0005yd-00 for nsis@ietf.org; Tue, 16 Mar 2004 06:02:42 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i2GB2gv06415 for ; Tue, 16 Mar 2004 12:02:42 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i2GB2bV02684 for ; Tue, 16 Mar 2004 12:02:37 +0100 (MET) Received: from mchh275e.mchh.siemens.de (mchh275e.mchh.siemens.de [139.21.200.61]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA19998 for ; Tue, 16 Mar 2004 12:02:13 +0100 (MET) Received: by mchh275e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Mar 2004 12:02:35 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A022C7C73@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: HANCOCK ROBERT , Tschofenig Hannes , nsis@ietf.org Subject: AW: [NSIS] comments on NSIS Security Threats ID Date: Tue, 16 Mar 2004 12:02:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Robert,=20 thanks for the enlightening clarification. I understand the threat and = the possible solution path now, however the current text IMHO just does = not at all explain it. It is just too short.=20 Cornelia > -----Urspr=FCngliche Nachricht----- > Von: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > Gesendet: Samstag, 13. M=E4rz 2004 17:14 > An: 'Kappler Cornelia'; Tschofenig Hannes; nsis@ietf.org > Betreff: RE: [NSIS] comments on NSIS Security Threats ID >=20 >=20 > hi, >=20 > a comment on cornelia's comment (which in her email is > targeted at 4.3 but which i think is actually about 4.4): >=20 > > -----Original Message----- > > From: Kappler Cornelia [mailto:cornelia.kappler@siemens.com] > > Sent: Saturday, March 13, 2004 04:35 > > To: Tschofenig Hannes; nsis@ietf.org > > Subject: [NSIS] comments on NSIS Security Threats ID > >=20 > >=20 > > Hi Hannes,=20 > > my comments mostly relate to the structure of Sec 4 (along=20 > > similar lines as Robert was suggesting), and to problems I=20 > > have understanding identity spoofing of flow identifieres.=20 > See below.=20 > [snip] >=20 > > The 3rd paragraph introduces exploitation of the spoofing of=20 > > flow identifiers. The remaining paragraphs of 4.3 all seem to=20 > > discuss this problem in more detail. It took me some time to=20 > > realize this, may be you could add an explaining sentence. > > 2nd last paragraph of 4.3: "The ability...to inject data=20 > > atraffic..requires the ability to also receive the data=20 > > traffic. This is, however, true only if the flow identifier=20 > > consists of a value that contains addresses used for=20 > > routing."=20 >=20 > the real point is more subtle. compared to the original > "The ability for an adversary to inject data traffic that matches a=20 > certain flow identifier established by a legitimate user often=20 > requires the ability also to receive the data traffic. " >=20 > one might emphasise=20 > "The ability for an adversary to inject data traffic that matches a=20 > certain flow identifier established by a legitimate user=20 > and to get some benefit from injecting that traffic > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > often=20 > requires the ability also to receive the data traffic.=20 > or to have one's correspondent receive it. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^" >=20 > > Doesnt seem to make sense. I can picture various=20 > > scenarios where I am able to receive data traffic not really=20 > > destined to me, independent of the structure of the flow=20 > > identifier...!? >=20 > you can always try to receive on-link traffic for one of > your neighbours, but that is not really the issue. the > point is: > a) a 'reservation' has an associated filter specification > b) it also has an intended beneficiary > c) all traffic that matches (a) will get the benefit, but > d) that traffic may not be associated with the beneficiary (b) >=20 > now, it is possible to write filter specifications which are > similarly fine-grained, but which are very different in the=20 > possibilities they allow other users to generate traffic which > is useful to them but not what the original user intended.=20 > hence the threat. >=20 > apart from per-packet cryptographic authentication at each > router, it's difficult to counter this type of threat. the > approach being discussed here is to say that if you specify > traffic some ways, the forwarding system itself (i.e. the most=20 > fundamental part of the network layer) will provide some > protection. the arguments are similar to what was done for > mip6 (see draft-nikander-mobileip-v6-ro-sec-02). >=20 > some examples may be needed. >=20 > *) reserve class X for traffic with SPI=3Dfred > =3D=3D> anyone can set SPI=3Dfred in their own packets and get > class X for them. >=20 > *) reserve class X for traffic with proto/port=3DTCP/80 and > source=3Dmyself > =3D=3D> all my outgoing web traffic will get class X; but so > will that from anyone else who spoofs my source address. > (it's hard but not impossible for the spoofer to benefit=20 > from this.) if applied, ingress filtering on the traffic > will make it harder. >=20 > *) reserve class X for traffic with proto/port=3DTCP/80 and > destination=3Dmyself > =3D=3D> all my incoming traffic will get class X; if we assume > destination address spoofing is impossible, we are just=20 > about done. >=20 > [all these examples are slightly artificial, since the NTLP > would have difficulty in routing messages about such vaguely > specified flows, but they make the general point.] >=20 > some master wordsmithing may be required. >=20 > r. >=20 > > The same paragraph continues: "If ... using...a flow=20 > > identifier that do not require such a property (CK: i.e.=20 > > addresses used for routing I assume?? Or ability to receive=20 > > data traffic? But this I think is independent of the=20 > > structure of the flow identifier) then ...injecting traffic=20 > > are much easier." Doesnt make sense to me either (I may just=20 > > have problems catching on...) >=20 > --=20 >=20 > Visit our website at www.roke.co.uk >=20 > Registered Office: Roke Manor Research Ltd, Siemens House,=20 > Oldbury, Bracknell, > Berkshire. RG12 8FZ >=20 > The information contained in this e-mail and any attachments=20 > is confidential to > Roke Manor Research Ltd and must not be passed to any third=20 > party without > permission. This communication is for information only and=20 > shall not create or > change any contractual relationship. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 16 11:44:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10171 for ; Tue, 16 Mar 2004 11:44:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Hfg-0006kL-Lz for nsis-archive@odin.ietf.org; Tue, 16 Mar 2004 11:44:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GGi4DH025916 for nsis-archive@odin.ietf.org; Tue, 16 Mar 2004 11:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Hfd-0006jD-US; Tue, 16 Mar 2004 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Hew-0006i2-JE for nsis@optimus.ietf.org; Tue, 16 Mar 2004 11:43:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10115 for ; Tue, 16 Mar 2004 11:43:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Hev-0004j5-00 for nsis@ietf.org; Tue, 16 Mar 2004 11:43:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3He7-0004aO-00 for nsis@ietf.org; Tue, 16 Mar 2004 11:42:28 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B3HdE-0004Qo-00 for nsis@ietf.org; Tue, 16 Mar 2004 11:41:32 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3HdD-0005rO-Uf; Tue, 16 Mar 2004 16:41:31 +0000 To: john.loughney@nokia.com cc: nsis@ietf.org Subject: Re: [NSIS] Plans for the protocol drafts In-Reply-To: Message from john.loughney@nokia.com of "Tue, 16 Mar 2004 10:21:02 +0200." Date: Tue, 16 Mar 2004 08:41:31 -0800 From: Allison Mankin Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, all, There should be mailing list discussion for each protocol draft of the Early Review comments and how they will be addressed. Allison _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Mar 17 05:11:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28666 for ; Wed, 17 Mar 2004 05:11:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Y12-0006a1-Bb for nsis-archive@odin.ietf.org; Wed, 17 Mar 2004 05:11:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HABCbu025290 for nsis-archive@odin.ietf.org; Wed, 17 Mar 2004 05:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Y0u-0006Yq-Uc; Wed, 17 Mar 2004 05:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Y0J-0006SD-Su for nsis@optimus.ietf.org; Wed, 17 Mar 2004 05:10:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28586 for ; Wed, 17 Mar 2004 05:10:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Y0G-0004ZE-00 for nsis@ietf.org; Wed, 17 Mar 2004 05:10:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3XzM-0004Rv-00 for nsis@ietf.org; Wed, 17 Mar 2004 05:09:29 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1B3Xyb-0004Ec-00 for nsis@ietf.org; Wed, 17 Mar 2004 05:08:41 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMQMV9>; Wed, 17 Mar 2004 10:08:11 -0000 Message-ID: From: "Hancock, Robert" To: "'Allison Mankin'" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Plans for the protocol drafts Date: Wed, 17 Mar 2004 10:08:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, for the GIMPS doc: I've posted a discussion response to Dave's comments shortly after the meeting. I think they are all clarifications or editorial issues, with two exceptions: - the looping issue (which i'll write something separate about) - the NAT traversal issue, on which we know more work needs to be done (but there wasn't really a specific comment here). watch this space... For Alex's 'general' comments, I'm still waiting for some confirmation that I've understood the concerns correctly and then I'll look at fixing them (actually in the framework document). His comments on GIMPS are I think again clarification matters, specifically: - Q: why per-flow routing info at the NTLP level? A: the same reason NHOP/PHOP state is held per flow in RSVP; and also that messaging associations which terminate more than one IP hop away cannot be selected only by looking at the local forwarding table (==> per flow routing is needed). We could put more in 3.1 about this (not too much I hope). - Q: Suggests flow-based routing? A: this is probably a response to the naming of an object as 'flow routing information'. But this is not information about how to route the flow, it is information about the flow to ascertain how it is routed (so the signalling can go the same way). In fact, we will probably change this object to 'message routing information' in the next version anyway. If people have further comments on the GIMPS review comments, please send them. One question from me about document scope and structure (partly brought up by the nature of the review comments): a lot of the comments (the bulk, in fact) are "why is this like this?" or "what is this bit for?" or "why not do it that way?" - in other words, requests for explanation and design rationale. How much of that type of information should be reflected in the actual protocol document, given the need to balance two conflicting concerns: - a general concern in the IETF that we do a bad job of capturing such information for later use; and - a general concern in the IETF that all documents are too long. If there are examples of how this has been handled in similar protocol development activities that people would care to recommend as a model to follow, that would be interesting. r. > -----Original Message----- > From: Allison Mankin [mailto:mankin@psg.com] > Sent: Tuesday, March 16, 2004 16:42 > To: john.loughney@nokia.com > Cc: nsis@ietf.org > Subject: Re: [NSIS] Plans for the protocol drafts > > > Hi, all, > > There should be mailing list discussion for each > protocol draft of the Early Review comments and how they > will be addressed. > > Allison > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Mar 17 10:53:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13981 for ; Wed, 17 Mar 2004 10:53:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dM1-00005U-U5 for nsis-archive@odin.ietf.org; Wed, 17 Mar 2004 10:53:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HFrDC2000325 for nsis-archive@odin.ietf.org; Wed, 17 Mar 2004 10:53:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dLx-0008UA-KW; Wed, 17 Mar 2004 10:53:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dLV-0008L2-4o for nsis@optimus.ietf.org; Wed, 17 Mar 2004 10:52:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13717 for ; Wed, 17 Mar 2004 10:52:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3dLS-0006x9-00 for nsis@ietf.org; Wed, 17 Mar 2004 10:52:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3dJ5-0006Oe-00 for nsis@ietf.org; Wed, 17 Mar 2004 10:50:13 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1B3dH7-0005n3-00 for nsis@ietf.org; Wed, 17 Mar 2004 10:48:09 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMQQCS>; Wed, 17 Mar 2004 15:47:16 -0000 Message-ID: From: "Hancock, Robert" To: "Nsis (E-mail)" Date: Wed, 17 Mar 2004 15:47:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] Message Looping in GIMPS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, One of Dave Oran's early review comments was (from the email) > - What led to the decision to use a hop count rather > than a VIA-style path recording? and from the discussion at the meeting, the issues were - a VIA mechanism can prune a loop much faster than a hop count (and this is the main purpose of the hop count) - route recording might end up being used (and thus re-invented) by many signalling applications anyway After some thought, at the moment I think that the current function split between GIMPS and signalling applications is right and that it is right for GIMPS to use a counter based mechanism for loop handling. But the argument is quite detailed. r. argument follows: Looping ------- Message looping can happen at (at least) 3 levels: 1. normal packet looping at the IP level. 2. a message looping around a set of GIMPS-aware nodes without finding a signalling application node to be delivered to. 3. messages looping between instances of a signalling application. (1) is out of our hands; we know it will happen (at least transiently) and that the IP TTL will sort things out. (2) - if it happens even after (1) has been dealt with - has to be handled by GIMPS. Then the question is whether to handle it with a hop count or VIA mechanism. (But it is not immediately obvious that (2) can happen, see below.) (3) could be handled by each signalling application; or, GIMPS could provide a common service. And in the second case, it could use the same mechanism used for (2), or a different mechanism. Does GIMPS *need* an internal loop-prevention mechanism? -------------------------------------------------------- One might think that case (2) could never arise (except as a side effect of packet looping). Firstly, a discovery message is supposed to be forwarded precisely like any other IP packet; secondly, we would like to have the situation where the GIMPS routing state refers to [and messaging associations run directly between] signalling application peers. So, either things are handled in the IP layer; or, the looping happens between instances of the signalling application in question - no pure GIMPS loops are possible. However, even in the current design, discovery messages are not handled exactly like IP datagrams, because of the policy routing/load balancing problem. If a network implements pf/lb in all its nodes but only some of them are GIMPS aware, discovery messages will be forwarded according to their IP header in the GIMPS unaware nodes but according the flow identifier in the GIMPS aware nodes; therefore, loops are possible. (I think this could probably be counted a pathological condition but it can't be ruled out. In particular, such loops, if they did occur, probably would not be transient.) In addition, it is still possible that people may want to build networks where C-mode associations are used to trunk signalling messages through GIMPS-only nodes, or there may be other message routing mechanisms added later (e.g. for the path-decoupled case). Once we loosen the connection with IP routing, loop prevention at the GIMPS level becomes a requirement. So, loop prevention within GIMPS for looping at level (2) is needed. How to do loop prevention within GIMPS? --------------------------------------- We have a choice here between hop counting and route recording. There are several trade-offs to make here. If we leave aside the possibility that applications would want route recording for their own purposes for now, the issue is of which design option is most appropriate within GIMPS. I think several aspects point at a hop count being more appropriate: *) it's fast. loop detection will be being done mainly on datagram messages discovering the next NSLP-aware hop, and we know this is a sensitive area for router performance (people would like to do this "get this message past a node which doesn't care about it" in the fast path if possible). So, a check&decrement of a counter (in the fixed header) is preferable to scanning a route record for an identity and inserting a new field. *) we expect looping to be rare (it shouldn't come about through GIMPS misconfiguration, initially only pathological IP pf/lb situations) so detecting it early and efficiently (which a VIA mechanism would do) is less important than making the cost of the processing low. *) it doesn't lead to message expansion. discovery mode messages are size limited, and adding route records may make them hard to propagate. or, people might want to start record trimming and so on. *) it's simple. we don't have to get into worries about topology hiding, what namespaces to use for node identities. So, I would propose to keep the GHC as a loop detection mechanism within the GIMPS layer. (Obviously, the rules about how to process it need to be specified more precisely.) This can then also be used as *one* weapon to handle message looping at the signalling application layer (since NSLPs can read and set the GHC in their messages). Should GIMPS provide route recording as a service? -------------------------------------------------- Despite all this, it is still possible (likely?) that there is a use for route recording for various purposes for use by signalling applications. That may be for loop detection or something else. Loops may be caused by negotiation loops within a single instance of a NSLP (between peers or over a longer distance), or by feedback between microflow and aggregate signalling, or any other sort of reason, and the GHC may not be suitable or powerful enough to handle this. We could make a recording mechanism almost directly out of the comparable functionality in SIP or Diameter. However, I think this functionality comes into the same class as some other items of 'generally useful signalling protocol' function, like state refresh management or MLPP: it may be useful for several signalling applications, but doesn't have a significant interaction with the other functions within GIMPS itself. Exactly how to make such re-usable components is an interesting question, but our assumption within NSIS (up to now) is that it is a question for the signalling application layer, not for the NTLP layer. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Mar 17 21:01:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24341 for ; Wed, 17 Mar 2004 21:01:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3mqF-0005N0-De for nsis-archive@odin.ietf.org; Wed, 17 Mar 2004 21:01:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I213E8020621 for nsis-archive@odin.ietf.org; Wed, 17 Mar 2004 21:01:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3mqD-0005ME-Sl; Wed, 17 Mar 2004 21:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3mpG-0005Iq-0Y for nsis@optimus.ietf.org; Wed, 17 Mar 2004 21:00:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24253 for ; Wed, 17 Mar 2004 20:59:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3mpD-0004ie-00 for nsis@ietf.org; Wed, 17 Mar 2004 20:59:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3moN-0004bb-00 for nsis@ietf.org; Wed, 17 Mar 2004 20:59:08 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1B3mo0-0004Ta-00 for nsis@ietf.org; Wed, 17 Mar 2004 20:58:44 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i2I1spRH012818; Wed, 17 Mar 2004 20:54:51 -0500 (EST) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id i2I1sQC00589; Wed, 17 Mar 2004 20:54:51 -0500 Message-ID: <40590152.3020902@cs.columbia.edu> Date: Wed, 17 Mar 2004 20:54:26 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: "Nsis (E-mail)" Subject: Re: [NSIS] Message Looping in GIMPS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > are handled in the IP layer; or, the looping happens between > instances of the signalling application in question - no pure > GIMPS loops are possible. I think it's more precise to say that loops are possible, just no *infinite* loops. I.e., a packet can circle around the block a few times, but it will eventually be dropped on the floor. If the loop is tight, it can circle quite a few times. > > However, even in the current design, discovery messages are > not handled exactly like IP datagrams, because of the policy > routing/load balancing problem. If a network implements pf/lb in > all its nodes but only some of them are GIMPS aware, discovery > messages will be forwarded according to their IP header in the > GIMPS unaware nodes but according the flow identifier in the > GIMPS aware nodes; therefore, loops are possible. (I think this > could probably be counted a pathological condition but it can't > be ruled out. In particular, such loops, if they did occur, > probably would not be transient.) I don't see how this is different. IP TTL will have the same effect in either case. Given that the flow label is part of the header, I'm confused by the distinction. > > In addition, it is still possible that people may want to build > networks where C-mode associations are used to trunk signalling > messages through GIMPS-only nodes, or there may be other message > routing mechanisms added later (e.g. for the path-decoupled case). > Once we loosen the connection with IP routing, loop prevention at > the GIMPS level becomes a requirement. That is indeed the more likely concern, in addition to efficiency. > > So, loop prevention within GIMPS for looping at level (2) is needed. > > How to do loop prevention within GIMPS? > --------------------------------------- > *) it's fast. loop detection will be being done mainly on > datagram messages discovering the next NSLP-aware hop, and we know > this is a sensitive area for router performance (people would like > to do this "get this message past a node which doesn't care about > it" in the fast path if possible). So, a check&decrement of a > counter (in the fixed header) is preferable to scanning a route > record for an identity and inserting a new field. > > *) we expect looping to be rare (it shouldn't come about through > GIMPS misconfiguration, initially only pathological IP pf/lb > situations) so detecting it early and efficiently (which a VIA > mechanism would do) is less important than making the cost of the > processing low. > > *) it doesn't lead to message expansion. discovery mode messages > are size limited, and adding route records may make them hard to > propagate. or, people might want to start record trimming and so > on. > > *) it's simple. we don't have to get into worries about topology > hiding, what namespaces to use for node identities. > > So, I would propose to keep the GHC as a loop detection mechanism > within the GIMPS layer. (Obviously, the rules about how to process > it need to be specified more precisely.) This can then also be used > as *one* weapon to handle message looping at the signalling application > layer (since NSLPs can read and set the GHC in their messages). Note that SIP simply chose to do both, since they have complementary properties (speed of inspection vs. early discovery and better diagnostics). I don't see why we couldn't *allow* (not mandate) that if route-recording is used, that entities can inspect this and use it to discover loops. (As a side note: In SIP, we had to deal with 'spirals', where messages would visit the same node twice, after modification. I don't think this is likely to occur here.) > > Should GIMPS provide route recording as a service? > -------------------------------------------------- > > Despite all this, it is still possible (likely?) that there is > a use for route recording for various purposes for use by > signalling applications. That may be for loop detection or > something else. Loops may be caused by negotiation loops within > a single instance of a NSLP (between peers or over a longer > distance), or by feedback between microflow and aggregate signalling, > or any other sort of reason, and the GHC may not be suitable or > powerful enough to handle this. We could make a recording mechanism > almost directly out of the comparable functionality in SIP or > Diameter. > > However, I think this functionality comes into the same class as > some other items of 'generally useful signalling protocol' function, > like state refresh management or MLPP: it may be useful for several > signalling applications, but doesn't have a significant interaction > with the other functions within GIMPS itself. Exactly how to make > such re-usable components is an interesting question, but our > assumption within NSIS (up to now) is that it is a question for the > signalling application layer, not for the NTLP layer. I respectfully disagree. Since we'd want to be able to record every NTLP hop, not just every NSLP hop, it makes sense to offer this as an optional service within NTLP. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Mar 18 04:39:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29520 for ; Thu, 18 Mar 2004 04:39:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tzW-0006cK-Sp for nsis-archive@odin.ietf.org; Thu, 18 Mar 2004 04:39:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I9d6VO025411 for nsis-archive@odin.ietf.org; Thu, 18 Mar 2004 04:39:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tzR-0006ag-TL; Thu, 18 Mar 2004 04:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tyl-0006TL-3G for nsis@optimus.ietf.org; Thu, 18 Mar 2004 04:38:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29459 for ; Thu, 18 Mar 2004 04:38:16 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3tyi-0006aK-00 for nsis@ietf.org; Thu, 18 Mar 2004 04:38:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3txj-0006Si-00 for nsis@ietf.org; Thu, 18 Mar 2004 04:37:16 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1B3tx9-0006Ly-00 for nsis@ietf.org; Thu, 18 Mar 2004 04:36:39 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i2I9abIe025980; Thu, 18 Mar 2004 10:36:37 +0100 Subject: Re: [NSIS] Plans for the protocol drafts To: Allison Mankin Cc: john.loughney@nokia.com, nsis@ietf.org, "Georgios Karagiannis" , "McDonald, Andrew" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 18 Mar 2004 10:36:34 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/18/2004 10:36:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Allison, John, all, We have had a first discussion of the comments among the authors and this is how we see the current status (per comment). Best regards, Sven NSLP comments ============= 1. Need for explicit teardown invoked by the AAA element? I think aspect is already possible. To clarify, we can extend the description of what may trigger the NSLP handler with AAA in addition to e.g. RMF. Teardown by an external element can be handled by a combination of a NOTIFY and a tearing RESERVE. 2. How is receiver selection based on ADSPEC done if resources are reserved in the forward direction with RESERVE? In the current sender-initiated model you can do a QUERY/RESPONSE/RESERVE. This costs 0.5xRTT more than a PATH/RESV. As possible optimization here could be to do a QUERY send the RESERVE and RESPONSE in parallel. This would have no impact on the protocol (only intelligence on the receiver side). We will provide an example on receiver-initiated reservation in the next version. 3. some talk about 2-phase operation for RSVP. Any thought of the same for NSLP? We discussed about a RESERVE/COMMIT model in QoS NSLP. At the moment, we feel that this might be solved at the QoS model level which is opaque to QoS NSLP. 4. Didn't see any way to do resource sharing across flows. There is, but maybe not for a general case. Two flows with the same session ID but different flow ID will share resources. This is used in special cases of mobility and route changes. GIMPS does have some wildcarding of flow IDs, which would probably get you to the same level of resource sharing as RSVP (to be checked). 5. Ditto for fate-sharing across flows (if you tear one down you tear the fate-shared ones down) Within QoS NSLP, you could regard this as a policy decision taken by a QNE. However, we could think about a SESSION_FATE_SHARED object similar to BOUND_SESSION_IP. Is there any interest in fate sharing between different NSLPs (e.g. qos-nslp/natfw-nslp)? 6. Reservation priority is declared out of scope but is critically important. We can't just punt this. One thought is to have it be part of a set of "common facilities" that go across all the GIMPS applications. I bet there are a number of such common things which are not part of the transport but aren't specific to a particular signaling appication. We would like to receive input on this from the WG. Why do they think it is needed, what are the requirements, ... 7. Is there any capability for make-before-break so that reservations can be installed on multiple paths at the same time to deal with graceful mobility? It seems that the notion of flow/session separation captures part of this, but I don't see how it solves the double-booking problems on the common links. We have thought about a possible extensions of the SII object, but reservations on future paths conflict with the current NSIS charter. With the current spec, it is not obvious how this functionality could be provided. An extension of the SII would conceivably impact the GIMPS requirements as well. 8. How does bi-dir reservation enforce symmetric routing? At present, we imagine that it should not enforce symmetric routing but make assumptions on one-end being on the path for both directions (whether it is sender+receiver initiated reserve, or remote initiated model). Binding of both reservation would happen at the end points. 9. State refresh reduction (a la rfc2961): this is vital. We agree with the comment. The current draft hints at a solution with RESPONSE message. We will make this explicit in the next version. 10. Don't like multiple qos models. (Complicated, and can't work.) The proposal here is to see what the QoS model draft teams come up with and clarify exactly what is achieved when the QoS model work has progressed a bit. Allison Mankin @ietf.org on 16/03/2004 17:41:31 Sent by: nsis-admin@ietf.org To: john.loughney@nokia.com cc: nsis@ietf.org Subject: Re: [NSIS] Plans for the protocol drafts Hi, all, There should be mailing list discussion for each protocol draft of the Early Review comments and how they will be addressed. Allison _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Mar 18 07:13:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05545 for ; Thu, 18 Mar 2004 07:13:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3wOX-00086V-Aj for nsis-archive@odin.ietf.org; Thu, 18 Mar 2004 07:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ICD4IF031135 for nsis-archive@odin.ietf.org; Thu, 18 Mar 2004 07:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3wOT-00085u-4P; Thu, 18 Mar 2004 07:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3wO3-0007zs-FZ for nsis@optimus.ietf.org; Thu, 18 Mar 2004 07:12:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05522 for ; Thu, 18 Mar 2004 07:12:34 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3wO2-0001tQ-00 for nsis@ietf.org; Thu, 18 Mar 2004 07:12:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3wN3-0001kk-00 for nsis@ietf.org; Thu, 18 Mar 2004 07:11:33 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B3wMD-0001cv-00 for nsis@ietf.org; Thu, 18 Mar 2004 07:10:41 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2ICAea13968; Thu, 18 Mar 2004 14:10:40 +0200 (EET) X-Scanned: Thu, 18 Mar 2004 14:10:23 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2ICANj0011527; Thu, 18 Mar 2004 14:10:23 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 007c0Qjg; Thu, 18 Mar 2004 14:01:59 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2IC1xs21590; Thu, 18 Mar 2004 14:01:59 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Mar 2004 14:01:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Plans for the protocol drafts Date: Thu, 18 Mar 2004 14:01:54 +0200 Message-ID: Thread-Topic: [NSIS] Plans for the protocol drafts Thread-Index: AcQLdiJpgEjAZSrqSyGDr5un5/n6NQBaHLZA To: Cc: X-OriginalArrivalTime: 18 Mar 2004 12:01:54.0657 (UTC) FILETIME=[CE4CE510:01C40CE0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Allison, > There should be mailing list discussion for each=20 > protocol draft of the Early Review comments and how they > will be addressed. As mentioned, there have been some discussions already started, and authors have been discussing the impact of some of the issues off of the list.=20 I would hope that we could get updated documents out in a reasonable tine, with the results of the discussions based upon the reviews=20 from IETF 59. I encourage WG members to comment on the reviews were were made at IETF 59. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Mar 18 07:15:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05715 for ; Thu, 18 Mar 2004 07:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3wQQ-0008NN-PE for nsis-archive@odin.ietf.org; Thu, 18 Mar 2004 07:15:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ICF25w032157 for nsis-archive@odin.ietf.org; Thu, 18 Mar 2004 07:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3wQQ-0008MX-1s; Thu, 18 Mar 2004 07:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3wPw-0008LS-Vs for nsis@optimus.ietf.org; Thu, 18 Mar 2004 07:14:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05624 for ; Thu, 18 Mar 2004 07:14:31 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3wPw-0002CB-00 for nsis@ietf.org; Thu, 18 Mar 2004 07:14:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3wP0-00022F-00 for nsis@ietf.org; Thu, 18 Mar 2004 07:13:35 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B3wO3-0001tS-00 for nsis@ietf.org; Thu, 18 Mar 2004 07:12:35 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2ICCXa16336; Thu, 18 Mar 2004 14:12:33 +0200 (EET) X-Scanned: Thu, 18 Mar 2004 14:13:15 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i2ICDF3T012333; Thu, 18 Mar 2004 14:13:15 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00vxN5AV; Thu, 18 Mar 2004 14:13:13 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2ICCDs29879; Thu, 18 Mar 2004 14:12:13 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Mar 2004 14:12:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Message Looping in GIMPS Date: Thu, 18 Mar 2004 14:12:11 +0200 Message-ID: Thread-Topic: [NSIS] Message Looping in GIMPS Thread-Index: AcQMODR/J8OJgqiUQ6mGaO0o8gPQJQAqXkIw To: , X-OriginalArrivalTime: 18 Mar 2004 12:12:11.0928 (UTC) FILETIME=[3E38F980:01C40CE2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Robert, I'll cut to the chase and comment on your suggestions: > So, I would propose to keep the GHC as a loop detection mechanism > within the GIMPS layer. (Obviously, the rules about how to process > it need to be specified more precisely.) This can then also be used > as *one* weapon to handle message looping at the signalling = application > layer (since NSLPs can read and set the GHC in their messages). I agree with this. =20 > Should GIMPS provide route recording as a service? > -------------------------------------------------- >=20 > Despite all this, it is still possible (likely?) that there is=20 > a use for route recording for various purposes for use by > signalling applications. That may be for loop detection or > something else. Loops may be caused by negotiation loops within > a single instance of a NSLP (between peers or over a longer > distance), or by feedback between microflow and aggregate signalling, > or any other sort of reason, and the GHC may not be suitable or > powerful enough to handle this. We could make a recording mechanism > almost directly out of the comparable functionality in SIP or > Diameter. >=20 > However, I think this functionality comes into the same class as > some other items of 'generally useful signalling protocol' function, > like state refresh management or MLPP: it may be useful for several > signalling applications, but doesn't have a significant interaction > with the other functions within GIMPS itself. Exactly how to make > such re-usable components is an interesting question, but our > assumption within NSIS (up to now) is that it is a question for the > signalling application layer, not for the NTLP layer. I'd punt this question up to the NSLP-folks. Do you see benefits for = path recording? I agree with Robert that it falls into the nice to have category, but I'd like to know if the NSLPs would like to use such a feature. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Mar 18 07:42:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06946 for ; Thu, 18 Mar 2004 07:42:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3wqY-0001K9-BZ for nsis-archive@odin.ietf.org; Thu, 18 Mar 2004 07:42:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ICg2wj005080 for nsis-archive@odin.ietf.org; Thu, 18 Mar 2004 07:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3wqX-0001JV-03; Thu, 18 Mar 2004 07:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3wps-0001Ii-C8 for nsis@optimus.ietf.org; Thu, 18 Mar 2004 07:41:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06921 for ; Thu, 18 Mar 2004 07:41:18 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3wpr-0005so-00 for nsis@ietf.org; Thu, 18 Mar 2004 07:41:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3wp0-0005n7-00 for nsis@ietf.org; Thu, 18 Mar 2004 07:40:27 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1B3woO-0005gn-00 for nsis@ietf.org; Thu, 18 Mar 2004 07:39:48 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i2ICdjIe021496; Thu, 18 Mar 2004 13:39:45 +0100 Subject: RE: [NSIS] Message Looping in GIMPS To: john.loughney@nokia.com Cc: , X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 18 Mar 2004 13:39:41 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/18/2004 13:39:45 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John, From a QoS NSLP point of view, I would say that record route is useful but that we would probably use it indirectly to: 1. keep/tear down reservations on old paths or branches The QoS NSLP draft currently proposes the use of the Source Identification Information (SII) as a way to detect peer changes at the QoS NSLP and/or as a way to rapidly tear down old branches (alternatively, it could be used to keep the reservation of these old branches). The SII is just an identifier to the QoS NSLP. However, one way to implement it at the GIMPS level would be a record route. This would ensure that messages can be send on old paths (instead of keeping state at the nodes, the state is kept in the recorded route). 2. make reservations on backup paths Support of record routing begs the question of what to do with explicit routing (which has already been mentioned in the discussions). Explicit routing (at the GIMPS layer) would mean that a mechanism is needed to derive the "route object" via other means than recording it during path setup. If used for e.g. reservations on backup paths, however, it would only offer one hop protection and would need to be complemented by an explicit routing mechanism at the NSLP layer. Since we are at this point not so much interested in the explicit route per se, but more in its applications, other mechanisms to do the above would also be OK. Best regards, Sven john.loughney@nokia.com@ietf.org on 18/03/2004 13:12:11 Sent by: nsis-admin@ietf.org To: , cc: Subject: RE: [NSIS] Message Looping in GIMPS Hi Robert, I'll cut to the chase and comment on your suggestions: > So, I would propose to keep the GHC as a loop detection mechanism > within the GIMPS layer. (Obviously, the rules about how to process > it need to be specified more precisely.) This can then also be used > as *one* weapon to handle message looping at the signalling application > layer (since NSLPs can read and set the GHC in their messages). I agree with this. > Should GIMPS provide route recording as a service? > -------------------------------------------------- > > Despite all this, it is still possible (likely?) that there is > a use for route recording for various purposes for use by > signalling applications. That may be for loop detection or > something else. Loops may be caused by negotiation loops within > a single instance of a NSLP (between peers or over a longer > distance), or by feedback between microflow and aggregate signalling, > or any other sort of reason, and the GHC may not be suitable or > powerful enough to handle this. We could make a recording mechanism > almost directly out of the comparable functionality in SIP or > Diameter. > > However, I think this functionality comes into the same class as > some other items of 'generally useful signalling protocol' function, > like state refresh management or MLPP: it may be useful for several > signalling applications, but doesn't have a significant interaction > with the other functions within GIMPS itself. Exactly how to make > such re-usable components is an interesting question, but our > assumption within NSIS (up to now) is that it is a question for the > signalling application layer, not for the NTLP layer. I'd punt this question up to the NSLP-folks. Do you see benefits for path recording? I agree with Robert that it falls into the nice to have category, but I'd like to know if the NSLPs would like to use such a feature. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Mar 18 08:42:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10175 for ; Thu, 18 Mar 2004 08:42:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xmf-0006Md-Nq for nsis-archive@odin.ietf.org; Thu, 18 Mar 2004 08:42:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IDg5RE024447 for nsis-archive@odin.ietf.org; Thu, 18 Mar 2004 08:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xmb-0006L7-EX; Thu, 18 Mar 2004 08:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xlw-0006H3-KX for nsis@optimus.ietf.org; Thu, 18 Mar 2004 08:41:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10079 for ; Thu, 18 Mar 2004 08:41:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xlv-0006Hf-00 for nsis@ietf.org; Thu, 18 Mar 2004 08:41:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xky-000682-00 for nsis@ietf.org; Thu, 18 Mar 2004 08:40:21 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B3xk3-0005zp-00 for nsis@ietf.org; Thu, 18 Mar 2004 08:39:23 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2IDdMqY014400 for ; Thu, 18 Mar 2004 14:39:22 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 14:39:21 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Mar 2004 14:41:00 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: sven.van_den_bosch@alcatel.be, Allison Mankin Cc: john.loughney@nokia.com, nsis@ietf.org, Georgios Karagiannis , "McDonald, Andrew" , Kappler Cornelia Subject: RE: [NSIS] Plans for the protocol drafts Date: Thu, 18 Mar 2004 14:38:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 18 Mar 2004 13:39:21.0694 (UTC) FILETIME=[6B67EFE0:01C40CEE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi All, Just a short comment: I think, questions 2 and 3 and RSVP-like operation example will be discussed in more detail in Cornelia's control load draft after specifying receiver-initiated reservation in QoS-NSLP. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > sven.van_den_bosch@alcatel.be > Sent: Thursday, March 18, 2004 10:37 AM > To: Allison Mankin > Cc: john.loughney@nokia.com; nsis@ietf.org; Georgios Karagiannis; > McDonald, Andrew > Subject: Re: [NSIS] Plans for the protocol drafts > > > Hi Allison, John, all, > > We have had a first discussion of the comments among the > authors and this > is how we see the current status (per comment). > > Best regards, > Sven > > NSLP comments > ============= > > 1. Need for explicit teardown invoked by the AAA element? > > I think aspect is already possible. To clarify, we can extend the > description of what may trigger the NSLP handler with AAA in > addition to > e.g. RMF. Teardown by an external element can be handled by a > combination > of a NOTIFY and a tearing RESERVE. > > 2. How is receiver selection based on ADSPEC done if > resources are reserved > in the forward direction with RESERVE? > > In the current sender-initiated model you can do a > QUERY/RESPONSE/RESERVE. > This costs 0.5xRTT more than a PATH/RESV. As possible > optimization here > could be to do a QUERY send the RESERVE and RESPONSE in parallel. This > would have no impact on the protocol (only intelligence on > the receiver > side). We will provide an example on receiver-initiated > reservation in the > next version. > > 3. some talk about 2-phase operation for RSVP. Any thought of > the same for > NSLP? > > We discussed about a RESERVE/COMMIT model in QoS NSLP. At the > moment, we > feel that this might be solved at the QoS model level which > is opaque to > QoS NSLP. > > 4. Didn't see any way to do resource sharing across flows. > > There is, but maybe not for a general case. Two flows with > the same session > ID but different flow ID will share resources. This is used in special > cases of mobility and route changes. GIMPS does have some > wildcarding of > flow IDs, which would probably get you to the same level of resource > sharing as RSVP (to be checked). > > 5. Ditto for fate-sharing across flows (if you tear one down > you tear the > fate-shared ones down) > > Within QoS NSLP, you could regard this as a policy decision > taken by a QNE. > However, we could think about a SESSION_FATE_SHARED object similar to > BOUND_SESSION_IP. Is there any interest in fate sharing > between different > NSLPs (e.g. qos-nslp/natfw-nslp)? > > 6. Reservation priority is declared out of scope but is critically > important. We can't just punt this. One thought is to have it > be part of a > set of "common facilities" that go across all the GIMPS > applications. I bet > there are a number of such common things which are not part of the > transport but aren't specific to a particular signaling appication. > > We would like to receive input on this from the WG. Why do > they think it is > needed, what are the requirements, ... > > 7. Is there any capability for make-before-break so that > reservations can > be installed on multiple paths at the same time to deal with graceful > mobility? It seems that the notion of flow/session separation > captures part > of this, but I don't see how it solves the double-booking > problems on the > common links. > > We have thought about a possible extensions of the SII object, but > reservations on future paths conflict with the current NSIS > charter. With > the current spec, it is not obvious how this functionality could be > provided. An extension of the SII would conceivably impact the GIMPS > requirements as well. > > 8. How does bi-dir reservation enforce symmetric routing? > > At present, we imagine that it should not enforce symmetric > routing but > make assumptions on one-end being on the path for both > directions (whether > it is sender+receiver initiated reserve, or remote initiated model). > Binding of both reservation would happen at the end points. > > 9. State refresh reduction (a la rfc2961): this is vital. > > We agree with the comment. The current draft hints at a solution with > RESPONSE message. We will make this explicit in the next version. > > 10. Don't like multiple qos models. (Complicated, and can't work.) > > The proposal here is to see what the QoS model draft teams > come up with and > clarify exactly what is achieved when the QoS model work has > progressed a > bit. > > > > > > > Allison Mankin @ietf.org on 16/03/2004 17:41:31 > > Sent by: nsis-admin@ietf.org > > > To: john.loughney@nokia.com > cc: nsis@ietf.org > Subject: Re: [NSIS] Plans for the protocol drafts > > > Hi, all, > > There should be mailing list discussion for each > protocol draft of the Early Review comments and how they > will be addressed. > > Allison > > _______________________________________________ > 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 > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Mar 19 06:25:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26572 for ; Fri, 19 Mar 2004 06:25:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4I7w-00008Y-H4 for nsis-archive@odin.ietf.org; Fri, 19 Mar 2004 06:25:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JBPOFo000507 for nsis-archive@odin.ietf.org; Fri, 19 Mar 2004 06:25:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4I7p-0008UD-Ut; Fri, 19 Mar 2004 06:25:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4I6x-0008FT-8G for nsis@optimus.ietf.org; Fri, 19 Mar 2004 06:24:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25625 for ; Fri, 19 Mar 2004 06:23:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4I24-0004t4-00 for nsis@ietf.org; Fri, 19 Mar 2004 06:19:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4I0y-0004nh-00 for nsis@ietf.org; Fri, 19 Mar 2004 06:18:15 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1B4Hzj-0004U4-00 for nsis@ietf.org; Fri, 19 Mar 2004 06:16:55 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i2JBGOv03432; Fri, 19 Mar 2004 12:16:25 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i2JBGOx17227; Fri, 19 Mar 2004 12:16:24 +0100 (MET) Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA22927; Fri, 19 Mar 2004 12:16:23 +0100 (MET) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 12:16:22 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A022C7C90@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: =?iso-8859-1?Q?=27Attila_B=E1der_=28IJ/ETH=29=27?= , sven.van_den_bosch@alcatel.be, Allison Mankin Cc: john.loughney@nokia.com, nsis@ietf.org, Georgios Karagiannis , MCDONALD ANDREW Subject: AW: [NSIS] Plans for the protocol drafts Date: Fri, 19 Mar 2004 12:16:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Attila and all,=20 well, in principle the IntServ Controlled-Load Service and RSVP are = independent. However when receiver-ini is specified in qos-nslp, I'll = provide an example in my draft of how to use it for controlled-load. = This would also include a description of the receiver selecting QoS = parameters - basically bandwidth in this case - based on the "AdSpec" = (or whatever the corresponding object is in NSIS - we'll work on this = when specifying the QSpec) Regarding RESERVE /COMMIT may be the right place to put this is in one = of the Common Control Informations since it is going to be usable = (potentially) by all QoS -signaling- models. I see this as borderline = between qos-nslp and qos signaling models.=20 [For people familiar with the control info details: RESERVE/COMMIT = could also be located in the QoS signaling model specific control info, = i.e. stackable, however defined as part of the "tool box", i.e. = reusable by several models] Cornelia > -----Urspr=FCngliche Nachricht----- > Von: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com]=20 > Gesendet: Donnerstag, 18. M=E4rz 2004 14:39 > An: sven.van_den_bosch@alcatel.be; Allison Mankin > Cc: john.loughney@nokia.com; nsis@ietf.org; Georgios=20 > Karagiannis; McDonald, Andrew; Kappler Cornelia > Betreff: RE: [NSIS] Plans for the protocol drafts >=20 >=20 > Hi All, >=20 > Just a short comment: I think, questions 2 and 3 and=20 > RSVP-like operation example will be discussed in more detail=20 > in Cornelia's control load draft after specifying=20 > receiver-initiated reservation in QoS-NSLP. >=20 > Best regards, Attila >=20 > > -----Original Message----- > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > > sven.van_den_bosch@alcatel.be > > Sent: Thursday, March 18, 2004 10:37 AM > > To: Allison Mankin > > Cc: john.loughney@nokia.com; nsis@ietf.org; Georgios Karagiannis; > > McDonald, Andrew > > Subject: Re: [NSIS] Plans for the protocol drafts > >=20 > >=20 > > Hi Allison, John, all, > >=20 > > We have had a first discussion of the comments among the=20 > > authors and this > > is how we see the current status (per comment). > >=20 > > Best regards, > > Sven > >=20 > > NSLP comments > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 1. Need for explicit teardown invoked by the AAA element? > >=20 > > I think aspect is already possible. To clarify, we can extend the > > description of what may trigger the NSLP handler with AAA in=20 > > addition to > > e.g. RMF. Teardown by an external element can be handled by a=20 > > combination > > of a NOTIFY and a tearing RESERVE. > >=20 > > 2. How is receiver selection based on ADSPEC done if=20 > > resources are reserved > > in the forward direction with RESERVE? > >=20 > > In the current sender-initiated model you can do a=20 > > QUERY/RESPONSE/RESERVE. > > This costs 0.5xRTT more than a PATH/RESV. As possible=20 > > optimization here > > could be to do a QUERY send the RESERVE and RESPONSE in=20 > parallel. This > > would have no impact on the protocol (only intelligence on=20 > > the receiver > > side). We will provide an example on receiver-initiated=20 > > reservation in the > > next version. > >=20 > > 3. some talk about 2-phase operation for RSVP. Any thought of=20 > > the same for > > NSLP? > >=20 > > We discussed about a RESERVE/COMMIT model in QoS NSLP. At the=20 > > moment, we > > feel that this might be solved at the QoS model level which=20 > > is opaque to > > QoS NSLP. > >=20 > > 4. Didn't see any way to do resource sharing across flows. > >=20 > > There is, but maybe not for a general case. Two flows with=20 > > the same session > > ID but different flow ID will share resources. This is used=20 > in special > > cases of mobility and route changes. GIMPS does have some=20 > > wildcarding of > > flow IDs, which would probably get you to the same level of = resource > > sharing as RSVP (to be checked). > >=20 > > 5. Ditto for fate-sharing across flows (if you tear one down=20 > > you tear the > > fate-shared ones down) > >=20 > > Within QoS NSLP, you could regard this as a policy decision=20 > > taken by a QNE. > > However, we could think about a SESSION_FATE_SHARED object=20 > similar to > > BOUND_SESSION_IP. Is there any interest in fate sharing=20 > > between different > > NSLPs (e.g. qos-nslp/natfw-nslp)? > >=20 > > 6. Reservation priority is declared out of scope but is critically > > important. We can't just punt this. One thought is to have it=20 > > be part of a > > set of "common facilities" that go across all the GIMPS=20 > > applications. I bet > > there are a number of such common things which are not part of the > > transport but aren't specific to a particular signaling appication. > >=20 > > We would like to receive input on this from the WG. Why do=20 > > they think it is > > needed, what are the requirements, ... > >=20 > > 7. Is there any capability for make-before-break so that=20 > > reservations can > > be installed on multiple paths at the same time to deal=20 > with graceful > > mobility? It seems that the notion of flow/session separation=20 > > captures part > > of this, but I don't see how it solves the double-booking=20 > > problems on the > > common links. > >=20 > > We have thought about a possible extensions of the SII object, but > > reservations on future paths conflict with the current NSIS=20 > > charter. With > > the current spec, it is not obvious how this functionality could be > > provided. An extension of the SII would conceivably impact the = GIMPS > > requirements as well. > >=20 > > 8. How does bi-dir reservation enforce symmetric routing? > >=20 > > At present, we imagine that it should not enforce symmetric=20 > > routing but > > make assumptions on one-end being on the path for both=20 > > directions (whether > > it is sender+receiver initiated reserve, or remote initiated = model). > > Binding of both reservation would happen at the end points. > >=20 > > 9. State refresh reduction (a la rfc2961): this is vital. > >=20 > > We agree with the comment. The current draft hints at a=20 > solution with > > RESPONSE message. We will make this explicit in the next version. > >=20 > > 10. Don't like multiple qos models. (Complicated, and can't work.) > >=20 > > The proposal here is to see what the QoS model draft teams=20 > > come up with and > > clarify exactly what is achieved when the QoS model work has=20 > > progressed a > > bit. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Allison Mankin @ietf.org on 16/03/2004 17:41:31 > >=20 > > Sent by: nsis-admin@ietf.org > >=20 > >=20 > > To: john.loughney@nokia.com > > cc: nsis@ietf.org > > Subject: Re: [NSIS] Plans for the protocol drafts > >=20 > >=20 > > Hi, all, > >=20 > > There should be mailing list discussion for each > > protocol draft of the Early Review comments and how they > > will be addressed. > >=20 > > Allison > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Mar 19 06:35:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27242 for ; Fri, 19 Mar 2004 06:35:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4IHL-0001T1-J9 for nsis-archive@odin.ietf.org; Fri, 19 Mar 2004 06:35:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JBZ4OO005590 for nsis-archive@odin.ietf.org; Fri, 19 Mar 2004 06:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4IHH-0001QM-Iq; Fri, 19 Mar 2004 06:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4IGI-0001PB-3h for nsis@optimus.ietf.org; Fri, 19 Mar 2004 06:34:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27205 for ; Fri, 19 Mar 2004 06:33:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4IGD-0006Rn-00 for nsis@ietf.org; Fri, 19 Mar 2004 06:33:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4IFH-0006OU-00 for nsis@ietf.org; Fri, 19 Mar 2004 06:33:02 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1B4IEQ-0006L5-00 for nsis@ietf.org; Fri, 19 Mar 2004 06:32:06 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2JBW8Ah003482 for ; Fri, 19 Mar 2004 12:32:08 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 Mar 2004 12:32:07 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 12:33:49 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: Kappler Cornelia , sven.van_den_bosch@alcatel.be, Allison Mankin Cc: john.loughney@nokia.com, nsis@ietf.org, Georgios Karagiannis , MCDONALD ANDREW Subject: RE: [NSIS] Plans for the protocol drafts Date: Fri, 19 Mar 2004 12:31:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 19 Mar 2004 11:32:07.0723 (UTC) FILETIME=[CF9E27B0:01C40DA5] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Cornelia, =20 >=20 > Hi Attila and all,=20 >=20 > well, in principle the IntServ Controlled-Load Service and=20 > RSVP are independent. However when receiver-ini is specified=20 > in qos-nslp, I'll provide an example in my draft of how to=20 > use it for controlled-load. This would also include a=20 > description of the receiver selecting QoS parameters -=20 > basically bandwidth in this case - based on the "AdSpec" (or=20 > whatever the corresponding object is in NSIS - we'll work on=20 > this when specifying the QSpec) It would be nice. I tried to propose this because in Seoul we agreed that= our application drafts should be focused more on signaling models than Q= oS models. >=20 > Regarding RESERVE /COMMIT may be the right place to put this=20 > is in one of the Common Control Informations since it is=20 > going to be usable (potentially) by all QoS -signaling-=20 > models. I see this as borderline between qos-nslp and qos=20 > signaling models.=20 >=20 I agree=20 Best regards, Attila > [For people familiar with the control info details:=20 > RESERVE/COMMIT could also be located in the QoS signaling=20 > model specific control info, i.e. stackable, however defined=20 > as part of the "tool box", i.e. reusable by several models] >=20 > Cornelia >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com]=20 > > Gesendet: Donnerstag, 18. M=E4rz 2004 14:39 > > An: sven.van_den_bosch@alcatel.be; Allison Mankin > > Cc: john.loughney@nokia.com; nsis@ietf.org; Georgios=20 > > Karagiannis; McDonald, Andrew; Kappler Cornelia > > Betreff: RE: [NSIS] Plans for the protocol drafts > >=20 > >=20 > > Hi All, > >=20 > > Just a short comment: I think, questions 2 and 3 and=20 > > RSVP-like operation example will be discussed in more detail=20 > > in Cornelia's control load draft after specifying=20 > > receiver-initiated reservation in QoS-NSLP. > >=20 > > Best regards, Attila > >=20 > > > -----Original Message----- > > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > > > sven.van_den_bosch@alcatel.be > > > Sent: Thursday, March 18, 2004 10:37 AM > > > To: Allison Mankin > > > Cc: john.loughney@nokia.com; nsis@ietf.org; Georgios Karagiannis; > > > McDonald, Andrew > > > Subject: Re: [NSIS] Plans for the protocol drafts > > >=20 > > >=20 > > > Hi Allison, John, all, > > >=20 > > > We have had a first discussion of the comments among the=20 > > > authors and this > > > is how we see the current status (per comment). > > >=20 > > > Best regards, > > > Sven > > >=20 > > > NSLP comments > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > 1. Need for explicit teardown invoked by the AAA element? > > >=20 > > > I think aspect is already possible. To clarify, we can extend the > > > description of what may trigger the NSLP handler with AAA in=20 > > > addition to > > > e.g. RMF. Teardown by an external element can be handled by a=20 > > > combination > > > of a NOTIFY and a tearing RESERVE. > > >=20 > > > 2. How is receiver selection based on ADSPEC done if=20 > > > resources are reserved > > > in the forward direction with RESERVE? > > >=20 > > > In the current sender-initiated model you can do a=20 > > > QUERY/RESPONSE/RESERVE. > > > This costs 0.5xRTT more than a PATH/RESV. As possible=20 > > > optimization here > > > could be to do a QUERY send the RESERVE and RESPONSE in=20 > > parallel. This > > > would have no impact on the protocol (only intelligence on=20 > > > the receiver > > > side). We will provide an example on receiver-initiated=20 > > > reservation in the > > > next version. > > >=20 > > > 3. some talk about 2-phase operation for RSVP. Any thought of=20 > > > the same for > > > NSLP? > > >=20 > > > We discussed about a RESERVE/COMMIT model in QoS NSLP. At the=20 > > > moment, we > > > feel that this might be solved at the QoS model level which=20 > > > is opaque to > > > QoS NSLP. > > >=20 > > > 4. Didn't see any way to do resource sharing across flows. > > >=20 > > > There is, but maybe not for a general case. Two flows with=20 > > > the same session > > > ID but different flow ID will share resources. This is used=20 > > in special > > > cases of mobility and route changes. GIMPS does have some=20 > > > wildcarding of > > > flow IDs, which would probably get you to the same level=20 > of resource > > > sharing as RSVP (to be checked). > > >=20 > > > 5. Ditto for fate-sharing across flows (if you tear one down=20 > > > you tear the > > > fate-shared ones down) > > >=20 > > > Within QoS NSLP, you could regard this as a policy decision=20 > > > taken by a QNE. > > > However, we could think about a SESSION_FATE_SHARED object=20 > > similar to > > > BOUND_SESSION_IP. Is there any interest in fate sharing=20 > > > between different > > > NSLPs (e.g. qos-nslp/natfw-nslp)? > > >=20 > > > 6. Reservation priority is declared out of scope but is critically > > > important. We can't just punt this. One thought is to have it=20 > > > be part of a > > > set of "common facilities" that go across all the GIMPS=20 > > > applications. I bet > > > there are a number of such common things which are not part of the > > > transport but aren't specific to a particular signaling=20 > appication. > > >=20 > > > We would like to receive input on this from the WG. Why do=20 > > > they think it is > > > needed, what are the requirements, ... > > >=20 > > > 7. Is there any capability for make-before-break so that=20 > > > reservations can > > > be installed on multiple paths at the same time to deal=20 > > with graceful > > > mobility? It seems that the notion of flow/session separation=20 > > > captures part > > > of this, but I don't see how it solves the double-booking=20 > > > problems on the > > > common links. > > >=20 > > > We have thought about a possible extensions of the SII object, but > > > reservations on future paths conflict with the current NSIS=20 > > > charter. With > > > the current spec, it is not obvious how this=20 > functionality could be > > > provided. An extension of the SII would conceivably=20 > impact the GIMPS > > > requirements as well. > > >=20 > > > 8. How does bi-dir reservation enforce symmetric routing? > > >=20 > > > At present, we imagine that it should not enforce symmetric=20 > > > routing but > > > make assumptions on one-end being on the path for both=20 > > > directions (whether > > > it is sender+receiver initiated reserve, or remote=20 > initiated model). > > > Binding of both reservation would happen at the end points. > > >=20 > > > 9. State refresh reduction (a la rfc2961): this is vital. > > >=20 > > > We agree with the comment. The current draft hints at a=20 > > solution with > > > RESPONSE message. We will make this explicit in the next version. > > >=20 > > > 10. Don't like multiple qos models. (Complicated, and can't work.) > > >=20 > > > The proposal here is to see what the QoS model draft teams=20 > > > come up with and > > > clarify exactly what is achieved when the QoS model work has=20 > > > progressed a > > > bit. > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > Allison Mankin @ietf.org on 16/03/2004 17:41:31 > > >=20 > > > Sent by: nsis-admin@ietf.org > > >=20 > > >=20 > > > To: john.loughney@nokia.com > > > cc: nsis@ietf.org > > > Subject: Re: [NSIS] Plans for the protocol drafts > > >=20 > > >=20 > > > Hi, all, > > >=20 > > > There should be mailing list discussion for each > > > protocol draft of the Early Review comments and how they > > > will be addressed. > > >=20 > > > Allison > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 > > This communication is confidential and intended solely for=20 > > the addressee(s). Any unauthorized review, use, disclosure or=20 > > distribution is prohibited. If you believe this message has=20 > > been sent to you in error, please notify the sender by=20 > > replying to this transmission and delete the message without=20 > > disclosing it. Thank you. > >=20 > > E-mail including attachments is susceptible to data=20 > > corruption, interruption, unauthorized amendment, tampering=20 > > and viruses, and we only send and receive e-mails on the=20 > > basis that we are not liable for any such corruption,=20 > > interception, amendment, tampering or viruses or any=20 > > consequences thereof. > >=20 >=20 This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Mar 19 21:41:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07280 for ; Fri, 19 Mar 2004 21:41:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4WQ7-0007SY-5M for nsis-archive@odin.ietf.org; Fri, 19 Mar 2004 21:41:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K2f7Mg028659 for nsis-archive@odin.ietf.org; Fri, 19 Mar 2004 21:41:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4WQ3-0007RW-UJ; Fri, 19 Mar 2004 21:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4WPd-0007Os-Ey for nsis@optimus.ietf.org; Fri, 19 Mar 2004 21:40:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07242 for ; Fri, 19 Mar 2004 21:40:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4WPa-0002WE-00 for nsis@ietf.org; Fri, 19 Mar 2004 21:40:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4WOd-0002Qo-00 for nsis@ietf.org; Fri, 19 Mar 2004 21:39:35 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1B4WO6-0002M5-00 for nsis@ietf.org; Fri, 19 Mar 2004 21:39:03 -0500 Received: from bear.cs.columbia.edu (IDENT:DNmbV+AMlbG1mgExaxwT6RzCXFUib+Fx@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i2K2d3RI005329 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 19 Mar 2004 21:39:03 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-96-135.mad.east.verizon.net [138.89.96.135]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i2K2d1Xe002396 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Mar 2004 21:39:02 -0500 Message-ID: <405BAEC8.9090904@cs.columbia.edu> Date: Fri, 19 Mar 2004 21:39:04 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: "Hancock, Robert" CC: "Nsis (E-mail)" Subject: Re: [NSIS] Message Looping in GIMPS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > what is currently unstated is how the IP TTL is handled in 'forwarded' > discovery messages. if it is decremented just as if the packet > were being forwarded at the IP layer, this will also sort out > loops as you say. Since these are regular IP packets, I think it would be a seriously broken router that did not decrement the IP TTL for these. The path and thus the times-around-the-loop may obviously be different even if the two types of packets share parts of the path (diverge and merge). > it was partly the question of how GIMPS would know how to distinguish > a loop from a spiral which made me cautious here. i agree that SIP-like > spiralling seems less likely (but maybe that's just because we haven't > thought of all the signalling applications yet...) Spiraling occurs, in general, if the destination address can be changed. In SIP, that is the request-URI. In GIMPS, this seems a stretch, but if you define a loop as visiting the same place twice, it's at least theoretically possible: (1) A sends packet to B, via the border router R(B) (2) B changes destination address to C, which (3) causes the packet to visit the border router again Thus, the packet visits the same *node* twice, but it's not really a loop. As far as I can tell, such 'hairpinning' can only occur if the destination address can be modified. The solution is simple: record both the place visited and the address. A loop requires a duplication of both. That said, I'm at a loss to conjure up an example where such destination address changes have any value. (In SIP, they do, since name translation is a core protocol function.) Trying hard, maybe a visit from a CH to a HA to the FA would cause such hairpinning. > > why would one want to record every NTLP hop? this sounds to me more > like a signalling application ("clever traceroute") in its own right. Debugging. We can indeed define this as an application, but to be useful, every NTLP node would always have to support it. In general, I think it is very useful to be able to tell at the edges where a packet or message has been. It makes it much easier to see why things happen, particularly for places that you can't really 'touch' easily. Again based on SIP experience, both trace and source routing have proven to be extremely valuable. Indeed, the only complaint has been that we should have included more of it earlier. I think it would be a mistake not to have this capability. It's hard to add later, since its value is mainly that everybody implements it. > > this is really a question of what people want (and don't want). > my reasoning is: > - everyone would like to keep the NTLP simple (i.e. not put in extra > functions) > - route recording could get complicated to specify and implement I don't think so. It's very simple - add an address record. > - route recording seems to have minimal or no interactions with > other NTLP functions (so it would be easy to add later) No - see above. > > I think a possible approach would be to wait for someone to write > a proposal for a route recording object and a set of processing rules. > then we could see how it fit into the current GIMPS design, and also > how it matched the requirements of different signalling applications. > in the meantime, not thinking about it doesn't seem to be too risky > a path to take. I disagree for the reasons stated above. I think the general experience with Internet protocols is that having debug functions from the get-go makes implementations more robust and more deployable. Kludging things later (as in traceroute, since the original IP mechanism is broken) tends to yield suboptimal solutions. (Details about why traceroute has problems available on request.) > > r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Mar 20 04:27:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03307 for ; Sat, 20 Mar 2004 04:27:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4cl0-00009r-7H for nsis-archive@odin.ietf.org; Sat, 20 Mar 2004 04:27:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K9R6kh000592 for nsis-archive@odin.ietf.org; Sat, 20 Mar 2004 04:27:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ckv-000096-BL; Sat, 20 Mar 2004 04:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4cki-00008j-Fz for nsis@optimus.ietf.org; Sat, 20 Mar 2004 04:26:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03303 for ; Sat, 20 Mar 2004 04:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4ckf-0003wA-00 for nsis@ietf.org; Sat, 20 Mar 2004 04:26:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4cjg-0003qf-00 for nsis@ietf.org; Sat, 20 Mar 2004 04:25:45 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1B4cjB-0003eo-00 for nsis@ietf.org; Sat, 20 Mar 2004 04:25:13 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMRNSB>; Sat, 20 Mar 2004 09:24:33 -0000 Message-ID: From: "Hancock, Robert" To: "'Henning Schulzrinne '" Cc: "'Nsis (E-mail) '" Subject: RE: [NSIS] Message Looping in GIMPS Date: Sat, 20 Mar 2004 09:24:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , ok - we should distinguish between *) easy to add later - doesn't change the rest of the protocol processing rules *) hard to add later - it's mainly useful when a high percentage of the nodes implement it but a lot have been deployed without it i think the route recording function matches both these. i agree with the debugging aspect being important, and important from the start (i don't believe the qos-nslp needs that have been mentioned actually need route recording themselves, i write something about that later). i'd be very happy to see someone define a 'diagnostics NSLP' which could even become a MUST/SHOULD to implement along with GIMPS (apart from anything else, it would give us a non-trivial NSLP to play with). there are probably other diagnostic functions that are also needed (some sort of e2e echo, for example). r. -----Original Message----- From: Henning Schulzrinne To: Hancock, Robert Cc: Nsis (E-mail) Sent: 20/03/2004 02:39 Subject: Re: [NSIS] Message Looping in GIMPS > what is currently unstated is how the IP TTL is handled in 'forwarded' > discovery messages. if it is decremented just as if the packet > were being forwarded at the IP layer, this will also sort out > loops as you say. Since these are regular IP packets, I think it would be a seriously broken router that did not decrement the IP TTL for these. The path and thus the times-around-the-loop may obviously be different even if the two types of packets share parts of the path (diverge and merge). > it was partly the question of how GIMPS would know how to distinguish > a loop from a spiral which made me cautious here. i agree that SIP-like > spiralling seems less likely (but maybe that's just because we haven't > thought of all the signalling applications yet...) Spiraling occurs, in general, if the destination address can be changed. In SIP, that is the request-URI. In GIMPS, this seems a stretch, but if you define a loop as visiting the same place twice, it's at least theoretically possible: (1) A sends packet to B, via the border router R(B) (2) B changes destination address to C, which (3) causes the packet to visit the border router again Thus, the packet visits the same *node* twice, but it's not really a loop. As far as I can tell, such 'hairpinning' can only occur if the destination address can be modified. The solution is simple: record both the place visited and the address. A loop requires a duplication of both. That said, I'm at a loss to conjure up an example where such destination address changes have any value. (In SIP, they do, since name translation is a core protocol function.) Trying hard, maybe a visit from a CH to a HA to the FA would cause such hairpinning. > > why would one want to record every NTLP hop? this sounds to me more > like a signalling application ("clever traceroute") in its own right. Debugging. We can indeed define this as an application, but to be useful, every NTLP node would always have to support it. In general, I think it is very useful to be able to tell at the edges where a packet or message has been. It makes it much easier to see why things happen, particularly for places that you can't really 'touch' easily. Again based on SIP experience, both trace and source routing have proven to be extremely valuable. Indeed, the only complaint has been that we should have included more of it earlier. I think it would be a mistake not to have this capability. It's hard to add later, since its value is mainly that everybody implements it. > > this is really a question of what people want (and don't want). > my reasoning is: > - everyone would like to keep the NTLP simple (i.e. not put in extra > functions) > - route recording could get complicated to specify and implement I don't think so. It's very simple - add an address record. > - route recording seems to have minimal or no interactions with > other NTLP functions (so it would be easy to add later) No - see above. > > I think a possible approach would be to wait for someone to write > a proposal for a route recording object and a set of processing rules. > then we could see how it fit into the current GIMPS design, and also > how it matched the requirements of different signalling applications. > in the meantime, not thinking about it doesn't seem to be too risky > a path to take. I disagree for the reasons stated above. I think the general experience with Internet protocols is that having debug functions from the get-go makes implementations more robust and more deployable. Kludging things later (as in traceroute, since the original IP mechanism is broken) tends to yield suboptimal solutions. (Details about why traceroute has problems available on request.) > > r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Mar 20 04:45:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03759 for ; Sat, 20 Mar 2004 04:45:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4d2V-0001f6-Hz for nsis-archive@odin.ietf.org; Sat, 20 Mar 2004 04:45:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K9jBDF006351 for nsis-archive@odin.ietf.org; Sat, 20 Mar 2004 04:45:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4d2N-0001eD-QK; Sat, 20 Mar 2004 04:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4d29-0001dn-3W for nsis@optimus.ietf.org; Sat, 20 Mar 2004 04:44:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03745 for ; Sat, 20 Mar 2004 04:44:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4d26-0005fH-00 for nsis@ietf.org; Sat, 20 Mar 2004 04:44:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4d18-0005aN-00 for nsis@ietf.org; Sat, 20 Mar 2004 04:43:46 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1B4d0z-0005VS-00 for nsis@ietf.org; Sat, 20 Mar 2004 04:43:37 -0500 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Sat, 20 Mar 2004 10:43:35 +0100 Message-ID: <405C123C.4010501@cs.uni-goettingen.de> Date: Sat, 20 Mar 2004 10:43:24 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: "'Henning Schulzrinne '" , "'Nsis (E-mail) '" Subject: Re: [NSIS] Message Looping in GIMPS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Hancock, Robert wrote: > ok - we should distinguish between > > *) easy to add later - doesn't change the rest of the protocol > processing rules > > *) hard to add later - it's mainly useful when a high percentage of > the nodes implement it but a lot have been deployed without it > > i think the route recording function matches both these. i agree > with the debugging aspect being important, and important from the > start (i don't believe the qos-nslp needs that have been mentioned > actually need route recording themselves, i write something about that > later). > > i'd be very happy to see someone define a 'diagnostics NSLP' > which could even become a MUST/SHOULD to implement along > with GIMPS (apart from anything else, it would give us a > non-trivial NSLP to play with). there are probably other > diagnostic functions that are also needed (some sort of e2e > echo, for example). Earlier we had an attempt with a simple "traceroute", described in http://user.informatik.uni-goettingen.de/~fu/paper/draft-fu-ccamp-traceroute-00.txt http://user.informatik.uni-goettingen.de/~fu/paper/IETF-fu-ccamp-traceroute.pdf (presentation slides at IETF#57 - CCAMP WG) We are currently prototyping it. If interested we would be glad to work with the team and extend it towards diagnostics NSLP. Regards, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 23 21:29:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20555 for ; Tue, 23 Mar 2004 21:29:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5y8d-0004OM-Qy for nsis-archive@odin.ietf.org; Tue, 23 Mar 2004 21:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O2T3V6016862 for nsis-archive@odin.ietf.org; Tue, 23 Mar 2004 21:29:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5y8b-0004Mp-CH; Tue, 23 Mar 2004 21:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5y8M-0004MS-57 for nsis@optimus.ietf.org; Tue, 23 Mar 2004 21:28:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20545 for ; Tue, 23 Mar 2004 21:28:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5y8J-0002TX-00 for nsis@ietf.org; Tue, 23 Mar 2004 21:28:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5y7i-0002Pv-00 for nsis@ietf.org; Tue, 23 Mar 2004 21:28:07 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1B5y71-0002Bq-00 for nsis@ietf.org; Tue, 23 Mar 2004 21:27:23 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i2O2I6u3026390; Wed, 24 Mar 2004 10:18:13 +0800 (SGT) From: "Cheng Hong" To: Cc: , , "'Georgios Karagiannis'" , "'McDonald, Andrew'" , "'Allison Mankin'" Subject: RE: [NSIS] Plans for the protocol drafts Date: Wed, 24 Mar 2004 10:26:19 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <008901c41147$66757360$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Sven,=20 Please see some comments below inline. Best regards Cheng Hong >=20 > NSLP comments > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1. Need for explicit teardown invoked by the AAA element? >=20 > I think aspect is already possible. To clarify, we can extend=20 > the description of what may trigger the NSLP handler with AAA=20 > in addition to e.g. RMF. Teardown by an external element can=20 > be handled by a combination of a NOTIFY and a tearing RESERVE. I think the teardown decision has to be made with more than a single=20 information source. The AAA element could trigger the teardown, but = other=20 issues also need to be considered. As what we discussed in the mailing=20 list, to support the multi-homing, indication from the end node should = also be considered in decision making. > 3. some talk about 2-phase operation for RSVP. Any thought of=20 > the same for NSLP? >=20 > We discussed about a RESERVE/COMMIT model in QoS NSLP. At the=20 > moment, we feel that this might be solved at the QoS model=20 > level which is opaque to QoS NSLP. This may not be opaque to QoS NSLP.With this RESERVE/COMMIT model,=20 QoS NSLP should include messages that could do the roll-back action.=20 > 4. Didn't see any way to do resource sharing across flows. >=20 > There is, but maybe not for a general case. Two flows with=20 > the same session ID but different flow ID will share=20 > resources. This is used in special cases of mobility and=20 > route changes. GIMPS does have some wildcarding of flow IDs,=20 > which would probably get you to the same level of resource=20 > sharing as RSVP (to be checked). The resource sharing is only meaningful inside each individual NSLP. Therefore, the GIMPS may not be able to provide the necessary function unless it is mandated that the session-ID would be unique across all the NSLPs.=20 =20 > 6. Reservation priority is declared out of scope but is=20 > critically important. We can't just punt this. One thought is=20 > to have it be part of a set of "common facilities" that go=20 > across all the GIMPS applications. I bet there are a number=20 > of such common things which are not part of the transport but=20 > aren't specific to a particular signaling appication. >=20 > We would like to receive input on this from the WG. Why do=20 > they think it is needed, what are the requirements, ... This could be useful if we want to differentiate the flows, and assign different priority for different flows. In that case, reservation for the corresponding flows could also be assigned with priority. > 7. Is there any capability for make-before-break so that=20 > reservations can be installed on multiple paths at the same=20 > time to deal with graceful mobility? It seems that the notion=20 > of flow/session separation captures part of this, but I don't=20 > see how it solves the double-booking problems on the common links. >=20 > We have thought about a possible extensions of the SII=20 > object, but reservations on future paths conflict with the=20 > current NSIS charter. With the current spec, it is not=20 > obvious how this functionality could be provided. An=20 > extension of the SII would conceivably impact the GIMPS=20 > requirements as well. Similar to the first question, it also relates to the decision of the = tear down. In this make-before-break case, the reservation over the old path should = not be torn down before the handover finished. Therefore, a method has to be incorporated into the signaling for that.=20 As what we discussed earlier, a notification from the MN could be useful = for that.=20 > 8. How does bi-dir reservation enforce symmetric routing? >=20 > At present, we imagine that it should not enforce symmetric=20 > routing but make assumptions on one-end being on the path for=20 > both directions (whether it is sender+receiver initiated=20 > reserve, or remote initiated model). Binding of both=20 > reservation would happen at the end points. Does this imply that at least one end of the flow would be the QoS NSLP node? > 9. State refresh reduction (a la rfc2961): this is vital. >=20 > We agree with the comment. The current draft hints at a=20 > solution with RESPONSE message. We will make this explicit in=20 > the next version. >=20 > 10. Don't like multiple qos models. (Complicated, and can't work.) >=20 > The proposal here is to see what the QoS model draft teams=20 > come up with and clarify exactly what is achieved when the=20 > QoS model work has progressed a bit. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Mar 24 03:09:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03383 for ; Wed, 24 Mar 2004 03:09:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B63Rj-0004RP-Ih for nsis-archive@odin.ietf.org; Wed, 24 Mar 2004 03:09:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O8972S017067 for nsis-archive@odin.ietf.org; Wed, 24 Mar 2004 03:09:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B63Rg-0004QU-O1; Wed, 24 Mar 2004 03:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B63Of-0003td-BO for nsis@optimus.ietf.org; Wed, 24 Mar 2004 03:05:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03186 for ; Wed, 24 Mar 2004 03:05:54 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B63Ob-0003uh-00 for nsis@ietf.org; Wed, 24 Mar 2004 03:05:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B63Nd-0003eZ-00 for nsis@ietf.org; Wed, 24 Mar 2004 03:04:54 -0500 Received: from gc-na165.alcatel.fr ([64.208.49.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1B63Mh-0003Tj-00 for nsis@ietf.org; Wed, 24 Mar 2004 03:03:55 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i2O83sIe009022; Wed, 24 Mar 2004 09:03:54 +0100 Subject: RE: [NSIS] Plans for the protocol drafts To: "Cheng Hong" Cc: , , "'Georgios Karagiannis'" , "'McDonald, Andrew'" , "'Allison Mankin'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 24 Mar 2004 09:03:52 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/24/2004 09:03:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, Thanks for your comments. I have a few reactions inline. Best regards, Sven "Cheng Hong" on 24/03/2004 03:26:19 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: , , "'Georgios Karagiannis'" , "'McDonald, Andrew'" , "'Allison Mankin'" Subject: RE: [NSIS] Plans for the protocol drafts Hi Sven, Please see some comments below inline. Best regards Cheng Hong > > NSLP comments > ============= > > 1. Need for explicit teardown invoked by the AAA element? > > I think aspect is already possible. To clarify, we can extend > the description of what may trigger the NSLP handler with AAA > in addition to e.g. RMF. Teardown by an external element can > be handled by a combination of a NOTIFY and a tearing RESERVE. I think the teardown decision has to be made with more than a single information source. The AAA element could trigger the teardown, but other issues also need to be considered. As what we discussed in the mailing list, to support the multi-homing, indication from the end node should also be considered in decision making. Sven>> This is related to our earlier discussion on indication to teardown/retain reservation state by an end node. It is a related but slightly different issue than what was requested during the review: explicit teardown invoked by AAA element, which is possible. To support the end node indication we need to add a flag, as we discussed/agreed before. > 3. some talk about 2-phase operation for RSVP. Any thought of > the same for NSLP? > > We discussed about a RESERVE/COMMIT model in QoS NSLP. At the > moment, we feel that this might be solved at the QoS model > level which is opaque to QoS NSLP. This may not be opaque to QoS NSLP.With this RESERVE/COMMIT model, QoS NSLP should include messages that could do the roll-back action. Sven>> Can you clarify what the impact on QoS NSLP would be? I would imagine the signalling to look exactly the same from QoS NSLP perspective with an additional indication to commit resources. It seems that this difference mainly makes sense for the Resource Management Function (RMF), which does not participate in QoS NSLP processing anyway. > 4. Didn't see any way to do resource sharing across flows. > > There is, but maybe not for a general case. Two flows with > the same session ID but different flow ID will share > resources. This is used in special cases of mobility and > route changes. GIMPS does have some wildcarding of flow IDs, > which would probably get you to the same level of resource > sharing as RSVP (to be checked). The resource sharing is only meaningful inside each individual NSLP. Therefore, the GIMPS may not be able to provide the necessary function unless it is mandated that the session-ID would be unique across all the NSLPs. Sven>> Since the session ID is a large random identifier, why would it be "less unique" across NSLPs than within one NSLP? > 6. Reservation priority is declared out of scope but is > critically important. We can't just punt this. One thought is > to have it be part of a set of "common facilities" that go > across all the GIMPS applications. I bet there are a number > of such common things which are not part of the transport but > aren't specific to a particular signaling appication. > > We would like to receive input on this from the WG. Why do > they think it is needed, what are the requirements, ... This could be useful if we want to differentiate the flows, and assign different priority for different flows. In that case, reservation for the corresponding flows could also be assigned with priority. Sven>> OK. Do you see it as part of the QoS NSLP or as part of the QoS model (opaque to QoS NSLP, handled by RMF)? > 7. Is there any capability for make-before-break so that > reservations can be installed on multiple paths at the same > time to deal with graceful mobility? It seems that the notion > of flow/session separation captures part of this, but I don't > see how it solves the double-booking problems on the common links. > > We have thought about a possible extensions of the SII > object, but reservations on future paths conflict with the > current NSIS charter. With the current spec, it is not > obvious how this functionality could be provided. An > extension of the SII would conceivably impact the GIMPS > requirements as well. Similar to the first question, it also relates to the decision of the tear down. In this make-before-break case, the reservation over the old path should not be torn down before the handover finished. Therefore, a method has to be incorporated into the signaling for that. As what we discussed earlier, a notification from the MN could be useful for that. Sven>> Agreed. See my earlier response. > 8. How does bi-dir reservation enforce symmetric routing? > > At present, we imagine that it should not enforce symmetric > routing but make assumptions on one-end being on the path for > both directions (whether it is sender+receiver initiated > reserve, or remote initiated model). Binding of both > reservation would happen at the end points. Does this imply that at least one end of the flow would be the QoS NSLP node? Sven>> Do you want to support bi-directional reservation for cases where the first QoS NSLP node on the path is different for the forward and reverse direction? Bi-directional reservation is mainly an optimization. Wouldn't you rather leave these "strange" cases unoptimized? > 9. State refresh reduction (a la rfc2961): this is vital. > > We agree with the comment. The current draft hints at a > solution with RESPONSE message. We will make this explicit in > the next version. > > 10. Don't like multiple qos models. (Complicated, and can't work.) > > The proposal here is to see what the QoS model draft teams > come up with and clarify exactly what is achieved when the > QoS model work has progressed a bit. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Mar 24 10:30:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29188 for ; Wed, 24 Mar 2004 10:30:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6AKQ-0004ah-Pt for nsis-archive@odin.ietf.org; Wed, 24 Mar 2004 10:30:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OFU26Z017642 for nsis-archive@odin.ietf.org; Wed, 24 Mar 2004 10:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6AKP-0004Zz-BX; Wed, 24 Mar 2004 10:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6AJv-0004XP-Sr for nsis@optimus.ietf.org; Wed, 24 Mar 2004 10:29:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28821 for ; Wed, 24 Mar 2004 10:29:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6AJt-0001wb-00 for nsis@ietf.org; Wed, 24 Mar 2004 10:29:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6AAA-0007JC-00 for nsis@ietf.org; Wed, 24 Mar 2004 10:19:27 -0500 Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1B6A8Q-0005t6-00 for nsis@ietf.org; Wed, 24 Mar 2004 10:17:39 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i2OF3wYL015974 for ; Wed, 24 Mar 2004 10:17:08 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 405DCB7600180552; Wed, 24 Mar 2004 10:16:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Plans for the protocol drafts Date: Wed, 24 Mar 2004 09:17:07 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA3A2C@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] Plans for the protocol drafts Thread-Index: AcQMzOH0UC181rXaR5qfyoPhtibwbAE2DIGg From: "Ash, Gerald R (Jerry), ALABS" To: , Cc: "Ash, Gerald R (Jerry), ALABS" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Sven, Dave> 6. Reservation priority is declared out of scope Dave> but is critically important. We can't just punt Dave> this. One thought is to have it be part of a set Dave> of "common facilities" that go across all the Dave> GIMPS applications. I bet there are a number of Dave> such common things which are not part of the Dave> transport but aren't specific to a particular Dave> signaling application. Sven> We would like to receive input on this from the Sven> WG. Why do they think it is needed, what are the Sven> requirements, ... I agree with Dave that 'reservation priority' is critically important to = add. IMO there should be a requirement for reservation priority (i.e., = for emergency services/ETS/E911, etc.) for the NSLP QoS signaling. The = 'standard Qspec' being worked now by the QoS model draft teams can be = the vehicle to introduce this. As requested by John (and the WG), we = will work out a common Qspec across models, and maximize commonality. To maximize commonality, I think it preferable to make reservation = priority a part of the common QoS NSLP rather than part of the = individual QoS model (opaque to QoS NSLP). =20 As discussed in 'NSIS Network Service Layer Protocol QoS Signaling = Proof-of-Concept' = http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-= concept-01.txt, reservation priority is a way to differentiate emergency = services flows, and assign them a higher priority than normal or = best-effort priority flows. Requirements for reservation priority are = suggested in Section B.4 'Support of Priority & Reliability Attributes': a. Reliability can be requested in the form of a Priority Class for a = specific network function, such as CAC priority. b. There are a limited number of Priority Classes to ensure scalability = (e.g., 3 classes), such as: - CAC Priority Class: The urgency with which a service connection is = desired (e.g., High, Normal, Best Effort). - Restoration Priority Class: The urgency with which a service requires = successful restoration under failure conditions (e.g., High, Normal, = Best Effort). Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Mar 25 21:05:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08851 for ; Thu, 25 Mar 2004 21:05:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6giV-0007n2-DS for nsis-archive@odin.ietf.org; Thu, 25 Mar 2004 21:05:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q253H2029923 for nsis-archive@odin.ietf.org; Thu, 25 Mar 2004 21:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6giT-0007mB-Fb; Thu, 25 Mar 2004 21:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6giF-0007lY-DW for nsis@optimus.ietf.org; Thu, 25 Mar 2004 21:04:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08845 for ; Thu, 25 Mar 2004 21:04:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6giC-0006cN-00 for nsis@ietf.org; Thu, 25 Mar 2004 21:04:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ghI-0006Yf-00 for nsis@ietf.org; Thu, 25 Mar 2004 21:03:49 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1B6ggZ-0006QU-00 for nsis@ietf.org; Thu, 25 Mar 2004 21:03:03 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i2Q1raaP016598; Fri, 26 Mar 2004 09:53:46 +0800 (SGT) From: "Cheng Hong" To: Cc: , , "'Georgios Karagiannis'" , "'McDonald, Andrew'" , "'Allison Mankin'" Subject: RE: [NSIS] Plans for the protocol drafts Date: Fri, 26 Mar 2004 10:01:51 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <00bc01c412d6$52208220$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Sven, Thanks for your reply. Please see some further comments below: >=20 > This may not be opaque to QoS NSLP.With this RESERVE/COMMIT=20 > model, QoS NSLP should include messages that could do the=20 > roll-back action. >=20 > Sven>> Can you clarify what the impact on QoS NSLP would be? I would > imagine the signalling to look exactly the same from QoS NSLP=20 > perspective with an additional indication to commit=20 > resources. It seems that this difference mainly makes sense=20 > for the Resource Management Function (RMF), which does not=20 > participate in QoS NSLP processing anyway. I think this depends on whether we want to make the QoS NSLP support RESERVE/COMMIT or letting individual QoS Model to support that. If the = QoS NSLP needs to support it, some information element, e.g. a flag and corresponding RSN, should be included in the common header of QoS NSLP messages.=20 If the QoS Model is left to deal with it, the above information could be placed into QSPEC. Then, the QSPEC should contain an object defined for = this purpose.=20 > The resource sharing is only meaningful inside each=20 > individual NSLP. Therefore, the GIMPS may not be able to=20 > provide the necessary function unless it is mandated that the=20 > session-ID would be unique across all the NSLPs. >=20 > Sven>> Since the session ID is a large random identifier, why=20 > would it=20 > Sven>> be > "less unique" across NSLPs than within one NSLP? Statistically, it would not be very much "less unique". But since this feature we want to introduce here depends on the uniqueness of the ID, = it should be made explicit. Maybe some guideline should be given in = framework stating that different NSLP should use different session-ID. Otherwise, = in implementation, a node could conveniently reuse the same session-ID for different NSLP applications since nothing forbids that.=20 > This could be useful if we want to differentiate the flows,=20 > and assign different priority for different flows. In that=20 > case, reservation for the corresponding flows could also be=20 > assigned with priority. >=20 > Sven>> OK. Do you see it as part of the QoS NSLP or as part of the QoS > model (opaque to QoS NSLP, handled by RMF)? It depends on how the priority would be used. Does it have meaning = across the QoS Models? Will there be multiple QoS Model at each node shareing = the same RMF? My feeling is that make it part of QoS NSLP may be better or = it could be a mandated part of QSPEC.=20 > Does this imply that at least one end of the flow would be=20 > the QoS NSLP node? >=20 > Sven>> Do you want to support bi-directional reservation for=20 > cases where > the first QoS NSLP node on the path is different for the=20 > forward and reverse direction? Bi-directional reservation is=20 > mainly an optimization. Wouldn't you rather leave these=20 > "strange" cases unoptimized? Agree. This doesn't have to be the focus at this stage. But should we = state clearly that this case is for future development? best regards Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Mar 26 07:12:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15636 for ; Fri, 26 Mar 2004 07:12:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6qBr-0008AN-Oz for nsis-archive@odin.ietf.org; Fri, 26 Mar 2004 07:12:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QCBxTC031376 for nsis-archive@odin.ietf.org; Fri, 26 Mar 2004 07:11:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6qBq-00089m-MO; Fri, 26 Mar 2004 07:11:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6qAx-00081K-23 for nsis@optimus.ietf.org; Fri, 26 Mar 2004 07:11:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15527 for ; Fri, 26 Mar 2004 07:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6qAs-0002IG-00 for nsis@ietf.org; Fri, 26 Mar 2004 07:10:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6q9z-0002Cf-00 for nsis@ietf.org; Fri, 26 Mar 2004 07:10:04 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1B6q9A-000272-00 for nsis@ietf.org; Fri, 26 Mar 2004 07:09:12 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i2QC94v29994; Fri, 26 Mar 2004 13:09:04 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i2QC92T07904; Fri, 26 Mar 2004 13:09:03 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 26 Mar 2004 13:08:16 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685EF8@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Cheng Hong'" , sven.van_den_bosch@alcatel.be Cc: john.loughney@nokia.com, nsis@ietf.org, "'Georgios Karagiannis'" , "'McDonald, Andrew'" , "'Allison Mankin'" Subject: RE: [NSIS] Plans for the protocol drafts Date: Fri, 26 Mar 2004 13:08:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi cheng, you find a small comment inline: > -----Original Message----- > From: Cheng Hong [mailto:hcheng@psl.com.sg] > Sent: Friday, March 26, 2004 3:02 AM > To: sven.van_den_bosch@alcatel.be > Cc: john.loughney@nokia.com; nsis@ietf.org; 'Georgios Karagiannis'; > 'McDonald, Andrew'; 'Allison Mankin' > Subject: RE: [NSIS] Plans for the protocol drafts > > > Hi Sven, > > Thanks for your reply. Please see some further comments below: > > > > > > This may not be opaque to QoS NSLP.With this RESERVE/COMMIT > > model, QoS NSLP should include messages that could do the > > roll-back action. > > > > Sven>> Can you clarify what the impact on QoS NSLP would be? I would > > imagine the signalling to look exactly the same from QoS NSLP > > perspective with an additional indication to commit > > resources. It seems that this difference mainly makes sense > > for the Resource Management Function (RMF), which does not > > participate in QoS NSLP processing anyway. > > I think this depends on whether we want to make the QoS NSLP support > RESERVE/COMMIT or letting individual QoS Model to support > that. If the QoS > NSLP needs to support it, some information element, e.g. a flag and > corresponding RSN, should be included in the common header of QoS NSLP > messages. > > If the QoS Model is left to deal with it, the above > information could be > placed into QSPEC. Then, the QSPEC should contain an object > defined for this > purpose. > > > > > > The resource sharing is only meaningful inside each > > individual NSLP. Therefore, the GIMPS may not be able to > > provide the necessary function unless it is mandated that the > > session-ID would be unique across all the NSLPs. > > > > Sven>> Since the session ID is a large random identifier, why > > would it > > Sven>> be > > "less unique" across NSLPs than within one NSLP? > > Statistically, it would not be very much "less unique". But since this > feature we want to introduce here depends on the uniqueness > of the ID, it > should be made explicit. Maybe some guideline should be given > in framework > stating that different NSLP should use different session-ID. > Otherwise, in > implementation, a node could conveniently reuse the same > session-ID for > different NSLP applications since nothing forbids that. i tried to address issues of the session id construction for a long time. unfortunately, i haven't received too many comments yet. a discussion of the importance of a security property called sender invariance can be found in the current mobility id and also in separate draft: http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-sid-00.txt your comments are highly appreciated. ciao hannes > > > > > This could be useful if we want to differentiate the flows, > > and assign different priority for different flows. In that > > case, reservation for the corresponding flows could also be > > assigned with priority. > > > > Sven>> OK. Do you see it as part of the QoS NSLP or as part > of the QoS > > model (opaque to QoS NSLP, handled by RMF)? > > It depends on how the priority would be used. Does it have > meaning across > the QoS Models? Will there be multiple QoS Model at each node > shareing the > same RMF? My feeling is that make it part of QoS NSLP may be > better or it > could be a mandated part of QSPEC. > > > > > > Does this imply that at least one end of the flow would be > > the QoS NSLP node? > > > > Sven>> Do you want to support bi-directional reservation for > > cases where > > the first QoS NSLP node on the path is different for the > > forward and reverse direction? Bi-directional reservation is > > mainly an optimization. Wouldn't you rather leave these > > "strange" cases unoptimized? > > Agree. This doesn't have to be the focus at this stage. But > should we state > clearly that this case is for future development? > > best regards > > Cheng Hong > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Mar 26 09:45:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22188 for ; Fri, 26 Mar 2004 09:45:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6sZz-0001wb-LQ for nsis-archive@odin.ietf.org; Fri, 26 Mar 2004 09:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QEj3wa007467 for nsis-archive@odin.ietf.org; Fri, 26 Mar 2004 09:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6sZx-0001wH-LL; Fri, 26 Mar 2004 09:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6sZA-0001v3-Ru for nsis@optimus.ietf.org; Fri, 26 Mar 2004 09:44:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22161 for ; Fri, 26 Mar 2004 09:44:09 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6sZ8-0002AV-00 for nsis@ietf.org; Fri, 26 Mar 2004 09:44:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6sYF-00028S-00 for nsis@ietf.org; Fri, 26 Mar 2004 09:43:15 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1B6sXf-00026c-00 for nsis@ietf.org; Fri, 26 Mar 2004 09:42:39 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i2QEgaIe028687; Fri, 26 Mar 2004 15:42:36 +0100 Subject: RE: [NSIS] Plans for the protocol drafts To: "Ash, Gerald R (Jerry), ALABS" Cc: , "Ash, Gerald R (Jerry), ALABS" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 26 Mar 2004 15:42:22 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/26/2004 15:42:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Jerry, Sorry for the delayed reply. Please find some comments inline. Best regards, Sven "Ash, Gerald R (Jerry), ALABS" on 24/03/2004 16:17:07 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, cc: "Ash, Gerald R (Jerry), ALABS" Subject: RE: [NSIS] Plans for the protocol drafts Hi Sven, Dave> 6. Reservation priority is declared out of scope Dave> but is critically important. We can't just punt Dave> this. One thought is to have it be part of a set Dave> of "common facilities" that go across all the Dave> GIMPS applications. I bet there are a number of Dave> such common things which are not part of the Dave> transport but aren't specific to a particular Dave> signaling application. Sven> We would like to receive input on this from the Sven> WG. Why do they think it is needed, what are the Sven> requirements, ... I agree with Dave that 'reservation priority' is critically important to add. IMO there should be a requirement for reservation priority (i.e., for emergency services/ETS/E911, etc.) for the NSLP QoS signaling. The 'standard Qspec' being worked now by the QoS model draft teams can be the vehicle to introduce this. As requested by John (and the WG), we will work out a common Qspec across models, and maximize commonality. To maximize commonality, I think it preferable to make reservation priority a part of the common QoS NSLP rather than part of the individual QoS model (opaque to QoS NSLP). As discussed in 'NSIS Network Service Layer Protocol QoS Signaling Proof-of-Concept' http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt , reservation priority is a way to differentiate emergency services flows, and assign them a higher priority than normal or best-effort priority flows. Requirements for reservation priority are suggested in Section B.4 'Support of Priority & Reliability Attributes': a. Reliability can be requested in the form of a Priority Class for a specific network function, such as CAC priority. b. There are a limited number of Priority Classes to ensure scalability (e.g., 3 classes), such as: - CAC Priority Class: The urgency with which a service connection is desired (e.g., High, Normal, Best Effort). - Restoration Priority Class: The urgency with which a service requires successful restoration under failure conditions (e.g., High, Normal, Best Effort). Sven>> I agree with you that reservation priority is needed and I believe that the proposals that you mention are probably a good way of implementing it if you want to support it. What I am not sure about is whether it should be part of the QoS NSLP. Even if it is common to multiple QoS models, it still would only affect the Resource Management Function (RMF) (unlike the message priority) which makes it outside of the QoS NSLP scope in my opinion. Anyway, I think it is good that the concept and the potential solution matures in the QoS model draft team. We can decide when we see what it turned out to be whether we still want to put it in the QoS NSLP spec. Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Mar 26 09:51:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22450 for ; Fri, 26 Mar 2004 09:51:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6sfn-0002Jo-Ql for nsis-archive@odin.ietf.org; Fri, 26 Mar 2004 09:51:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QEp3Wh008909 for nsis-archive@odin.ietf.org; Fri, 26 Mar 2004 09:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6sfm-0002J2-IF; Fri, 26 Mar 2004 09:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ser-0002G0-2k for nsis@optimus.ietf.org; Fri, 26 Mar 2004 09:50:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22372 for ; Fri, 26 Mar 2004 09:50:02 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6sep-0002UB-00 for nsis@ietf.org; Fri, 26 Mar 2004 09:50:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6sdu-0002SG-00 for nsis@ietf.org; Fri, 26 Mar 2004 09:49:06 -0500 Received: from gc-na165.alcatel.fr ([64.208.49.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1B6sd6-0002QE-00 for nsis@ietf.org; Fri, 26 Mar 2004 09:48:16 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i2QEm6If000316; Fri, 26 Mar 2004 15:48:10 +0100 Subject: RE: [NSIS] Plans for the protocol drafts To: "Cheng Hong" Cc: , , "'Georgios Karagiannis'" , "'McDonald, Andrew'" , "'Allison Mankin'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 26 Mar 2004 15:47:56 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/26/2004 15:48:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Cheng Hong, Thanks for your reply. Please see some more comments inline. Sven "Cheng Hong" on 26/03/2004 03:01:51 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: , , "'Georgios Karagiannis'" , "'McDonald, Andrew'" , "'Allison Mankin'" Subject: RE: [NSIS] Plans for the protocol drafts Hi Sven, Thanks for your reply. Please see some further comments below: > > This may not be opaque to QoS NSLP.With this RESERVE/COMMIT > model, QoS NSLP should include messages that could do the > roll-back action. > > Sven>> Can you clarify what the impact on QoS NSLP would be? I would > imagine the signalling to look exactly the same from QoS NSLP > perspective with an additional indication to commit > resources. It seems that this difference mainly makes sense > for the Resource Management Function (RMF), which does not > participate in QoS NSLP processing anyway. I think this depends on whether we want to make the QoS NSLP support RESERVE/COMMIT or letting individual QoS Model to support that. If the QoS NSLP needs to support it, some information element, e.g. a flag and corresponding RSN, should be included in the common header of QoS NSLP messages. If the QoS Model is left to deal with it, the above information could be placed into QSPEC. Then, the QSPEC should contain an object defined for this purpose. Sven>> Agreed. But what did you mean with the rollback action? > The resource sharing is only meaningful inside each > individual NSLP. Therefore, the GIMPS may not be able to > provide the necessary function unless it is mandated that the > session-ID would be unique across all the NSLPs. > > Sven>> Since the session ID is a large random identifier, why > would it > Sven>> be > "less unique" across NSLPs than within one NSLP? Statistically, it would not be very much "less unique". But since this feature we want to introduce here depends on the uniqueness of the ID, it should be made explicit. Maybe some guideline should be given in framework stating that different NSLP should use different session-ID. Otherwise, in implementation, a node could conveniently reuse the same session-ID for different NSLP applications since nothing forbids that. Sven>> OK, that would be a possibility: A node SHOULD NOT reuse the same session ID for different NSLPs. > This could be useful if we want to differentiate the flows, > and assign different priority for different flows. In that > case, reservation for the corresponding flows could also be > assigned with priority. > > Sven>> OK. Do you see it as part of the QoS NSLP or as part of the QoS > model (opaque to QoS NSLP, handled by RMF)? It depends on how the priority would be used. Does it have meaning across the QoS Models? Will there be multiple QoS Model at each node shareing the same RMF? My feeling is that make it part of QoS NSLP may be better or it could be a mandated part of QSPEC. Sven>> In either case, I think the topic is now taken up by the QoS model draft team which would be the right place for either of these outcomes. We can decide where to put it based on the solution they propose. > Does this imply that at least one end of the flow would be > the QoS NSLP node? > > Sven>> Do you want to support bi-directional reservation for > cases where > the first QoS NSLP node on the path is different for the > forward and reverse direction? Bi-directional reservation is > mainly an optimization. Wouldn't you rather leave these > "strange" cases unoptimized? Agree. This doesn't have to be the focus at this stage. But should we state clearly that this case is for future development? Sven>> It can be listed as a case for future investigation. best regards Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Mar 27 00:50:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12498 for ; Sat, 27 Mar 2004 00:50:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76hp-0004MC-Jc for nsis-archive@odin.ietf.org; Sat, 27 Mar 2004 00:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2R5o5L1016737 for nsis-archive@odin.ietf.org; Sat, 27 Mar 2004 00:50:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76hl-0004KD-Fq; Sat, 27 Mar 2004 00:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6mks-0004AW-H2 for nsis@optimus.ietf.org; Fri, 26 Mar 2004 03:31:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06879 for ; Fri, 26 Mar 2004 03:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6mkq-00052w-00 for nsis@ietf.org; Fri, 26 Mar 2004 03:31:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6mk0-0004xo-00 for nsis@ietf.org; Fri, 26 Mar 2004 03:31:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6mj3-0004sn-00; Fri, 26 Mar 2004 03:30:01 -0500 Received: from [212.100.197.254] (helo=mail.com) by mx2.foretec.com with smtp (Exim 4.24) id 1B6mj3-0004ec-7i; Fri, 26 Mar 2004 03:30:01 -0500 Reply-To: From: "BushCheney04@GeorgeWBush.com" Date: Fri, 26 Mar 2004 03:30:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.9 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, FROM_ENDS_IN_NUMS,X_MSMAIL_PRIORITY_HIGH,X_PRIORITY_HIGH autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] Please Consider My Experience When Voting in 2004 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-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 Resume of George W. Bush February 26, 2004, 05:15 PM Past Work Experience: I ran for U.S. Congress and lost. I produced a Hollywood slasher B movie. I bought an oil company, but couldn't find any oil in Texas; the company went bankrupt shortly after I sold all my stock. I bought the Texas Rangers baseball team in a sweetheart deal that took land using taxpayer money. With my father's help and name, I was elected Governor of Texas. Accomplishments as Governor: I changed pollution laws in favor of the power and oil companies and made Texas the most polluted state in the Union. I replaced Los Angeles with Houston as the most smog-ridden city in America. I cut taxes and bankrupted Texas government to the tune of billions in borrowed money. I set the record for the most executions by any Governor in American history. I became U.S. President after losing the popular vote by over 500,000 votes with the help of major Enron money and my father's appointments to the Supreme Court. Accomplishments as President: I spent the U.S. surplus and effectively bankrupted the U.S. Treasury. I entered my office with the strongest economy in U.S. history and have turned every single economic category downward -- all in less than two years. I shattered the record for the largest annual deficit in U.S. history. I garnered the most sympathy for the U.S. after the World Trade Center attacks and less than a year later made the U.S. the most resented country in the world, possibly the largest failure of diplomacy in World history. I am the first president in U.S. history to enter office with a criminal record. I set the the all-time record for most days on vacation in any one year period. I am supporting development of a "Tactical Bunker Buster" nuke, a WMD. I am getting our troops killed, under the lie of Saddam's procurement of Yellow Cake Nuke WMD components, then blaming the lie on our British friends. I set the record for most campaign fund-raising trips by a U.S. president. In my first year in! office over 2-million Americans l Records and References: I have at least one conviction for drunk driving in Maine. My Texas driving record has been erased and is not available. I was AWOL from the National Guard. I refuse to take a drug test or even answer any questions about drug use. All records of my tenure as Governor of Texas are now in my father's library, sealed, and unavailable for public view. All records of SEC investigations into insider trading or bankrupt companies are sealed in secrecy and unavailable for public view. All records or minutes from meetings that I, or my Vice-President, attended regarding public energy policy are sealed in secrecy and unavailable for public review. Please consider my experience when voting in 2004. Show you care about our country's future and forward this to every voter you know. Protest is patriotism. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Mar 27 00:50:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12500 for ; Sat, 27 Mar 2004 00:50:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76hp-0004MB-JR for nsis-archive@odin.ietf.org; Sat, 27 Mar 2004 00:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2R5o5Sf016738 for nsis-archive@odin.ietf.org; Sat, 27 Mar 2004 00:50:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76hm-0004KS-3A; Sat, 27 Mar 2004 00:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6tTL-0003wT-HO for nsis@optimus.ietf.org; Fri, 26 Mar 2004 10:42:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26530 for ; Fri, 26 Mar 2004 10:42:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6tTI-0005hr-00 for nsis@ietf.org; Fri, 26 Mar 2004 10:42:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6tSO-0005ev-00 for nsis@ietf.org; Fri, 26 Mar 2004 10:41:17 -0500 Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1B6tRi-0005Y6-00 for nsis@ietf.org; Fri, 26 Mar 2004 10:40:35 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i2QEq7gx006750 for ; Fri, 26 Mar 2004 09:40:04 -0600 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 405DCB760028A013; Fri, 26 Mar 2004 10:39:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Plans for the protocol drafts Date: Fri, 26 Mar 2004 09:40:03 -0600 Message-ID: Thread-Topic: [NSIS] Plans for the protocol drafts Thread-Index: AcQTQL3hMCh1zpDjT7uQ1f+2OXb05QABc6Lg From: "Tarapore, Percy S, ALABS" To: , "Ash, Gerald R (Jerry), ALABS" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sven, Here is another reason why reservation priority should be given strong consideration for inclusion in the QoS NSLP. Suppose an emergency service session is being initiated through SIP. Currently, SIP does not support the prioritization of session initiation and hence, some work needs to be done in SIP to permit this (e.g., inclusion of resource priority headers). Once this is defined, the interaction between SIP and other protocols such as RSVP-TE will need to transfer the priority level of the initiated session. Having reservation priority as an integral part of QoS NSLP will greatly facilitate such interactions. Percy S. Tarapore -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: Friday, March 26, 2004 9:42 AM To: Ash, Gerald R (Jerry), ALABS Cc: nsis@ietf.org; Ash, Gerald R (Jerry), ALABS Subject: RE: [NSIS] Plans for the protocol drafts Hi Jerry, Sorry for the delayed reply. Please find some comments inline. Best regards, Sven "Ash, Gerald R (Jerry), ALABS" on 24/03/2004 16:17:07 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, cc: "Ash, Gerald R (Jerry), ALABS" Subject: RE: [NSIS] Plans for the protocol drafts Hi Sven, Dave> 6. Reservation priority is declared out of scope Dave> but is critically important. We can't just punt Dave> this. One thought is to have it be part of a set Dave> of "common facilities" that go across all the Dave> GIMPS applications. I bet there are a number of Dave> such common things which are not part of the Dave> transport but aren't specific to a particular Dave> signaling application. Sven> We would like to receive input on this from the Sven> WG. Why do they think it is needed, what are the Sven> requirements, ... I agree with Dave that 'reservation priority' is critically important to add. IMO there should be a requirement for reservation priority (i.e., for emergency services/ETS/E911, etc.) for the NSLP QoS signaling. The 'standard Qspec' being worked now by the QoS model draft teams can be the vehicle to introduce this. As requested by John (and the WG), we will work out a common Qspec across models, and maximize commonality. To maximize commonality, I think it preferable to make reservation priority a part of the common QoS NSLP rather than part of the individual QoS model (opaque to QoS NSLP). As discussed in 'NSIS Network Service Layer Protocol QoS Signaling Proof-of-Concept' http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of -concept-01.txt , reservation priority is a way to differentiate emergency services flows, and assign them a higher priority than normal or best-effort priority flows. Requirements for reservation priority are suggested in Section B.4 'Support of Priority & Reliability Attributes': a. Reliability can be requested in the form of a Priority Class for a specific network function, such as CAC priority. b. There are a limited number of Priority Classes to ensure scalability (e.g., 3 classes), such as: - CAC Priority Class: The urgency with which a service connection is desired (e.g., High, Normal, Best Effort). - Restoration Priority Class: The urgency with which a service requires successful restoration under failure conditions (e.g., High, Normal, Best Effort). Sven>> I agree with you that reservation priority is needed and I believe that the proposals that you mention are probably a good way of implementing it if you want to support it. What I am not sure about is whether it should be part of the QoS NSLP. Even if it is common to multiple QoS models, it still would only affect the Resource Management Function (RMF) (unlike the message priority) which makes it outside of the QoS NSLP scope in my opinion. Anyway, I think it is good that the concept and the potential solution matures in the QoS model draft team. We can decide when we see what it turned out to be whether we still want to put it in the QoS NSLP spec. Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Mar 27 16:33:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01099 for ; Sat, 27 Mar 2004 16:33:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7LQQ-0002JG-In for nsis-archive@odin.ietf.org; Sat, 27 Mar 2004 16:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2RLX6VL008874 for nsis-archive@odin.ietf.org; Sat, 27 Mar 2004 16:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7LQK-0002H2-Vn; Sat, 27 Mar 2004 16:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7LPZ-00029y-TU for nsis@optimus.ietf.org; Sat, 27 Mar 2004 16:32:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01041 for ; Sat, 27 Mar 2004 16:32:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7LPX-0003Zo-00 for nsis@ietf.org; Sat, 27 Mar 2004 16:32:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7LOc-0003U0-00 for nsis@ietf.org; Sat, 27 Mar 2004 16:31:15 -0500 Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1B7LNz-0003Lz-00 for nsis@ietf.org; Sat, 27 Mar 2004 16:30:36 -0500 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i2RLU5Wc007888 for ; Sat, 27 Mar 2004 16:30:06 -0500 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 404B562A005A6021; Sat, 27 Mar 2004 16:26:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Plans for the protocol drafts Date: Sat, 27 Mar 2004 16:30:06 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A069FC88C@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [NSIS] Plans for the protocol drafts Thread-Index: AcQTQL3hMCh1zpDjT7uQ1f+2OXb05QABc6LgAD7hLeA= From: "Roy, Radhika R, ALABS" To: "Tarapore, Percy S, ALABS" , , "Ash, Gerald R (Jerry), ALABS" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Folks: Here is the IETF draft what SIP is doing for the resources priority: http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-03. txt Considering the above, NSIS WG can also decide what needs to be done for development of NSIS protocols. Best regards, Radhika R. Roy -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Tarapore, Percy S, ALABS Sent: Friday, March 26, 2004 10:40 AM To: sven.van_den_bosch@alcatel.be; Ash, Gerald R (Jerry), ALABS Cc: nsis@ietf.org Subject: RE: [NSIS] Plans for the protocol drafts Sven, Here is another reason why reservation priority should be given strong consideration for inclusion in the QoS NSLP. Suppose an emergency service session is being initiated through SIP. Currently, SIP does not support the prioritization of session initiation and hence, some work needs to be done in SIP to permit this (e.g., inclusion of resource priority headers). Once this is defined, the interaction between SIP and other protocols such as RSVP-TE will need to transfer the priority level of the initiated session. Having reservation priority as an integral part of QoS NSLP will greatly facilitate such interactions. Percy S. Tarapore -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: Friday, March 26, 2004 9:42 AM To: Ash, Gerald R (Jerry), ALABS Cc: nsis@ietf.org; Ash, Gerald R (Jerry), ALABS Subject: RE: [NSIS] Plans for the protocol drafts Hi Jerry, Sorry for the delayed reply. Please find some comments inline. Best regards, Sven "Ash, Gerald R (Jerry), ALABS" on 24/03/2004 16:17:07 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, cc: "Ash, Gerald R (Jerry), ALABS" Subject: RE: [NSIS] Plans for the protocol drafts Hi Sven, Dave> 6. Reservation priority is declared out of scope Dave> but is critically important. We can't just punt Dave> this. One thought is to have it be part of a set Dave> of "common facilities" that go across all the Dave> GIMPS applications. I bet there are a number of Dave> such common things which are not part of the Dave> transport but aren't specific to a particular Dave> signaling application. Sven> We would like to receive input on this from the Sven> WG. Why do they think it is needed, what are the Sven> requirements, ... I agree with Dave that 'reservation priority' is critically important to add. IMO there should be a requirement for reservation priority (i.e., for emergency services/ETS/E911, etc.) for the NSLP QoS signaling. The 'standard Qspec' being worked now by the QoS model draft teams can be the vehicle to introduce this. As requested by John (and the WG), we will work out a common Qspec across models, and maximize commonality. To maximize commonality, I think it preferable to make reservation priority a part of the common QoS NSLP rather than part of the individual QoS model (opaque to QoS NSLP). As discussed in 'NSIS Network Service Layer Protocol QoS Signaling Proof-of-Concept' http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of -concept-01.txt , reservation priority is a way to differentiate emergency services flows, and assign them a higher priority than normal or best-effort priority flows. Requirements for reservation priority are suggested in Section B.4 'Support of Priority & Reliability Attributes': a. Reliability can be requested in the form of a Priority Class for a specific network function, such as CAC priority. b. There are a limited number of Priority Classes to ensure scalability (e.g., 3 classes), such as: - CAC Priority Class: The urgency with which a service connection is desired (e.g., High, Normal, Best Effort). - Restoration Priority Class: The urgency with which a service requires successful restoration under failure conditions (e.g., High, Normal, Best Effort). Sven>> I agree with you that reservation priority is needed and I believe that the proposals that you mention are probably a good way of implementing it if you want to support it. What I am not sure about is whether it should be part of the QoS NSLP. Even if it is common to multiple QoS models, it still would only affect the Resource Management Function (RMF) (unlike the message priority) which makes it outside of the QoS NSLP scope in my opinion. Anyway, I think it is good that the concept and the potential solution matures in the QoS model draft team. We can decide when we see what it turned out to be whether we still want to put it in the QoS NSLP spec. Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Mar 28 23:29:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23237 for ; Sun, 28 Mar 2004 23:29:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7oOZ-0002u9-OE for nsis-archive@odin.ietf.org; Sun, 28 Mar 2004 23:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T4T7aQ011160 for nsis-archive@odin.ietf.org; Sun, 28 Mar 2004 23:29:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7oOU-0002tV-38; Sun, 28 Mar 2004 23:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7oNj-0002sa-HG for nsis@optimus.ietf.org; Sun, 28 Mar 2004 23:28:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23181 for ; Sun, 28 Mar 2004 23:28:12 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7oNh-0001wh-00 for nsis@ietf.org; Sun, 28 Mar 2004 23:28:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7oMm-0001pH-00 for nsis@ietf.org; Sun, 28 Mar 2004 23:27:16 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B7oMC-0001hS-00 for nsis@ietf.org; Sun, 28 Mar 2004 23:26:40 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2T4QVT02908; Mon, 29 Mar 2004 07:26:31 +0300 (EET DST) X-Scanned: Mon, 29 Mar 2004 07:26:05 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2T4Q5Gb009961; Mon, 29 Mar 2004 07:26:05 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00QcWCZ7; Mon, 29 Mar 2004 07:26:04 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2T4Q2s03354; Mon, 29 Mar 2004 07:26:02 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Mar 2004 07:26:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Plans for the protocol drafts Date: Mon, 29 Mar 2004 07:26:00 +0300 Message-ID: Thread-Topic: [NSIS] Plans for the protocol drafts Thread-Index: AcQTQL3hMCh1zpDjT7uQ1f+2OXb05QABc6LgAH+soEA= To: , , Cc: X-OriginalArrivalTime: 29 Mar 2004 04:26:01.0556 (UTC) FILETIME=[F1202940:01C41545] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Percy, > Here is another reason why reservation priority should be given strong > consideration for inclusion in the QoS NSLP. Suppose an emergency > service session is being initiated through SIP. Currently, SIP does = not > support the prioritization of session initiation and hence, some work > needs to be done in SIP to permit this (e.g., inclusion of resource > priority headers). Once this is defined, the interaction between SIP = and > other protocols such as RSVP-TE will need to transfer the priority = level > of the initiated session. Having reservation priority as an integral > part of QoS NSLP will greatly facilitate such interactions. At the TSVWG WG in Seoul, Fred Baker presented issues on Multi-Level=20 Preemption and Precedence: http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-01.= txt I think we may like to consider similar functionality in the NTLP, as this seems to be relevant to many applicaitons NSIS may serve. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 29 04:57:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22688 for ; Mon, 29 Mar 2004 04:57:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tW1-00031X-2M for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 04:57:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T9v80J011598 for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 04:57:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tVu-00030F-SC; Mon, 29 Mar 2004 04:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tVD-0002wd-T8 for nsis@optimus.ietf.org; Mon, 29 Mar 2004 04:56:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22623 for ; Mon, 29 Mar 2004 04:56:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tVA-0002hs-00 for nsis@ietf.org; Mon, 29 Mar 2004 04:56:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tUG-0002aX-00 for nsis@ietf.org; Mon, 29 Mar 2004 04:55:21 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1B7tTK-0002Lg-00 for nsis@ietf.org; Mon, 29 Mar 2004 04:54:22 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGM4JQY>; Mon, 29 Mar 2004 10:53:47 +0100 Message-ID: From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , tarapore@att.com, sven.van_den_bosch@alcatel.be, gash@att.com Cc: nsis@ietf.org Subject: priority and pre-emption in NSIS (was: RE: [NSIS] Plans for the p rotocol drafts) Date: Mon, 29 Mar 2004 10:53:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, [trying to structure this rather long thread a little:] I think we could probably say that there is general agreement that 'priority and preemption should not be ignored' (which I think was the force of Dave's original comment). However, I'm still pretty confused about whether there is a single consensus meaning of the words, and I still don't think I've seen (or understood) arguments for putting such handling low rather than high in the overall NSIS architecture. (There are at least 4 choices: in the NTLP; in some 'common part' of NSLPs if we give up the view that NSLPs should be entirely independent; in each NSLP; or in the resource descriptions [QoS Models] in the case of the QoS-NSLP.) My main concern is that priority/pre-emption are actually complex concepts, and trying to force all applications (or even QoS models) into the same structure will probably fail. For example: *) the draft-ash-... discusses [I think] two priorities, for CAC (checked at admission) and restoration (after failure). *) RFC3181 [I think] decomposes the CAC priority into one value checked when the call is admitted, and another value describing how strongly to defend a call after it has been admitted. *) In the mobile environment, a distinction is made between the priority for an entirely new call, compared to one where new resources are needed because of a handover. (In NSIS terms: does the concept of priority apply to flows or sessions?) In addition, while these concepts may be well understood for QoS, and the *concept* of priority may be well understood for NATs (i.e. contention for the address pool), do we really have any confidence that the actual definitions derived from a QoS perspective carry over to the NAT world? Is restoration at the per-flow level meaningful to describe? Do we even want to think about a protocol which implies the ability to pre-empt an address? For these reasons, I would say that putting priority and pre-emption concepts in the NTLP is (politely) not a good idea: either we have to go through a *long* activity to define a fully functional MLPP object, or we have a simple one but accept that MLPP objects will appear at multiples layers (yuk). And all this for something which as far as I can tell has no interactions with the other functionality inside the NTLP. So far as the QoS NSLP is concerned, I think the current approach of attacking the problem via the QoS models is a good one. (One implication of this is that it should consider 3181 as one of the inputs.) However, even here, I don't see what are the real arguments for making the MLPP aspects part of the base protocol - is it because there are strong interactions with the other parts of the protocol? - or to make implementations easier? - or to make interactions with SIP well defined? (But 3312 AFAIK puts the priority aspects inside SDP with the other session parameters, and this would also tend to correlate with putting priority aspects in the QM, at least to me.) More discussion is needed here. r. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, March 29, 2004 05:26 > To: tarapore@att.com; sven.van_den_bosch@alcatel.be; gash@att.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] Plans for the protocol drafts > > > Hi Percy, > > > Here is another reason why reservation priority should be > given strong > > consideration for inclusion in the QoS NSLP. Suppose an emergency > > service session is being initiated through SIP. Currently, > SIP does not > > support the prioritization of session initiation and hence, > some work > > needs to be done in SIP to permit this (e.g., inclusion of resource > > priority headers). Once this is defined, the interaction > between SIP and > > other protocols such as RSVP-TE will need to transfer the > priority level > > of the initiated session. Having reservation priority as an integral > > part of QoS NSLP will greatly facilitate such interactions. > > At the TSVWG WG in Seoul, Fred Baker presented issues on Multi-Level > Preemption and Precedence: > > http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-tha t-works-01.txt I think we may like to consider similar functionality in the NTLP, as this seems to be relevant to many applicaitons NSIS may serve. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 29 09:03:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03220 for ; Mon, 29 Mar 2004 09:03:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7xLz-0002pW-7o for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 09:03:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TE33Xv010877 for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 09:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7xLy-0002pH-03; Mon, 29 Mar 2004 09:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7xLf-0002oK-7s for nsis@optimus.ietf.org; Mon, 29 Mar 2004 09:02:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03179 for ; Mon, 29 Mar 2004 09:02:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7xLd-0006ig-00 for nsis@ietf.org; Mon, 29 Mar 2004 09:02:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7xKi-0006aA-00 for nsis@ietf.org; Mon, 29 Mar 2004 09:01:45 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1B7xKF-0006PL-00 for nsis@ietf.org; Mon, 29 Mar 2004 09:01:15 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 29 Mar 2004 15:00:35 +0100 Message-ID: From: "Hancock, Robert" To: "'sven.van_den_bosch@alcatel.be'" , Cheng Hong Cc: nsis@ietf.org Date: Mon, 29 Mar 2004 15:00:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] QoS-NSLP two-phase operation (was: RE: Plans for the protocol dra fts) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, Basically I think I agree with Sven on this issue: two-phase operation can/should be done in the QoS-Model (maybe in a generic way); or, in any case, it doesn't need to be built into the protocol operation. The specifics depend on what is really assumed to be the semantic of the Phase-I-RESERVE. a) If it means "would resources be available right now?" then this can be implemented quite happily with a QUERY of some sort (I assume). The initiator has to take the chance that the answer may change between the Phase-I message and actually installing the reservation in Phase-II. b) If it means "I would like the following resources to be guaranteed available when I ask for them" then this implies creating some state in the network representing the guarantee. But then the state installed by the Phase-I message has to be managed just like any other reservation state, and that includes e.g. handling path changes, teardown/rollback and so on. So if you do decide to represent two phase operation non-opaquely in the QoS-NSLP (e.g. as separate RESERVE and COMMIT messages) then all these state handling rules will have to be worked out for both (as well as the interactions between the two). Keeping two-phase operation opaque to the NSLP would seem to be much easier. There *are* some respects in which a Phase-I message could usefully be processed differently from a Phase-II message. Specifically, during Phase-I, you only need to know which outgoing interface a reservation applies to, whereas in Phase-II you need to know which specific packets are affected. If this matters (e.g. you want to send a Phase-I message before you know all the information about port numbers), this would imply changing some information objects - even the flow identifier at the GIMPS level - between messages. But it's precisely for this sort of reason that we have the Session ID and that we allow flow identifiers to change mid-session. (Maybe this use case needs to be worked out in a bit more detail, but it seems OK at first sight.) robert h. [partial reconstruction of thread follows] > > 3. some talk about 2-phase operation for RSVP. Any thought of > > the same for NSLP? > > > > We discussed about a RESERVE/COMMIT model in QoS NSLP. At the > > moment, we feel that this might be solved at the QoS model > > level which is opaque to QoS NSLP. > > This may not be opaque to QoS NSLP.With this RESERVE/COMMIT model, > QoS NSLP should include messages that could do the roll-back action. > > Sven>> Can you clarify what the impact on QoS NSLP would be? I would > imagine the signalling to look exactly the same from QoS NSLP > perspective > with an additional indication to commit resources. It seems that this > difference mainly makes sense for the Resource Management > Function (RMF), > which does not participate in QoS NSLP processing anyway. > [Cheng] > I think this depends on whether we want to make the QoS NSLP support > RESERVE/COMMIT or letting individual QoS Model to support > that. If the QoS > NSLP needs to support it, some information element, e.g. a flag and > corresponding RSN, should be included in the common header of QoS NSLP > messages. > > If the QoS Model is left to deal with it, the above > information could be > placed into QSPEC. Then, the QSPEC should contain an object > defined for > this > purpose. > > Sven>> Agreed. But what did you mean with the rollback action? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 29 09:36:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04382 for ; Mon, 29 Mar 2004 09:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7xru-00052s-0l for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 09:36:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TEa1vo019391 for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 09:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7xrt-00052D-Ey; Mon, 29 Mar 2004 09:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7xrW-00051X-FE for nsis@optimus.ietf.org; Mon, 29 Mar 2004 09:35:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04353 for ; Mon, 29 Mar 2004 09:35:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7xrU-0003FZ-00 for nsis@ietf.org; Mon, 29 Mar 2004 09:35:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7xqW-00038D-00 for nsis@ietf.org; Mon, 29 Mar 2004 09:34:37 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B7xpz-00030K-00 for nsis@ietf.org; Mon, 29 Mar 2004 09:34:03 -0500 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2TEXTKj024294; Mon, 29 Mar 2004 06:33:29 -0800 (PST) Received: from [10.32.245.157] (stealth-10-32-245-157.cisco.com [10.32.245.157]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANP64168; Mon, 29 Mar 2004 06:33:22 -0800 (PST) Date: Mon, 29 Mar 2004 09:33:21 -0500 From: "David R. Oran" To: "Hancock, Robert" , "'john.loughney@nokia.com'" , tarapore@att.com, sven.van_den_bosch@alcatel.be, gash@att.com cc: nsis@ietf.org Subject: Re: priority and pre-emption in NSIS (was: RE: [NSIS] Plans for the p rotocol drafts) Message-ID: <2147483647.1080552801@[10.32.245.157]> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========99841E1C018168759B12==========" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --==========99841E1C018168759B12========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Monday, March 29, 2004 10:53 AM +0100 "Hancock, Robert"=20 wrote: > dear all, > > [trying to structure this rather long thread a little:] > > I think we could probably say that there is general agreement > that 'priority and preemption should not be ignored' (which > I think was the force of Dave's original comment). > Fair assessment. > However, I'm still pretty confused about whether there is a > single consensus meaning of the words, and I still don't > think I've seen (or understood) arguments for putting such > handling low rather than high in the overall NSIS architecture. > (There are at least 4 choices: in the NTLP; in some 'common part' > of NSLPs if we give up the view that NSLPs should be entirely > independent; in each NSLP; or in the resource descriptions [QoS > Models] in the case of the QoS-NSLP.) > I believe I advocated putting it in a "common semantics" section of the=20 NSLPs. The justification was/is threefold: a) what is being "prioritized" and possibly "preempted" where there is=20 resource contention are those resources themselves and not transport state=20 or the resources of the transport itself. This argues for these functions=20 to be "above" the transport". b) when resources are to be considered for preemption, those resources may=20 be of different sorts and for different NSLPs (e.g. QoS classifiers,=20 firewall pinholes, NAT translation entries). Having different semantics for = identifying and computing ordering of different resource types is=20 inconvenient at best and a recipe for incoherent preemption operation at=20 worst. This argues for putting these functions below the individual NSLPs. c) the semantics and operational characteristics of preemption are=20 reasonably well understood from prior work in MPLS and RSVP. It seems=20 unlikely that there would be substantially different methodologies needed=20 for different NSIS applications. I of course can't prove this, but one=20 would think that by now some kind of counter-example would have emerged for = the need for different preemption behavior for different kinds of resources = for the same higher-level application usages. > My main concern is that priority/pre-emption are actually > complex concepts, and trying to force all applications (or even > QoS models) into the same structure will probably fail. For I think part of the problem is in fact that people try to make this too=20 complicated! Often the difference among schemes is due to random people=20 redesigning things that don't need to be redesigned rather than from any=20 underlying difference in requirements. > example: > *) the draft-ash-... discusses [I think] two priorities, for > CAC (checked at admission) and restoration (after failure). Yes, that maps nicely onto establishment and holding priorities, just like=20 in MPLS and RSVP. > *) RFC3181 [I think] decomposes the CAC priority into one > value checked when the call is admitted, and another value > describing how strongly to defend a call after it has been > admitted. If these are different I must be failing to see the subtleties... > *) In the mobile environment, a distinction is made between the > priority for an entirely new call, compared to one where new > resources are needed because of a handover. (In NSIS terms: > does the concept of priority apply to flows or sessions?) > Ditto for establishment versus holding priorities. > In addition, while these concepts may be well understood for > QoS, and the *concept* of priority may be well understood for > NATs (i.e. contention for the address pool), do we really have > any confidence that the actual definitions derived from a QoS > perspective carry over to the NAT world? No, but do we have a counter-example? Sometimes it's best to be guided by=20 intuition based on experience with existing resource preemption schemes=20 that have or have not worked in the past. > Is restoration at the > per-flow level meaningful to describe? Is this rhetorical? It's like asking if per-flow QoS makes sense when=20 resources are only allocated in aggregates. Pre-emption behavior is (I=20 think) well defined in these cases. What gets complicated are the policy=20 issues around choosing the state to preempt when the choice is=20 non-deterministic (as are many interesting cases). However, these issues to = not affect the protocol - they are local algorithms. Note: what does affect the protocol is the need to communicate fate-sharing = and some possible intermediate states for resources which are fate-shared.=20 I have a talk on this subject which I've been giving the last couple of=20 months and have some suggestions for how to handle this. I briefly alluded=20 to this in the NSIS meeting where I proposed that we need both explicit=20 "resource sharing" identifiers and "fate-sharing" identifiers for=20 resources. I would claim that these two things are also elements that=20 belong in some commmon layer above the transport and below the individual=20 NSLPs. > Do we even want to think > about a protocol which implies the ability to pre-empt an address? > Yes, why not? It already happens when translation entries get reused - all=20 we're doing is explicitly signaling and hence making the system work = better! > For these reasons, I would say that putting priority and > pre-emption concepts in the NTLP is (politely) not a good idea: I agree that it does not belong in the transport itself, for the reasons I=20 outlined above. > either we have to go through a *long* activity to define a fully > functional MLPP object, or we have a simple one but accept that > MLPP objects will appear at multiples layers (yuk). First, I don't see why this has to be long and complicated. We have good=20 existing work to guide us. Second, I suspect that if we have something well = designed there will not in fact be a need for custom stuff in individual=20 NSLPs. The benefit of consistent preemption behavior across resource types=20 should (in my mind anyway) outweigh the per-application optimizations=20 people always seem to want for dubious reasons. > And all this > for something which as far as I can tell has no interactions with > the other functionality inside the NTLP. > Also agree on this. > So far as the QoS NSLP is concerned, I think the current approach > of attacking the problem via the QoS models is a good one. (One > implication of this is that it should consider 3181 as one of the > inputs.) You lost me on this one. I don't see how QoS models help or hinder the=20 ability to do preemption. Try again? > However, even here, I don't see what are the real arguments > for making the MLPP aspects part of the base protocol - is it because > there are strong interactions with the other parts of the protocol? No, it's because a single end-to-end application doing NSIS signaling may=20 have multiple resource types from multiple NSLPs allocated and it needs to=20 be able to communicate the preemption properties it wants for those things=20 in a consistent way. This becomes even more critical once we peel the onion = one more layer and look at fate sharing, where the resource identifiers and = their preemption-properties need to be communicated in application=20 protocols as well as in NSIS. > - or to make implementations easier? - or to make interactions with > SIP well defined? (But 3312 AFAIK puts the priority aspects inside > SDP with the other session parameters, and this would also tend to > correlate with putting priority aspects in the QM, at least to me.) > More discussion is needed here. > Certainly don't disagree that more discussion is useful. Dave. > r. > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: Monday, March 29, 2004 05:26 >> To: tarapore@att.com; sven.van_den_bosch@alcatel.be; gash@att.com >> Cc: nsis@ietf.org >> Subject: RE: [NSIS] Plans for the protocol drafts >> >> >> Hi Percy, >> >> > Here is another reason why reservation priority should be >> given strong >> > consideration for inclusion in the QoS NSLP. Suppose an emergency >> > service session is being initiated through SIP. Currently, >> SIP does not >> > support the prioritization of session initiation and hence, >> some work >> > needs to be done in SIP to permit this (e.g., inclusion of resource >> > priority headers). Once this is defined, the interaction >> between SIP and >> > other protocols such as RSVP-TE will need to transfer the >> priority level >> > of the initiated session. Having reservation priority as an integral >> > part of QoS NSLP will greatly facilitate such interactions. >> >> At the TSVWG WG in Seoul, Fred Baker presented issues on Multi-Level >> Preemption and Precedence: >> >> http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-tha > t-works-01.txt > > I think we may like to consider similar functionality in the NTLP, as > this seems to be relevant to many applications NSIS may serve. > > 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 --==========99841E1C018168759B12========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAaDOxjWaEtlTdKuYRAoufAJ9F+hrWGIK8tXK6NEwksxadHMDxoQCgmGP5 AJoh78ENq032TL+UjmHv6GU= =/0NS -----END PGP SIGNATURE----- --==========99841E1C018168759B12==========-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 29 09:50:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04942 for ; Mon, 29 Mar 2004 09:50:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7y5T-0005y3-0Q for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 09:50:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TEo2ML022908 for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 09:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7y5R-0005xF-Uw; Mon, 29 Mar 2004 09:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7y4v-0005wO-P8 for nsis@optimus.ietf.org; Mon, 29 Mar 2004 09:49:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04916 for ; Mon, 29 Mar 2004 09:49:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7y4t-0005CA-00 for nsis@ietf.org; Mon, 29 Mar 2004 09:49:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7y3z-00054w-00 for nsis@ietf.org; Mon, 29 Mar 2004 09:48:32 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B7y3J-0004qX-00 for nsis@ietf.org; Mon, 29 Mar 2004 09:47:49 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Mar 2004 06:53:20 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2TElFKj010790; Mon, 29 Mar 2004 06:47:15 -0800 (PST) Received: from [10.32.245.157] (stealth-10-32-245-157.cisco.com [10.32.245.157]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANP64826; Mon, 29 Mar 2004 06:47:12 -0800 (PST) Date: Mon, 29 Mar 2004 09:47:10 -0500 From: "David R. Oran" To: "Hancock, Robert" , "'sven.van_den_bosch@alcatel.be'" , Cheng Hong cc: nsis@ietf.org Subject: Re: [NSIS] QoS-NSLP two-phase operation (was: RE: Plans for the protocol dra fts) Message-ID: <2147483647.1080553630@[10.32.245.157]> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========8412E2D94633D91551BB==========" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --==========8412E2D94633D91551BB========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Terminology collision alert: In most distributed systems, "two-phase operation" tends to mean separate=20 reserve/commit phases, as opposed to what seems to be discussed here. In=20 the NSIS universe, this translates into the reserve phase actually setting=20 the resources aside and doing admission control, but not actually=20 installing the state in the data plane. Only when the commit phase is=20 executed is data plane state installed. (there are elaborations where the=20 reserve phase installs some "negative" data plane state but I won't=20 complicate this thread by going into that). Don't know quite what to do about this, other than to point out that I=20 would like to make sure we can do reserve/commit phases in NSIS since they=20 are arguably needed to avoid certain theft-of-serivce scenarios. That said, = I suspect reserve/commit two-phase operation DOES affect the NSLP protocol=20 state machines and can't be finessed with QoS models - the state needs to=20 be explicitly modeled as part of the NSLP itself. I don't have a strong opinion on whether separate "how much resource is=20 available" and "please reserve resources" phases are needed or not. We=20 don't have any implementation experience with the RSVP ADSPEC scheme to=20 have a basis for comparison. Dave. --On Monday, March 29, 2004 3:00 PM +0100 "Hancock, Robert"=20 wrote: > dear all, > > Basically I think I agree with Sven on this issue: two-phase > operation can/should be done in the QoS-Model (maybe in a generic > way); or, in any case, it doesn't need to be built into the > protocol operation. > > The specifics depend on what is really assumed to be the > semantic of the Phase-I-RESERVE. > > a) If it means "would resources be available right now?" > then this can be implemented quite happily with a QUERY of > some sort (I assume). The initiator has to take the chance > that the answer may change between the Phase-I message and > actually installing the reservation in Phase-II. > > b) If it means "I would like the following resources to be > guaranteed available when I ask for them" then this implies > creating some state in the network representing the guarantee. > But then the state installed by the Phase-I message has to > be managed just like any other reservation state, and that > includes e.g. handling path changes, teardown/rollback and > so on. So if you do decide to represent two phase operation > non-opaquely in the QoS-NSLP (e.g. as separate RESERVE and > COMMIT messages) then all these state handling rules will have > to be worked out for both (as well as the interactions between > the two). Keeping two-phase operation opaque to the NSLP would > seem to be much easier. > > There *are* some respects in which a Phase-I message could > usefully be processed differently from a Phase-II message. > Specifically, during Phase-I, you only need to know which > outgoing interface a reservation applies to, whereas in Phase-II > you need to know which specific packets are affected. If this > matters (e.g. you want to send a Phase-I message before you > know all the information about port numbers), this would imply > changing some information objects - even the flow identifier > at the GIMPS level - between messages. But it's precisely for > this sort of reason that we have the Session ID and that we > allow flow identifiers to change mid-session. (Maybe this use > case needs to be worked out in a bit more detail, but it seems > OK at first sight.) > > robert h. > > [partial reconstruction of thread follows] > >> > 3. some talk about 2-phase operation for RSVP. Any thought of >> > the same for NSLP? >> > >> > We discussed about a RESERVE/COMMIT model in QoS NSLP. At the >> > moment, we feel that this might be solved at the QoS model >> > level which is opaque to QoS NSLP. >> >> This may not be opaque to QoS NSLP.With this RESERVE/COMMIT model, >> QoS NSLP should include messages that could do the roll-back action. >> >> Sven>> Can you clarify what the impact on QoS NSLP would be? I would >> imagine the signalling to look exactly the same from QoS NSLP >> perspective >> with an additional indication to commit resources. It seems that this >> difference mainly makes sense for the Resource Management >> Function (RMF), >> which does not participate in QoS NSLP processing anyway. >> > > [Cheng] >> I think this depends on whether we want to make the QoS NSLP support >> RESERVE/COMMIT or letting individual QoS Model to support >> that. If the QoS >> NSLP needs to support it, some information element, e.g. a flag and >> corresponding RSN, should be included in the common header of QoS NSLP >> messages. >> >> If the QoS Model is left to deal with it, the above >> information could be >> placed into QSPEC. Then, the QSPEC should contain an object >> defined for >> this >> purpose. >> >> Sven>> Agreed. But what did you mean with the rollback action? > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --==========8412E2D94633D91551BB========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAaDbvjWaEtlTdKuYRAutVAKDlqdfuvnHdlQBqR9gEHpxgaetbZgCfTIe4 cnS1hoEz/+CkHxirBVFS2N4= =lwPd -----END PGP SIGNATURE----- --==========8412E2D94633D91551BB==========-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 29 10:17:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07087 for ; Mon, 29 Mar 2004 10:17:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yW0-0005lJ-4J for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 10:17:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TFHRe3022103 for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 10:17:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yVw-0005jJ-E2; Mon, 29 Mar 2004 10:17:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yVL-0005Xj-H3 for nsis@optimus.ietf.org; Mon, 29 Mar 2004 10:16:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06940 for ; Mon, 29 Mar 2004 10:16:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7yV8-0001Mp-00 for nsis@ietf.org; Mon, 29 Mar 2004 10:16:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7yUH-0001Dw-00 for nsis@ietf.org; Mon, 29 Mar 2004 10:15:42 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1B7yTR-0000ut-00 for nsis@ietf.org; Mon, 29 Mar 2004 10:14:49 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 29 Mar 2004 16:14:18 +0100 Message-ID: From: "Hancock, Robert" To: "'David R. Oran'" , "'sven.van_den_bosch@alcatel.be'" , Cheng Hong Cc: nsis@ietf.org Subject: RE: [NSIS] QoS-NSLP two-phase operation (was: RE: Plans for the p rotocol dra fts) Date: Mon, 29 Mar 2004 16:14:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dave, (extracting from your text below): so far as I can tell, > the reserve phase actually setting > the resources aside and doing admission control, but not actually > installing the state in the data plane. Only when the commit phase is > executed is data plane state installed. is the same as my case (b), and > separate "how much resource is > available" and "please reserve resources" phases is my case (a). I quite agree that these are totally different (but sometimes I still can't tell which one people are referring to, hence i put them both in). Or is there yet another possible meaning which I have missed? I agree also that (b) is the more interesting one (if it is the same as what you are asking for). On the question of whether the state handling to provide it interacts with the rest of the QoS-NSLP state handling (and has to be visible to it), at the moment I just don't see what the problems are - in fact, I only see problems doing it the other way. Maybe some more examples would help (e.g. do you have pointers to the theft-of-service scenarios you mention?) robert h. > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Monday, March 29, 2004 15:47 > To: Hancock, Robert; 'sven.van_den_bosch@alcatel.be'; Cheng Hong > Cc: nsis@ietf.org > Subject: Re: [NSIS] QoS-NSLP two-phase operation (was: RE: > Plans for the > protocol dra fts) > > > Terminology collision alert: > > In most distributed systems, "two-phase operation" tends to > mean separate > reserve/commit phases, as opposed to what seems to be > discussed here. In > the NSIS universe, this translates into the reserve phase > actually setting > the resources aside and doing admission control, but not actually > installing the state in the data plane. Only when the commit phase is > executed is data plane state installed. (there are > elaborations where the > reserve phase installs some "negative" data plane state but I won't > complicate this thread by going into that). > > Don't know quite what to do about this, other than to point > out that I > would like to make sure we can do reserve/commit phases in > NSIS since they > are arguably needed to avoid certain theft-of-serivce > scenarios. That said, > I suspect reserve/commit two-phase operation DOES affect the > NSLP protocol > state machines and can't be finessed with QoS models - the > state needs to > be explicitly modeled as part of the NSLP itself. > > I don't have a strong opinion on whether separate "how much > resource is > available" and "please reserve resources" phases are needed > or not. We > don't have any implementation experience with the RSVP ADSPEC > scheme to > have a basis for comparison. > > Dave. > > --On Monday, March 29, 2004 3:00 PM +0100 "Hancock, Robert" > wrote: > > > dear all, > > > > Basically I think I agree with Sven on this issue: two-phase > > operation can/should be done in the QoS-Model (maybe in a generic > > way); or, in any case, it doesn't need to be built into the > > protocol operation. > > > > The specifics depend on what is really assumed to be the > > semantic of the Phase-I-RESERVE. > > > > a) If it means "would resources be available right now?" > > then this can be implemented quite happily with a QUERY of > > some sort (I assume). The initiator has to take the chance > > that the answer may change between the Phase-I message and > > actually installing the reservation in Phase-II. > > > > b) If it means "I would like the following resources to be > > guaranteed available when I ask for them" then this implies > > creating some state in the network representing the guarantee. > > But then the state installed by the Phase-I message has to > > be managed just like any other reservation state, and that > > includes e.g. handling path changes, teardown/rollback and > > so on. So if you do decide to represent two phase operation > > non-opaquely in the QoS-NSLP (e.g. as separate RESERVE and > > COMMIT messages) then all these state handling rules will have > > to be worked out for both (as well as the interactions between > > the two). Keeping two-phase operation opaque to the NSLP would > > seem to be much easier. > > > > There *are* some respects in which a Phase-I message could > > usefully be processed differently from a Phase-II message. > > Specifically, during Phase-I, you only need to know which > > outgoing interface a reservation applies to, whereas in Phase-II > > you need to know which specific packets are affected. If this > > matters (e.g. you want to send a Phase-I message before you > > know all the information about port numbers), this would imply > > changing some information objects - even the flow identifier > > at the GIMPS level - between messages. But it's precisely for > > this sort of reason that we have the Session ID and that we > > allow flow identifiers to change mid-session. (Maybe this use > > case needs to be worked out in a bit more detail, but it seems > > OK at first sight.) > > > > robert h. > > > > [partial reconstruction of thread follows] > > > >> > 3. some talk about 2-phase operation for RSVP. Any thought of > >> > the same for NSLP? > >> > > >> > We discussed about a RESERVE/COMMIT model in QoS NSLP. At the > >> > moment, we feel that this might be solved at the QoS model > >> > level which is opaque to QoS NSLP. > >> > >> This may not be opaque to QoS NSLP.With this RESERVE/COMMIT model, > >> QoS NSLP should include messages that could do the > roll-back action. > >> > >> Sven>> Can you clarify what the impact on QoS NSLP would > be? I would > >> imagine the signalling to look exactly the same from QoS NSLP > >> perspective > >> with an additional indication to commit resources. It > seems that this > >> difference mainly makes sense for the Resource Management > >> Function (RMF), > >> which does not participate in QoS NSLP processing anyway. > >> > > > > [Cheng] > >> I think this depends on whether we want to make the QoS > NSLP support > >> RESERVE/COMMIT or letting individual QoS Model to support > >> that. If the QoS > >> NSLP needs to support it, some information element, e.g. a flag and > >> corresponding RSN, should be included in the common header > of QoS NSLP > >> messages. > >> > >> If the QoS Model is left to deal with it, the above > >> information could be > >> placed into QSPEC. Then, the QSPEC should contain an object > >> defined for > >> this > >> purpose. > >> > >> Sven>> Agreed. But what did you mean with the rollback action? > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 29 10:55:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09808 for ; Mon, 29 Mar 2004 10:55:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7z6h-0001i3-LG for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 10:55:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TFtNcJ006570 for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 10:55:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7z6d-0001hA-HT; Mon, 29 Mar 2004 10:55:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7z6E-0001ff-N0 for nsis@optimus.ietf.org; Mon, 29 Mar 2004 10:54:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09738 for ; Mon, 29 Mar 2004 10:54:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7z65-0007UB-00 for nsis@ietf.org; Mon, 29 Mar 2004 10:54:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7z59-0007LH-00 for nsis@ietf.org; Mon, 29 Mar 2004 10:53:48 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1B7z4X-0007Bd-00 for nsis@ietf.org; Mon, 29 Mar 2004 10:53:09 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 29 Mar 2004 16:52:39 +0100 Message-ID: From: "Hancock, Robert" To: "'David R. Oran'" , "'john.loughney@nokia.com'" , tarapore@att.com, sven.van_den_bosch@alcatel.be, gash@att.com Cc: nsis@ietf.org Subject: RE: priority and pre-emption in NSIS (was: RE: [NSIS] Plans for t he p rotocol drafts) Date: Mon, 29 Mar 2004 16:52:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dave, I think we (you & me) are in agreement on not wanting this stuff in the transport, so I've snipped those bits and we can wait to see if someone still wants to re-open the question. For the rest of your comments: > > However, I'm still pretty confused about whether there is a > > single consensus meaning of the words, and I still don't > > think I've seen (or understood) arguments for putting such > > handling low rather than high in the overall NSIS architecture. > > (There are at least 4 choices: in the NTLP; in some 'common part' > > of NSLPs if we give up the view that NSLPs should be entirely > > independent; in each NSLP; or in the resource descriptions [QoS > > Models] in the case of the QoS-NSLP.) > > > I believe I advocated putting it in a "common semantics" > section of the > NSLPs. The justification was/is threefold: > a) what is being "prioritized" and possibly "preempted" where > there is > resource contention are those resources themselves and not > transport state > or the resources of the transport itself. This argues for > these functions > to be "above" the transport". agree here. > b) when resources are to be considered for preemption, those > resources may > be of different sorts and for different NSLPs (e.g. QoS classifiers, > firewall pinholes, NAT translation entries). Having different > semantics for > identifying and computing ordering of different resource types is > inconvenient at best and a recipe for incoherent preemption > operation at > worst. This argues for putting these functions below the > individual NSLPs. this is a good point. > c) the semantics and operational characteristics of preemption are > reasonably well understood from prior work in MPLS and RSVP. It seems > unlikely that there would be substantially different > methodologies needed > for different NSIS applications. I of course can't prove > this, but one > would think that by now some kind of counter-example would > have emerged for > the need for different preemption behavior for different > kinds of resources > for the same higher-level application usages. I think there is just very little practical experience except from the case of the 'bandwidth' type of resource, so little chance for a counter-example to arise. We return to this below... > > > > My main concern is that priority/pre-emption are actually > > complex concepts, and trying to force all applications (or even > > QoS models) into the same structure will probably fail. For > I think part of the problem is in fact that people try to > make this too > complicated! Often the difference among schemes is due to > random people > redesigning things that don't need to be redesigned rather > than from any > underlying difference in requirements. OK: my concern is that once you open even a small can of worms, sometimes the result is that people join the discussion by just bringing more worms. If there was a consensus simple definition of priority and pre-emption that everyone could agree on, most of my worries would evaporate. > > > example: > > *) the draft-ash-... discusses [I think] two priorities, for > > CAC (checked at admission) and restoration (after failure). > Yes, that maps nicely onto establishment and holding > priorities, just like in MPLS and RSVP. So far as I can tell, restoration priority in the ITU sense is not the same concept as holding ("defending") priority in the RSVP/3181 sense: in the 3181 model, during CAC, the preemption priority of the new flow is compared with defending priority of existing flows, so both priorities are CAC-related. There is no separate concept of restoration priority in 3181 (at least, that I can find.) Note I'm not asserting that you definitely need to have 3 priority values (e.g. that restoration priority can't be derived from the other two), only that work would need to be done to understand and normalise the already existing set of concepts. And I don't know how long that would take. > > > *) RFC3181 [I think] decomposes the CAC priority into one > > value checked when the call is admitted, and another value > > describing how strongly to defend a call after it has been > > admitted. > If these are different I must be failing to see the subtleties... see above (I may be finding subtleties where there are none). > > > *) In the mobile environment, a distinction is made between the > > priority for an entirely new call, compared to one where new > > resources are needed because of a handover. (In NSIS terms: > > does the concept of priority apply to flows or sessions?) > > > Ditto for establishment versus holding priorities. Again, I think this is a separate concept: essentially, there are two different reasons why you might need new resources on an interface: 1. because there is a new session ("call") in the network, or 2. because there an existing session which is starting to use a new interface (e.g. because of a mobile node having moved), which is then higher priority than case (1). This seems like the same reasoning behing preemption and defending priorities (the ordering typically assumed is the same); however, in case (2), you would be using the defending priority of the handed-over flow to decide whether to admit it at the new node. So it is at least a different algorithm. > > > In addition, while these concepts may be well understood for > > QoS, and the *concept* of priority may be well understood for > > NATs (i.e. contention for the address pool), do we really have > > any confidence that the actual definitions derived from a QoS > > perspective carry over to the NAT world? > No, but do we have a counter-example? Sometimes it's best to > be guided by > intuition based on experience with existing resource > preemption schemes > that have or have not worked in the past. > > > Is restoration at the > > per-flow level meaningful to describe? > Is this rhetorical? It's like asking if per-flow QoS makes sense when > resources are only allocated in aggregates. Pre-emption > behavior is (I > think) well defined in these cases. What gets complicated are > the policy > issues around choosing the state to preempt when the choice is > non-deterministic (as are many interesting cases). However, > these issues to > not affect the protocol - they are local algorithms. It's sort of rhetorical: the analogue of restoration in the QoS sense would presumably be that a NAT has some public address space, which it then loses, and attempts to restore. If it gets the same addresses back (or some of them) it would just allow them to continue to be used; if the new public addresses are different, it would surely be up to endpoints to reestablish sessions anyway. The fundamental difference from QoS is that the QoS resource - once allocated - is not structurally bound to that flow, it's only bound inside the node doing the allocation, and that node can swap resources between flows while only causing a performance change. NATs have much less freedom about re-allocating already allocated resources. (Of course, you could solve this particular issue by saying 'NATs ignore restoration priority' - if the generic object has such a thing in the first place. But it's just an example of where different resource structures lead to different priority processing.) > > Note: what does affect the protocol is the need to > communicate fate-sharing > and some possible intermediate states for resources which are > fate-shared. > I have a talk on this subject which I've been giving the last > couple of > months and have some suggestions for how to handle this. I > briefly alluded > to this in the NSIS meeting where I proposed that we need > both explicit > "resource sharing" identifiers and "fate-sharing" identifiers for > resources. I would claim that these two things are also elements that > belong in some commmon layer above the transport and below > the individual > NSLPs. > > > Do we even want to think > > about a protocol which implies the ability to pre-empt an address? > > > Yes, why not? It already happens when translation entries get > reused - all > we're doing is explicitly signaling and hence making the > system work better! I just imagine certain security concerns... [snip] > > either we have to go through a *long* activity to define a fully > > functional MLPP object, or we have a simple one but accept that > > MLPP objects will appear at multiples layers (yuk). > First, I don't see why this has to be long and complicated. > We have good > existing work to guide us. Second, I suspect that if we have > something well > designed there will not in fact be a need for custom stuff in > individual > NSLPs. The benefit of consistent preemption behavior across > resource types > should (in my mind anyway) outweigh the per-application optimizations > people always seem to want for dubious reasons. This would be nice (could be a persuasive argument, in the right hands...) [snip] > > So far as the QoS NSLP is concerned, I think the current approach > > of attacking the problem via the QoS models is a good one. (One > > implication of this is that it should consider 3181 as one of the > > inputs.) > You lost me on this one. I don't see how QoS models help or > hinder the > ability to do preemption. Try again? 2nd try: brain-work is under way inside the QoS-Model 'team' to understand the problem better and to establish what the common features are (at least for the QoS application). When we see the results of that work we will have made some progress. (We don't have people working on the cross-NSLP aspects, though.) > > > However, even here, I don't see what are the real arguments > > for making the MLPP aspects part of the base protocol - is > it because > > there are strong interactions with the other parts of the protocol? > No, it's because a single end-to-end application doing NSIS > signaling may > have multiple resource types from multiple NSLPs allocated > and it needs to > be able to communicate the preemption properties it wants for > those things > in a consistent way. This becomes even more critical once we > peel the onion > one more layer and look at fate sharing, where the resource > identifiers and > their preemption-properties need to be communicated in application > protocols as well as in NSIS. Good point (again). robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Mar 29 11:04:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07086 for ; Mon, 29 Mar 2004 10:17:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yW0-0005lI-3t for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 10:17:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TFHRJ6022108 for nsis-archive@odin.ietf.org; Mon, 29 Mar 2004 10:17:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yVp-0005fp-00; Mon, 29 Mar 2004 10:17:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yUU-0005Rv-I0 for nsis@optimus.ietf.org; Mon, 29 Mar 2004 10:15:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06890 for ; Mon, 29 Mar 2004 10:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7yUS-0001Fe-00 for nsis@ietf.org; Mon, 29 Mar 2004 10:15:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7yTe-000165-00 for nsis@ietf.org; Mon, 29 Mar 2004 10:15:03 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B7ySw-0000us-00 for nsis@ietf.org; Mon, 29 Mar 2004 10:14:18 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2TFEHqY007984 for ; Mon, 29 Mar 2004 17:14:17 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Mar 2004 17:14:17 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 29 Mar 2004 17:14:17 +0200 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'sven.van_den_bosch@alcatel.be'" Cc: nsis@ietf.org, "Ash, Gerald R (Jerry), ALABS" Subject: RE: [NSIS] Plans for the protocol drafts Date: Mon, 29 Mar 2004 11:31:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 29 Mar 2004 15:14:17.0199 (UTC) FILETIME=[80BC47F0:01C415A0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Sven, If WG decides that we need reservation priority, I think, it is common feature for QoS models, so it should be defined in QoS NSLP. Best regards, Attila -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of sven.van_den_bosch@alcatel.be Sent: Friday, March 26, 2004 3:42 PM To: Ash, Gerald R (Jerry), ALABS Cc: nsis@ietf.org; Ash, Gerald R (Jerry), ALABS Subject: RE: [NSIS] Plans for the protocol drafts Hi Jerry, Sorry for the delayed reply. Please find some comments inline. Best regards, Sven "Ash, Gerald R (Jerry), ALABS" on 24/03/2004 16:17:07 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, cc: "Ash, Gerald R (Jerry), ALABS" Subject: RE: [NSIS] Plans for the protocol drafts Hi Sven, Dave> 6. Reservation priority is declared out of scope Dave> but is critically important. We can't just punt Dave> this. One thought is to have it be part of a set Dave> of "common facilities" that go across all the Dave> GIMPS applications. I bet there are a number of Dave> such common things which are not part of the Dave> transport but aren't specific to a particular Dave> signaling application. Sven> We would like to receive input on this from the Sven> WG. Why do they think it is needed, what are the Sven> requirements, ... I agree with Dave that 'reservation priority' is critically important to add. IMO there should be a requirement for reservation priority (i.e., for emergency services/ETS/E911, etc.) for the NSLP QoS signaling. The 'standard Qspec' being worked now by the QoS model draft teams can be the vehicle to introduce this. As requested by John (and the WG), we will work out a common Qspec across models, and maximize commonality. To maximize commonality, I think it preferable to make reservation priority a part of the common QoS NSLP rather than part of the individual QoS model (opaque to QoS NSLP). As discussed in 'NSIS Network Service Layer Protocol QoS Signaling Proof-of-Concept' http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt , reservation priority is a way to differentiate emergency services flows, and assign them a higher priority than normal or best-effort priority flows. Requirements for reservation priority are suggested in Section B.4 'Support of Priority & Reliability Attributes': a. Reliability can be requested in the form of a Priority Class for a specific network function, such as CAC priority. b. There are a limited number of Priority Classes to ensure scalability (e.g., 3 classes), such as: - CAC Priority Class: The urgency with which a service connection is desired (e.g., High, Normal, Best Effort). - Restoration Priority Class: The urgency with which a service requires successful restoration under failure conditions (e.g., High, Normal, Best Effort). Sven>> I agree with you that reservation priority is needed and I believe that the proposals that you mention are probably a good way of implementing it if you want to support it. What I am not sure about is whether it should be part of the QoS NSLP. Even if it is common to multiple QoS models, it still would only affect the Resource Management Function (RMF) (unlike the message priority) which makes it outside of the QoS NSLP scope in my opinion. Anyway, I think it is good that the concept and the potential solution matures in the QoS model draft team. We can decide when we see what it turned out to be whether we still want to put it in the QoS NSLP spec. Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 18:43:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04522 for ; Tue, 30 Mar 2004 18:43:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj5-0006ZK-Gy for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SEnI89001016 for nsis-archive@odin.ietf.org; Sat, 28 Feb 2004 09:49:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5m1-00006X-Qw; Sat, 28 Feb 2004 09:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5lI-00089M-HM for nsis@optimus.ietf.org; Sat, 28 Feb 2004 09:48:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18221 for ; Sat, 28 Feb 2004 09:48:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5lG-0005ox-00 for nsis@ietf.org; Sat, 28 Feb 2004 09:48:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax5kR-0005iE-00 for nsis@ietf.org; Sat, 28 Feb 2004 09:47:24 -0500 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5jb-0005bc-00 for nsis@ietf.org; Sat, 28 Feb 2004 09:46:31 -0500 Received: from ibzgate.ibz.gwdg.de ([134.76.38.21] helo=cs.uni-goettingen.de) by mailer.gwdg.de with esmtp (Exim 4.20) id 1Ax5jO-00022b-Bz; Sat, 28 Feb 2004 15:46:18 +0100 Message-ID: <4040A9A2.3060406@cs.uni-goettingen.de> Date: Sat, 28 Feb 2004 15:45:54 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: "McDonald, Andrew" , "'Georgios Karagiannis'" , "'sven.van_den_bosch@alcatel.be'" , "'Kappler Cornelia'" , "'Cheng Hong'" , "'nsis@ietf.org'" Subject: Re: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Hancock, Robert wrote: > hi, > [just to reassure you: if a message arrived in C-mode you > can always send back a message along the same association; Just from a programmer's view: In TCP, connections are duplex but conceptually "uni-directional" between a server and a client: once a connection is set up, data can be sent by the server back toward the client, but the control is in the client side (i.e., these data are sent when the server passively acquires a request from the client). Of course with some tricks in programming, a true uni-directionality can be made possible, but at cost of possibly more complex socket operation. As a tradeoff, another connection - we just need one connection in maximum per direction between a GIMPS-peer pair - in the reverse direction could be an viable option. > D-mode messages always include the Node-Addressing of the > peer that sent it, so you can respond direct to that.] If the data does not concern with any other nodes in between these two D-mode peers (e.g., just to acknowledge the previous D- sender), this can work. However, if in the reverse way changing something in the middle is desired, we have to rely on PHOP info as in RSVP. Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 18:49:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06063 for ; Tue, 30 Mar 2004 18:49:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj0-0006ZK-A6 for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HFg7ZG011284 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:42:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7ML-0002vr-IA; Tue, 17 Feb 2004 10:42:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7M2-0002uT-I2 for nsis@optimus.ietf.org; Tue, 17 Feb 2004 10:41:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06448 for ; Tue, 17 Feb 2004 10:41:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7Lz-0001g6-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:41:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7KP-0001OY-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:40:06 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1At7JQ-0001Dq-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:39:04 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1HFd2Ah005799 for ; Tue, 17 Feb 2004 16:39:02 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Feb 2004 16:39:02 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJ2KMG1>; Tue, 17 Feb 2004 16:40:20 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: Thanh Tra LUU , nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 16:42:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 17 Feb 2004 15:39:02.0657 (UTC) FILETIME=[2B336F10:01C3F56C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Nary Tra, Thank you for your comments and questions, please find my answers below, Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Thanh Tra LUU > Sent: Tuesday, February 17, 2004 2:14 PM > To: nsis@ietf.org > Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > hi Attila, > > i've read your draft. i see it as the continuation of rmd model, an one of > many models that qos-nslp can support. i find it very interesting and i have > some questions to understand better your model. > > 1. How to translate a resource request into resource units request? The > translation ensures all qos parameters of the original request ? (e.g. > delay) One of the main goals of RMD is to have a very simple resource reservation in interior nodes, therefore all QoS parameters have to be translated into resource units, also delay. This means that reservation may has to be made for peak rate. The number of reource units that has to be reserved for an incoming resoure request depends also on the traffic model used and we see it as an ortogonal problem to the signalling. > 2. There is a timer for each reservation per flow in interior nodes, so an > interior node charge will linearly increase following the number of per flow > sessions? > Not exactly, there is not a timer for each flow. In reservation based method we use a sliding window algorithm. The window size is the refresh period and it is divided into N time slots. The window is moved by these time steps. The number of refreshed units and new reservations are counted in each window and the reservation is increased by the difference of these two. Therefore the stored states scales with N. > 3. In the last paragraph of 2(protocol model), 'they are not able to > establish and maintain security associations with their neighbors, which > means, they can only be applied in a trusted domain'. The stateless does not > mean no security association. In rsvp, the sa is not specified how it can > create (maybe by ike, manual) and which node is the next rsvp-aware node. > The RMD QoS-NSLP model relies on the (intra-domain) security associations provided by the QoS-NSLP protocol. > 4. you didn't introduce what TIME_VALUES object is. Just because i'd like to > know it more clearly. This is inherited from QoS-NSLP, now I see that it is called REFRESH_PERIOD in the QoS NSLP draft. It is the same as TIME_VALUES of RSVP. > > 5. an interior node can be an edge node of other flows ? No, this was not our purpose. But it is possible to configure an interior node to operate also as an edge node. In that situation additional functionalities have to be included, e.g., when and how the node is used as interior and when as an edge node. > > 6. it seems that an ingress node must know the egress node before making the > local reservation. Can it be done at the same time ? tell me the reason why > you don't integrate the e2e reservation and local reservation in a same > message. I might see the reason in rfc3175, but it's not the answer in your > case. > The main reason is the transport of messages. Most of the RMD QoS NSLP messages should be transported in datagram mode, e2e messages usually need reliable transport. > thanks & regards > > Nary Tra, > ENST, Paris This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 18:52:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06924 for ; Tue, 30 Mar 2004 18:52:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rix-0006Yx-Uh for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DB2MNJ004861 for nsis-archive@odin.ietf.org; Fri, 13 Feb 2004 06:02:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arb3x-0001Bk-JS; Fri, 13 Feb 2004 06:00:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arb2N-0000T5-6y for nsis@optimus.ietf.org; Fri, 13 Feb 2004 05:59:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04036 for ; Fri, 13 Feb 2004 05:59:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arb2D-0004Q8-00 for nsis@ietf.org; Fri, 13 Feb 2004 05:59:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arb16-0004Kh-00 for nsis@ietf.org; Fri, 13 Feb 2004 05:57:53 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1Arb0q-0004GS-00 for nsis@ietf.org; Fri, 13 Feb 2004 05:57:36 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i1DAvah07495 for ; Fri, 13 Feb 2004 11:57:37 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1DAvZV01153 for ; Fri, 13 Feb 2004 11:57:35 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Feb 2004 11:57:00 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D2E@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: nsis@ietf.org Date: Fri, 13 Feb 2004 11:57:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] security threats for nsis Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, we (dirk and myself) have compiled a new version of the threats draft. you can find a pre-04 version at: http://www.tschofenig.priv.at/drafts/draft-ietf-nsis-threats-04pre.txt i have also created a html 03/04-diff version of the draft which can be found at: http://www.tschofenig.priv.at/drafts/draft-ietf-nsis-threats-04-from-3.diff.html due to some formating problems (too long lines) in version 03 you see a large number of modifications although they really aren't. we would like to thank richard graveman for his detailed review and michael richardson for his recently posted comments. we have incorporated some of them while others are left for further discussion. if you have some comments please let us know (before monday). ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 18:52:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06957 for ; Tue, 30 Mar 2004 18:52:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rix-0006a4-Th for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12ABT7N019621 for nsis-archive@odin.ietf.org; Mon, 2 Feb 2004 05:11:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anb38-000568-Ef; Mon, 02 Feb 2004 05:11:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anb2I-00050X-GB for nsis@optimus.ietf.org; Mon, 02 Feb 2004 05:10:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00359 for ; Mon, 2 Feb 2004 05:10:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anb2F-0007Ts-00 for nsis@ietf.org; Mon, 02 Feb 2004 05:10:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anb1K-0007L1-00 for nsis@ietf.org; Mon, 02 Feb 2004 05:09:34 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1Anb0S-0007EV-00 for nsis@ietf.org; Mon, 02 Feb 2004 05:08:40 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i12A8eb24547; Mon, 2 Feb 2004 11:08:40 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i12A8aw01539; Mon, 2 Feb 2004 11:08:36 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Feb 2004 11:08:03 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC064B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'luu@infres.enst.fr'" Cc: nsis@ietf.org Date: Mon, 2 Feb 2004 11:08:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [NSIS] RE: rsvp doi draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi luu, > hi hannes, > > i see two approaches: > -you define a new doi (as in your draft) > -you only define a new protocol-id in the ipsec doi > > in the second one, it will be easier if you want to change from one > security protocol (prococol-id) to the others, and it reduces > the database > for two doi (in the second approach). i've discussed with ibrahim the > tls/ssl, it seems that he follows the second. however, for the other > reasons, i agree the first is more reasonable. reading their papers i got the impression that they also follow the first approach. maybe i should also discuss this issue with them. tls uses algorithms which are not negotiated by ike. hence, i think you have no other choice than defining a new doi. > > in the msec wg, i see the value doi=2 is used for group > multicase doi. i'm > interested in this approach and i think you might like it. i like the work of the msec working group. the interest in multicast signaling approaches (in case of nsis) is quite low. do you plan to take a closer look at it? > > cheers, > > Nary Tra > ENST,Paris > ciao hannes > > > thanks for making me aware of these documents. i have asked > the authors to > send me a copy and they did it. i have read these two > document to address > your question. you asked whether it would be possible to > register a new doi > value only (without anything else) - if i remember it correctly. > > after reading the paper i must conclude that the approach for > writing a doi > seems to be reasonable. the authors of the above-mentioned papers also > follow the same approach as we did it. their intention is, however, > different. > > ciao > hannes > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 18:58:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08607 for ; Tue, 30 Mar 2004 18:58:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rit-0006Yx-Tm for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IAAFTs001111 for nsis-archive@odin.ietf.org; Thu, 18 Mar 2004 05:10:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uSH-0000A0-9G; Thu, 18 Mar 2004 05:08:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uQq-000053-6M for nsis@optimus.ietf.org; Thu, 18 Mar 2004 05:07:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00574 for ; Thu, 18 Mar 2004 05:07:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uQm-0002Kz-00 for nsis@ietf.org; Thu, 18 Mar 2004 05:07:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uPs-0002EH-00 for nsis@ietf.org; Thu, 18 Mar 2004 05:06:21 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1B3uPO-00026S-00 for nsis@ietf.org; Thu, 18 Mar 2004 05:05:50 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGNF1RM>; Thu, 18 Mar 2004 10:05:15 -0000 Message-ID: From: "Hancock, Robert" To: "'Henning Schulzrinne'" Cc: "Nsis (E-mail)" Subject: RE: [NSIS] Message Looping in GIMPS Date: Thu, 18 Mar 2004 10:05:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, > > However, even in the current design, discovery messages are > > not handled exactly like IP datagrams, because of the policy > > routing/load balancing problem. If a network implements pf/lb in > > all its nodes but only some of them are GIMPS aware, discovery > > messages will be forwarded according to their IP header in the > > GIMPS unaware nodes but according the flow identifier in the > > GIMPS aware nodes; therefore, loops are possible. (I think this > > could probably be counted a pathological condition but it can't > > be ruled out. In particular, such loops, if they did occur, > > probably would not be transient.) > > I don't see how this is different. IP TTL will have the same > effect in > either case. Given that the flow label is part of the header, I'm > confused by the distinction. the point is that even if your network never loops an 'ordinary' IP packet, GIMPS packets might loop because they go through a different forwarding process from ordinary packets. (e.g. if there was a routing policy in place in the network about DCCP traffic being routed a special way, a discovery message relating to a DCCP flow would be routed like DCCP traffic in a GIMPS aware node, but like non-DCCP traffic in a GIMPS-unaware node). what is currently unstated is how the IP TTL is handled in 'forwarded' discovery messages. if it is decremented just as if the packet were being forwarded at the IP layer, this will also sort out loops as you say. > > > > > In addition, it is still possible that people may want to build > > networks where C-mode associations are used to trunk signalling > > messages through GIMPS-only nodes, or there may be other message > > routing mechanisms added later (e.g. for the path-decoupled case). > > Once we loosen the connection with IP routing, loop prevention at > > the GIMPS level becomes a requirement. > > That is indeed the more likely concern, in addition to efficiency. > > > > > So, loop prevention within GIMPS for looping at level (2) is needed. > > > > How to do loop prevention within GIMPS? > > --------------------------------------- > > > *) it's fast. loop detection will be being done mainly on > > datagram messages discovering the next NSLP-aware hop, and we know > > this is a sensitive area for router performance (people would like > > to do this "get this message past a node which doesn't care about > > it" in the fast path if possible). So, a check&decrement of a > > counter (in the fixed header) is preferable to scanning a route > > record for an identity and inserting a new field. > > > > *) we expect looping to be rare (it shouldn't come about through > > GIMPS misconfiguration, initially only pathological IP pf/lb > > situations) so detecting it early and efficiently (which a VIA > > mechanism would do) is less important than making the cost of the > > processing low. > > > > *) it doesn't lead to message expansion. discovery mode messages > > are size limited, and adding route records may make them hard to > > propagate. or, people might want to start record trimming and so > > on. > > > > *) it's simple. we don't have to get into worries about topology > > hiding, what namespaces to use for node identities. > > > > So, I would propose to keep the GHC as a loop detection mechanism > > within the GIMPS layer. (Obviously, the rules about how to process > > it need to be specified more precisely.) This can then also be used > > as *one* weapon to handle message looping at the signalling application > > layer (since NSLPs can read and set the GHC in their messages). > > Note that SIP simply chose to do both, since they have complementary > properties (speed of inspection vs. early discovery and better > diagnostics). I don't see why we couldn't *allow* (not > mandate) that if > route-recording is used, that entities can inspect this and use it to > discover loops. i agree - if GIMPS had a route recording capability, there is no reason not to allow it to be used for loop detection. > > (As a side note: In SIP, we had to deal with 'spirals', where > messages > would visit the same node twice, after modification. I don't > think this > is likely to occur here.) it was partly the question of how GIMPS would know how to distinguish a loop from a spiral which made me cautious here. i agree that SIP-like spiralling seems less likely (but maybe that's just because we haven't thought of all the signalling applications yet...) > > > > > Should GIMPS provide route recording as a service? > > -------------------------------------------------- > > > > Despite all this, it is still possible (likely?) that there is > > a use for route recording for various purposes for use by > > signalling applications. That may be for loop detection or > > something else. Loops may be caused by negotiation loops within > > a single instance of a NSLP (between peers or over a longer > > distance), or by feedback between microflow and aggregate > signalling, > > or any other sort of reason, and the GHC may not be suitable or > > powerful enough to handle this. We could make a recording mechanism > > almost directly out of the comparable functionality in SIP or > > Diameter. > > > > However, I think this functionality comes into the same class as > > some other items of 'generally useful signalling protocol' function, > > like state refresh management or MLPP: it may be useful for several > > signalling applications, but doesn't have a significant interaction > > with the other functions within GIMPS itself. Exactly how to make > > such re-usable components is an interesting question, but our > > assumption within NSIS (up to now) is that it is a question for the > > signalling application layer, not for the NTLP layer. > > I respectfully disagree. Since we'd want to be able to record > every NTLP > hop, not just every NSLP hop, it makes sense to offer this as an > optional service within NTLP. why would one want to record every NTLP hop? this sounds to me more like a signalling application ("clever traceroute") in its own right. this is really a question of what people want (and don't want). my reasoning is: - everyone would like to keep the NTLP simple (i.e. not put in extra functions) - route recording could get complicated to specify and implement - route recording seems to have minimal or no interactions with other NTLP functions (so it would be easy to add later) I think a possible approach would be to wait for someone to write a proposal for a route recording object and a set of processing rules. then we could see how it fit into the current GIMPS design, and also how it matched the requirements of different signalling applications. in the meantime, not thinking about it doesn't seem to be too risky a path to take. r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 18:59:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08858 for ; Tue, 30 Mar 2004 18:59:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ris-0006YH-0g for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCW5cx010266 for nsis-archive@odin.ietf.org; Wed, 22 Oct 2003 08:32:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI9j-0002ev-4X; Wed, 22 Oct 2003 08:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI9c-0002dB-Iy for nsis@optimus.ietf.org; Wed, 22 Oct 2003 08:31:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05697 for ; Wed, 22 Oct 2003 08:31:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACI9W-0004SM-00 for nsis@ietf.org; Wed, 22 Oct 2003 08:31:50 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1ACI9V-0004SE-00 for nsis@ietf.org; Wed, 22 Oct 2003 08:31:49 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 22 Oct 2003 15:31:47 +0300 Date: Wed, 22 Oct 2003 15:31:46 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] Next steps for the analysis document In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, since it seems that there is a need for some analysis and pointers to inter-domain issues, could those people interested in this issue (namely Roland, Rute, Hermann) provide the text and list of references? Please try to be objective, rather than subjective...;) Current Section 6.5 could be turned into Section 7 "Inter-domain Protocols", for example. I would need the text this week. Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 19:01:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09178 for ; Tue, 30 Mar 2004 19:01:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006ZK-RC for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI9gjsG020221 for nsis-archive@odin.ietf.org; Tue, 18 Nov 2003 04:42:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2N1-000547-9N; Tue, 18 Nov 2003 04:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2MV-00053e-CF for nsis@optimus.ietf.org; Tue, 18 Nov 2003 04:41:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11886 for ; Tue, 18 Nov 2003 04:41:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2MS-0001NL-00 for nsis@ietf.org; Tue, 18 Nov 2003 04:41:28 -0500 Received: from web21508.mail.yahoo.com ([66.163.169.19]) by ietf-mx with smtp (Exim 4.12) id 1AM2MR-0001NI-00 for nsis@ietf.org; Tue, 18 Nov 2003 04:41:27 -0500 Message-ID: <20031118094128.60962.qmail@web21508.mail.yahoo.com> Received: from [137.194.2.20] by web21508.mail.yahoo.com via HTTP; Tue, 18 Nov 2003 17:41:28 CST Date: Tue, 18 Nov 2003 17:41:28 +0800 (CST) From: =?iso-8859-1?q?Herve=20Chaplin?= Subject: RE: [NSIS] Mobility-related issues in the NTLP/QoS-NSLP To: nsis@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1491805534-1069148488=:59862" 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: , --0-1491805534-1069148488=:59862 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi Lee, I agree with Nary that more details are neccessary. See some comments in lines : Nary Tra wrote; > draft-jeong-nsis-mobility-ntlp-01 : > > In the section 4, I think more analysis are neccessary: > At first, how can NTLP sent a MOBILE object to the > cross router (CRN), is it sent from the last NTLP node > to the previous (next) node or to the previous/next > mQoS_NSLP hop ? [S-H] We assume that the MOBILITY object can be part of the NTLP information in mobile scenarios, so it can be sent to the CRN by a peer discovery message after handover. If the interactions with CARD & CT are considered, the MOBILITY object can also be transferred from an OAR to the CRN by the CT during handover. We also assume that a peer discovery message is sent between NTLP nodes after handover, and afterward the mQoS-NSLP state can be re-established fast through the CRN. [herve] Peer discovery is only be done between NTLP peer. In case CRN is not the next/previous NTLP node, peer discovery can not be used to detect CRN. > Secondly, how a node know if it is the appropriate > cross router ? You wrote: " When a route change > caused by mobility occurs,the CRN can be recognized > by comparing the existing session identifier with the > session identifier of the flow received from an incoming > interface. If the session identifier is still the same and > the flow identifier or interface number has been > changed, the current NSIS-aware node is recognized > as a CRN ". It seems nonsense because this node can > only know there is a routing change. [S-H] After a route change caused by mobility, an NSIS node can set up the NTLP state along the new path by peer discovery. That is, if an NSIS node has two different NTLP states with the same mQoS-NSLP and session identifier, it can be an appropriate CRN. Note that an NSIS-aware CRN should be a merging point of the old and new paths, which should have two different (old and new) NTLP states. [herve] You defined NTLP states ? How does NTLP node identify its own state (NTLP state) ? > In the section 5, what is dead CRN ? ( CRN is broken > down, NTLP of CRN is broken down ? ) If you mean > peer detection (discovery), I think this is always be > supported for all signaling application. [S-H] We mentioned that the CRN itself could be considered dead when it was temporarily or permanently disconnected from the network due to the failure of communication links (or processors), system rebooting, or node congestion. It is also possible that the NTLP of CRN does not work properly (in this case, the CRN can also be considered dead). Dead peer discovery can be considered as an extension to the peer discovery. [herve] Peer discovery is sent following the downstream toward NR (using flow routing). If a node on the data path dies, nothing can be done because the node sending PD request will never receive ACK, it fails to detect next peer. How can it find a new next peer ? In the upstream path, it is not the same. Your dead peer discovery looks like a keep-alive notification. Right ? More details, please. Herve The New Yahoo! Search - Join the Search Contest. Stand a chance to win prizes! --0-1491805534-1069148488=:59862 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
hi Lee,
 
I agree with Nary that more details are neccessary. See some comments in lines :

Nary Tra wrote;

> draft-jeong-nsis-mobility-ntlp-01 :
>
> In the section 4, I think more analysis are neccessary:
> At first, how can NTLP sent a MOBILE object to the
> cross router (CRN), is it sent from the last NTLP node
> to the previous (next) node or to the previous/next
> mQoS_NSLP hop ?

[S-H] We assume that the MOBILITY object can be part of the NTLP information in mobile scenarios, so it can be sent to the CRN by a peer discovery message after handover. If the interactions with CARD & CT are considered, the MOBILITY object can also be transferred from an OAR to the CRN by the CT during handover.
We also assume that a peer discovery message is sent between NTLP nodes after handover, and afterward the mQoS-NSLP state can be re-established fast through the CRN.
[herve] Peer discovery is only be done between NTLP peer. In case CRN is not the next/previous NTLP node, peer discovery can not be used to detect CRN. 

> Secondly, how a node know if it is the appropriate
> cross router ?  You wrote: " When a route change
> caused by mobility occurs,the CRN can be recognized
> by comparing the existing session identifier with the
> session identifier of the flow received from an incoming > interface. If the session identifier is still the same and
> the flow identifier or interface number has been
> changed, the current NSIS-aware node is recognized
> as a CRN ". It seems nonsense because this node can
> only know there is a routing change.

[S-H] After a route change caused by mobility, an NSIS node can set up the NTLP state along the new path by peer discovery. That is, if an NSIS node has two different NTLP states with the same mQoS-NSLP and session identifier, it can be an appropriate CRN. Note that an NSIS-aware CRN should be a merging point of the old and new paths, which should have two different (old and new) NTLP states.
[herve] You defined NTLP states ? How does NTLP node identify its own state (NTLP state) ?
 

> In the section 5, what is dead CRN ? ( CRN is broken
> down, NTLP of CRN is broken down ? ) If you mean
> peer detection (discovery), I think this is always be
> supported for all signaling application.

[S-H] We mentioned that the CRN itself could be considered dead when it was temporarily or permanently disconnected from the network due to the failure of communication links (or processors), system rebooting, or node congestion. It is also possible that the NTLP of CRN does not work properly (in this case, the CRN can also be considered dead). Dead peer discovery
can be considered as an extension to the peer discovery.
[herve] Peer discovery is sent following the downstream toward NR (using flow routing). If a node on the data path dies, nothing can be done because the node sending PD request will never receive ACK, it fails to detect next peer. How can it find a new next peer ? In the upstream path, it is not the same. Your dead peer discovery looks like a keep-alive notification. Right ? More details, please.
 
Herve

The New Yahoo! Search
- Join the Search Contest. Stand a chance to win prizes! --0-1491805534-1069148488=:59862-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 19:02:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09431 for ; Tue, 30 Mar 2004 19:02:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006ZK-E1 for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF3DIv029568 for nsis-archive@odin.ietf.org; Wed, 18 Feb 2004 10:03:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTEE-0007gT-07; Wed, 18 Feb 2004 10:03:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTDB-0006nw-Gc for nsis@optimus.ietf.org; Wed, 18 Feb 2004 10:02:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16221; Wed, 18 Feb 2004 10:02:01 -0500 (EST) Message-Id: <200402181502.KAA16221@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, 18 Feb 2004 10:02:01 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rsvp-sec-properties-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: , --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 : RSVP Security Properties Author(s) : H. Tschofenig Filename : draft-ietf-nsis-rsvp-sec-properties-04.txt Pages : 46 Date : 2004-2-18 This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done with RSVP and to capture the knowledge about past activities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-04.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-rsvp-sec-properties-04.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-rsvp-sec-properties-04.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: <2004-2-18101637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rsvp-sec-properties-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rsvp-sec-properties-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101637.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 19:02:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09483 for ; Tue, 30 Mar 2004 19:02:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006Yx-D2 for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NFa1Sr001239 for nsis-archive@odin.ietf.org; Thu, 23 Oct 2003 11:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChVJ-0000Jt-Ol; Thu, 23 Oct 2003 11:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChUr-0000EE-Id for nsis@optimus.ietf.org; Thu, 23 Oct 2003 11:35: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 LAA29733; Thu, 23 Oct 2003 11:35:22 -0400 (EDT) Message-Id: <200310231535.LAA29733@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, 23 Oct 2003 11:35:22 -0400 Subject: [NSIS] I-D ACTION:draft-hancock-nsis-routing-mobility-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 : Interactions of Routing and Mobility on NTLP and NSLP Author(s) : R. Hancock, J. Manner, C. Shen Filename : draft-hancock-nsis-routing-mobility-00.txt Pages : 36 Date : 2003-10-23 IP packet routing and changes in routes can have major influence on protocols and services that set state in network nodes. Routing may change, for example, due to node failure within the network, need for load balancing, multihoming or due to end-host or even network mobility. This draft is a first step in helping us to decide on how these problems should be handled and how interactions with other protocols should be handled and a stimulus to further security work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hancock-nsis-routing-mobility-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-routing-mobility-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-routing-mobility-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-23112319.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hancock-nsis-routing-mobility-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hancock-nsis-routing-mobility-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-23112319.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 19:02:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09516 for ; Tue, 30 Mar 2004 19:02:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006Yx-B0 for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF3F6l029814 for nsis-archive@odin.ietf.org; Wed, 18 Feb 2004 10:03:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTEJ-0007ke-A5; Wed, 18 Feb 2004 10:03:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTDN-0006xV-K1 for nsis@optimus.ietf.org; Wed, 18 Feb 2004 10:02:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16262; Wed, 18 Feb 2004 10:02:14 -0500 (EST) Message-Id: <200402181502.KAA16262@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, 18 Feb 2004 10:02:13 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-threats-04.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --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 : Security Threats for NSIS Author(s) : H. Tschofenig, D. Kroeselberg Filename : draft-ietf-nsis-threats-04.txt Pages : 24 Date : 2004-2-18 This threats document provides a detailed analysis of the security threats relevant for the NSIS protocol. It calls attention to and helps with understanding of various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific NSIS protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-04.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-threats-04.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-threats-04.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: <2004-2-18101652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-threats-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-threats-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101652.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 19:03:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09586 for ; Tue, 30 Mar 2004 19:03:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006a4-BO for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF29XL026322 for nsis-archive@odin.ietf.org; Wed, 18 Feb 2004 10:02:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTD8-0006lo-Oj; Wed, 18 Feb 2004 10:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTCb-0006O6-Sg for nsis@optimus.ietf.org; Wed, 18 Feb 2004 10:01:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16057; Wed, 18 Feb 2004 10:01:26 -0500 (EST) Message-Id: <200402181501.KAA16057@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, 18 Feb 2004 10:01:25 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-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. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : A NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Author(s) : M. Stiemerling Filename : draft-ietf-nsis-nslp-natfw-01.txt Pages : 88 Date : 2004-2-18 This draft describes scenarios, problems and solutions for path-coupled Network Address Translator and Firewall signaling. This is one of the two NSIS Signaling Layer Protocols (NSLPs) the working group will address during its work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-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-ietf-nsis-nslp-natfw-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-ietf-nsis-nslp-natfw-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: <2004-2-18101554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101554.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 19:03:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09604 for ; Tue, 30 Mar 2004 19:03:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006ZK-BN for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF297D026323 for nsis-archive@odin.ietf.org; Wed, 18 Feb 2004 10:02:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTD9-0006nd-Vc; Wed, 18 Feb 2004 10:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTCz-0006fd-Ug for nsis@optimus.ietf.org; Wed, 18 Feb 2004 10:01:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16164; Wed, 18 Feb 2004 10:01:50 -0500 (EST) Message-Id: <200402181501.KAA16164@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, 18 Feb 2004 10:01:50 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-02.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 : NSLP for Quality-of-Service signaling Author(s) : S. Van den Bosch Filename : draft-ietf-nsis-qos-nslp-02.txt Pages : 68 Date : 2004-2-18 This draft describes an NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with the NTLP, it provides functionality similar to RSVP and extends it. The QoS-NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This version of the draft focuses on the basic protocol structure. It identifies the different message types and describes the basic operation of the protocol to create, refresh, modify and teardown a reservation or to obtain information on the characteristics of the associated data path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-qos-nslp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-qos-nslp-02.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: <2004-2-18101623.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-nslp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-nslp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101623.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Mar 30 19:03:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09686 for ; Tue, 30 Mar 2004 19:03:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006Yx-7x for nsis-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF290t026321 for nsis-archive@odin.ietf.org; Wed, 18 Feb 2004 10:02:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTD9-0006ml-DE; Wed, 18 Feb 2004 10:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTCp-0006ZI-JD for nsis@optimus.ietf.org; Wed, 18 Feb 2004 10:01:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16133; Wed, 18 Feb 2004 10:01:40 -0500 (EST) Message-Id: <200402181501.KAA16133@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, 18 Feb 2004 10:01:39 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-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. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : GIMPS: General Internet Messaging Protocol for Signaling Author(s) : H. Schulzrinne Filename : draft-ietf-nsis-ntlp-01.txt Pages : 64 Date : 2004-2-18 This document specifies protocol stacks for the routing and transport of per-flow signaling messages along the path taken by that flow through the network. The solution uses existing transport and security protocols under a common messaging layer, the Generic Internet Messaging Protocol for Signaling (GIMPS), which provides a universal service for diverse signaling applications. GIMPS does not handle signaling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIMPS and the lower layer protocols provides a solution for the base protocol component of the 'Next Steps in Signaling' framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-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-ietf-nsis-ntlp-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-ietf-nsis-ntlp-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: <2004-2-18101607.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101607.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Mar 31 08:58:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23209 for ; Wed, 31 Mar 2004 08:58:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8gEH-00031P-CX for nsis-archive@odin.ietf.org; Wed, 31 Mar 2004 08:58:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VDw5wM011616 for nsis-archive@odin.ietf.org; Wed, 31 Mar 2004 08:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8gED-00030s-MX; Wed, 31 Mar 2004 08:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8gDL-0002zD-7s for nsis@optimus.ietf.org; Wed, 31 Mar 2004 08:57:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23151 for ; Wed, 31 Mar 2004 08:57:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8gDJ-0000RW-00 for nsis@ietf.org; Wed, 31 Mar 2004 08:57:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8gCl-0000Nz-00 for nsis@ietf.org; Wed, 31 Mar 2004 08:56:32 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1B8g5F-0000BW-00 for nsis@ietf.org; Wed, 31 Mar 2004 08:48:45 -0500 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id i2VDmRCi000223; Wed, 31 Mar 2004 15:48:27 +0200 (MET DST) Message-ID: <015601c41726$d9360a10$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "=?iso-8859-1?Q?Attila_B=E1der_\=28IJ/ETH\=29?=" , Cc: , "Ash, Gerald R \(Jerry\), ALABS" References: Subject: Re: [NSIS] Plans for the protocol drafts Date: Wed, 31 Mar 2004 15:47:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by utrhcs.cs.utwente.nl id i2VDmRCi000223 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all I agree with Attila on this! best regards, Georgios ----- Original Message -----=20 From: "Attila B=E1der (IJ/ETH)" To: Cc: ; "Ash, Gerald R (Jerry), ALABS" Sent: Monday, March 29, 2004 11:31 AM Subject: RE: [NSIS] Plans for the protocol drafts > Hi Sven, > > If WG decides that we need reservation priority, I think, it is common feature for QoS models, so it should be defined in QoS NSLP. > > Best regards, Attila > > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > sven.van_den_bosch@alcatel.be > Sent: Friday, March 26, 2004 3:42 PM > To: Ash, Gerald R (Jerry), ALABS > Cc: nsis@ietf.org; Ash, Gerald R (Jerry), ALABS > Subject: RE: [NSIS] Plans for the protocol drafts > > > Hi Jerry, > > Sorry for the delayed reply. Please find some comments inline. > > Best regards, > Sven > > > > > > "Ash, Gerald R (Jerry), ALABS" on 24/03/2004 16:17:07 > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, > cc: "Ash, Gerald R (Jerry), ALABS" > Subject: RE: [NSIS] Plans for the protocol drafts > > > Hi Sven, > > Dave> 6. Reservation priority is declared out of scope > Dave> but is critically important. We can't just punt > Dave> this. One thought is to have it be part of a set > Dave> of "common facilities" that go across all the > Dave> GIMPS applications. I bet there are a number of > Dave> such common things which are not part of the > Dave> transport but aren't specific to a particular > Dave> signaling application. > > Sven> We would like to receive input on this from the > Sven> WG. Why do they think it is needed, what are the > Sven> requirements, ... > > I agree with Dave that 'reservation priority' is critically important t= o > add. IMO there should be a requirement for reservation priority (i.e., for > emergency services/ETS/E911, etc.) for the NSLP QoS signaling. The > 'standard Qspec' being worked now by the QoS model draft teams can be t= he > vehicle to introduce this. As requested by John (and the WG), we will work > out a common Qspec across models, and maximize commonality. > > To maximize commonality, I think it preferable to make reservation priority > a part of the common QoS NSLP rather than part of the individual QoS mo= del > (opaque to QoS NSLP). > > As discussed in 'NSIS Network Service Layer Protocol QoS Signaling > Proof-of-Concept' > http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-= concept-01.txt > , reservation priority is a way to differentiate emergency services flo= ws, > and assign them a higher priority than normal or best-effort priority > flows. Requirements for reservation priority are suggested in Section = B.4 > 'Support of Priority & Reliability Attributes': > a. Reliability can be requested in the form of a Priority Class for a > specific network function, such as CAC priority. > b. There are a limited number of Priority Classes to ensure scalability > (e.g., 3 classes), such as: > - CAC Priority Class: The urgency with which a service connection is > desired (e.g., High, Normal, Best Effort). > - Restoration Priority Class: The urgency with which a service requires > successful restoration under failure conditions (e.g., High, Normal, Be= st > Effort). > > Sven>> I agree with you that reservation priority is needed and I belie= ve > that the proposals that you mention are probably a good way of implementing > it if you want to support it. What I am not sure about is whether it should > be part of the QoS NSLP. Even if it is common to multiple QoS models, i= t > still would only affect the Resource Management Function (RMF) (unlike = the > message priority) which makes it outside of the QoS NSLP scope in my > opinion. Anyway, I think it is good that the concept and the potential > solution matures in the QoS model draft team. We can decide when we see > what it turned out to be whether we still want to put it in the QoS NSL= P > spec. > > Regards, > Jerry > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Mar 31 09:10:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23472 for ; Wed, 31 Mar 2004 09:10:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8gPs-0003rZ-V1 for nsis-archive@odin.ietf.org; Wed, 31 Mar 2004 09:10:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VEA4io014835 for nsis-archive@odin.ietf.org; Wed, 31 Mar 2004 09:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8gPs-0003qe-0b; Wed, 31 Mar 2004 09:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8gPT-0003lG-Q9 for nsis@optimus.ietf.org; Wed, 31 Mar 2004 09:09:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23405 for ; Wed, 31 Mar 2004 09:09:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8gPS-0000r7-00 for nsis@ietf.org; Wed, 31 Mar 2004 09:09:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8gP0-0000ji-00 for nsis@ietf.org; Wed, 31 Mar 2004 09:09:12 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1B8gMZ-0000cF-00 for nsis@ietf.org; Wed, 31 Mar 2004 09:06:39 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMVDML>; Wed, 31 Mar 2004 15:06:02 +0100 Message-ID: From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , nsis@ietf.org Date: Wed, 31 Mar 2004 15:06:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] GIMPS etc. planning (was: RE: Plans for the protocol 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: , hi john, all, For info, we (me & Henning) made some rough plans in Seoul about what would be good targets for the next stage or two on GIMPS. People could comment on the following list (or even contribute!) *) a review to look for nice-to-have functionality to remove. *) set up common guidelines on message formats (with the NSLP people). *) define some sort of (abstracted) API between NSLPs and GIMPS (not technically part of the standard but necessary to clarify some of our thinking). *) clarify what bits of NAT handling functionality go where (in conjunction with the NATFW NSLP people), and whether the NATFW NSLP has any special requirements on GIMPS. *) start work on some of the error conditions (reboot handling, last-node problem and so on). So far as mechanisms for progress are concerned, I can certainly see the value in something like an interim, if enough people want to come (I'm less of a fan of wide-open conference calls until we have really precisely defined issues to be finalised, but that may just be a personal issue). Siemens would be happy to host such a meeting in Europe, probably the UK. May is a nice month here, at least sometimes. In the meantime, any input on the current draft would of course be appreciated... Yours, Robert H. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, March 16, 2004 08:21 > To: nsis@ietf.org > Subject: [NSIS] Plans for the protocol drafts > > > Hi all, > > I would like to get some feedback from the WG about the next > steps for the 3 protocol drafts. I would like to progress > the drafts - it would be reasonable to request the authors > release an updated version of the drafts sometime in May. > Would it be helpful to arrange some conference calls around > this, or even an interim meeting before San Diego? > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis