From Stiemerling@nw.neclab.eu Wed Nov 4 13:43:36 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F8F28C14E for ; Wed, 4 Nov 2009 13:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45j4kNEoqOkD for ; Wed, 4 Nov 2009 13:43:35 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 46B3728C14C for ; Wed, 4 Nov 2009 13:43:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 0E6142C0203C1 for ; Wed, 4 Nov 2009 22:43:57 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkuC+3zdnj4p for ; Wed, 4 Nov 2009 22:43:56 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id E39D32C01898B for ; Wed, 4 Nov 2009 22:43:51 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2009 22:43:51 +0100 Message-ID: <547F018265F92642B577B986577D671CE38A75@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS "office hours" at IETF#76 Thread-Index: Acpdl+XXtDjmxFfuT/aFmkhdYHQZHg== From: "Martin Stiemerling" To: "NSIS" Subject: [NSIS] NSIS "office hours" at IETF#76 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 21:43:36 -0000 Dear all, As announced earlier, there will be no NSIS session during the upcoming = IETF meeting.=20 However, to have time to discuss NSIS related topics, Jukka and me will = offer "office hours" during the meeting: WEDNESDAY, November 11, 2009 1510-1610 Afternoon Session II and 1610-1630 Afternoon Beverage and Snack Break We will announce the place where we meet later on. Let us know if you plan to come and what you like to discuss: = nsis-chairs@tools.ietf.org Thanks, Martin stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 From Stiemerling@nw.neclab.eu Tue Nov 10 22:17:07 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1EA28C2C0 for ; Tue, 10 Nov 2009 22:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYUnF-ojm3YW for ; Tue, 10 Nov 2009 22:17:06 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B29E228C2B5 for ; Tue, 10 Nov 2009 22:17:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5B5532C01C9B0 for ; Wed, 11 Nov 2009 07:17:34 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp1f3f5coWDj for ; Wed, 11 Nov 2009 07:17:34 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 3716B2C01C99C for ; Wed, 11 Nov 2009 07:17:29 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Nov 2009 07:17:06 +0100 Message-ID: <547F018265F92642B577B986577D671CE39101@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671CE38A75@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS "office hours" at IETF#76 Thread-Index: Acpdl+XXtDjmxFfuT/aFmkhdYHQZHgE/m6UQ References: <547F018265F92642B577B986577D671CE38A75@VENUS.office> From: "Martin Stiemerling" To: "NSIS" Subject: Re: [NSIS] NSIS "office hours" at IETF#76 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:17:07 -0000 somewhat got my initial email lost:=20 The location is in front of Acacia West.=20 Martin stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf = Of > Martin Stiemerling > Sent: Thursday, November 05, 2009 6:44 AM > To: NSIS > Subject: [NSIS] NSIS "office hours" at IETF#76 >=20 > Dear all, >=20 > As announced earlier, there will be no NSIS session during the = upcoming > IETF meeting. >=20 > However, to have time to discuss NSIS related topics, Jukka and me = will > offer "office hours" during the meeting: >=20 > WEDNESDAY, November 11, 2009 > 1510-1610 Afternoon Session II > and > 1610-1630 Afternoon Beverage and Snack Break >=20 > We will announce the place where we meet later on. >=20 > Let us know if you plan to come and what you like to discuss: nsis- > chairs@tools.ietf.org >=20 > Thanks, >=20 > Martin >=20 >=20 > stiemerling@nw.neclab.eu >=20 > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis From Stiemerling@nw.neclab.eu Tue Nov 10 22:39:09 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBED428C29B for ; Tue, 10 Nov 2009 22:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN0C6c8ppanh for ; Tue, 10 Nov 2009 22:39:08 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 07DB83A68F3 for ; Tue, 10 Nov 2009 22:39:05 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EA47C2C01C99C for ; Wed, 11 Nov 2009 07:18:51 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW030+kIP-61 for ; Wed, 11 Nov 2009 07:18:51 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id CC2E42C01898B for ; Wed, 11 Nov 2009 07:18:46 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Nov 2009 07:18:45 +0100 Message-ID: <547F018265F92642B577B986577D671CE39102@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS "office hours" at IETF#76 Thread-Index: Acpdl+XXtDjmxFfuT/aFmkhdYHQZHgE/m6UQAAAXcWA= References: <547F018265F92642B577B986577D671CE38A75@VENUS.office> From: "Martin Stiemerling" To: "NSIS" Subject: Re: [NSIS] NSIS "office hours" at IETF#76 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:39:09 -0000 ok, we meet in the 4th floor in front of Camelia stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Martin Stiemerling > Sent: Wednesday, November 11, 2009 3:17 PM > To: NSIS > Subject: RE: [NSIS] NSIS "office hours" at IETF#76 >=20 > somewhat got my initial email lost: >=20 > The location is in front of Acacia West. >=20 >=20 > Martin >=20 > stiemerling@nw.neclab.eu >=20 > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 > > -----Original Message----- > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf > Of > > Martin Stiemerling > > Sent: Thursday, November 05, 2009 6:44 AM > > To: NSIS > > Subject: [NSIS] NSIS "office hours" at IETF#76 > > > > Dear all, > > > > As announced earlier, there will be no NSIS session during the > upcoming > > IETF meeting. > > > > However, to have time to discuss NSIS related topics, Jukka and me > will > > offer "office hours" during the meeting: > > > > WEDNESDAY, November 11, 2009 > > 1510-1610 Afternoon Session II > > and > > 1610-1630 Afternoon Beverage and Snack Break > > > > We will announce the place where we meet later on. > > > > Let us know if you plan to come and what you like to discuss: nsis- > > chairs@tools.ietf.org > > > > Thanks, > > > > Martin > > > > > > stiemerling@nw.neclab.eu > > > > NEC Laboratories Europe - Network Research Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www.ietf.org/mailman/listinfo/nsis From root@core3.amsl.com Tue Nov 10 23:15:10 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4FA3E3A68C4; Tue, 10 Nov 2009 23:15:05 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091111071507.4FA3E3A68C4@core3.amsl.com> Date: Tue, 10 Nov 2009 23:15:05 -0800 (PST) Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-22.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 07:15:12 -0000 --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 : QoS NSLP QSPEC Template Author(s) : A. Bader, G. Ash, C. Kappler, D. Oran Filename : draft-ietf-nsis-qspec-22.txt Pages : 57 Date : 2009-11-10 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. The node initiating the NSIS signaling adds an initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-22.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-nsis-qspec-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-10230904.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Wed Nov 11 01:08:12 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 820BE3A69B0; Wed, 11 Nov 2009 01:08:12 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091111090812.820BE3A69B0@core3.amsl.com> Date: Wed, 11 Nov 2009 01:08:12 -0800 (PST) Cc: nsis@ietf.org Subject: [NSIS] Last Call: draft-ietf-nsis-qos-nslp (NSLP for Quality-of-Service Signaling) to Experimental RFC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 09:08:12 -0000 The IESG has received a request from the Next Steps in Signaling WG (nsis) to consider the following document: - 'NSLP for Quality-of-Service Signaling ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-11-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-17.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10853&rfc_flag=0 From wwwrun@core3.amsl.com Wed Nov 11 01:09:06 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 07B5F28C112; Wed, 11 Nov 2009 01:09:05 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091111090906.07B5F28C112@core3.amsl.com> Date: Wed, 11 Nov 2009 01:09:06 -0800 (PST) Cc: nsis@ietf.org Subject: [NSIS] Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 09:09:06 -0000 The IESG has received a request from the Next Steps in Signaling WG (nsis) to consider the following document: - 'QoS NSLP QSPEC Template ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-11-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-22.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12323&rfc_flag=0 From acmorton@att.com Fri Nov 13 11:54:30 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4923A6A42 for ; Fri, 13 Nov 2009 11:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.611 X-Spam-Level: X-Spam-Status: No, score=-105.611 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWxUoDNUEA-m for ; Fri, 13 Nov 2009 11:54:30 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id BF08D3A6918 for ; Fri, 13 Nov 2009 11:54:29 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-5.tower-121.messagelabs.com!1258142098!31396136!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 7440 invoked from network); 13 Nov 2009 19:54:58 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-5.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Nov 2009 19:54:58 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id nADJsv2Z016306 for ; Fri, 13 Nov 2009 13:54:58 -0600 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id nADJspaM016090 for ; Fri, 13 Nov 2009 13:54:51 -0600 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id nADJsplG007463 for ; Fri, 13 Nov 2009 14:54:51 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id nADJshQH007180 for ; Fri, 13 Nov 2009 14:54:43 -0500 Message-Id: <200911131954.nADJshQH007180@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-216-122.vpn.east.att.com[135.70.216.122](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20091113195441gw10014qtve>; Fri, 13 Nov 2009 19:54:42 +0000 X-Originating-IP: [135.70.216.122] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Nov 2009 14:54:39 -0500 To: Magnus Westerlund , draft-ietf-nsis-y1541-qosm@tools.ietf.org, NSIS From: Al Morton In-Reply-To: <4AD87985.6030304@ericsson.com> References: <4AD87985.6030304@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [NSIS] AD review of draft-ietf-nsis-y1541-qosm-07 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 19:54:30 -0000 NSIS WG, At 08:47 AM 10/16/2009, Magnus Westerlund wrote: >3. Section 3.1: What are the definitions of the Bp and M parameter? Those of us who have discussed Magnus' comment above are trying to agree on a path forward. Both parameters have standard definitions: A reference definition for M, max datagram size, is in RFC 2212. ITU-T Y.1221 seems to be the only standard where Bp, the peak Bucket Size of a dual token bucket is specified. I have proposed removing Bp because the additional complexity of a dual token bucket is not essential to the main subject of the draft (the Y.1541 classes). I have asked at this week's ITU-T meeting, and the only implementors of ITU-T Y.1221 indicated that they were not using Bp, only the parameters for a single token bucket. Jerry Ash would like to retain Bp, citing the informational ITU-T Supplement referenced in the draft, and indicated that dual token buckets are well-established and non-controversial. Others have asked me to phrase the question to the list. So, with the above background, should we simplify and drop Bp, or keep it in? thanks and regards, Al From gash5107@yahoo.com Fri Nov 13 14:29:47 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6923A684A for ; Fri, 13 Nov 2009 14:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.042 X-Spam-Level: X-Spam-Status: No, score=-100.042 tagged_above=-999 required=5 tests=[AWL=2.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKYpZhFV3Rnh for ; Fri, 13 Nov 2009 14:29:46 -0800 (PST) Received: from web63601.mail.re1.yahoo.com (web63601.mail.re1.yahoo.com [69.147.97.71]) by core3.amsl.com (Postfix) with SMTP id CE4533A67AA for ; Fri, 13 Nov 2009 14:29:45 -0800 (PST) Received: (qmail 72839 invoked by uid 60001); 13 Nov 2009 22:30:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258151413; bh=y+CKwNhWtALiyoagxAPdV3OJRwyv4u3INptCrNBvctM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XfKezpiU2+Dtl1XK79lqDHNHAj2thplJ0+XIfJt9d0bzA9NXB4/IAekVbE/QDVKx7VhL98TMZ87jkYdwSu2P/SILD13zvAkqve2IQwRgqkHQ0LVYP8HSz4rtRSzoXqQ/Zx+gjf+oiwiXEWHkFUyqk8nsPGJJu0ppDbO8w9PJIhI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HjtIE42kxdyngGrrWGnMC1EUGfcZmExHrOzfQc4VqpU1m+tbTloFFpUJT79oQmsgGCegu6MIca2S7uJFZUppQYyTToZshQGWN6mn18mMMacuCBhg2njhZO6lFMt+32ZXw4hDvHoYGFpANBR4XJVC5WivAofSNPZPHH3PRz0YMoM=; Message-ID: <406754.72502.qm@web63601.mail.re1.yahoo.com> X-YMail-OSG: 0X6ntdEVM1lHDKcGuvMOSTEb1S6vfl7lpgomLB2lOoNrS5YEmxCB0IIPido93D5t_JW4oOPCV8jVucvR6cIWA9vN.r7OjYJGC8Y5fK7jdR1QeTXPIwsgmI8UWBvPQaUk_hHGXrP7YDOV.kbInHe7bmJEWKx_BajK3xnfu62HP_XST0x3_6wRF8xbhyzwoe9wnYZNVzp0KSKPOQbLuoGS5mBKAGyMzVcawTVOHtRZ2tei3FrvozGL0vTzfda0Uhc9UHBeWMVStOdIHF_iIWmwVlpp52RBzpIzaMJdo0giUxkyZU8HnewrgZPdi9tCYteMKeXQOl4jj0f_VSK0zOdpzNta__q6gFgK3HYZM5u3j6EyxLtTFA1n1dcBwc6rMjECmFlyPn5edVcnj3SP72rA8R_Pyjzqbog- Received: from [24.91.148.40] by web63601.mail.re1.yahoo.com via HTTP; Fri, 13 Nov 2009 14:30:13 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.7.361.4 Date: Fri, 13 Nov 2009 14:30:13 -0800 (PST) From: Gerald Ash To: NSIS , Al Morton In-Reply-To: <200911131954.nADJshfh007179@alpd052.aldc.att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1974720766-1258151413=:72502" Cc: draft-ietf-nsis-y1541-qosm@tools.ietf.org Subject: Re: [NSIS] AD review of draft-ietf-nsis-y1541-qosm-07 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 22:29:47 -0000 --0-1974720766-1258151413=:72502 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I wasn't aware that Al Morton was taking this question to the list, so I wo= uld like to clarify the points I'm making regarding the dual token bucket p= arameter Bp: =A0 1. The basis for including the parameter Bp=A0is the=A0ITU-T Recommendation= "Signaling Requirements for IP-QoS" (available at http://www.itu.int/rec/T= -REC-Q.Sup51/en), which=A0REQUIRES the dual token bucket parameters (includ= ing Bp) for QoS signaling.=A0 IMO if the the ITU doesn't want to require a = dual token bucket for QoS signaling, they should revise the requirements.= =A0=A0Perhaps=A0co-authors of=A0the ITU-T QoS signaling requirements could = comment. =A0 2. Magnus only asked for a definition of Bp, which is readily available.=A0= =A0Magnus made no=A0claim that Bp was too complex or any suggestion that th= e parameter should be removed.=A0=A0But rather than simply providing the de= finition as requested, Al Morton has=A0now decided=A0that Bp is too complex= and should=A0be removed. =A0 3. The=A0intent of the Y.1541-QOSM document is to=A0specify an NSIS QoS mod= el (QOSM) based on=A0all QoS signaling requirements=A0contained in=A0ITU-T = recommendations, not only the=A0Y.1541 QoS classes, but also the Q.Sup51 tr= affic model (TMOD) signaling requirements, and restoration priority signali= ng requirements. =A0 Thanks, Jerry=A0 --- On Fri, 11/13/09, Al Morton wrote: From: Al Morton Subject: Re: AD review of draft-ietf-nsis-y1541-qosm-07 To: "Magnus Westerlund" , draft-ietf-nsis-y= 1541-qosm@tools.ietf.org, "NSIS" Date: Friday, November 13, 2009, 2:54 PM NSIS WG, At 08:47 AM 10/16/2009, Magnus Westerlund wrote: >3. Section 3.1: What are the definitions of the Bp and M parameter? Those of us who have discussed Magnus' comment above are trying to agree on a path forward. Both parameters have standard definitions: A reference definition for M, max datagram size, is in RFC 2212. ITU-T Y.1221 seems to be the only standard where Bp, the peak Bucket Size of a dual token bucket is specified. I have proposed removing Bp because the additional complexity of a dual token bucket is not essential to the main subject of the draft (the Y.1541 classes). I have asked at this week's ITU-T meeting, and the only implementors of ITU-T Y.1221 indicated that they were not using Bp, only the parameters for a single token bucket. Jerry Ash would like to retain Bp, citing the informational ITU-T Supplement referenced in the draft, and indicated that dual token buckets are well-established and non-controversial. Others have asked me to phrase the question to the list. So, with the above background, should we simplify and drop Bp, or keep it in? thanks and regards, Al =0A=0A=0A --0-1974720766-1258151413=:72502 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <= /table>
=0A=0A --0-1974720766-1258151413=:72502-- From gash5107@yahoo.com Sun Nov 22 12:15:59 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E563A6774 for ; Sun, 22 Nov 2009 12:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.037 X-Spam-Level: X-Spam-Status: No, score=-102.037 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S32S6LHBt6wS for ; Sun, 22 Nov 2009 12:15:59 -0800 (PST) Received: from web63606.mail.re1.yahoo.com (web63606.mail.re1.yahoo.com [69.147.97.76]) by core3.amsl.com (Postfix) with SMTP id 3BD693A68D5 for ; Sun, 22 Nov 2009 12:15:59 -0800 (PST) Received: (qmail 54893 invoked by uid 60001); 22 Nov 2009 20:15:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258920947; bh=asvPCz089EsPLTCGP59apLMtYirFInlcDmVsTcashWU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PeDYdxVVfusKekaQa3f0cJlIpxWPV2kr+6y9EOvhml/F3uDYeLe13vQ3crwlb9D6XPJ8KzGQ35/iSJASGp6kmq+l6PEDvSUtewsJh5tKbxM5Y3J41S97DPPYfElLbADGqum2CP8CvvG/5z6K7j2BCfjp60COdHd2h0ZnYSMIGv0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xL8Xw0RFPrpf6AIr5JzhMxc7hhu8vEgfuKpa6zEt9XpqmHmgBp3+OrbN9ubnJUjemvw1JSGXCjIVTpD7XVB8+2nvMCWH/JkVxDI54C1L8ykISqH7tXdAEYkp2xfQpFExt4g6qf+s5ArrqZfA6XYzmcgk0N0oc+PqjYUR16iVhRs=; Message-ID: <70090.54109.qm@web63606.mail.re1.yahoo.com> X-YMail-OSG: 7UjvBpUVM1l_m1J75Dpg9mjCeu8ShkM.jyfmWNoGQokiB7O2.625faJ3A.ZMqPrs042S8jcP0YTG_fhEEEM9DXCAENNSvBsqeG4r69HO2xePkly13rixXJFkDo504mg7T3.vR9JseKSi2Z3CXdflB3z0VwDpjXu6lDwbMCLt8x8yDiGTSh8X4RuddC.9DVqs8V5OR2GP.Lkx9Hp7W23X52rHtifzij8bClfhY5RtAkaArCaGE4vECNyeLJzUf3ciDBN142DcIQFYZY6q6rSbbMbYX7exMUdhqZRbJ7F788x_KzS0d6RDAjLWwEc2GLYbSAa_kZNi4YYk4RHDUJiBFh8z3PXpsjDszU1HsAwXSmgUXLs_IdHBPwH1vG8MhY1luwVsEwVWF.Un Received: from [24.91.148.40] by web63606.mail.re1.yahoo.com via HTTP; Sun, 22 Nov 2009 12:15:46 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.8.100.260964 Date: Sun, 22 Nov 2009 12:15:46 -0800 (PST) From: Gerald Ash To: "Joel M. Halpern" In-Reply-To: <4B087892.5050901@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1331346153-1258920946=:54109" Cc: IETF discussion list , draft-ietf-nsis-qspec@tools.ietf.org, General Area Review Team , Mary Barnes , nsis@ietf.org Subject: Re: [NSIS] Gen-Art Review: draft-ietf-nsis-qspec-22.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 20:15:59 -0000 --0-1331346153-1258920946=:54109 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Joel, =A0 Thanks for the quick review.=A0 I agree with all your comments and suggesti= ons. =A0 Regarding your suggestion on RFC type (change it from Informational=A0to PS= ), I believe it could not become=A0PS since the other NSIS documents (GIST = & QoS-NSLP) are Experimental. =A0 Thanks again, Jerry --- On Sat, 11/21/09, Joel M. Halpern wrote: From: Joel M. Halpern Subject: Gen-Art Review: draft-ietf-nsis-qspec-22.txt To: "General Area Review Team" , "Mary Barnes" Cc: "Magnus Westerlun" , "IETF discussion l= ist" , nsis@ietf.org, draft-ietf-nsis-qspec@tools.ietf.org Date: Saturday, November 21, 2009, 6:32 PM I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-nsis-qspec-22 =A0 =A0 QoS NSLP QSPEC Template Reviewer: Joel Halpern Review Date: 21-Nov-2009 IETF LC End Date: 25-Nov-2009 IESG Telechat date: N/A Summary: This document is almost ready for publication as an RFC. I am concerned about the RFC type.=A0 If a revision of the document is need= ed, there are a few minor items to consider for inclusion. Major: I am unclear about whether the intended status (Informational) for this doc= ument is correct. At first, it seemed correct.=A0=A0=A0The document is defined as providing a= template for a resource specification block (a QSPEC), and other model spe= cific documents are expected to define exactly what QoS paramters they will= use. It even seemed fine that this document mandates that the QSPEC include the = indication of the QoS Model.=A0 That is necessary information. Where I start to have concerns is in section 3.1 of this document. There, t= he document starts specifying requirements on any and of QoS Model document= s.=A0 It says things like "A QOSM specification MUST include the following:= ".=A0 If this document is defining normative requirements for standards tra= ck documents (and the text explicitly states that QOSM definitions sometime= s need to be standards track), then I don't see how it can be an informatio= nal document. If the QOSM requirements, and the QSPEC support requirements ("The QSPEC ob= jects ... MUST be supported by QNEs.") are actually copied from some other = document, then the problem is a lesser issue of unclear referent.=A0 But if= this document is the source for these normative requirements, it does seem= that Informational is wrong. Given that this document actually defines bits to be used on the wire, it m= ay be appropriate to publish it as a PS. Alternatively, BCP may be acceptable, although a bit unusual. The fact that this document defines the format of information fields and in= cludes the IANA registration for those fields to be used in QOSM documents = also suggests that informational is inappropriate as it would create a conc= eptual dependence of all standards track QOSM documents on an Informational= RFC.=A0 Also, this document includes guidelines to follow in future IANA a= llocations. Minor: In describing the constraints parameters, the text in section 3.3.2 careful= ly describes the semantics, and the composition rule.=A0 However, it seems = to leave out the unit of measure. (The constraints are given in the detaile= d message information formats section, but it would seem sensible to includ= e them in 3.3.2.) Editorial: Should there be an editorial note when "minimum QoS" is first described ind= icating that the term "minimum" is used generically, as for many parameters= , like loss rate or latency, what needs to be specified is the maximum acce= ptable value? =0A=0A=0A --0-1331346153-1258920946=:54109 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I wasn't aware that Al Morton was taking= this question to the list, so I would like to clarify the points I'm makin= g regarding the dual token bucket parameter Bp:
 
1. The basis for including the parameter Bp is the ITU-T Rec= ommendation "Signaling Requirements for IP-QoS" (available at = http://www.itu.int/rec/= T-REC-Q.Sup51/en), which REQUIRES the dual token bucket parameters= (including Bp) for QoS signaling.  IMO if the the ITU doesn't want to= require a dual token bucket for QoS signaling, they should revise the requ= irements.  Perhaps co-authors of the ITU-T QoS signalin= g requirements could comment.
 
2. Magnus only asked for a definition of Bp, which is readily availabl= e.  Magnus made no claim that Bp was too complex or any sugg= estion that the parameter should be removed.  But rather than sim= ply providing the definition as requested, Al Morton has now decided&n= bsp;that Bp is too complex and should be removed.
 
3. The intent of the Y.1541-QOSM document is to specify an N= SIS QoS model (QOSM) based on all QoS signaling requireme= nts contained in ITU-T recommendations, not only the Y.1541 = QoS classes, but also the Q.Sup51 traffic model (TMOD) signaling requiremen= ts, and restoration priority signaling requirements.
 
Thanks,
Jerry 

--- On Fri, 11/13/09, Al Morton <acmorton@= att.com> wrote:

From: Al Morton <acmorton@att.com>
Subje= ct: Re: AD review of draft-ietf-nsis-y1541-qosm-07
To: "Magnus Westerlun= d" <magnus.westerlund@ericsson.com>, draft-ietf-nsis-y1541-qosm@tools= .ietf.org, "NSIS" <nsis@ietf.org>
Date: Friday, November 13, 2009,= 2:54 PM

NSIS WG,

At 08:47 AM 10/16/2009, Magnus Weste= rlund wrote:
>3. Section 3.1: What are the definitions of the Bp and = M parameter?

Those of us who have discussed Magnus' comment above ar= e
trying to agree on a path forward.

Both parameters have standar= d definitions:
A reference definition for M, max datagram size, is in RF= C 2212.
ITU-T Y.1221 seems to be the only standard where Bp,
the peak= Bucket Size of a dual token bucket is specified.

I have proposed re= moving Bp because the additional complexity
of a dual token bucket is no= t essential to the main subject
of the draft (the Y.1541 classes).
I = have asked at this week's ITU-T meeting, and the only implementors
of IT= U-T Y.1221 indicated that they were not using Bp,
only the parameters fo= r a single token bucket.

Jerry Ash would like to retain Bp, citing t= he informational
ITU-T Supplement referenced in the draft, and indicated that
dual token buckets are well-established and non-controve= rsial.

Others have asked me to phrase the question to the list.
S= o, with the above background, should we simplify and drop Bp,
or keep it= in?

thanks and regards,
Al

Joel,
 
Thanks for the quick review.  I agree with all your comments and = suggestions.
 
Regarding your suggestion on RFC type (change it from Informational&nb= sp;to PS), I believe it could not become PS since the other NSIS docum= ents (GIST & QoS-NSLP) are Experimental.
 
Thanks again,
Jerry

--- On Sat, 11/21/09, Joel M. Halpern <jmh@joelh= alpern.com> wrote:

From: Joel M. Halpern <jmh@joelhalpern.com>=
Subject: Gen-Art Review: draft-ietf-nsis-qspec-22.txt
To: "General A= rea Review Team" <gen-art@ietf.org>, "Mary Barnes" <mary.barnes@no= rtel.com>
Cc: "Magnus Westerlun" <magnus.westerlund@ericsson.com&g= t;, "IETF discussion list" <ietf@ietf.org>, nsis@ietf.org, draft-ietf= -nsis-qspec@tools.ietf.org
Date: Saturday, November 21, 2009, 6:32 PM
I have been selected as the General Area Review Team= (Gen-ART)
reviewer for this draft (for background on Gen-ART, please se= e
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).<= BR>
Please resolve these comments along with any other Last Call comment= s
you may receive.

Document: draft-ietf-nsis-qspec-22
  &= nbsp; QoS NSLP QSPEC Template
Reviewer: Joel Halpern
Review Date: 21-= Nov-2009
IETF LC End Date: 25-Nov-2009
IESG Telechat date: N/A
Summary: This document is almost ready for publication as an RFC.
I am = concerned about the RFC type.  If a revision of the document is needed= , there are a few minor items to consider for inclusion.

Major:
I= am unclear about whether the intended status (Informational) for this docu= ment is correct.
At first, it seemed correct.   The document is defined as providing a template for a resource specification b= lock (a QSPEC), and other model specific documents are expected to define e= xactly what QoS paramters they will use.
It even seemed fine that this d= ocument mandates that the QSPEC include the indication of the QoS Model.&nb= sp; That is necessary information.

Where I start to have concerns is= in section 3.1 of this document. There, the document starts specifying req= uirements on any and of QoS Model documents.  It says things like "A Q= OSM specification MUST include the following:".  If this document is d= efining normative requirements for standards track documents (and the text = explicitly states that QOSM definitions sometimes need to be standards trac= k), then I don't see how it can be an informational document.
If the QOS= M requirements, and the QSPEC support requirements ("The QSPEC objects ... = MUST be supported by QNEs.") are actually copied from some other document, then the problem is a lesser issue of unclear referent.  Bu= t if this document is the source for these normative requirements, it does = seem that Informational is wrong.

Given that this document actually = defines bits to be used on the wire, it may be appropriate to publish it as= a PS.
Alternatively, BCP may be acceptable, although a bit unusual.
=
The fact that this document defines the format of information fields an= d includes the IANA registration for those fields to be used in QOSM docume= nts also suggests that informational is inappropriate as it would create a = conceptual dependence of all standards track QOSM documents on an Informati= onal RFC.  Also, this document includes guidelines to follow in future= IANA allocations.


Minor:
In describing the constraints param= eters, the text in section 3.3.2 carefully describes the semantics, and the= composition rule.  However, it seems to leave out the unit of measure. (The constraints are given in the detailed message information fo= rmats section, but it would seem sensible to include them in 3.3.2.)
Editorial:
Should there be an editorial note when "minimum QoS" is firs= t described indicating that the term "minimum" is used generically, as for = many parameters, like loss rate or latency, what needs to be specified is t= he maximum acceptable value?

= =0A=0A --0-1331346153-1258920946=:54109-- From magnus.westerlund@ericsson.com Mon Nov 23 00:34:55 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AEE528C111; Mon, 23 Nov 2009 00:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uid0nCREiQuN; Mon, 23 Nov 2009 00:34:54 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 78FC428C10F; Mon, 23 Nov 2009 00:34:53 -0800 (PST) X-AuditID: c1b4fb24-b7b67ae000001a2a-97-4b0a49280924 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 34.22.06698.8294A0B4; Mon, 23 Nov 2009 09:34:48 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 09:34:48 +0100 Received: from [147.214.183.163] ([147.214.183.163]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 09:34:47 +0100 Message-ID: <4B0A4928.1020809@ericsson.com> Date: Mon, 23 Nov 2009 09:34:48 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Joel M. Halpern" References: <70090.54109.qm@web63606.mail.re1.yahoo.com> <4B099F1E.5010204@joelhalpern.com> In-Reply-To: <4B099F1E.5010204@joelhalpern.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Nov 2009 08:34:47.0680 (UTC) FILETIME=[D0CFB000:01CA6C17] X-Brightmail-Tracker: AAAAAA== Cc: IETF discussion list , draft-ietf-nsis-qspec@tools.ietf.org, General Area Review Team , Mary Barnes , nsis@ietf.org Subject: Re: [NSIS] Gen-Art Review: draft-ietf-nsis-qspec-22.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:34:55 -0000 Hi Joel and Jerry, Yes, these are clearly left overs before forcing all the documents into experimental. I commented in AD review about registration rules requiring standards track. Which I believe is fixed, but the comments in the document seems to not have been fixed. Secondly I think we need to have a discussion on the intended status of the document. I think I personally do have a preference for publication as experimental. I agree that it defines so much of the data format and its rules that it makes sense to have it on the experimental track, rather than informational. More views and arguments please. Magnus Joel M. Halpern skrev: > If the problem is that the base documents are experimental, then I am > very confused by the repeated references in the document to standards > track documents for defining new state machine transitions. If that > state machines are standards track, it would seem that the QoS encodings > for those state machines ought to be standards track as well. > > If the state machines are not standards track, then it would seem that > this document should be experimental, to match the rest of the set. > > Yours, > Joel > > Gerald Ash wrote: >> >> Joel, >> >> Thanks for the quick review. I agree with all your comments and >> suggestions. >> >> Regarding your suggestion on RFC type (change it from Informational to >> PS), I believe it could not become PS since the other NSIS documents >> (GIST & QoS-NSLP) are Experimental. >> >> Thanks again, >> Jerry >> >> --- On *Sat, 11/21/09, Joel M. Halpern //* wrote: >> >> >> From: Joel M. Halpern >> Subject: Gen-Art Review: draft-ietf-nsis-qspec-22.txt >> To: "General Area Review Team" , "Mary Barnes" >> >> Cc: "Magnus Westerlun" , "IETF >> discussion list" , nsis@ietf.org, >> draft-ietf-nsis-qspec@tools.ietf.org >> Date: Saturday, November 21, 2009, 6:32 PM >> >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-nsis-qspec-22 >> QoS NSLP QSPEC Template >> Reviewer: Joel Halpern >> Review Date: 21-Nov-2009 >> IETF LC End Date: 25-Nov-2009 >> IESG Telechat date: N/A >> >> Summary: This document is almost ready for publication as an RFC. >> I am concerned about the RFC type. If a revision of the document is >> needed, there are a few minor items to consider for inclusion. >> >> Major: >> I am unclear about whether the intended status (Informational) for >> this document is correct. >> At first, it seemed correct. The document is defined as providing >> a template for a resource specification block (a QSPEC), and other >> model specific documents are expected to define exactly what QoS >> paramters they will use. >> It even seemed fine that this document mandates that the QSPEC >> include the indication of the QoS Model. That is necessary >> information. >> >> Where I start to have concerns is in section 3.1 of this document. >> There, the document starts specifying requirements on any and of QoS >> Model documents. It says things like "A QOSM specification MUST >> include the following:". If this document is defining normative >> requirements for standards track documents (and the text explicitly >> states that QOSM definitions sometimes need to be standards track), >> then I don't see how it can be an informational document. >> If the QOSM requirements, and the QSPEC support requirements ("The >> QSPEC objects ... MUST be supported by QNEs.") are actually copied >> from some other document, then the problem is a lesser issue of >> unclear referent. But if this document is the source for these >> normative requirements, it does seem that Informational is wrong. >> >> Given that this document actually defines bits to be used on the >> wire, it may be appropriate to publish it as a PS. >> Alternatively, BCP may be acceptable, although a bit unusual. >> >> The fact that this document defines the format of information fields >> and includes the IANA registration for those fields to be used in >> QOSM documents also suggests that informational is inappropriate as >> it would create a conceptual dependence of all standards track QOSM >> documents on an Informational RFC. Also, this document includes >> guidelines to follow in future IANA allocations. >> >> >> Minor: >> In describing the constraints parameters, the text in section 3.3.2 >> carefully describes the semantics, and the composition rule. >> However, it seems to leave out the unit of measure. (The constraints >> are given in the detailed message information formats section, but >> it would seem sensible to include them in 3.3.2.) >> >> Editorial: >> Should there be an editorial note when "minimum QoS" is first >> described indicating that the term "minimum" is used generically, as >> for many parameters, like loss rate or latency, what needs to be >> specified is the maximum acceptable value? >> >> > -- Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jmh@joelhalpern.com Sat Nov 21 15:32:36 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101813A67D3; Sat, 21 Nov 2009 15:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxA+E4t5b4rI; Sat, 21 Nov 2009 15:32:35 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3408D3A67A1; Sat, 21 Nov 2009 15:32:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6658A43039C; Sat, 21 Nov 2009 15:32:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-79.clppva.btas.verizon.net [71.161.50.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 3703E430399; Sat, 21 Nov 2009 15:32:31 -0800 (PST) Message-ID: <4B087892.5050901@joelhalpern.com> Date: Sat, 21 Nov 2009 18:32:34 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: General Area Review Team , Mary Barnes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 23 Nov 2009 00:50:41 -0800 Cc: draft-ietf-nsis-qspec@tools.ietf.org, IETF discussion list , nsis@ietf.org Subject: [NSIS] Gen-Art Review: draft-ietf-nsis-qspec-22.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 23:32:36 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-nsis-qspec-22 QoS NSLP QSPEC Template Reviewer: Joel Halpern Review Date: 21-Nov-2009 IETF LC End Date: 25-Nov-2009 IESG Telechat date: N/A Summary: This document is almost ready for publication as an RFC. I am concerned about the RFC type. If a revision of the document is needed, there are a few minor items to consider for inclusion. Major: I am unclear about whether the intended status (Informational) for this document is correct. At first, it seemed correct. The document is defined as providing a template for a resource specification block (a QSPEC), and other model specific documents are expected to define exactly what QoS paramters they will use. It even seemed fine that this document mandates that the QSPEC include the indication of the QoS Model. That is necessary information. Where I start to have concerns is in section 3.1 of this document. There, the document starts specifying requirements on any and of QoS Model documents. It says things like "A QOSM specification MUST include the following:". If this document is defining normative requirements for standards track documents (and the text explicitly states that QOSM definitions sometimes need to be standards track), then I don't see how it can be an informational document. If the QOSM requirements, and the QSPEC support requirements ("The QSPEC objects ... MUST be supported by QNEs.") are actually copied from some other document, then the problem is a lesser issue of unclear referent. But if this document is the source for these normative requirements, it does seem that Informational is wrong. Given that this document actually defines bits to be used on the wire, it may be appropriate to publish it as a PS. Alternatively, BCP may be acceptable, although a bit unusual. The fact that this document defines the format of information fields and includes the IANA registration for those fields to be used in QOSM documents also suggests that informational is inappropriate as it would create a conceptual dependence of all standards track QOSM documents on an Informational RFC. Also, this document includes guidelines to follow in future IANA allocations. Minor: In describing the constraints parameters, the text in section 3.3.2 carefully describes the semantics, and the composition rule. However, it seems to leave out the unit of measure. (The constraints are given in the detailed message information formats section, but it would seem sensible to include them in 3.3.2.) Editorial: Should there be an editorial note when "minimum QoS" is first described indicating that the term "minimum" is used generically, as for many parameters, like loss rate or latency, what needs to be specified is the maximum acceptable value? From jmh@joelhalpern.com Sun Nov 22 12:29:21 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555213A6843; Sun, 22 Nov 2009 12:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSvJ4cWEq1l3; Sun, 22 Nov 2009 12:29:20 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 322683A672E; Sun, 22 Nov 2009 12:29:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E7A4E430403; Sun, 22 Nov 2009 12:29:16 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-79.clppva.btas.verizon.net [71.161.50.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 76B444303FD; Sun, 22 Nov 2009 12:29:15 -0800 (PST) Message-ID: <4B099F1E.5010204@joelhalpern.com> Date: Sun, 22 Nov 2009 15:29:18 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gerald Ash References: <70090.54109.qm@web63606.mail.re1.yahoo.com> In-Reply-To: <70090.54109.qm@web63606.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 23 Nov 2009 00:50:41 -0800 Cc: IETF discussion list , draft-ietf-nsis-qspec@tools.ietf.org, General Area Review Team , Mary Barnes , nsis@ietf.org Subject: Re: [NSIS] Gen-Art Review: draft-ietf-nsis-qspec-22.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 20:29:21 -0000 If the problem is that the base documents are experimental, then I am very confused by the repeated references in the document to standards track documents for defining new state machine transitions. If that state machines are standards track, it would seem that the QoS encodings for those state machines ought to be standards track as well. If the state machines are not standards track, then it would seem that this document should be experimental, to match the rest of the set. Yours, Joel Gerald Ash wrote: > > Joel, > > Thanks for the quick review. I agree with all your comments and > suggestions. > > Regarding your suggestion on RFC type (change it from Informational to > PS), I believe it could not become PS since the other NSIS documents > (GIST & QoS-NSLP) are Experimental. > > Thanks again, > Jerry > > --- On *Sat, 11/21/09, Joel M. Halpern //* wrote: > > > From: Joel M. Halpern > Subject: Gen-Art Review: draft-ietf-nsis-qspec-22.txt > To: "General Area Review Team" , "Mary Barnes" > > Cc: "Magnus Westerlun" , "IETF > discussion list" , nsis@ietf.org, > draft-ietf-nsis-qspec@tools.ietf.org > Date: Saturday, November 21, 2009, 6:32 PM > > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-nsis-qspec-22 > QoS NSLP QSPEC Template > Reviewer: Joel Halpern > Review Date: 21-Nov-2009 > IETF LC End Date: 25-Nov-2009 > IESG Telechat date: N/A > > Summary: This document is almost ready for publication as an RFC. > I am concerned about the RFC type. If a revision of the document is > needed, there are a few minor items to consider for inclusion. > > Major: > I am unclear about whether the intended status (Informational) for > this document is correct. > At first, it seemed correct. The document is defined as providing > a template for a resource specification block (a QSPEC), and other > model specific documents are expected to define exactly what QoS > paramters they will use. > It even seemed fine that this document mandates that the QSPEC > include the indication of the QoS Model. That is necessary information. > > Where I start to have concerns is in section 3.1 of this document. > There, the document starts specifying requirements on any and of QoS > Model documents. It says things like "A QOSM specification MUST > include the following:". If this document is defining normative > requirements for standards track documents (and the text explicitly > states that QOSM definitions sometimes need to be standards track), > then I don't see how it can be an informational document. > If the QOSM requirements, and the QSPEC support requirements ("The > QSPEC objects ... MUST be supported by QNEs.") are actually copied > from some other document, then the problem is a lesser issue of > unclear referent. But if this document is the source for these > normative requirements, it does seem that Informational is wrong. > > Given that this document actually defines bits to be used on the > wire, it may be appropriate to publish it as a PS. > Alternatively, BCP may be acceptable, although a bit unusual. > > The fact that this document defines the format of information fields > and includes the IANA registration for those fields to be used in > QOSM documents also suggests that informational is inappropriate as > it would create a conceptual dependence of all standards track QOSM > documents on an Informational RFC. Also, this document includes > guidelines to follow in future IANA allocations. > > > Minor: > In describing the constraints parameters, the text in section 3.3.2 > carefully describes the semantics, and the composition rule. > However, it seems to leave out the unit of measure. (The constraints > are given in the detailed message information formats section, but > it would seem sensible to include them in 3.3.2.) > > Editorial: > Should there be an editorial note when "minimum QoS" is first > described indicating that the term "minimum" is used generically, as > for many parameters, like loss rate or latency, what needs to be > specified is the maximum acceptable value? > > From magnus.westerlund@ericsson.com Fri Nov 27 04:58:18 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABCE3A657C for ; Fri, 27 Nov 2009 04:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE6QCklVoJ-u for ; Fri, 27 Nov 2009 04:58:17 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 249563A67D8 for ; Fri, 27 Nov 2009 04:58:15 -0800 (PST) X-AuditID: c1b4fb3e-b7b33ae0000045f9-4d-4b0fcc8f9731 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 89.A0.17913.F8CCF0B4; Fri, 27 Nov 2009 13:56:47 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 13:56:47 +0100 Received: from [147.214.183.163] ([147.214.183.163]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 13:56:46 +0100 Message-ID: <4B0FCC8F.9010103@ericsson.com> Date: Fri, 27 Nov 2009 13:56:47 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: draft-ietf-nsis-nslp-natfw@tools.ietf.org, NSIS X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Nov 2009 12:56:46.0763 (UTC) FILETIME=[13C467B0:01CA6F61] X-Brightmail-Tracker: AAAAAA== Subject: [NSIS] Incremental deployement story for draft-ietf-nsis-nslp-natfw-20 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 12:58:18 -0000 Hi, I am reviewing the NAT/FW NSLP and have some high level questions about this work regarding incremental deployment. When reading the document I get the impression that it starts out in world where the majority of the nodes have been upgraded and focus on mechanism in that world. It is not that it needs to work, but to me the main focus would be to ensure that the signaling protocol works well when deploying it only in one access network, or even subnet and then starts to grow the deployment. I am missing this story and how to get good performance out of the NSLP in such settings. The proxy mode enables this to some degree but seems to lack some functionality to allow for incremental deployment. The main issue seems to be sender proxying that seems to lack a method to indicate: Please proxy this but also try end to end. That allows for quick setup of the egress to public path, and allows for opening all the way if the end-to-end actually works. I would like to have a section that describes how one can start out with some end-hosts and edge-NAT/FW that support proxying. Then probe the path towards end-to-end to see if there are additional NATFW aware entities on the path allowing for a increase functionality scope. I am also a bit worried about the assumption that edge devices must be correctly configured. Consider the case of an ISP that does NAT44, i.e. the customer - ISP edge has one NAT that may have been the edge initially, but then the ISP has run out of addresses and decides to deploy its own NAT. For the application running in an end-host the gain with the NATFW signalling is lost until the customer edge device is reconfigured to not any longer be the edge. I don't know if there is a simple solution to this problem. If not I would defer the inclusion but it should be noted as a short coming. Comments? Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Nov 27 05:12:20 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D96E3A67FA for ; Fri, 27 Nov 2009 05:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwpQgVv2OuW6 for ; Fri, 27 Nov 2009 05:12:13 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9DFBC3A67D9 for ; Fri, 27 Nov 2009 05:12:09 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-d8-4b0fd021e146 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 9D.CC.14961.120DF0B4; Fri, 27 Nov 2009 14:12:01 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 14:10:57 +0100 Received: from [147.214.183.163] ([147.214.183.163]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 14:10:57 +0100 Message-ID: <4B0FCFE1.40807@ericsson.com> Date: Fri, 27 Nov 2009 14:10:57 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: draft-ietf-nsis-nslp-natfw@tools.ietf.org, NSIS X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Nov 2009 13:10:57.0042 (UTC) FILETIME=[0E92AF20:01CA6F63] X-Brightmail-Tracker: AAAAAA== Subject: [NSIS] Multi-level NAT and draft-ietf-nsis-nslp-natfw-20 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 13:12:20 -0000 Hi, I am a bit concerned with the handling of multi-level of NATs by the document. As currently defined it will force all flows to be pinned to the edge-NAT. As I understand there are no mechanism on how to optimize this route when the DR is behind the same NAT, or on a higher layer. Ni --192.168.0/24-- NAT1 -- 10.0.0.0/8 --- NAT2 Internet (public IP) | Nr1 --192.168.0/24-- NAT3 -- | Nr2 10.1.2.3 So the above diagram shows on Ni and two Nrs. 1. Ni -> Nr1: Both Ni and Nr1 does external towards NAT2 and get an external address+port binding. Then they exchange that external binding and all traffic gets pinned to NAT2 instead of taking shortes path by NAT1 to NAT3 directly. However to do that Nr1 and Ni both needs to be aware that they also have the address on the external side of NAT1 and NAT3 respectively. If you run ICE and actually have a STUN server in the 10/8 network configured you can actually get the shorter path to work. If the NATFW NSLP would provide with all external addresses you have towards the public network it could allow for optimizations. 2. In case two Ni -> Nr2 is even more obvious. Pinning this to NAT2 is an important fall back, but allowing for trying might be worth it. Please note that if there are overlapping address domains between Ni and the public Internet the regular routing will not necessary allow sending the packet to the right domain. This also makes it important to present the address as having different utility. The NAT2 external binding address would be the default as it is most likely to work. However, the NAT1 external address is also useful for certain applications. I don't know how difficult this is to address. Comments? Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Nov 30 05:06:05 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDCFA3A6A67 for ; Mon, 30 Nov 2009 05:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUydCEpMp0Vt for ; Mon, 30 Nov 2009 05:06:05 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 8540B3A693D for ; Mon, 30 Nov 2009 05:06:04 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-75-4b13c3347897 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 9E.49.14961.433C31B4; Mon, 30 Nov 2009 14:05:56 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 14:05:56 +0100 Received: from [147.214.183.163] ([147.214.183.163]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 14:05:55 +0100 Message-ID: <4B13C334.3080004@ericsson.com> Date: Mon, 30 Nov 2009 14:05:56 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: draft-ietf-nsis-nslp-natfw@tools.ietf.org, NSIS X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 Nov 2009 13:05:55.0931 (UTC) FILETIME=[DA560AB0:01CA71BD] X-Brightmail-Tracker: AAAAAA== Subject: [NSIS] Comments draft-ietf-nsis-nslp-natfw-20 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 13:06:06 -0000 Hi, This email are capturing various comments I have on the document when reviewing it. 1. I am missing detailed examples that indicate what information that are included in the messages at various points. Especially I think there need to be a full fledged example for a receiver proxy case with indication where an application would do the signaling to exchange information. 2. Section 3.2.8. When requiring random number, I would make this into cryptographically random number, and point at RFC4986. 3. Section 3.4: If I understand the session refresh timer setting, the only way for a on path to increase the refresh period is to send an error message. This is a difficult security vs load trade-off that I am not certain what even a reasonable default is. Can you provide a better recommendation on default value? 4. When reading the spec, it requires quite a good knowledge about what information is included in various GIST messages. For example CREATE is routed using the MRI. Not making clear which MRI is used, although the path coupled MRI seems to be needed to be able to find the correct binding/reservation in a NAT. Also you need to remember that the path couple MRI do contains both source and destination ports. 5. Page 40, last paragraph. a. In first sentence: It is the EXTERNAL request, rather than respond that is discussed? Can you clarify that by adding request in that case. b. "An edge-NAT will use the information provided in the NATFW_DTINFO object to allow only NATFW CREATE message with the MRI matching ('src IPv4/v6 address', 'src port number', 'protocol') to be forwarded." My brain gets confused from what view point and direction these source address + port and protocol are. To me it seems that they are in the wrong direction. Clarify please. 6. Section 3.8: "The policy rule uses the LE-MRM MRI source-address (see [I-D.ietf-nsis-ntlp]) as the flow destination IP address and the network-layer-version as IP version. " "network-layer-version" what field is that. The LE-MRM does have IP-Ver as a field, so this seem confusing. 7. Table 1: In right column IP-protocol are confusing. Are you meaning the L4 protocol running on top of IP here, i.e. transport protocol? Please use a better term. 8. Section 4.2.2: so the binding to what protocol the port is for is provided by the MRI? 9. Section 4.2.3: I am bit confused here by the directionality of the rules. Shouldn't that be made explicit in relation to the Create request direction? 10. Section 4.2.3: What if the additional port isn't being mapped towards the same host as the first one, i.e. is it possible to use this as attack vector to block a port that isn't used by oneself? 11. Section 5: I think the security model is extremely heavy weight, especially requiring egress nodes to have trust relationship with other networks egress nodes. Are there any way that can make the proxy-mode usage and scaling that to dual mode work in such way that the complexities are primarily about authentication and authorization within ones own network? 12. Section 7: I think the document needs to be more explicit what information that are present in the registries. For example the Message type registry seems to be a Name, values and reference. Also what the current values are which can be addressed either by explicit tables in the IANA section or a pointer to the relevant section. Comments? Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From gash5107@yahoo.com Mon Nov 30 09:12:54 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1564728C136 for ; Mon, 30 Nov 2009 09:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.295 X-Spam-Level: X-Spam-Status: No, score=-101.295 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18p1VDsMNjEw for ; Mon, 30 Nov 2009 09:12:44 -0800 (PST) Received: from web63605.mail.re1.yahoo.com (web63605.mail.re1.yahoo.com [69.147.97.75]) by core3.amsl.com (Postfix) with SMTP id 3B65C3A67F2 for ; Mon, 30 Nov 2009 09:12:44 -0800 (PST) Received: (qmail 33017 invoked by uid 60001); 30 Nov 2009 17:12:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259601151; bh=GnB0gqZbfKoJ2PPhgCb7A2Q8pC+tmLmlFeLmc54aLVA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OI1y983NlevIskqBbH+N2WJ8mRRZmnWCmgOz6C1DbVkP1GgoMz0KWMfbYBZna82ziocpe/YksT8FZxJF3JQOb5AnQJOBKj4RZCnqg79VS+mQHmTn9+HEbkV9iQLszAgj/A+j24jtfpznke1BiFIMlQjcBvIzZEiAWbSrWrBIPLA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dVkT0IaUWifkCCbFlCfelaOQx30FnsY0kZRY0qnQ1JJM2M+Wz1eSW8rLpBPeEaNPUcOno9JQV7YD7r4ftKxxHgt5w5Vos0wXLE0VrCxh51iyQcpGHxOH5yDRB5r6eW0D84yIAFF5I7h0N2hd869f4sWvj0LSj1DNezd965CCdLo=; Message-ID: <58192.32970.qm@web63605.mail.re1.yahoo.com> X-YMail-OSG: JHzAPWUVM1kjfzvkGwXr7DJAD3RhRsXki7i9qDfDEc.vjs_cVTzgOHSjrexkyq9ZhsdxcVsaOFf8lWDQBH2Qa_EboM2FN8LZkDlislQ4xYdjrqLoWedD4cwV5SH4GLK2nO4HmVZDwzHZOnTxur1bNME_MtfKz5XfA194zZxBoMgdp7VEC3wqntylT4Ew.O.tOW6j.f4BfZ.51cG3rlNUZSSf0Waa0q0iCV_.qOVl3J7RIiEW.Jnv7LUUQ5cbEnM1SMlvYPvXSHyH7naZShRoBP5Rr1FPkd0A_MY.Cs6NvuLiWtaA8oqRV7AiADBKhvBwQbmppPZcfiF7xmLi92xq1QdRiV51_Vvfhr_cG58r_if3roTa04n7u7m2esOipG6raML12SJZ8p6ce_ljJlF2.HjVJOvBfOfyHxOrIa.CxAPuC9v9YuKRnzaldHRdU55td5VMdZr5pRJbZFNpqKSF.3GHGFlTbPeiM7Oa7w3M6SHEKaw2GoPMslmh9CiNIIBFmARtktZ39JHVOouF2DLTb1hwvGej4l1m.U69vAtVlpYr1.zNmyUM076gmQ9hxY_eY78DvtGAzw57u4oeOygHmNz18m10NAXAJdEVyBkoni4RkXOFAyk5GGSxT7apaJvdYt53osGqIVpYbwTzbGXPr69pZ6ae374drJIZRUrS.UcVfbKwbQVo_6iS52EFJXyhfMPZWxFYDFWp1ISyYTv6iw2d4yUjrezwOxJJ8YJCD74TIsHMjp56tPkdItCYIkS6Bg3e3S3bKHtKLu6ryfsjrX52Ip4Od7GhrBs9kJdFu3Ne8PnufKm_KSxoVbzo Received: from [24.91.148.40] by web63605.mail.re1.yahoo.com via HTTP; Mon, 30 Nov 2009 09:12:30 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.8.100.260964 Date: Mon, 30 Nov 2009 09:12:30 -0800 (PST) From: Gerald Ash To: IETF-Announce , ietf@ietf.org, nsis@ietf.org In-Reply-To: <20091111090906.07B5F28C112@core3.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-889216674-1259601150=:32970" Subject: [NSIS] Maximum Packet Size Parameter -- Re: Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 17:12:54 -0000 --0-889216674-1259601150=:32970 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All, =A0 Al Morton has recently raised=A0concerns=A0RE taking the Maximum Packet Siz= e=A0 parameter out of the QSPEC document.=A0 Based on his comments (give= n below, along with other background), it appears that the parameter sh= ould be put back into the QSPEC. =A0 Please comment on=A0whether=A0the parameter should be put back into the= QSPEC. =A0 Thanks, Jerry =A0 Background: =A0 The Maximum Packet Size Parameter =A0was taken out back in July 2005 in = QSPEC version 5, with the following explanation in the change history: =A0 " =A0 Version -05: =A0=A0 - discarded QSPEC parameter (Maximum packet size) since MTU =A0=A0=A0=A0 discovery is expected to be handled by procedure currently def= ined =A0=A0=A0=A0 by PMTUD WG" =A0 Some further=A0explanation for removing the parameter =A0is=A0given=A0in= a message posted by=A0Cornelia Kappler on the IETF web-site=A0at http://ww= w.ietf.org/mail-archive/web/nsis/current/msg07923.html: =A0 "AW: [NSIS] smallest path MTU - Maximum Packet Size [M] To: "ext Bernd Schloer" , =20 Subject: AW: [NSIS] smallest path MTU - Maximum Packet Size [M]=20 From: "Kappler, Cornelia" =20 Date: Fri, 1 Jun 2007 09:53:50 +0200=20 Cc:=20 In-reply-to: <465C9BAE.1050505@cs.uni-goettingen.de>=20 List-help: =20 List-id: Next Steps in Signaling =20 List-post: =20 List-subscribe: , =20 List-unsubscribe: , =20 References: <465C9BAE.1050505@cs.uni-goettingen.de>=20 Thread-index: AceiOM3OwdCeaEOuS267eWNZJzBL6QB6Qufg=20 Thread-topic: [NSIS] smallest path MTU - Maximum Packet Size [M]=20 Hi all,=20 at the Interim meeting in May 2005 we decided to drop the MTU, see http://= www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html=20 Cornelia=20 > -----Urspr=FCngliche Nachricht----- > Von: ext Bernd Schloer [mailto:bschloer at cs.uni-goettingen.de]=20 > Gesendet: Dienstag, 29. Mai 2007 23:31 > An: nsis at ietf.org > Betreff: [NSIS] smallest path MTU - Maximum Packet Size [M] >=20 > Hi, >=20 > in version 13 of the QSPEC-draft the Maximum Packet Size [M]=20 > was removed from the > TMOD parameter (former Traffic parameter). >=20 > RFC2211 mentions, that links are not permitted to fragment=20 > packets which receive > the controlled-load service and packets larger than the MTU=20 > of the link are treated > as non-conformant to the TSPEC. >=20 > What was the reason to omit this parameter? >=20 > Best regards, > Bernd" Hannes Tschofenig kindly provided links to the Munich Interim Meeting Minut= es at http://www.tschofenig.priv.at/nsis/munich/MeetingMinutes.html =A0 It appears that the discussion of MTU discovery somehow led to a conclusion= that the maximum packet size parameter should be eliminated as well, a= s documented in this portion of the minutes: =A0 "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlledl= oad-01.txt=20 Slides: http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/Ctrld_Load_QOS= M_Interim_Munich.ppt Cornelia Kappler presents and she starts with an overview of IntServ. What is IntServ Controlled-Load service? -IntServ Controlled Load Service is (in NSIS terms) a QoS Model -RFC 2210 specifies how to signal for Controled load using RSVP -This ID specifies how to signal for Controled Load using NSIS -Controlled-Load Service (RFC 2211) -Provides approximatively service of an unloaded best-effort network -QoS parameters signaled are Token Bucket and MTU -Implemented per "network element", i.e. per-router or per-subnet Can be used for=20 Reserving resources per-flow per-router Admission control at edge of Diffserv domains Admission control into MPLS clouds How to signal for Controlled Load service with NSIS -Role of QNEs -One or more QNR per "network element" -Stateless QNEs? -Provide approximatively service of an uiloaded best-effort network may als= o be possible with stateless QNEs Discussion started about MTU insertion in the QoS NSLP since not all router= s would be supporting the NSIS Qos NSLP it was decided to remove the MTU di= scovery from controlled load and Qos-NSLP draft. If required MTU discovery = would be using mechanisms out of scope of NSIS (PMTUD or other)" =A0 Bernd Schloer raised the concern of eliminating in his message referenc= ed above: =A0 "In version 13 of the QSPEC-draft the Maximum Packet Size [M]=A0was removed= from the TMOD parameter (former Traffic parameter). RFC2211 mentions, that links are not permitted to fragment=A0packets which = receive the controlled-load service and packets larger than the MTU=A0of th= e link are treated as non-conformant to the TSPEC. What was the reason to omit this parameter?" =A0 Al Morton raised=A0the same and additional concerns in a recent discussion: =A0 "It seems to me that=A0 several points were missed by citing the Packetization Layer Path MTU Discovery (PLPMTUD) [note: see RFC 4821 http://www.rfc-editor.org/rfc/rfc4821.txt] as a replacement for specifying M, Max Pkt size: =A0-=A0 only the sending end-point will store what PLPMTUD discovers, =A0=A0=A0 intermediate points where shaping or policing reside will not =A0=A0=A0 know the Max pkt size the sender intends to use. =A0-=A0 the Max packet size that a sender uses may be much less than MTU, =A0=A0=A0 VoIP is the most obvious example. Or, it wasn't understood that M was a critical part of the peak=20 rate definition.=A0 From RFC 2212: =A0=A0 The peak rate, p, is measured in bytes of IP datagrams per second an= d =A0=A0 has the same range and suggested representation as the bucket rate. =A0=A0 The peak rate is the maximum rate at which the source and any =A0=A0 reshaping points (reshaping points are defined below) may inject =A0=A0 bursts of traffic into the network.=A0 More precisely, it is a =A0=A0 requirement that for all time periods the amount of data sent cannot =A0=A0 exceed M+pT where M is the maximum datagram size and T is the length =A0=A0 of the time period.=20 Note that parameter M is part of the RFC 2212 TSPEC, and M is apparently different from the MTU: =A0=A0 Links are not permitted to fragment datagrams as part of guaranteed =A0=A0 service.=A0 Datagrams larger than the MTU of the link MUST be police= d =A0=A0 as non-conformant which means that they will be policed according to =A0=A0 the rules described in the Policing section below." =A0 It seems that Bernd and Al have=A0raised valid concerns: discovery of MTU d= oes not=A0eliminate the need to specify in the TMOD parameter.=A0 It ap= pears that the parameter should be put back in the QSPEC.=A0 It should = not be a big issue since=A0 was already there in the QSPEC up through ve= rsion 4 (see http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-04.tx= t). =A0=A0 --- On Wed, 11/11/09, The IESG wrote: From: The IESG Subject: [NSIS] Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) = to Informational RFC To: "IETF-Announce" Cc: nsis@ietf.org Date: Wednesday, November 11, 2009, 4:09 AM The IESG has received a request from the Next Steps in Signaling WG=20 (nsis) to consider the following document: - 'QoS NSLP QSPEC Template ' =A0=A0=A0 as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action.=A0 Please send substantive comments to the ietf@ietf.org mailing lists by 2009-11-25. Exceptionally,=20 comments may be sent to iesg@ietf.org instead. In either case, please=20 retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-22.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D12323&rfc_flag=3D0 _______________________________________________ nsis mailing list nsis@ietf.org https://www.ietf.org/mailman/listinfo/nsis =0A=0A=0A --0-889216674-1259601150=:32970 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All,
 
Al Morton has recently raised concerns RE ta= king the Maximum Packet Size <M> parameter out of the QSPEC docu= ment.  Based on his comments (given below, along with other background= ), it appears that the <M> parameter should be put back into the QSPE= C.
 
Please comment on whether the <M> para= meter should be put back into the QSPEC.
 
Thanks,
Jerry
 
Background:
 
The Maximum Packet Size Parameter <M> was t= aken out back in July 2005 in QSPEC version 5, with the following explanati= on in the change history:
 
"   Version -05:

   - discarded = QSPEC parameter <M> (Maximum packet size) since MTU
  &n= bsp;  discovery is expected to be handled by procedure currently defin= ed
     by PMTUD WG"
 
Some further explanation for removing the paramet= er <M> is given in a message posted by Cornelia K= appler on the IETF web-site at = http://www.ie= tf.org/mail-archive/web/nsis/current/msg07923.html:
 
"AW: [NSIS] smallest path MTU - Maximum Packet Size [M= ]
 
Hi all,=20

at the Interim meeting in May 2005 we decided to drop the MTU, see  =
http://www.ietf-nsis.org/nsis/Munich_Interim_=
Meeting/MeetingMinutes.html=20

Cornelia=20

> -----Urspr=FCngliche Nachricht-----
> Von: ext Bernd Schloer [mailto:bschloer=
 at cs.uni-goettingen.de]=20
> Gesendet: Dienstag, 29. Mai 2007 23:31
> An: nsis at ie=
tf.org
> Betreff: [NSIS] smallest path MTU - Maximum Packet Siz=
e [M]
>=20
> Hi,
>=20
> in version 13 of the QSPEC-draft the Maximum Packet Size [M]=20
> was removed from the
> TMOD parameter (former Traffic parameter).
>=20
> RFC2211 mentions, that links are not permitted to fragment=20
> packets which receive
> the controlled-load service and packets larger than the MTU=20
> of the link are treated
> as non-conformant to the TSPEC.
>=20
> What was the reason to omit this parameter?
>=20
> Best regards,
> Bernd"
Hannes Tschofenig kindly provid= ed links to the Munich Interim Meeting Minutes at
 
It appears that the discussion of MTU discovery someho= w led to a conclusion that the maximum packet size parameter <M> shou= ld be eliminated as well, as documented in this portion of the minutes:
 
"A QoS Model for Signaling IntServ Controlled-Load Ser= vice with NSIS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
http://www.ietf.org/inter= net-drafts/draft-kappler-nsis-qosmodel-controlledload-01.txt<= /A>=20
Slides: http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/Ctrld_Load_QOSM_= Interim_Munich.ppt

Cornelia Kapple= r presents and she starts with an overview of IntServ.

What is IntSe= rv Controlled-Load service?
-IntServ Controlled Load Service is (in NSIS= terms) a QoS Model
-RFC 2210 specifies how to signal for Controled load= using RSVP
-This ID specifies how to signal for Controled Load using NS= IS
-Controlled-Load Service (RFC 2211)
-Provides approximatively serv= ice of an unloaded best-effort network
-QoS parameters signaled are Token Bucket and MTU
-Implemented per "<= SPAN id=3Dlw_1259596944_5 class=3Dyshortcuts>network element", i.e. per-= router or per-subnet
Can be used for
Reserving resources per-flow pe= r-router
Admission control= at edge of Diffserv domains
Admission control into MPLS clouds
How to signal for Controlled Load service with NSIS
-Role of QNEs<= BR>-One or more QNR per "network element"
-Stateless QNEs?
-Provide a= pproximatively service of an uiloaded best-effort network may also be possi= ble with stateless QNEs

Discussion started about MTU insertion in th= e QoS NSLP since not all routers would be supporting the NSIS Qos NSLP it w= as decided to remove the MTU discovery from controlled load and Qos-NSLP dr= aft. If required MTU discovery would be using mechanisms out of scope of NS= IS (PMTUD or other)"
 
Bernd Schloer raised the concern of eliminating <M> in his messa= ge referenced above:
 
"In version 13 of the QSPEC-draft the Maximum Packet Size [M] was= removed from the TMOD parameter (former Traffic parameter).
RFC2211 mentions, that links are not permitted to fragment packet= s which receive the controlled-load service and packets larger than the MTU=  of the link are treated as non-conformant to the TSPEC.
What was the reason to omit this parameter?"
 
Al Morton raised the same and additional concerns in a recent dis= cussion:
 
"It seems to me that  several points were missed
by citing the= Packetization Layer Path MTU Discovery (PLPMTUD)
[note: see RFC 4821 http://www.rfc-editor.org/rfc/rfc4821.txt]
as a replac= ement for specifying M, Max Pkt size:

 -  only the sending= end-point will store what PLPMTUD discovers,
    interme= diate points where shaping or policing reside will not
   = ; know the Max pkt size the sender intends to use.

 -  the= Max packet size that a sender uses may be much less than MTU,
 &nb= sp;  VoIP is the most obvious example.

Or, it wasn't understood= that M was a critical part of the peak
rate definition.  From RFC= 2212:
   The peak rate, p, is measured in bytes of IP datagra= ms per second and
   has the same range and suggested represen= tation as the bucket rate.
   The peak rate is the maximum rat= e at which the source and any
   reshaping points (reshaping po= ints are defined below) may inject
   bursts of traffic into t= he network.  More precisely, it is a
   requirement that = for all time periods the amount of data sent cannot
   exceed = M+pT where M is the maximum datagram size and T is the length
 &nbs= p; of the time period.

Note that parameter M is part of the RFC 221= 2 TSPEC, and M is apparently
different from the MTU:
   Lin= ks are not permitted to fragment datagrams as part of guaranteed
 &= nbsp; service.  Datagrams larger than the MTU of the link MUST be poli= ced
   as non-conformant which means that they will be policed= according to
   the rules described in the Policing section b= elow."
 
It seems that Bernd and Al have raised valid concerns: discovery = of MTU does not eliminate the need to specify <M> in the TMOD pa= rameter.  It appears that the <M> parameter should be put back i= n the QSPEC.  It should not be a big issue since <M> was al= ready there in the QSPEC up through version 4 (see http://www.waterspr= ings.org/pub/id/draft-ietf-nsis-qspec-04.txt).
 
 

--- On Wed, 11/11/09, The IESG <iesg-secretary@ietf.org&g= t; wrote:

From: The IESG <iesg-secretary@ietf.org>Subject: [NSIS] Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template)= to Informational RFC
To: "IETF-Announce" <ietf-announce@ietf.org>=
Cc: nsis@ietf.org
Date: Wednesday, November 11, 2009, 4:09 AM
The IESG has received a request from the Next Steps = in Signaling WG
(nsis) to consider the following document:

- 'Qo= S NSLP QSPEC Template '
   <draft-ietf-nsis-qspec-22.t= xt> as an Informational RFC

The IESG plans to make a decision in = the next few weeks, and solicits
final comments on this action.  Pl= ease send substantive comments to the
iet= f@ietf.org mailing lists by 2009-11-25. Exceptionally,
comments may= be sent to iesg@ietf.org instead. In ei= ther case, please
retain the beginning of the Subject line to allow aut= omated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-= 22.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/pub= lic/pidtracker.cgi?command=3Dview_id&dTag=3D12323&rfc_flag=3D0<= BR>
_______________________________________________
nsis mailing list=
nsis@ietf.org
https://www.ietf.org/ma= ilman/listinfo/nsis

=0A=0A = --0-889216674-1259601150=:32970-- From gash5107@yahoo.com Mon Nov 30 12:01:34 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DD03A69AE for ; Mon, 30 Nov 2009 12:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+NvZdGI+DAn for ; Mon, 30 Nov 2009 12:01:32 -0800 (PST) Received: from web63604.mail.re1.yahoo.com (web63604.mail.re1.yahoo.com [69.147.97.74]) by core3.amsl.com (Postfix) with SMTP id A2CEA28C190 for ; Mon, 30 Nov 2009 12:01:24 -0800 (PST) Received: (qmail 64512 invoked by uid 60001); 30 Nov 2009 20:01:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259611275; bh=7a1+5/QTZs2pZ0BvLvFWjwZP88ZP5ELlEfCfaFWweog=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=oOXaeUC8QDHwDFyBIMHEk/7AArTlCPHPijuoDi9Eky2oBEZL141MIw6iapluN22xLRv99+fuzDtx1HSbaJUQ917SpewMklYgB3A0+fvJoSA6uOhSVc+St97AIHU3Vi7kEMfwLbXDW9OvM9P7ReJYdLST/4UJ2Lp6pC1rkR0Z0yw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=w1zRgF9RiyxbAjo+6WNMhRu7Roq0N5FMkiSynVbSAjemFczpdDqIonvQlWGqc04a6FlRTzAR4YPjHSd5H9LnWO6erN0GQAvtUtGGfNdpYrl+h7Q/BhJOWbCBfdfNyzIMY8Lo+nCeiURbS8UB35Ds6uRLqr9sH3uEhw1sgS5k6ko=; Message-ID: <53366.64256.qm@web63604.mail.re1.yahoo.com> X-YMail-OSG: TvKLILQVM1lkn2hvu3OgzSEdDN07.8ecR2kbe4FrfEffyUa6acDnIDxqT.DI8Mbt2k4mFN3lRwHFzl.n6klZnrQ5Bp2PsTWV7C_eVpQOtqmyhiFtcRioaWoK5ZOzyi_4GvN2yVrUjc6cEBD9vdyIdBs.QHB3m1rjXHW8NMLXcyfcO7IqeDj68GdICvXC79aFxIDRPJ7fW3fkGhvWP24CX1S97._T_FIQ1HEkL03CJDt.R3IgCcRI97FOO6K6cjSgRaRWSxWeC3mV5Ka_jhvZwBJBAOlIy1cYDFGUZiLhkjv5EDz0KVyOLPihKNh0HWUpUm4a0X3OWbPHdfWc82in1v9Mkr3L09Wec.5atlluGXFGh9U- Received: from [24.91.148.40] by web63604.mail.re1.yahoo.com via HTTP; Mon, 30 Nov 2009 12:01:14 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.8.100.260964 Date: Mon, 30 Nov 2009 12:01:14 -0800 (PST) From: Gerald Ash To: NSIS , Al Morton In-Reply-To: <406754.72502.qm@web63601.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-54579355-1259611274=:64256" Cc: draft-ietf-nsis-y1541-qosm@tools.ietf.org, David Black Subject: [NSIS] Dual Token Bucket Requirements -- Re: AD review of draft-ietf-nsis-y1541-qosm-07 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:01:34 -0000 --0-54579355-1259611274=:64256 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All, =A0 The draft http://www.ietf.org/id/draft-ietf-nsis-y1541-qosm-07.txt=A0curren= tly requires a dual token bucket and peak bucket size parameter (Rp) be spe= cified.=A0 However,=A0in expired draft http://tools.ietf.org/id/draft-vaana= nen-mpls-svc-diff-framework-00.txt, it says: =A0 "=A0- Three color marker based service [RFC 2697, RFC 2698]: Here the =A0=A0 customer=C6s traffic is marked with one of three colors (using a dua= l =A0=A0 token bucket scheme) and the packets marked with each color are =A0=A0 guaranteed a certain maximum loss probability. Practically this =A0=A0 could mean that packets conforming to committed rate specification =A0=A0 have better delivery guarantee than those that exceed it." =A0 Since the QSPEC draft (http://www.ietf.org/id/draft-ietf-nsis-qspec-22.txt)= currently provides 2 TMOD parameters to accommodate the 3-color marker bas= ed service,=A0it appears that a dual token bucket capability is already pro= vided by the QSPEC and there is no further need to specify=A0the Rp paramet= er in the Y.1541-QOSM draft.=A0 It would be up to=A0an individual=A0QOSM sp= ecification to detail the use of the 2 TMOD parameters to achieve a dual to= ken bucket. =A0 Comments? =A0 Thanks, Jerry=A0 --- On Fri, 11/13/09, Gerald Ash wrote: From: Gerald Ash Subject: Re: AD review of draft-ietf-nsis-y1541-qosm-07 To: "NSIS" , "Al Morton" Cc: "Jerry Ash" , "Magnus Westerlund" , draft-ietf-nsis-y1541-qosm@tools.ietf.org Date: Friday, November 13, 2009, 5:30 PM I wasn't aware that Al Morton was taking this question to the list, so I wo= uld like to clarify the points I'm making regarding the dual token bucket p= arameter Bp: =A0 1. The basis for including the parameter Bp=A0is the=A0ITU-T Recommendation= "Signaling Requirements for IP-QoS" (available at http://www.itu.int/rec/T= -REC-Q.Sup51/en), which=A0REQUIRES the dual token bucket parameters (includ= ing Bp) for QoS signaling.=A0 IMO if the the ITU doesn't want to require a = dual token bucket for QoS signaling, they should revise the requirements.= =A0=A0Perhaps=A0co-authors of=A0the ITU-T QoS signaling requirements could = comment. =A0 2. Magnus only asked for a definition of Bp, which is readily available.=A0= =A0Magnus made no=A0claim that Bp was too complex or any suggestion that th= e parameter should be removed.=A0=A0But rather than simply providing the de= finition as requested, Al Morton has=A0now decided=A0that Bp is too complex= and should=A0be removed. =A0 3. The=A0intent of the Y.1541-QOSM document is to=A0specify an NSIS QoS mod= el (QOSM) based on=A0all QoS signaling requirements=A0contained in=A0ITU-T = recommendations, not only the=A0Y.1541 QoS classes, but also the Q.Sup51 tr= affic model (TMOD) signaling requirements, and restoration priority signali= ng requirements. =A0 Thanks, Jerry=A0 --- On Fri, 11/13/09, Al Morton wrote: From: Al Morton Subject: Re: AD review of draft-ietf-nsis-y1541-qosm-07 To: "Magnus Westerlund" , draft-ietf-nsis-y= 1541-qosm@tools.ietf.org, "NSIS" Date: Friday, November 13, 2009, 2:54 PM NSIS WG, At 08:47 AM 10/16/2009, Magnus Westerlund wrote: >3. Section 3.1: What are the definitions of the Bp and M parameter? Those of us who have discussed Magnus' comment above are trying to agree on a path forward. Both parameters have standard definitions: A reference definition for M, max datagram size, is in RFC 2212. ITU-T Y.1221 seems to be the only standard where Bp, the peak Bucket Size of a dual token bucket is specified. I have proposed removing Bp because the additional complexity of a dual token bucket is not essential to the main subject of the draft (the Y.1541 classes). I have asked at this week's ITU-T meeting, and the only implementors of ITU-T Y.1221 indicated that they were not using Bp, only the parameters for a single token bucket. Jerry Ash would like to retain Bp, citing the informational ITU-T Supplement referenced in the draft, and indicated that dual token buckets are well-established and non-controversial. Others have asked me to phrase the question to the list. So, with the above background, should we simplify and drop Bp, or keep it in? thanks and regards, Al =0A=0A=0A --0-54579355-1259611274=:64256 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All,
 
 
" - Three color marker based service [RFC 2697, RFC 2698]: Here t= he
   customer=C6s traffic is marked with one of three colors = (using a dual
   token bucket scheme) and the packets marked w= ith each color are
   guaranteed a certain maximum loss probab= ility. Practically this
   could mean that packets conforming = to committed rate specification
   have better delivery guaran= tee than those that exceed it."
 
Since the QSPEC draft (http://www.ietf.org/id/draft-ietf-nsis-qspec-22.txt) currently provides 2 TMOD parameters to accommodate the 3-color mar= ker based service, it appears that a dual token bucket capability is a= lready provided by the QSPEC and there is no further need to specify t= he Rp parameter in the Y.1541-QOSM draft.  It would be up to an i= ndividual QOSM specification to detail the use of the 2 TMOD parameter= s to achieve a dual token bucket.
 
Comments?
 
Thanks,
Jerry 


--- On Fri, 11/13/09, Gerald Ash <gash= 5107@yahoo.com> wrote:

From: Gerald Ash <gash5107@yahoo.com>
Su= bject: Re: AD review of draft-ietf-nsis-y1541-qosm-07
To: "NSIS" <nsi= s@ietf.org>, "Al Morton" <acmorton@att.com>
Cc: "Jerry Ash" <= ;gash5107@yahoo.com>, "Magnus Westerlund" <magnus.westerlund@ericsson= .com>, draft-ietf-nsis-y1541-qosm@tools.ietf.org
Date: Friday, Novemb= er 13, 2009, 5:30 PM

<= /TBODY>
I wasn't aware that Al Morton was taking this question to the list, so= I would like to clarify the points I'm making regarding the dual token buc= ket parameter Bp:
 
1. The basis for including the parameter Bp is the ITU-T Rec= ommendation "Signaling Requirements for IP-QoS" (available at = http://www.itu.int/rec/T-REC-Q.Sup51/en), which REQUIRES= the dual token bucket parameters (including Bp) for QoS signaling.  I= MO if the the ITU doesn't want to require a dual token bucket for QoS signa= ling, they should revise the requirements.  Perhaps co-autho= rs of the ITU-T QoS signaling requirements could comment.
 
2. Magnus only asked for a definition of Bp, which is readily availabl= e.  Magnus made no claim that Bp was too complex or any sugg= estion that the parameter should be removed.  But rather than sim= ply providing the definition as requested, Al Morton has now decided&n= bsp;that Bp is too complex and should be removed.
 
3. The intent of the Y.1541-QOSM document is to specify an N= SIS QoS model (QOSM) based on all QoS signaling requireme= nts contained in ITU-T recommendations, not only the Y.1541 = QoS classes, but also the Q.Sup51 traffic model (TMOD) signaling requiremen= ts, and restoration priority signaling requirements.
 
Thanks,
Jerry 

--- On Fri, 11/13/09, Al Morton <acmorton@= att.com> wrote:

From: Al Morton <acmorton@att.com>
Subje= ct: Re: AD review of draft-ietf-nsis-y1541-qosm-07
To: "Magnus Westerlun= d" <magnus.westerlund@ericsson.com>, draft-ietf-nsis-y1541-qosm@tools= .ietf.org, "NSIS" <nsis@ietf.org>
Date: Friday, November 13, 2009,= 2:54 PM

NSIS WG,

At 08:47 AM 10/16/2009, Magnus Weste= rlund wrote:
>3. Section 3.1: What are the definitions of the Bp and = M parameter?

Those of us who have discussed Magnus' comment above ar= e
trying to agree on a path forward.

Both parameters have standar= d definitions:
A reference definition for M, max datagram size, is in RF= C 2212.
ITU-T Y.1221 seems to be the only standard where Bp,
the peak= Bucket Size of a dual token bucket is specified.

I have proposed re= moving Bp because the additional complexity
of a dual token bucket is no= t essential to the main subject
of the draft (the Y.1541 classes).
I = have asked at this week's ITU-T meeting, and the only implementors
of IT= U-T Y.1221 indicated that they were not using Bp,
only the parameters fo= r a single token bucket.

Jerry Ash would like to retain Bp, citing t= he informational
ITU-T Supplement referenced in the draft, and indicated that
dual token buckets are well-established and non-controve= rsial.

Others have asked me to phrase the question to the list.
S= o, with the above background, should we simplify and drop Bp,
or keep it= in?

thanks and regards,
Al



=0A=0A --0-54579355-1259611274=:64256--