From magnus.westerlund@ericsson.com Thu Oct 1 06:54:31 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 408FA3A696A for ; Thu, 1 Oct 2009 06:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.732 X-Spam-Level: X-Spam-Status: No, score=-5.732 tagged_above=-999 required=5 tests=[AWL=0.517, 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 eCJus1F8-MMd for ; Thu, 1 Oct 2009 06:54:30 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D2A033A688B for ; Thu, 1 Oct 2009 06:54:29 -0700 (PDT) X-AuditID: c1b4fb3e-b7b63ae0000049dc-c8-4ac4b4e5c39b Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 02.1C.18908.5E4B4CA4; Thu, 1 Oct 2009 15:55:49 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 15:54:26 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 15:54:26 +0200 Message-ID: <4AC4B492.6070005@ericsson.com> Date: Thu, 01 Oct 2009 15:54:26 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: NSIS , draft-ietf-nsis-qos-nslp@tools.ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Oct 2009 13:54:26.0797 (UTC) FILETIME=[B08FF1D0:01CA429E] X-Brightmail-Tracker: AAAAAA== Subject: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 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: Thu, 01 Oct 2009 13:54:31 -0000 Hi, I have finally completed my AD review of the QoS NSLP and QSPEC documents. QSPEC will be dealt in a separate email. But here are my questions and comments. A. Section 3.1.2: Please expand DSCP on its first usage. B. Section 3.1.3 contains a reference to draft-manner-nsis-nslp-auth. This is an informational reference. But I do wonder about the security solution and its need to carry authentication information. No, I don't want to make this a normative reference. But I do wonder how the WG plans to present the lack of even one fully specified security solution, even if this is going for experimental. C. Section 3.2.12.1: How long does it take to detect that a new down stream peer exist, or that truncation has happened? D. Section 4.6, page 35, second paragraph. It is not clear to me how (1) can be guaranteed to arrive prior to (2), or if both message are sent width bound to the other one? E. Section 4.7.1, page 39: "Note that the egress should use a timer, with a preconfigured value, that can be used to synchronise the arrival of both messages, i.e., the end-to-end RESERVE message and the local RESERVE' message." I can't understand this "using a timer for synchronization" in this sentence. F. Section 5.1.2.1: "If the session of this message is bound to another session, then the RESERVE message SHOULD include the SESSION_ID of that other session in a BOUND_SESSION_ID object." Why a SHOULD here. Please explain when you could or should break the SHOULD. G. Section 5.1.2.2: "A QUERY message MAY contain a second QSPEC object." QUERY = COMMON_HEADER [ RII ][ *BOUND_SESSION_ID ] [ PACKET_CLASSIFIER ] [ INFO_SPEC ] QSPEC The BNF seem to not allow for a second QSPEC object. H. Section 5.1.3: "The remaining bits marked 'r' are reserved." There are no definition of the meaning of reserved bits. I assume SHALL be set to 0, SHALL be ignored on reception? I. Section 5.1.3.5: "The method-specific classifier data is two bytes long and consists of a set of flags: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|Y|P|T|F|S|A|B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+" This seems to be 4 bytes, and not 2. J. Section 5.1.3.6 " Offset: The byte in the object at which the QNE found the error. When this field is set to "0", the complete object is included." I don't get these two sentences to match. First sentence says this is a pointer to where the error is. Second sentence indicates that the object has been truncated upto the given offset. Please clarify. K. Section 5.3.6: " A SESSION_ID_LIST is carried in RESERVE messages. It is used in two cases, to refresh or two tear down the indicated sessions. " Second "two" should be a "to"? L. Section 6. Please update reference to RFC 5226. M. Section 7. "The protocol mechanisms s in this document try to minimize exhaustion attacks against these resources when performing authentication and authorization for QoS resources." Is the lone "s" after mechanisms intended? -- 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 Oct 2 02:32:29 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 B1B473A6808 for ; Fri, 2 Oct 2009 02:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=-1.851, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_SE=0.35, MANGLED_MEN=2.3, 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 0OsJkNWfFP6d for ; Fri, 2 Oct 2009 02:32:28 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C43EA3A696B for ; Fri, 2 Oct 2009 02:32:27 -0700 (PDT) X-AuditID: c1b4fb3e-b7b81ae0000009d4-e7-4ac5c9010bf6 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A2.A9.02516.109C5CA4; Fri, 2 Oct 2009 11:33:53 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 11:32:34 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 11:32:34 +0200 Message-ID: <4AC5C8B2.8000409@ericsson.com> Date: Fri, 02 Oct 2009 11:32:34 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: NSIS , draft-ietf-nsis-qspec@tools.ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Oct 2009 09:32:34.0294 (UTC) FILETIME=[45980160:01CA4343] X-Brightmail-Tracker: AAAAAA== Subject: [NSIS] AD comments on draft-ietf-nsis-qspec-21 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, 02 Oct 2009 09:32:29 -0000 Hi, Very sorry for the long delay in getting this review completed. 1. Section 1. last paragraph: I don't think "worked example" is easily understood. Can you find another word? 2. Section 3.1: - QSPEC parameter behavior for new QSPEC parameters the QOSM behavior (tear down preempted reservation) is not followed (see specification defines - define what happens in case of preemption if the default QNI Section 4.3.5) Some editing issues here around the second parenthesis in the first bullet. It closes in the second bullet. 3. Section 3.2: "QSPEC parameters are the parameters appearing in a QSPEC, which must include traffic (TMOD), ..." I do believe there is a missing word between traffic and "(TMOD). 4. Section 3.2, second paragraph: "IANA assigns a new QSPEC version number when changes that are not backwards compatible are made to the QSPEC and this document is reissued. " and "Later QSPEC versions MUST be backward compatible with earlier QSPEC versions." The two sentences are contradicting. Please make it clear when new version is needed. 5. Section 3.3.1: The 4 sub-parameters can you please specify units for them? 6. Section 3.3.1: You don't seem to have a definition of what "minimum policed unit" is. I assume that this definition from RFC 2211 is applicable, but still either include it or reference it. The minimum policed unit, m, is an integer measured in bytes. All IP datagrams less than size m will be counted against the token bucket as being of size m." 7. Section 3.3.1: What is the definition of peak rate? I understand that the "rate" is a uniform filling rate of the token bucket. However, peak rate implies that it is not a smoothed value nor has its own bucket depth parameter. So please provide a definition. 8. Section 3.3.2: " This delay results from the combination of speed-of-light propagation delay," Wouldn't it be clearer to say "link" instead of speed-of-light. Especially in cases where the link has retransmission or other features that makes the links propagation delay not solely be dependent on the speed-of-light in the medium used. 9. Section 3.3.2: "Furthermore, the QNI MUST add the propagation delay of the ingress link, if this link exists." How, is the QNI supposed to know the propagation delay of the ingress link? I agree that there are cases where this can be configured, but there appear to be a number of cases when it would not be the case. Therefore I am a bit questioning a MUST on something that may not be possible to perform. 10. Section 3.3.2: What is the definition of path error ratio? 11. This may seem out of context but I do want to know the answer to how the situation is handled when QNI and QNR are neighbors on a non QoS enabled network. 12. Section 4.2.1: "Note that the TMOD parameter and all QSPEC parameters with the M flag set MUST be examined by the RMF, and all QSPEC parameters with the M flag not set SHOULD be examined by the RMF, and appropriately flagged." What is meant with appropriately flagged in the above sentence? 13. Section 5.1.1: Even if version numbers are assigned by IANA I think the spec should be explicit on which version this one defines. Also as being the first version, I think assigning it yourself would be fully appropriate. 14. Section 5.1.1.: QSPEC Type: I think this should have a pointer to the IANA registry. 15. Section 5.1.1: " Length: The total length of the QSPEC excluding the common header" Please make it clear that you count in 32-bit words (?) and add the "." at the end of the sentence. 16. Section 5.1.2: "Parameter ID: Assigned to each parameter (see below)" The text below this does not discuss parameter ID in any useful way. Please correct that or provide a better reference to where it is discussed. 17. Section 5.2.1: "he parameters are represented by three floating point numbers in single-precision IEEE floating point format followed by one 32-bit integer in network byte order." Please add a reference for the IEEE floating point format. 18. Section 5.2.1: I don't think the reference in the section title is particular helping. I definitely prefer explicit references for each item so that you easily can find them. There is also a risk for confusion if multiple references are not agreeing on a parameter definition. For example take the "minimum policed unit". What it is is defined in RFC 2210, but there is also redundant interpretation text in RFC 2215. I also have a hard time determining if any reference is missing. 19. Section 5.2.3: The referenced documents does not define Path latency, only minimal path latency. Not obvious that they are the same, for example from a perspective of queuing delay or link ARQ. 20. Section 5.2.4: Once more the references are unclear. Especially as RFC 3393 doesn't use "jitter". You need to be explicit about what is what. 21. Section 5.2.5: First of all I am not convinced by looking in Y.1541 that packet loss ratio has a clear definition. I am missing what type of averaging is assumed in the value. If you going to measure this value you need to do it over sufficiently many packets, measuring over 7 packets with one loss doesn't say much. 22. Section 5.2.5: " An individual QNE can advertise a PLR value between zero and 10^-2 and the total PLR added across all QNEs can range as high as 10^-1." Isn't the restriction to advertise a link PLR no higher than 10^-2 a to strict limit. Doesn't there exist links out there that has that level of loss. Maybe not ones that you usually request QoS over, but anyway. 23. Section 5.2.11: "When the shaping causes unbounded queue growth at the shaper traffic can be dropped." To me the shaping seems unclear, as it contains a unknown factor of the queue used. Both queue depth and dropping model would influence how the shaping happens. 24. Section 5.2.11: Remark Value (6 bits): indicates either drop (set to 0) or DSCP value [RFC2474] to remark packets to when identified as excess So you can't remark traffic into the best-effort traffic class? Isn't that a severe limitation? And why are there need for two ways of marking drop as excess treatments? 25. Section 5.2.12: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|E|N|r| 12 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Two comments about the field definition for the third 16-bit word. First, why is one of the possible field value represented rather than giving the field a name. That way one can make it clear that the possibility for different structures in that 16-bit word. I would probably have defiend it as: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | PH Field Value |EN | I do understand that would be different from how RFC 3140 is representing the information, but be equivalent. As an alternative I would simple change the first diagram to say instead of DSCP | 0 0 ... to say PHB Field. Anyway, I think the current representation is unclear. 26. Section 7. There are registries that requires standard action for new registrations. I think that is not consistent with publishing this as experimental. Please address. 27. Section 7. QSPEC Procedures. This table is so confusing, I can't get my head around what code point space is registered. And if there are a second dimension for certain values and in that case which that is. 28. References: Can you please ensure that there is a blank line between each reference. Now it is very difficult to read the list. Also, making the reference using a hanging style makes it easier to find the reference identifiers. 29. Appendix B has alignment issues in the Protocol header length table. 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 bless@tm.uka.de Fri Oct 2 06:21:49 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 CE5883A69E0 for ; Fri, 2 Oct 2009 06:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=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 Mg8rcTlkqMqf for ; Fri, 2 Oct 2009 06:21:48 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 8FE8F3A6765 for ; Fri, 2 Oct 2009 06:21:48 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1Mti6H-0005jG-Td; Fri, 02 Oct 2009 15:23:14 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1Mti6H-0004Z1-Nz; Fri, 02 Oct 2009 15:23:09 +0200 Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id A42682FC00A; Fri, 2 Oct 2009 15:23:09 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id 991A21016B; Fri, 2 Oct 2009 15:23:09 +0200 (CEST) Message-ID: <4AC5FEBD.2030701@tm.uka.de> Date: Fri, 02 Oct 2009 15:23:09 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: NSIS References: <4AC4B492.6070005@ericsson.com> In-Reply-To: <4AC4B492.6070005@ericsson.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1254489795.041903000 Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 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, 02 Oct 2009 13:21:49 -0000 Hi, Magnus Westerlund wrote: > G. Section 5.1.2.2: > "A QUERY message > MAY contain a second QSPEC object." > QUERY = COMMON_HEADER > [ RII ][ *BOUND_SESSION_ID ] > [ PACKET_CLASSIFIER ] [ INFO_SPEC ] QSPEC > > The BNF seem to not allow for a second QSPEC object. Good catch. I guess that this is a remnant from an earlier approach. Our student Matthias Dettling actually found further inconsistencies related to QSPEC presence in QUERYs. Section 5.1.2.2 states: QUERY messages MUST always include a QSPEC. Section 4.3 states: To make a receiver-initiated reservation, the QNR constructs a QUERY message, which may contain a QSPEC object from its chosen QoS model (see Figure 8). So _may_ is not appropriate here since it MUST contain a QSPEC. Furthermore in section 5.4.2 is written: If the QUERY contained a QSPEC, it MUST be passed to the RMF where it may be modified by the QoS Model specific QUERY processing. The "if" is clearly wrong since a QSPEC MUST be included and I guess that the sentence is a duplicate of the earlier statement in the third paragraph of this section: When a QNE receives a QUERY message the QSPEC is passed to the RMF for processing. Regards, Roland From jukka.manner@tkk.fi Wed Oct 7 13:51:42 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 DD3A428C103 for ; Wed, 7 Oct 2009 13:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-1.626, BAYES_05=-1.11, FF_IHOPE_YOU_SINK=2.166, MANGLED_MEN=2.3, 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 BuiL6xZJvIw1 for ; Wed, 7 Oct 2009 13:51:41 -0700 (PDT) Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by core3.amsl.com (Postfix) with ESMTP id B6BE63A69A4 for ; Wed, 7 Oct 2009 13:51:40 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id n97KrIpl029805; Wed, 7 Oct 2009 23:53:18 +0300 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 31530-269-12; Wed, 7 Oct 2009 23:53:18 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id n97KqtLE029588; Wed, 7 Oct 2009 23:52:55 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id AC2871E159; Wed, 7 Oct 2009 23:52:55 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OvRY-44HSTnz; Wed, 7 Oct 2009 23:52:51 +0300 (EEST) Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 6CF561E1D2; Wed, 7 Oct 2009 23:52:45 +0300 (EEST) Received: from [192.168.0.156] (a91-154-4-72.elisa-laajakaista.fi [91.154.4.72]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id 2306C120050; Wed, 7 Oct 2009 23:52:45 +0300 (EEST) Message-ID: <4ACCE500.9090900@tkk.fi> Date: Wed, 07 Oct 2009 21:59:12 +0300 From: Jukka Manner User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Magnus Westerlund References: <21741_1254476213_ZZ0KQV00KUARY0HS.00_4AC5C8B2.8000409@ericsson.com> In-Reply-To: <21741_1254476213_ZZ0KQV00KUARY0HS.00_4AC5C8B2.8000409@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: draft-ietf-nsis-qspec@tools.ietf.org, NSIS Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21 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, 07 Oct 2009 20:51:43 -0000 Hi Magnus, Thank you for the review. Your comments seemed valid to me, and I'd like to hear the authors' replies and estimation when we could have an updated draft. Cheers, Jukka (on to analyzing my own feedback on the nslp ;) Magnus Westerlund wrote: > Hi, > > Very sorry for the long delay in getting this review completed. > > 1. Section 1. last paragraph: I don't think "worked example" is easily > understood. Can you find another word? > > 2. Section 3.1: > - QSPEC parameter behavior for new QSPEC parameters the QOSM > behavior (tear down preempted reservation) is not followed (see > specification defines > - define what happens in case of preemption if the default QNI > Section 4.3.5) > > Some editing issues here around the second parenthesis in the first > bullet. It closes in the second bullet. > > 3. Section 3.2: > "QSPEC > parameters are the parameters appearing in a QSPEC, which must > include traffic (TMOD), ..." > > I do believe there is a missing word between traffic and "(TMOD). > > 4. Section 3.2, second paragraph: > > "IANA > assigns a new QSPEC version number when changes that are not > backwards compatible are made to the QSPEC and this document is > reissued. " > > and > "Later QSPEC versions MUST be > backward compatible with earlier QSPEC versions." > > The two sentences are contradicting. Please make it clear when new > version is needed. > > 5. Section 3.3.1: The 4 sub-parameters can you please specify units for > them? > > 6. Section 3.3.1: You don't seem to have a definition of what "minimum > policed unit" is. I assume that this definition from RFC 2211 is > applicable, but still either include it or reference it. > > The minimum policed unit, m, is an integer measured in bytes. All IP > datagrams less than size m will be counted against the token bucket > as being of size m." > > 7. Section 3.3.1: What is the definition of peak rate? I understand that > the "rate" is a uniform filling rate of the token bucket. However, peak > rate implies that it is not a smoothed value nor has its own bucket > depth parameter. So please provide a definition. > > 8. Section 3.3.2: " This delay > results from the combination of speed-of-light propagation delay," > > Wouldn't it be clearer to say "link" instead of speed-of-light. > Especially in cases where the link has retransmission or other features > that makes the links propagation delay not solely be dependent on the > speed-of-light in the medium used. > > 9. Section 3.3.2: "Furthermore, the > QNI MUST add the propagation delay of the ingress link, if this link > exists." > > How, is the QNI supposed to know the propagation delay of the ingress > link? I agree that there are cases where this can be configured, but > there appear to be a number of cases when it would not be the case. > Therefore I am a bit questioning a MUST on something that may not be > possible to perform. > > 10. Section 3.3.2: What is the definition of path error ratio? > > 11. This may seem out of context but I do want to know the answer to how > the situation is handled when QNI and QNR are neighbors on a non QoS > enabled network. > > 12. Section 4.2.1: > "Note that > the TMOD parameter and all QSPEC parameters with the M flag set MUST > be examined by the RMF, and all QSPEC parameters with the M flag not > set SHOULD be examined by the RMF, and appropriately flagged." > > What is meant with appropriately flagged in the above sentence? > > 13. Section 5.1.1: Even if version numbers are assigned by IANA I think > the spec should be explicit on which version this one defines. Also as > being the first version, I think assigning it yourself would be fully > appropriate. > > 14. Section 5.1.1.: QSPEC Type: I think this should have a pointer to > the IANA registry. > > 15. Section 5.1.1: > " Length: The total length of the QSPEC excluding the common header" > > Please make it clear that you count in 32-bit words (?) and add the "." > at the end of the sentence. > > 16. Section 5.1.2: "Parameter ID: Assigned to each parameter (see below)" > > The text below this does not discuss parameter ID in any useful way. > Please correct that or provide a better reference to where it is discussed. > > 17. Section 5.2.1: > "he parameters are represented by three floating point > numbers in single-precision IEEE floating point format followed by > one 32-bit integer in network byte order." > > Please add a reference for the IEEE floating point format. > > 18. Section 5.2.1: I don't think the reference in the section title is > particular helping. I definitely prefer explicit references for each > item so that you easily can find them. There is also a risk for > confusion if multiple references are not agreeing on a parameter > definition. For example take the "minimum policed unit". What it is is > defined in RFC 2210, but there is also redundant interpretation text in > RFC 2215. I also have a hard time determining if any reference is missing. > > 19. Section 5.2.3: The referenced documents does not define Path > latency, only minimal path latency. Not obvious that they are the same, > for example from a perspective of queuing delay or link ARQ. > > 20. Section 5.2.4: Once more the references are unclear. Especially as > RFC 3393 doesn't use "jitter". You need to be explicit about what is what. > > 21. Section 5.2.5: First of all I am not convinced by looking in Y.1541 > that packet loss ratio has a clear definition. I am missing what type of > averaging is assumed in the value. If you going to measure this value > you need to do it over sufficiently many packets, measuring over 7 > packets with one loss doesn't say much. > > 22. Section 5.2.5: " An > individual QNE can advertise a PLR value between zero and 10^-2 > and the total PLR added across all QNEs can range as high as 10^-1." > > Isn't the restriction to advertise a link PLR no higher than 10^-2 a to > strict limit. Doesn't there exist links out there that has that level of > loss. Maybe not ones that you usually request QoS over, but anyway. > > 23. Section 5.2.11: > "When the shaping causes > unbounded queue growth at the shaper traffic can be dropped." > > To me the shaping seems unclear, as it contains a unknown factor of the > queue used. Both queue depth and dropping model would influence how the > shaping happens. > > 24. Section 5.2.11: > Remark Value (6 bits): indicates either drop (set to 0) or DSCP > value [RFC2474] to remark packets to when > identified as excess > > So you can't remark traffic into the best-effort traffic class? Isn't > that a severe limitation? And why are there need for two ways of marking > drop as excess treatments? > > 25. Section 5.2.12: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|E|N|r| 12 |r|r|r|r| 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > Two comments about the field definition for the third 16-bit word. > > First, why is one of the possible field value represented rather than > giving the field a name. That way one can make it clear that the > possibility for different structures in that 16-bit word. I would > probably have defiend it as: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > | PH Field Value |EN | > > I do understand that would be different from how RFC 3140 is > representing the information, but be equivalent. As an alternative I > would simple change the first diagram to say instead of DSCP | 0 0 ... > to say PHB Field. Anyway, I think the current representation is unclear. > > 26. Section 7. There are registries that requires standard action for > new registrations. I think that is not consistent with publishing this > as experimental. Please address. > > 27. Section 7. QSPEC Procedures. This table is so confusing, I can't get > my head around what code point space is registered. And if there are a > second dimension for certain values and in that case which that is. > > 28. References: Can you please ensure that there is a blank line between > each reference. Now it is very difficult to read the list. Also, making > the reference using a hanging style makes it easier to find the > reference identifiers. > > 29. Appendix B has alignment issues in the Protocol header length table. > > 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 > ---------------------------------------------------------------------- > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis -- Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 Helsinki University of Technology Mobile: +358+(0)50+5112973 Department of Communications Fax: +358+(0)9+451 2474 and Networking (Comnet) Office: G320 (Otakaari 5A) P.O. Box 3000, FIN-02015 TKK E-mail: jukka.manner@tkk.fi Finland WWW: www.comnet.tkk.fi From jukka.manner@tkk.fi Wed Oct 7 13:53:22 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 7C87E28C0F0 for ; Wed, 7 Oct 2009 13:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.592 X-Spam-Level: X-Spam-Status: No, score=-4.592 tagged_above=-999 required=5 tests=[AWL=2.007, BAYES_00=-2.599, 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 fOlWWpZ0vPwk for ; Wed, 7 Oct 2009 13:53:21 -0700 (PDT) Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by core3.amsl.com (Postfix) with ESMTP id 34A2B3A6914 for ; Wed, 7 Oct 2009 13:53:20 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id n97KsxF2030250; Wed, 7 Oct 2009 23:54:59 +0300 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 11322-47-2; Wed, 7 Oct 2009 23:54:59 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id n97Kr2JI029647; Wed, 7 Oct 2009 23:53:02 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id BAE5C1E1CD; Wed, 7 Oct 2009 23:53:02 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Mmu-f0-MEXeY; Wed, 7 Oct 2009 23:52:58 +0300 (EEST) Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 08BD61E1CF; Wed, 7 Oct 2009 23:52:51 +0300 (EEST) Received: from [192.168.0.156] (a91-154-4-72.elisa-laajakaista.fi [91.154.4.72]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id BC65E120050; Wed, 7 Oct 2009 23:52:50 +0300 (EEST) Message-ID: <4ACCFF63.1000808@tkk.fi> Date: Wed, 07 Oct 2009 23:51:47 +0300 From: Jukka Manner User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Magnus Westerlund References: <21741_1254405419_ZZ0KQU00DKH9EYBC.00_4AC4B492.6070005@ericsson.com> In-Reply-To: <21741_1254405419_ZZ0KQU00DKH9EYBC.00_4AC4B492.6070005@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, NSIS Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 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, 07 Oct 2009 20:53:22 -0000 Hi Magnus, thank you for the review. I'll try to answer from my part, haven't talked to the co-authors, yet. cheers, Jukka Magnus Westerlund wrote: > Hi, > > I have finally completed my AD review of the QoS NSLP and QSPEC > documents. QSPEC will be dealt in a separate email. But here are my > questions and comments. > > A. Section 3.1.2: Please expand DSCP on its first usage. Ack. > > B. Section 3.1.3 contains a reference to draft-manner-nsis-nslp-auth. > This is an informational reference. But I do wonder about the security > solution and its need to carry authentication information. No, I don't > want to make this a normative reference. But I do wonder how the WG > plans to present the lack of even one fully specified security solution, > even if this is going for experimental. Good question. This item is not on our charter but me, Martin and Hannes have worked on the topic sometime ago. Do you see we should add the user authentication and authorization e.g. as an experimental extension to the current NSLPs? The work is there, we could seek to finish it asap. > > C. Section 3.2.12.1: How long does it take to detect that a new down > stream peer exist, or that truncation has happened? I believe this is a GIST functionality and parameter, and can be configured differently depending on the deployment. > > D. Section 4.6, page 35, second paragraph. It is not clear to me how (1) > can be guaranteed to arrive prior to (2), or if both message are sent > width bound to the other one? I'll pass this to Georgios, he is the prime designer here, I believe. :) > > E. Section 4.7.1, page 39: > "Note that the egress should use a timer, with a > preconfigured value, that can be used to synchronise the arrival of > both messages, i.e., the end-to-end RESERVE message and the local > RESERVE' message." > > I can't understand this "using a timer for synchronization" in this > sentence. I'll pass this to Georgios, too. :) > > F. Section 5.1.2.1: "If the session of this message is bound to another > session, then the RESERVE message SHOULD include the SESSION_ID of that > other session in a BOUND_SESSION_ID object." > > Why a SHOULD here. Please explain when you could or should break the SHOULD. I don't actually know why only a SHOULD, this probably ought to be a MUST. If there is a binding, it must be indicated. > > G. Section 5.1.2.2: > "A QUERY message > MAY contain a second QSPEC object." > QUERY = COMMON_HEADER > [ RII ][ *BOUND_SESSION_ID ] > [ PACKET_CLASSIFIER ] [ INFO_SPEC ] QSPEC > > The BNF seem to not allow for a second QSPEC object. Roland already answered this, we'll fix it. > > H. Section 5.1.3: > "The remaining bits marked 'r' are reserved." There are no definition of > the meaning of reserved bits. I assume SHALL be set to 0, SHALL be > ignored on reception? Yes, clearly this statement is missing, will add. > > I. Section 5.1.3.5: > "The method-specific classifier data is two bytes long and consists of > a set of flags: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |X|Y|P|T|F|S|A|B| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+" > > This seems to be 4 bytes, and not 2. Yes. :) > > J. Section 5.1.3.6 > " Offset: The byte in the object at which the QNE found the error. > When this field is set to "0", the complete object is included." > > I don't get these two sentences to match. First sentence says this is a > pointer to where the error is. Second sentence indicates that the object > has been truncated upto the given offset. Please clarify. This means that either (1) there is the full object ("0") or (2) from "offset" upto the end of the object (not from beginning upto offset), where the problematic part starts at "offset". I'll clarify this. > > K. Section 5.3.6: > " > A SESSION_ID_LIST is carried in RESERVE messages. It is used in two > cases, to refresh or two tear down the indicated sessions. " > > Second "two" should be a "to"? Yes. :) > > L. Section 6. Please update reference to RFC 5226. Ack. > > M. Section 7. "The protocol mechanisms s in this > document try to minimize exhaustion attacks against these resources > when performing authentication and authorization for QoS resources." > > Is the lone "s" after mechanisms intended? Surely not. :) From jukka.manner@tkk.fi Wed Oct 7 13:55: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 55B8628C0D9 for ; Wed, 7 Oct 2009 13:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.094 X-Spam-Level: X-Spam-Status: No, score=-5.094 tagged_above=-999 required=5 tests=[AWL=1.505, BAYES_00=-2.599, 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 cYltu2WOWN1Y for ; Wed, 7 Oct 2009 13:55:06 -0700 (PDT) Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by core3.amsl.com (Postfix) with ESMTP id 387313A67F4 for ; Wed, 7 Oct 2009 13:55:06 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id n97Kuiuo028170; Wed, 7 Oct 2009 23:56:44 +0300 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 20852-209-3; Wed, 7 Oct 2009 23:56:44 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id n97KqwGL026914; Wed, 7 Oct 2009 23:52:58 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 239981E1D2; Wed, 7 Oct 2009 23:52:58 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TW9GCgNngfXJ; Wed, 7 Oct 2009 23:52:54 +0300 (EEST) Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id A279A1E1C7; Wed, 7 Oct 2009 23:52:46 +0300 (EEST) Received: from [192.168.0.156] (a91-154-4-72.elisa-laajakaista.fi [91.154.4.72]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id 650ED120050; Wed, 7 Oct 2009 23:52:46 +0300 (EEST) Message-ID: <4ACCE8A7.7050408@tkk.fi> Date: Wed, 07 Oct 2009 22:14:47 +0300 From: Jukka Manner User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Roland Bless References: <4AC4B492.6070005@ericsson.com> <2727_1254489827_ZZ0KQW00H2R2JM5Q.00_4AC5FEBD.2030701@tm.uka.de> In-Reply-To: <2727_1254489827_ZZ0KQW00H2R2JM5Q.00_4AC5FEBD.2030701@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, NSIS Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 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, 07 Oct 2009 20:55:07 -0000 Hi Roland, thanks for the note, we'll fix this one, too. Jukka Roland Bless wrote: > Hi, > > Magnus Westerlund wrote: > >> G. Section 5.1.2.2: >> "A QUERY message >> MAY contain a second QSPEC object." >> QUERY = COMMON_HEADER >> [ RII ][ *BOUND_SESSION_ID ] >> [ PACKET_CLASSIFIER ] [ INFO_SPEC ] QSPEC >> >> The BNF seem to not allow for a second QSPEC object. > > Good catch. I guess that this is a remnant from an earlier > approach. > > Our student Matthias Dettling actually found further inconsistencies > related to QSPEC presence in QUERYs. > > Section 5.1.2.2 states: > QUERY messages MUST always include a QSPEC. > > Section 4.3 states: > To make a receiver-initiated reservation, the QNR constructs a QUERY > message, which may contain a QSPEC object from its chosen QoS model > (see Figure 8). > > So _may_ is not appropriate here since it MUST contain a QSPEC. > > Furthermore in section 5.4.2 is written: > If the QUERY > contained a QSPEC, it MUST be passed to the RMF where it may be > modified by the QoS Model specific QUERY processing. > > The "if" is clearly wrong since a QSPEC MUST be included and > I guess that the sentence is a duplicate of the earlier statement in the > third paragraph of this section: > When a QNE receives a QUERY message the QSPEC is passed to the RMF > for processing. > > Regards, > Roland > -- Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 Helsinki University of Technology Mobile: +358+(0)50+5112973 Department of Communications Fax: +358+(0)9+451 2474 and Networking (Comnet) Office: G320 (Otakaari 5A) P.O. Box 3000, FIN-02015 TKK E-mail: jukka.manner@tkk.fi Finland WWW: www.comnet.tkk.fi From karagian@cs.utwente.nl Mon Oct 12 03:23:38 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 4C8893A68C6 for ; Mon, 12 Oct 2009 03:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.096 X-Spam-Level: ** X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 Q16qMLPdjycB for ; Mon, 12 Oct 2009 03:23:37 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 288843A681E for ; Mon, 12 Oct 2009 03:23:37 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id n9CANTqh022047; Mon, 12 Oct 2009 12:23:32 +0200 (MEST) From: "Georgios Karagiannis" To: "'Jukka Manner'" , "'Magnus Westerlund'" References: <21741_1254405419_ZZ0KQU00DKH9EYBC.00_4AC4B492.6070005@ericsson.com> <4ACCFF63.1000808@tkk.fi> Date: Mon, 12 Oct 2009 12:23:25 +0200 Message-ID: <004301ca4b26$0bf0eea0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4ACCFF63.1000808@tkk.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcpHk894O9C4AiMLS7OiycLlVLRzlgDkfjBQ X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 12 Oct 2009 12:23:35 +0200 (MEST) Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, 'NSIS' Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 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, 12 Oct 2009 10:23:38 -0000 Hi Magnus, Hi Jukka Magnus, thank you very much for the comments! I am working out comments D and E! Best regards, Georgios > -----Original Message----- > From: Jukka Manner [mailto:jukka.manner@tkk.fi] > Sent: woensdag 7 oktober 2009 22:52 > To: Magnus Westerlund > Cc: NSIS; draft-ietf-nsis-qos-nslp@tools.ietf.org > Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 > > Hi Magnus, thank you for the review. > > I'll try to answer from my part, haven't talked to the > co-authors, yet. > > cheers, > Jukka > > Magnus Westerlund wrote: > > Hi, > > > > I have finally completed my AD review of the QoS NSLP and QSPEC > > documents. QSPEC will be dealt in a separate email. But here are my > > questions and comments. > > > > A. Section 3.1.2: Please expand DSCP on its first usage. > > Ack. > > > > > B. Section 3.1.3 contains a reference to > draft-manner-nsis-nslp-auth. > > This is an informational reference. But I do wonder about > the security > > solution and its need to carry authentication information. > No, I don't > > want to make this a normative reference. But I do wonder how the WG > > plans to present the lack of even one fully specified security > > solution, even if this is going for experimental. > > Good question. This item is not on our charter but me, Martin > and Hannes have worked on the topic sometime ago. Do you see > we should add the user authentication and authorization e.g. > as an experimental extension to the current NSLPs? The work > is there, we could seek to finish it asap. > > > > > C. Section 3.2.12.1: How long does it take to detect that a > new down > > stream peer exist, or that truncation has happened? > > I believe this is a GIST functionality and parameter, and can > be configured differently depending on the deployment. > > > > > D. Section 4.6, page 35, second paragraph. It is not clear > to me how > > (1) can be guaranteed to arrive prior to (2), or if both > message are > > sent width bound to the other one? > > I'll pass this to Georgios, he is the prime designer here, I > believe. :) > > > > > E. Section 4.7.1, page 39: > > "Note that the egress should use a timer, with a > > preconfigured value, that can be used to synchronise the > arrival of > > both messages, i.e., the end-to-end RESERVE message and the local > > RESERVE' message." > > > > I can't understand this "using a timer for synchronization" in this > > sentence. > > I'll pass this to Georgios, too. :) > > > > > F. Section 5.1.2.1: "If the session of this message is bound to > > another session, then the RESERVE message SHOULD include the > > SESSION_ID of that other session in a BOUND_SESSION_ID object." > > > > Why a SHOULD here. Please explain when you could or should > break the SHOULD. > > I don't actually know why only a SHOULD, this probably ought > to be a MUST. If there is a binding, it must be indicated. > > > > > G. Section 5.1.2.2: > > "A QUERY message > > MAY contain a second QSPEC object." > > QUERY = COMMON_HEADER > > [ RII ][ *BOUND_SESSION_ID ] > > [ PACKET_CLASSIFIER ] [ INFO_SPEC ] QSPEC > > > > The BNF seem to not allow for a second QSPEC object. > > Roland already answered this, we'll fix it. > > > > > H. Section 5.1.3: > > "The remaining bits marked 'r' are reserved." There are no > definition > > of the meaning of reserved bits. I assume SHALL be set to > 0, SHALL be > > ignored on reception? > > Yes, clearly this statement is missing, will add. > > > > > I. Section 5.1.3.5: > > "The method-specific classifier data is two bytes long > and consists of > > a set of flags: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |X|Y|P|T|F|S|A|B| Reserved > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+" > > > > This seems to be 4 bytes, and not 2. > > Yes. :) > > > > > J. Section 5.1.3.6 > > " Offset: The byte in the object at which the QNE found the error. > > When this field is set to "0", the complete object is included." > > > > I don't get these two sentences to match. First sentence > says this is > > a pointer to where the error is. Second sentence indicates that the > > object has been truncated upto the given offset. Please clarify. > > This means that either (1) there is the full object ("0") or > (2) from "offset" upto the end of the object (not from > beginning upto offset), where the problematic part starts at > "offset". I'll clarify this. > > > > > K. Section 5.3.6: > > " > > A SESSION_ID_LIST is carried in RESERVE messages. It is > used in two > > cases, to refresh or two tear down the indicated sessions. " > > > > Second "two" should be a "to"? > > Yes. :) > > > > > L. Section 6. Please update reference to RFC 5226. > > Ack. > > > > > M. Section 7. "The protocol mechanisms s in this > > document try to minimize exhaustion attacks against > these resources > > when performing authentication and authorization for QoS > resources." > > > > Is the lone "s" after mechanisms intended? > > Surely not. :) > From bless@tm.uka.de Tue Oct 13 04:26:33 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 2DEDA28C13F for ; Tue, 13 Oct 2009 04:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 todsy5ZjNa-5 for ; Tue, 13 Oct 2009 04:26:32 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 18C0D28C0E7 for ; Tue, 13 Oct 2009 04:26:32 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1MxfWK-0004cu-UD; Tue, 13 Oct 2009 13:26:31 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1MxfWK-0004bw-PD; Tue, 13 Oct 2009 13:26:24 +0200 Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B477D2FC00A; Tue, 13 Oct 2009 13:26:24 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id 9B4511016B; Tue, 13 Oct 2009 13:26:24 +0200 (CEST) Message-ID: <4AD463E0.8040304@tm.uka.de> Date: Tue, 13 Oct 2009 13:26:24 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka Manner References: <4AC4B492.6070005@ericsson.com> <2727_1254489827_ZZ0KQW00H2R2JM5Q.00_4AC5FEBD.2030701@tm.uka.de> <4ACCE8A7.7050408@tkk.fi> In-Reply-To: <4ACCE8A7.7050408@tkk.fi> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1255433191.778174000 Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, NSIS Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 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: Tue, 13 Oct 2009 11:26:33 -0000 Hi Jukka, Jukka Manner wrote: > Hi Roland, thanks for the note, we'll fix this one, too. I have additional comments you might consider, mainly for consistency and clarification: A) Multiple Upstream RSNs Sec 5.2.1 State Manipulation: RSN from the upstream peer => One must allow for keeping multiple RSNs from different upstream peers Reasoning: this is along the same line as the reasoning for keeping multiple Flow IDs in case of mobility. Usually if R=1 (Replace Flag) is set, you only need to consider one RSN for an upstream peer, but if R=0, you will usually simply dismiss the RESERVE from the new upstream peer in most cases. The new peer however, cannot know which is the latest valid RSN that was used with the previous peer. It's not clear to me whether this will also affect the interface in A.1. I cannot find any SII-Handle which could be used as qualifier for the RSN. B) Receiver-initiated reservations: Sec. 3.2.12, p.20: "If routing changes in the middle of the path, the QNE that notices that its downstream path changed, the divergence point, ..." change to: "If routing changes in the middle of the path, the QNE that notices that its downstream path changed (indicated by a NetworkNotification from GIST), the divergence point, ..." I didn't find any text that states anything about repeating the QUERY message. State refreshes are performed by sending RESERVE messages upstream. So basically it is not necessary to repeat the QUERY from the sender in order to detect route changes, since GIST probing will discover the route change even without the QoS NLSP QUERY sent by the sender. This is a difference to RSVP for example, where the PATH message was periodically repeated, too. Thus I'd like to propose adding clarifying text at the end of sec. 4.3: As GIST will indicate re-routing events by NetworkNotification, it is not necessary to periodically repeat the QUERY message for route change detection (cf. Sec 3.2.12). more NITS: ---------- There is a typo on p.91: " o authorization_info: the AUTHO_SESSION object" => " o authorization_info: the AUTH_SESSION object" and p. 77: spacing: stateful QoS NSLP QNE receives a QUERY message with the RESERVE- INIT => stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT Regards, Roland From bless@tm.uka.de Tue Oct 13 05:31:04 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 0809B28C17B for ; Tue, 13 Oct 2009 05:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 vDVNnOEiQlbj for ; Tue, 13 Oct 2009 05:31:02 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 5F85228C175 for ; Tue, 13 Oct 2009 05:31:02 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1MxgWm-0007b5-1k; Tue, 13 Oct 2009 14:31:01 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1MxgWl-0007J6-RQ; Tue, 13 Oct 2009 14:30:55 +0200 Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id C29942FC008; Tue, 13 Oct 2009 14:30:55 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id AA7701016B; Tue, 13 Oct 2009 14:30:55 +0200 (CEST) Message-ID: <4AD472FF.4060306@tm.uka.de> Date: Tue, 13 Oct 2009 14:30:55 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Magnus Westerlund References: <4AC4B492.6070005@ericsson.com> In-Reply-To: <4AC4B492.6070005@ericsson.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1255437061.963792000 Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, NSIS Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 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: Tue, 13 Oct 2009 12:31:04 -0000 Hi Magnus, I'll try to answer C. and D. Magnus Westerlund wrote: > B. Section 3.1.3 contains a reference to draft-manner-nsis-nslp-auth. > This is an informational reference. But I do wonder about the security > solution and its need to carry authentication information. No, I don't > want to make this a normative reference. But I do wonder how the WG > plans to present the lack of even one fully specified security solution, > even if this is going for experimental. This is indeed a good point. Without the session authorization object, there is only TLS transport security in a hop-by-hop manner, which is also not related to individual sessions or users. So the above draft is indeed very useful. > C. Section 3.2.12.1: How long does it take to detect that a new down > stream peer exist, or that truncation has happened? Route change detections depends on the GIST route change detection mechanisms, at latest the next GIST probing Query message sent. Details are described in section 4.4.4. of the GIST draft, so in the default case of 30s routing state validity probing Querys are sent in the interval [15s...22.5s]. In some cases GIST may detect route changes faster and thus send a new Query earlier. Route change detection requires the three-way GIST handshake to be completed first though (i.e., at least RTT for GIST Query/Response pair). In case of path truncation, one must distinguish whether the new next hop is GIST aware or not. The draft describes the former case, so GIST will respond with "Unknown NSLPID" error in the GIST Response to the Query and the same duration as above can be expected. In the latter case of a non GIST-aware hop it takes longer, because the querying node may perform retransmissions and exponentially backup, so in this case we get a default 127*500ms=63.5s (T1=500ms, T2=64s) as worst case. But as indicated in 5.3.3 of the GIST draft, NSLPs may bound this response time by limiting T2 in the sendmessage() primitive explicitly. > D. Section 4.6, page 35, second paragraph. It is not clear to me how (1) > can be guaranteed to arrive prior to (2), or if both message are sent > width bound to the other one? That's exactly the motivation for the message binding. You cannot guarantee it, so both messages have to wait on each other. This case is described on p. 36: "Triggering message" (3) arrives before waiting (bound) message (1). Usually the waiting condition is then already satisfied, so (1) can be processed immediately. I'm not sure that I understand the last part of your question correctly, but (1) will contain a BOUND_MSG_ID and (2) and (3) will carry the corresponding MSG_ID. Regards, Roland From flefauch@cisco.com Wed Oct 14 01:56:19 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 B0A7D3A6896 for ; Wed, 14 Oct 2009 01:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.335 X-Spam-Level: X-Spam-Status: No, score=-10.335 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 otRaTSKw3GWl for ; Wed, 14 Oct 2009 01:56:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 850583A6823 for ; Wed, 14 Oct 2009 01:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=543; q=dns/txt; s=amsiport01001; t=1255510581; x=1256720181; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Francois=20Le=20Faucheur=20 |Subject:=20draft-ietf-nsis-qspec=20and=20emergency-rsvp |Date:=20Wed,=2014=20Oct=202009=2010:56:17=20+0200 |Message-Id:=20|To:=20=3D?iso-8859-1?Q?=3D22=3D28IJ/ETH=3D29_Attil a_B=3DE1der=3D22?=3D=20,=0D=0A =20=20=20=20=20=20=20=20g.karagiannis@ewi.utwente.nl,=20L ars=20Eggert=20,=0D=0A=20=20=20=20 =20=20=20=20cornelia.kappler@googlemail.com,=20David=20R =20Oran=20|Cc:=20Le=20Faucheur=20Francois =20,=0D=0A=20=20=20=20=20=20=20=20"Ca rlberg,=20Kenneth=20G."=20, =0D=0A=20=20=20=20=20=20=20=20"James=20M.=20Polk"=20,=0D=0A=20=20=20=20=20=20=20=20Gorry=20Fairh urst=20,=20NSIS=20, =0D=0A=20=20=20=20=20=20=20=20Janet=20P=20Gunn=20|Mime-Version:=201.0=20(Apple=20Message=20framewo rk=20v1076)|Content-Transfer-Encoding:=207bit; bh=i8fHbVewUx7v+CVKw/93tEHErWSSJDFT/emloqNoZl0=; b=Q8Q7AuuZ8Yfw3Cv5U8bHkXvhqi1xHTNSIOEFlqITKGOzgf22OT5ndNC3 1dyinAhhSb3qqDjc2XFHlm8Ub/fvWgJGGlgVBsaH46hbemH1qkvohwVC5 bxJkx+5mqP0Gi5lGc8aRNQnSO0tmD4Y5JovYBbEFBgswke/NBZc/BkKvD 8=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,556,1249257600"; d="scan'208";a="51737673" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 08:56:19 +0000 Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9E8uH06004614; Wed, 14 Oct 2009 08:56:18 GMT Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: Date: Wed, 14 Oct 2009 10:56:17 +0200 To: =?iso-8859-1?Q?=22=28IJ/ETH=29_Attila_B=E1der=22?= , g.karagiannis@ewi.utwente.nl, Lars Eggert , cornelia.kappler@googlemail.com, David R Oran Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Wed, 14 Oct 2009 06:12:59 -0700 Cc: Gorry Fairhurst , NSIS , "James M. Polk" , "Carlberg, Kenneth G." Subject: [NSIS] draft-ietf-nsis-qspec and emergency-rsvp 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, 14 Oct 2009 08:56:19 -0000 Folks, draft-ietf-nsis-qspec-21 (now expired) specifies the and . It also refers to emergency-rsvp in several places (e.g. in IANA section for extended RPH registry). Janet indicated that changes may be in the works in regards to those. Could you update us on the NSIS qspec plans wrt to: * * * references to emergency-rsvp ? This is so we ensure we have appropriate references back from emergency-rsvp to nsis-qspec. Thank you Francois From jgunn6@csc.com Wed Oct 14 05:25:45 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 766E43A69EB for ; Wed, 14 Oct 2009 05:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GlXF14eywCwd for ; Wed, 14 Oct 2009 05:25:44 -0700 (PDT) Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by core3.amsl.com (Postfix) with ESMTP id 5668C3A69E8 for ; Wed, 14 Oct 2009 05:25:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-13.tower-170.messagelabs.com!1255523144!18484956!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 3782 invoked from network); 14 Oct 2009 12:25:45 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-13.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Oct 2009 12:25:45 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n9ECPgI4003766; Wed, 14 Oct 2009 08:25:44 -0400 In-Reply-To: To: Francois Le Faucheur MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Wed, 14 Oct 2009 08:25:38 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 10/14/2009 08:27:19 AM, Serialize complete at 10/14/2009 08:27:19 AM Content-Type: multipart/alternative; boundary="=_alternative 0044438D8525764F_=" X-Mailman-Approved-At: Wed, 14 Oct 2009 06:12:59 -0700 Cc: Gorry Fairhurst , NSIS , cornelia.kappler@googlemail.com, "Carlberg, Kenneth G." , David R Oran , =?ISO-8859-1?Q?=28IJ=2FETH=29_Attila_B=E1der?= , "James M. Polk" , g.karagiannis@ewi.utwente.nl Subject: Re: [NSIS] draft-ietf-nsis-qspec and emergency-rsvp 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, 14 Oct 2009 12:25:45 -0000 This is a multipart message in MIME format. --=_alternative 0044438D8525764F_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I take it back.=20 My mind must be going. I was confusing the NSIS documents with the DIME=20 documents. My deepest apologies for causing confusion. Janet This is a PRIVATE message. If you are not the intended recipient, please=20 delete without copying and kindly advise us by e-mail of the mistake in=20 delivery.=20 NOTE: Regardless of content, this e-mail shall not operate to bind CSC to=20 any order or other contract unless pursuant to explicit written agreement=20 or government initiative expressly permitting the use of e-mail for such=20 purpose. Francois Le Faucheur =20 10/14/2009 04:56 AM To "(IJ/ETH) Attila B=E1der" ,=20 g.karagiannis@ewi.utwente.nl, Lars Eggert ,=20 cornelia.kappler@googlemail.com, David R Oran cc Le Faucheur Francois , "Carlberg, Kenneth G."=20 , "James M. Polk" , Gorry=20 Fairhurst , NSIS , Janet P=20 Gunn/USA/CSC@CSC Subject draft-ietf-nsis-qspec and emergency-rsvp Folks, draft-ietf-nsis-qspec-21 (now expired) specifies the and . It also refers to emergency-rsvp in=20 several places (e.g. in IANA section for extended RPH registry). Janet indicated that changes may be in the works in regards to those.=20 Could you update us on the NSIS qspec plans wrt to: * * * references to emergency-rsvp ? This is so we ensure we have appropriate references back from=20 emergency-rsvp to nsis-qspec. Thank you Francois --=_alternative 0044438D8525764F_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I take it back.

 My mind must be going.  I was confusing the NSIS documents with the DIME documents.

My deepest apologies for causing con= fusion.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.


Francois Le Faucheur = <flefauch@cisco.com>

10/14/2009 04:56 AM

To
"(IJ/ETH) Attila B=E1der" = <Attila.Bader@ericsson.com>, g.karagiannis@ewi.utwente.nl, Lars Eggert <lars.eggert@nokia.com>, cornelia.kappler@googlemail.com, David R Oran <oran@cisco.com>
cc
Le Faucheur Francois <flefauch@ci= sco.com>, "Carlberg, Kenneth G." <KENNETH.G.CARLBERG@saic.com>, "= ;James M. Polk" <jmpolk@cisco.com>, Gorry Fairhurst <gorry@erg.abdn.= ac.uk>, NSIS <nsis@ietf.org>, Janet P Gunn/USA/CSC@CSC
Subject
draft-ietf-nsis-qspec and emergency-= rsvp





Folks,

draft-ietf-nsis-qspec-21 (now expired) specifies the <Admission   Priority> and <RPH Priority>. It also refers to emergency-rsvp in  
several places (e.g. in IANA section for extended RPH registry).

Janet indicated that changes may be in the works in regards to those.  = ;
Could you update us on the NSIS qspec plans wrt to:
                * <Admission Priority>
                * <RPH Priority>
                * references to emergency-rsvp
?

This is so we ensure we have appropriate references back from  
emergency-rsvp to nsis-qspec.

Thank you

Francois
--=_alternative 0044438D8525764F_=-- From jmanner@cc.hut.fi Wed Oct 14 07:20:48 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 F0A2128C104 for ; Wed, 14 Oct 2009 07:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 43zcYLWl8WHj for ; Wed, 14 Oct 2009 07:20:47 -0700 (PDT) Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by core3.amsl.com (Postfix) with ESMTP id D1CD028C13F for ; Wed, 14 Oct 2009 07:20:46 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id n9EEKloV004634; Wed, 14 Oct 2009 17:20:47 +0300 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 24894-292-30; Wed, 14 Oct 2009 17:20:46 +0300 (EEST) Received: from vipunen.hut.fi (vipunen.hut.fi [130.233.228.9]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id n9EEGLox002309; Wed, 14 Oct 2009 17:16:21 +0300 Date: Wed, 14 Oct 2009 17:16:21 +0300 (EEST) From: Jukka MJ Manner To: Roland Bless In-Reply-To: <4AD463E0.8040304@tm.uka.de> Message-ID: References: <4AC4B492.6070005@ericsson.com> <2727_1254489827_ZZ0KQW00H2R2JM5Q.00_4AC5FEBD.2030701@tm.uka.de> <4ACCE8A7.7050408@tkk.fi> <4AD463E0.8040304@tm.uka.de> User-Agent: Alpine 1.99 (SOC 1136 2008-08-12) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-Mailman-Approved-At: Wed, 14 Oct 2009 07:27:28 -0700 Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, NSIS Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 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, 14 Oct 2009 14:20:48 -0000 Hi, Roland thanks for these, I'll take them into account when finalizing the next rev. Jukka On Tue, 13 Oct 2009, Roland Bless wrote: > Hi Jukka, > > Jukka Manner wrote: >> Hi Roland, thanks for the note, we'll fix this one, too. > > I have additional comments you might consider, mainly > for consistency and clarification: > > A) Multiple Upstream RSNs > Sec 5.2.1 State Manipulation: > RSN from the upstream peer > => One must allow for keeping multiple RSNs from different upstream > peers > > Reasoning: this is along the same line as the reasoning for keeping > multiple Flow IDs in case of mobility. Usually if R=1 (Replace Flag) > is set, you only need to consider one RSN for an upstream peer, but > if R=0, you will usually simply dismiss the RESERVE from the new > upstream peer in most cases. The new peer however, cannot know which > is the latest valid RSN that was used with the previous peer. > > It's not clear to me whether this will also affect the interface in > A.1. I cannot find any SII-Handle which could be used as qualifier > for the RSN. > > B) Receiver-initiated reservations: > Sec. 3.2.12, p.20: > "If routing changes in the middle of the path, the QNE that notices > that its downstream path changed, the divergence point, ..." > change to: > "If routing changes in the middle of the path, the QNE that notices > that its downstream path changed (indicated by a NetworkNotification > from GIST), the divergence point, ..." > > I didn't find any text that states anything about repeating the > QUERY message. State refreshes are performed by sending RESERVE > messages upstream. So basically it is not necessary to repeat > the QUERY from the sender in order to detect route changes, > since GIST probing will discover the route change even without > the QoS NLSP QUERY sent by the sender. This is a difference to > RSVP for example, where the PATH message was periodically > repeated, too. > > Thus I'd like to propose adding clarifying text at the > end of sec. 4.3: > As GIST will indicate re-routing events by NetworkNotification, > it is not necessary to periodically repeat the QUERY message > for route change detection (cf. Sec 3.2.12). > > more NITS: > ---------- > There is a typo on p.91: > " o authorization_info: the AUTHO_SESSION object" > => > " o authorization_info: the AUTH_SESSION object" > > and p. 77: spacing: > stateful QoS NSLP QNE receives a QUERY message with the RESERVE- INIT > => > stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT > > Regards, > Roland > > > From magnus.westerlund@ericsson.com Fri Oct 16 02:30:40 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 372EB3A67FD for ; Fri, 16 Oct 2009 02:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.015, 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 j30vm-+ZQIxT for ; Fri, 16 Oct 2009 02:30:29 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 1061F3A681F for ; Fri, 16 Oct 2009 02:30:24 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-d0-4ad83d26fcdc Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 70.99.08816.62D38DA4; Fri, 16 Oct 2009 11:30:14 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 11:29:05 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 11:29:04 +0200 Message-ID: <4AD83CE0.8010605@ericsson.com> Date: Fri, 16 Oct 2009 11:29:04 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Roland Bless References: <4AC4B492.6070005@ericsson.com> <4AD472FF.4060306@tm.uka.de> In-Reply-To: <4AD472FF.4060306@tm.uka.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Oct 2009 09:29:04.0279 (UTC) FILETIME=[1A32C270:01CA4E43] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, NSIS Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 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, 16 Oct 2009 09:30:47 -0000 Roland Bless skrev: > Hi Magnus, > > I'll try to answer C. and D. > > Magnus Westerlund wrote: >> B. Section 3.1.3 contains a reference to draft-manner-nsis-nslp-auth. >> This is an informational reference. But I do wonder about the security >> solution and its need to carry authentication information. No, I don't >> want to make this a normative reference. But I do wonder how the WG >> plans to present the lack of even one fully specified security solution, >> even if this is going for experimental. > > This is indeed a good point. Without the session authorization object, > there is only TLS transport security in a hop-by-hop manner, which is > also not related to individual sessions or users. So the above draft > is indeed very useful. I think there might be a point to admit openly that the security solution for this behavior is currently not specified and do require work. > >> C. Section 3.2.12.1: How long does it take to detect that a new down >> stream peer exist, or that truncation has happened? > > Route change detections depends on the GIST route change detection > mechanisms, at latest the next GIST probing Query message > sent. Details are described in section 4.4.4. of the GIST draft, so > in the default case of 30s routing state validity probing Querys are > sent in the interval [15s...22.5s]. In some cases GIST may detect > route changes faster and thus send a new Query earlier. Route change > detection requires the three-way GIST handshake to be completed first > though (i.e., at least RTT for GIST Query/Response pair). > In case of path truncation, one must distinguish whether the new > next hop is GIST aware or not. The draft describes the former case, > so GIST will respond with "Unknown NSLPID" error in the GIST Response > to the Query and the same duration as above can be expected. In the > latter case of a non GIST-aware hop it takes longer, because the > querying node may perform retransmissions and exponentially backup, > so in this case we get a default 127*500ms=63.5s (T1=500ms, T2=64s) > as worst case. But as indicated in 5.3.3 of the GIST draft, NSLPs may > bound this response time by limiting T2 in the sendmessage() primitive > explicitly. > Thanks for the answer. I don't think there is any need to do changes here in the text. >> D. Section 4.6, page 35, second paragraph. It is not clear to me how (1) >> can be guaranteed to arrive prior to (2), or if both message are sent >> width bound to the other one? > > That's exactly the motivation for the message binding. You cannot > guarantee it, so both messages have to wait on each other. This case > is described on p. 36: "Triggering message" (3) arrives before waiting > (bound) message (1). Usually the waiting condition is then already > satisfied, so (1) can be processed immediately. I'm not sure that I > understand the last part of your question correctly, but (1) will > contain a BOUND_MSG_ID and (2) and (3) will carry the corresponding > MSG_ID. > Hmm, clearly my thought process wasn't working. I don't see any issues with the text when revisiting it. It seem to have the relevant references to the mechanism used. So forget this comment. -- 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 jukka.manner@tkk.fi Fri Oct 16 02:42:13 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 302F83A699E for ; Fri, 16 Oct 2009 02:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.345 X-Spam-Level: X-Spam-Status: No, score=-5.345 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, 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 0wIX-VBN6557 for ; Fri, 16 Oct 2009 02:42:12 -0700 (PDT) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by core3.amsl.com (Postfix) with ESMTP id C73203A69BB for ; Fri, 16 Oct 2009 02:42:11 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id n9G9gDwN017275; Fri, 16 Oct 2009 12:42:13 +0300 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 20390-260-2; Fri, 16 Oct 2009 12:42:13 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id n9G9g1Bt017226; Fri, 16 Oct 2009 12:42:01 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 98F391E13F; Fri, 16 Oct 2009 12:42:01 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JCf2zhB5lxNt; Fri, 16 Oct 2009 12:41:57 +0300 (EEST) Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 411B21E077; Fri, 16 Oct 2009 12:41:57 +0300 (EEST) Received: from [130.233.154.59] (pc59.netlab.hut.fi [130.233.154.59]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id 311A9120050; Fri, 16 Oct 2009 12:41:57 +0300 (EEST) Message-ID: <4AD83FE5.7030707@tkk.fi> Date: Fri, 16 Oct 2009 12:41:57 +0300 From: Jukka Manner User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Magnus Westerlund References: <4AC4B492.6070005@ericsson.com> <4AD472FF.4060306@tm.uka.de> <2727_1255685491_ZZ0KRL007U6P4IG6.00_4AD83CE0.8010605@ericsson.com> In-Reply-To: <2727_1255685491_ZZ0KRL007U6P4IG6.00_4AD83CE0.8010605@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, Roland Bless , NSIS Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 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, 16 Oct 2009 09:42:13 -0000 Hi Magnus, So is the next step that I do the mentioned edits, and submit a version for the IESG? cheers, Jukka Magnus Westerlund wrote: > Roland Bless skrev: >> Hi Magnus, >> >> I'll try to answer C. and D. >> >> Magnus Westerlund wrote: >>> B. Section 3.1.3 contains a reference to draft-manner-nsis-nslp-auth. >>> This is an informational reference. But I do wonder about the security >>> solution and its need to carry authentication information. No, I don't >>> want to make this a normative reference. But I do wonder how the WG >>> plans to present the lack of even one fully specified security solution, >>> even if this is going for experimental. >> This is indeed a good point. Without the session authorization object, >> there is only TLS transport security in a hop-by-hop manner, which is >> also not related to individual sessions or users. So the above draft >> is indeed very useful. > > I think there might be a point to admit openly that the security > solution for this behavior is currently not specified and do require work. > >>> C. Section 3.2.12.1: How long does it take to detect that a new down >>> stream peer exist, or that truncation has happened? >> Route change detections depends on the GIST route change detection >> mechanisms, at latest the next GIST probing Query message >> sent. Details are described in section 4.4.4. of the GIST draft, so >> in the default case of 30s routing state validity probing Querys are >> sent in the interval [15s...22.5s]. In some cases GIST may detect >> route changes faster and thus send a new Query earlier. Route change >> detection requires the three-way GIST handshake to be completed first >> though (i.e., at least RTT for GIST Query/Response pair). >> In case of path truncation, one must distinguish whether the new >> next hop is GIST aware or not. The draft describes the former case, >> so GIST will respond with "Unknown NSLPID" error in the GIST Response >> to the Query and the same duration as above can be expected. In the >> latter case of a non GIST-aware hop it takes longer, because the >> querying node may perform retransmissions and exponentially backup, >> so in this case we get a default 127*500ms=63.5s (T1=500ms, T2=64s) >> as worst case. But as indicated in 5.3.3 of the GIST draft, NSLPs may >> bound this response time by limiting T2 in the sendmessage() primitive >> explicitly. >> > Thanks for the answer. I don't think there is any need to do changes > here in the text. > > >>> D. Section 4.6, page 35, second paragraph. It is not clear to me how (1) >>> can be guaranteed to arrive prior to (2), or if both message are sent >>> width bound to the other one? >> That's exactly the motivation for the message binding. You cannot >> guarantee it, so both messages have to wait on each other. This case >> is described on p. 36: "Triggering message" (3) arrives before waiting >> (bound) message (1). Usually the waiting condition is then already >> satisfied, so (1) can be processed immediately. I'm not sure that I >> understand the last part of your question correctly, but (1) will >> contain a BOUND_MSG_ID and (2) and (3) will carry the corresponding >> MSG_ID. >> > > Hmm, clearly my thought process wasn't working. I don't see any issues > with the text when revisiting it. It seem to have the relevant > references to the mechanism used. So forget this comment. > -- Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 Helsinki University of Technology Mobile: +358+(0)50+5112973 Department of Communications Fax: +358+(0)9+451 2474 and Networking (Comnet) Office: G320 (Otakaari 5A) P.O. Box 3000, FIN-02015 TKK E-mail: jukka.manner@tkk.fi Finland WWW: www.comnet.tkk.fi From magnus.westerlund@ericsson.com Fri Oct 16 06:42:35 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 604F53A6A20 for ; Fri, 16 Oct 2009 06:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.014, 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 FdFGwGpQ5I1B for ; Fri, 16 Oct 2009 06:42:34 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E7F8D3A6873 for ; Fri, 16 Oct 2009 06:42:33 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-40-4ad8784c7d58 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B8.7E.08816.C4878DA4; Fri, 16 Oct 2009 15:42:36 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 15:42:19 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 15:42:18 +0200 Message-ID: <4AD8783A.80200@ericsson.com> Date: Fri, 16 Oct 2009 15:42:18 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jukka Manner References: <4AC4B492.6070005@ericsson.com> <4AD472FF.4060306@tm.uka.de> <2727_1255685491_ZZ0KRL007U6P4IG6.00_4AD83CE0.8010605@ericsson.com> <4AD83FE5.7030707@tkk.fi> In-Reply-To: <4AD83FE5.7030707@tkk.fi> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Oct 2009 13:42:18.0853 (UTC) FILETIME=[7ADEC150:01CA4E66] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, Roland Bless , NSIS Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16 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, 16 Oct 2009 13:42:35 -0000 Jukka Manner skrev: > Hi Magnus, > > So is the next step that I do the mentioned edits, and submit a version > for the IESG? Submit a new version, and then I will do a IETF last call on the document. Magnus -- 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 Oct 16 06:47:48 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 E20323A685C for ; Fri, 16 Oct 2009 06:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.013, 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 qy7soC2503+I for ; Fri, 16 Oct 2009 06:47:48 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 974833A6873 for ; Fri, 16 Oct 2009 06:47:47 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-08-4ad87985d3da Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 47.90.04191.58978DA4; Fri, 16 Oct 2009 15:47:50 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 15:47:49 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 15:47:49 +0200 Message-ID: <4AD87985.6030304@ericsson.com> Date: Fri, 16 Oct 2009 15:47:49 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: draft-ietf-nsis-y1541-qosm@tools.ietf.org, NSIS X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Oct 2009 13:47:49.0185 (UTC) FILETIME=[3FC36B10:01CA4E67] X-Brightmail-Tracker: AAAAAA== Subject: [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, 16 Oct 2009 13:47:49 -0000 Hi, Here are my AD comments on Y.1541 QoSM. 1. Section 2.2: Please include units for all the parameters that has units. 2. Section 3.1: Reference for IEEE floating point spec is missing. 3. Section 3.1: What are the definitions of the Bp and M parameter? 4. Section 3.2: Why are there a discussion in the document for what the reserved bits may be used to? Aren't they either reserved for future extension or fully defined? If reserved the current sender and receiver behavior need to be defined. Normally; SHALL be set to 0 and SHALL be ignored on reception. 5. Section 5: This section defines the registries and initial codepoint assignments for the QSPEC template, in accordance with BCP 26 [RFC5226]. It also defines the procedural requirements to be followed by IANA in allocating new codepoints. This seems copied from the QSPEC document. It needs to reworded to correctly indicate what it does. I would also put have subsection for each of the IANA actions the draft do defines: 1. Register two QOSEC Parameters 2. Define a new registry for Restoriation Priority Parameter. 6. Section 6. I don't quite believe that there are no additional security considerations around either the model nor the added parameters. They may very well be handled by the mechanism in the QoS NSLP and QSPEC documents. But I think you need to at least bring up the security issues the model and the new parameters introduce. Please review my comments and revise the document as you find appropriate. If you find me in error or have other suggestions please tell me and the WG. 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 Tue Oct 20 18:23: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 5A5573A67A7 for ; Tue, 20 Oct 2009 18:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.629 X-Spam-Level: X-Spam-Status: No, score=-95.629 tagged_above=-999 required=5 tests=[AWL=-1.031, BAYES_05=-1.11, FF_IHOPE_YOU_SINK=2.166, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, MANGLED_MEN=2.3, 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 pPg-7FLsUtme for ; Tue, 20 Oct 2009 18:23:52 -0700 (PDT) Received: from web63606.mail.re1.yahoo.com (web63606.mail.re1.yahoo.com [69.147.97.76]) by core3.amsl.com (Postfix) with SMTP id 051503A67AF for ; Tue, 20 Oct 2009 18:23:51 -0700 (PDT) Received: (qmail 89621 invoked by uid 60001); 21 Oct 2009 01:23:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1256088237; bh=DHFjqxIQYlhA0MdWVcH3hLBzJDcyfWi2qJ5b0h2s7qs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=VjoRPVP0niMyHvkK8bh1vlCZCMe4L2TQ77GTuShC5GOxev7eszQ25hhb1+slU7AP3ajvdDywy553bn9O7M0KoyFMr7QJvzCV725mRTYfQVP58BAUMCZc7lbCcB7XCNr64pqztQxogQkEe39nRLiRh26c1e60QvgQCqF4T4yY3II= 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:MIME-Version:Content-Type; b=EhmsAZVPIR0BEUqv9qiaPScCokBUQRjsFBbgOgff8iqPPrZjLHeL6g6Sj9eBcy0CLW/TFhGdzAwZBXShgmAH7JvVqfqaA2g3Oa3GVY107CUrHETmIe3XOfkDIkaB9VCs+sAY15ZhYWNXR47EeyNcPvjXX0vqAwbR5ZXrdbIpsQU=; Message-ID: <522404.88576.qm@web63606.mail.re1.yahoo.com> X-YMail-OSG: VXSFH2AVM1nIjn1r9TV17VGNyTnOS6ZyNwxho7yBoAbEaygbSu1orBJe2sU7y_RmnjuUVMIUPKtmFhG0UgQjXdA4xlz5CZ6_gVIQmNZFzJh.tNJNiWavqg5JiboMN_Y.akjx3xVjtk.3CIdE2dIIgHz68CtnZ8geY2DWsqL1C9ovyXquV7hOl4qd.c31L5x6RW3IU8gF1gdt1te5Gf9CaIKRCMLNWJOFan6PUBo042yIlNwKjcd26OI.26UmjSL7pDALVdIOROoFJzA4OAWhDqq.4rugOXkYNJ_6IgtxxsNZ3yFqbgy8xyXVCV7K0WXv_co6vof95AsjIXO2lePxcb3Dd3MgdeujMLxCwgogihVr4LK_Plh1lV4c7mZ4 Received: from [24.91.148.40] by web63606.mail.re1.yahoo.com via HTTP; Tue, 20 Oct 2009 18:23:57 PDT X-Mailer: YahooMailClassic/7.0.14 YahooMailWebService/0.7.347.3 Date: Tue, 20 Oct 2009 18:23:57 -0700 (PDT) From: Gerald Ash To: Magnus Westerlund , NSIS MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-215315087-1256088237=:88576" Cc: draft-ietf-nsis-qspec@tools.ietf.org, David Black Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21 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, 21 Oct 2009 01:23:55 -0000 --0-215315087-1256088237=:88576 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Magnus, =C2=A0 Thanks for your comments. =C2=A0 Here are our responses (with input=C2=A0also from David Black and Al Morton= ). =C2=A0 Please let us know of any further comments or questions. =C2=A0 Thanks, Regards, Jerry =C2=A0 >=20 > --- On Fri, 10/2/09, Magnus Westerlund = =20 > wrote: >=20 >=20 > From: Magnus Westerlund > Subject: [NSIS] AD comments on draft-ietf-nsis-qspec-21 > To: "NSIS" , draft-ietf-nsis-qspec@tools.ietf.org > Date: Friday, October 2, 2009, 5:32 AM >=20 >=20 > Hi, >=20 > Very sorry for the long delay in getting this review completed. >=20 > 1. Section 1. last paragraph: I don't think "worked example" is easily > understood. Can you find another word? =C2=A0 Will substitute "an example" for "a worked example". > 2. Section 3.1: > - QSPEC parameter behavior for new QSPEC parameters the QOSM >=C2=A0=C2=A0=C2=A0=C2=A0 behavior (tear down preempted reservation) is not= followed (see >=C2=A0=C2=A0=C2=A0=C2=A0 specification defines >=C2=A0=C2=A0 - define what happens in case of preemption if the default QN= I >=C2=A0=C2=A0=C2=A0=C2=A0 Section 4.3..5) >=20 > Some editing issues here around the second parenthesis in the first > bullet. It closes in the second bullet. =C2=A0 These 2 bullet=C2=A0items should read as follows: =C2=A0 "=C2=A0 - QSPEC parameter behavior for new QSPEC parameters the QOSM =C2=A0=C2=A0=C2=A0=C2=A0 specification defines =C2=A0=C2=A0 - define what happens in case of preemption if the default QNI =C2=A0=C2=A0=C2=A0=C2=A0 behavior (tear down preempted reservation) is not = followed (see =C2=A0=C2=A0=C2=A0=C2=A0 Section 5.3.5) " > 3. Section 3.2: > "QSPEC >=C2=A0=C2=A0 parameters are the parameters appearing in a QSPEC, which mus= t >=C2=A0=C2=A0 include traffic (TMOD),=C2=A0 ..." >=20 > I do believe there is a missing word between traffic and "(TMOD). =C2=A0 Will change "include traffic (TMOD)" to "include the traffic model paramete= r (TMOD)" > 4. Section 3.2, second paragraph: >=20 > "IANA >=C2=A0=C2=A0 assigns a new QSPEC version number when changes that are not >=C2=A0=C2=A0 backwards compatible are made to the QSPEC and this document = is >=C2=A0=C2=A0 reissued. " >=20 > and > "Later QSPEC versions MUST be >=C2=A0=C2=A0 backward compatible with earlier QSPEC versions." >=20 > The two sentences are contradicting. Please make it clear when new > version is needed. =C2=A0 Will change=C2=A0 "IANA assigns a new QSPEC version number when changes that are not backward= s compatible are made to the QSPEC and this document is reissued." to "IANA assigns a new QSPEC version number when=C2=A0the current version is d= eprecated or deleted (as required by a=C2=A0specification)." > 5. Section 3.3.1: The 4 sub-parameters can you please specify units for > them? =C2=A0 =C2=A0=C2=A0 o rate (r) specified in=C2=A0bytes per second=20 =C2=A0=C2=A0 o bucket size (b) specified in bytes=20 =C2=A0=C2=A0 o peak rate (p) specified in bytes per second=20 =C2=A0=C2=A0 o minimum policed unit (m) specified in bytes=20 > 6. Section 3.3.1: You don't seem to have a definition of what "minimum > policed unit" is. I assume that this definition from RFC 2211 is > applicable, but still either include it or reference it. > >=C2=A0=C2=A0 The minimum policed unit, m, is an integer measured in bytes.= =C2=A0 All IP >=C2=A0=C2=A0 datagrams less than size m will be counted against the token = bucket >=C2=A0=C2=A0 as being of size m." =C2=A0 Will include the above definition and also reference RFC 2211. > 7. Section 3.3.1: What is the definition of peak rate? I understand that > the "rate" is a uniform filling rate of the token bucket. However, peak > rate implies that it is not a smoothed value nor has its own bucket > depth parameter. So please provide a definition. =C2=A0 The following definition=C2=A0given in RFC 2212 will be added and reference= d: " The peak rate is the maximum rate at which the source and any =C2=A0=C2=A0 reshaping points (reshaping points are defined below) may inje= ct =C2=A0=C2=A0 bursts of traffic into the network.=C2=A0 More precisely, it i= s a =C2=A0=C2=A0 requirement that for all time periods the amount of data sent = cannot =C2=A0=C2=A0 exceed M+pT where M is the maximum datagram size and T is the = length =C2=A0=C2=A0 of the time period.=C2=A0 Furthermore, p MUST be greater than = or equal to =C2=A0=C2=A0 the token bucket rate, r.=C2=A0 If the peak rate is unknown or =C2=A0=C2=A0 unspecified, then p MUST be set to infinity." > 8. Section 3.3.2: " This delay >=C2=A0=C2=A0 results from the combination of speed-of-light propagation de= lay," >=20 > Wouldn't it be clearer to say "link" instead of speed-of-light. > Especially in cases where the link has retransmission or other features > that makes the links propagation delay not solely be dependent on the > speed-of-light in the medium used. =C2=A0 Agree, will substitute "link" for "speed-of-light". > 9. Section 3.3.2: "Furthermore, the >=C2=A0=C2=A0 QNI MUST add the propagation delay of the ingress link, if th= is link >=C2=A0=C2=A0 exists." >=20 > How, is the QNI supposed to know the propagation delay of the ingress > link? I agree that there are cases where this can be configured, but > there appear to be a number of cases when it would not be the case. > Therefore I am a bit questioning a MUST on something that may not be > possible to perform. =C2=A0 Agree,=C2=A0it=C2=A0must be configured.=C2=A0 Will substitute "SHOULD" for = "MUST". > 10. Section 3.3.2: What is the definition of path error ratio? =C2=A0 Per the=C2=A0definition in Y.1540 and Y.1541: "Packet error ratio is the ratio of total errored IP packet outcomes to the= total of successful IP packet transfer outcomes plus errored IP packet out= comes in a population of interest,=C2=A0with a resolution of at least 10=E2= =80=939.=C2=A0 If lesser resolution is available in a value, the unused dig= its shall be set to zero." Will also add that the number of=C2=A0errored packets=C2=A0observed is dire= ctly related to the confidence in the result.=C2=A0=20 =C2=A0 > 11. This may seem out of context but I do want to know the answer to how > the situation is handled when QNI and QNR are neighbors on a non QoS > enabled network. =C2=A0 What "situation"=C2=A0are you=C2=A0referring to here?=C2=A0 IMO you can't h= ave a QNI and QNR in a "non QoS enabled network".=C2=A0 By definition, a QN= I and QNR are only defined in an NSIS enabled network (i.e., a QoS enabled = network). > 12. Section 4.2.1: > "Note that >=C2=A0=C2=A0 the TMOD parameter and all QSPEC parameters with the M flag s= et MUST >=C2=A0=C2=A0 be examined by the RMF, and all QSPEC parameters with the M f= lag not >=C2=A0=C2=A0 set SHOULD be examined by the RMF, and appropriately flagged.= " >=20 > What is meant with appropriately flagged in the above sentence? =C2=A0 It refers to setting the E flag (which is described in the=C2=A0sentence ju= st before the one you quote above in the current qspec document).=C2=A0 The= above sentence will be further clarified as follows: "the TMOD parameter and all QSPEC parameters with the M flag set MUST be ex= amined by the RMF, and all QSPEC parameters with the M flag not set SHOULD = be examined by the RMF, and the E flag set to=C2=A0indicate=C2=A0whether th= e parameter could or could not be satisfied." =C2=A0 > 13. Section 5.1.1: Even if version numbers are assigned by IANA I think > the spec should be explicit on which version this one defines. Also as > being the first version, I think assigning it yourself would be fully > appropriate.. =C2=A0 QSPEC Version 0=C2=A0is assigned in Section 7 (IANA Considerations), as fol= lows: =C2=A0 "=C2=A0=C2=A0 QSPEC Version (4 bits): =C2=A0=C2=A0 The following value is allocated by this specification:=20 =C2=A0=C2=A0 0: assigned to Version 0 QSPEC"=20 =C2=A0=20 Will also note this in Section 5.1.1.=20 > 14. Section 5.1.1.: QSPEC Type: I think this should have a pointer to > the IANA registry. =C2=A0 OK. =C2=A0 > 15. Section 5.1.1: > "=C2=A0=C2=A0 Length: The total length of the QSPEC excluding the common = header" >=20 > Please make it clear that you count in 32-bit words (?) and add the "." > at the end of the sentence. =C2=A0 "Length" is defined at the beginning of Section 5.1 as follows: "=C2=A0=C2=A0 o Length has the units of 32-bit words, and measures the leng= th of =C2=A0=C2=A0=C2=A0=C2=A0 Value.=C2=A0 If there is no Value, Length=3D0.=C2= =A0 The Object length=20 =C2=A0=C2=A0=C2=A0=C2=A0 excludes the header."=20 =C2=A0=20 The sentence you quote above in Section 5.1.1 will also be clarified as fol= lows:=20 "=C2=A0=C2=A0 Length: The total length of the QSPEC (in 32-bit words) exclu= ding the common header" =C2=A0 > 16. Section 5.1.2: "Parameter ID: Assigned to each parameter (see below)" >=20 > The text below this does not discuss parameter ID in any useful way. > Please correct that or provide a better reference to where it is discusse= d.=20 =C2=A0=20 Will clarify this sentence as follows:=20 "Parameter ID: Assigned consecutively=C2=A0to each QSPEC parameter (paramet= er ID's are assigned to each QSPEC parameter defined in this document=C2=A0= in Section 5.2=C2=A0below and in Section 7/IANA Considerations)" > 17. Section 5.2.1: > "he parameters are represented by three floating point >=C2=A0=C2=A0 numbers in single-precision IEEE floating point format follow= ed by >=C2=A0=C2=A0 one 32-bit integer in network byte order." >=20 > Please add a reference for the IEEE floating point format.=20 =C2=A0=20 This is=C2=A0Reference [IEEE754]=C2=A0now given in Section 11 (Informative = References).=C2=A0 Will give this reference also in the above sentence in S= ection 5.2.1. > 18. Section 5.2.1: I don't think the reference in the section title is > particular helping. I definitely prefer explicit references for each > item so that you easily can find them. There is also a risk for > confusion if multiple references are not agreeing on a parameter > definition. For example take the "minimum policed unit". What it is is > defined in RFC 2210, but there is also redundant interpretation text in > RFC 2215. I also have a hard time determining if any reference is missing= .=20 =C2=A0=20 OK, will move the references into=C2=A0each section, and avoid redundant re= ferences. > 19. Section 5.2.3: The referenced documents does not define Path > latency, only minimal path latency. Not obvious that they are the same, > for example from a perspective of queuing delay or link ARQ.=20 =C2=A0=20 The intention of the Path Latency parameter is the same as the Minimal Path= Latency parameter defined in Section 3.4 of RFC 2215.=C2=A0 Note that it a= lso says in RFC 2215:=20 =C2=A0=20 "The purpose of this parameter is to provide a baseline minimum path =C2=A0=C2=A0 latency for use with services which provide estimates or bound= s on =C2=A0=C2=A0 additional path delay, such as Guaranteed [RFC 2212]..=C2=A0 T= ogether with =C2=A0=C2=A0 the queuing delay bound offered by Guaranteed and similar serv= ices, =C2=A0=C2=A0 this parameter gives the application knowledge of both the min= imum =C2=A0=C2=A0 and maximum packet delivery delay."=20 =C2=A0=20 This is also the intent of the parameter for use in the QSPEC. > 20. Section 5.2.4: Once more the references are unclear. Especially as > RFC 3393 doesn't use "jitter". You need to be explicit about what is what= .=20 =C2=A0=20 It will be clarified that "jitter" is called "IP Delay Variation" in RFC 33= 93.=C2=A0 This is actually already stated in Section 3.3.2, but will be rei= terated in Section 5.2.4.=20 > 21. Section 5.2.5: First of all I am not convinced by looking in Y.1541 > that packet loss ratio has a clear definition. I am missing what type of > averaging is assumed in the value. If you going to measure this value > you need to do it over sufficiently many packets, measuring over 7 > packets with one loss doesn't say much.=20 =C2=A0=20 An evaluation interval of 1 minute is suggested in Y.1541.=C2=A0 This will = be noted in Section 5.2.5.=C2=A0=C2=A0Will also add that the number of loss= es observed is directly related to the confidence in the result. > 22. Section 5.2.5: " An >=C2=A0=C2=A0 individual QNE can advertise a PLR value between zero and 10^= -2 >=C2=A0=C2=A0 and the total PLR added across all QNEs can range as high as = 10^-1." >=20 > Isn't the restriction to advertise a link PLR no higher than 10^-2 a to > strict limit. Doesn't there exist links out there that has that level of > loss. Maybe not ones that you usually request QoS over, but anyway.=20 =C2=A0=20 The maximum limit of 10^-2 on a=C2=A0QNE's local=C2=A0PLR value and the max= imum limit (clamp value) of 10^-1 on=C2=A0accumulated end-to-end PLR value = are used to preserve the accuracy of the simple additive accumulation funct= ion specified in the QSPEC.=C2=A0=C2=A0It's important to avoid more complex= accumulation functions and stay with the simple additive accumulation func= tion (Y.1541 mentions the different methods in section 8.2.2 and 8.2.3).=C2= =A0 Furthermore, if these maximums are=C2=A0exceeded,=C2=A0then (as you say= )=C2=A0the path=C2=A0would not=C2=A0have much quality and=C2=A0would likely= not meet the=C2=A0QoS objectives anyway.=C2=A0 Finally the word "add" shou= ld replace the word "advertise"=C2=A0and the quoted sentence further clarif= ied=C2=A0as follows: "An individual QNE adds its local PLR value (up to=C2=A0a maximum of 10^-2)= to the total path PLR value (up to=C2=A0a maximum of 10^-1) , where the ac= ceptability of the total path PLR value added across all QNEs is determined= based on the QOSM being used."=C2=A0=20 > 23. Section 5.2.11: > "When the shaping causes >=C2=A0=C2=A0 unbounded queue growth at the shaper traffic can be dropped." >=20 > To me the shaping seems unclear, as it contains a unknown factor of the > queue used. Both queue depth and dropping model would influence how the > shaping happens.=20 =C2=A0=20 Actually, the bucket size in the TMOD parameter for excess traffic specifie= s the queuing behavior that is of concern.=C2=A0 The traffic in question he= re is not only out-of-profile wrt the primary traffic spec, but it's but it= 's *also* out of profile wrt to a secondary traffic spec for excess traffic= .=C2=A0 However, we=C2=A0see no problem with saying that any traffic that i= s excess of the TMOD for excess traffic MAY be dropped (or even SHOULD be d= ropped), and will rephrase the sentence in question as such.=20 =C2=A0=20 > 24. Section 5.2.11: > Remark Value (6 bits): indicates either drop (set to 0) or DSCP >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 value [RFC2474] to remark packets to when >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 identified as excess >=20 > So you can't remark traffic into the best-effort traffic class? Isn't > that a severe limitation? And why are there need for two ways of marking > drop as excess treatments?=20 =C2=A0=20 Correct.=C2=A0=C2=A0The usual DSCP for best-effort is zero, but=C2=A0the me= aning of that value has been changed to drop in the quoted text.=C2=A0 That= makes it impossible to remark to a DSCP of zero, which is usually the best= -effort traffic class.=C2=A0 However, since "drop" is already encoded in th= e Excess Treatment value, as you point out,=C2=A0we will=C2=A0remove the ab= ility to encode "drop" here, specifically, remove the words "either drop (s= et to 0) or" . > 25. Section 5.2.12: >=20 >=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3 >=C2=A0=C2=A0=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7= 8 9 0 1 >=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+ >=C2=A0=C2=A0 |M|E|N|r|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 12=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |r|r|r|r= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | >=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+ >=C2=A0=C2=A0 | DSCP=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |0 0 0 0 0 0 0 0 0 0|=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Reserved)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | >=C2=A0=C2=A0 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+= ---+ >=20 > Two comments about the field definition for the third 16-bit word. >=20 > First, why is one of the possible field value represented rather than > giving the field a name. That way one can make it clear that the > possibility for different structures in that 16-bit word. I would > probably have defiend it as: >=20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > | PH Field Value=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |EN | >=20 > I do understand that would be different from how RFC 3140 is > representing the information, but be equivalent. As an alternative I > would simple change the first diagram to say instead of DSCP=C2=A0=C2=A0 = | 0 0 ... > to say PHB Field. Anyway, I think the current representation is unclear.= =20 =C2=A0=20 What=C2=A0you suggest is consistent with RFC 3140 and=C2=A0a reasonable way= to do this.=C2=A0 We will=C2=A0substitute=C2=A0the 16 bits you suggest for= the DSCP + 10 bits of zeroes, and explain that the result matches RFC 3140= and that the following four figures show 4 possible formats based on the v= alue of the EN field. =C2=A0 > 26. Section 7. There are registries that requires standard action for > new registrations. I think that is not consistent with publishing this > as experimental. Please address.=20 =C2=A0=20 First, the QSPEC is an *Informational* document, not experimental.=C2=A0 In= any case, we will change "Standards Action" to "Specification Required" in= each case.=20 > 27. Section 7.. QSPEC Procedures. This table is so confusing, I can't get > my head around what code point space is registered. And if there are a > second dimension for certain values and in that case which that is.=20 =C2=A0=20 The=C2=A0QSPEC Procedures=C2=A0object=C2=A0being=C2=A0registered by IANA sp= ecifications=C2=A0in Section 7=C2=A0is specified in Section 5.1.1 (Common H= eader Format).=C2=A0 The=C2=A0code point=C2=A0space consists of a Message S= equence sub-parameter and an Object Combination sub-parameter.=C2=A0 Sectio= n 4.3 explains the Message Sequence and Object Combination sub-parameters.= =C2=A0 Object Combinations 0, 1, and 2 are explained in Section 4.3.1, 4.3.= 2, and 4.3.3, respectively.=C2=A0 Tables 1, 2, and 3 in Section 4.3 assign = the Message Sequence ID to=C2=A0Object Combinations 0, 1, and, 2, respectiv= ely.=C2=A0 There is an error to be corrected in the IANA specifications: Ob= ject Combination 2 (Section 4.3.3) has only one Message Sequence ID, not 3 = (this will be corrected.=C2=A0=C2=A0Hopefully this explains whatever=C2=A0c= onfusion there is here.=20 =C2=A0 > 28. References: Can you please ensure that there is a blank line between > each reference. Now it is very difficult to read the list.=20 =C2=A0=20 OK=20 =C2=A0=20 > Also, making > the reference using a hanging style makes it easier to find the > reference identifiers.=20 =C2=A0=20 Not sure what you mean by=C2=A0"hanging style"?=C2=A0=C2=A0Do you mean to i= ndent the references, e.g.,=20 =C2=A0=20 [3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Generation Partnership Project; Technical Specification Grou= p =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Services and System Aspects; enhanced Multi Level Precedence= and =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Preemption service (eMLPP) - Stage 1 (Release 7).=20 =C2=A0 If so, OK. =C2=A0 > 29. Appendix B has alignment issues in the Protocol header length table.= =20 =C2=A0=20 OK, will fix=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Phone=C2=A0 +46 10 7148287 > F=C3=A4r=C3=B6gatan 6=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ----------------------------------------------------------------------=0A= =0A=0A --0-215315087-1256088237=:88576 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Magnus,
 
Thanks for your comments.
 
Here are our responses (with input also from David Black and Al Morton).
 
Please let us know of any further comments or questions.
 
Thanks,
Regards,
Jerry
 
>
> --- On Fri, 10/2/09, Magnus We= sterlund <magnus.westerlund@eri= csson.com>
> wrote:
>
> <= BR>> From: Magnus Westerlund <magnus.westerlund@ericsson.com>
> Sub= ject: [NSIS] AD comments on draft-ietf-nsis-qspec-21
> To: "NSIS" <= ;nsis@ietf.org>, draft-ietf-nsis-qspec= @tools.ietf.org
> Date: Friday, October 2,= 2009, 5:32 AM
>
>
> Hi,
>
> Very sorry fo= r the long delay in getting this review completed.
>
> 1. Sect= ion 1. last paragraph: I don't think "worked example" is easily
> und= erstood. Can you find another word?
 
Will subst= itute "an example" for "a worked example".

> 2. Section 3.1:
> - QSPEC parameter behavior for new QS= PEC parameters the QOSM
>     behavior (tear down= preempted reservation) is not followed (see
>    = ; specification defines
>   - define what happens in case o= f preemption if the default QNI
>     Section 4.3= ..5)
>
> Some editing issues here around the second parenthesi= s in the first
> bullet. It closes in the second bullet.
 
These 2 bullet items should read as follows:
 
"  - QSPEC parameter behavior for new QSPEC parameters the QOSM     specification defines
   - define w= hat happens in case of preemption if the default QNI
   &= nbsp; behavior (tear down preempted reservation) is not followed (see
&n= bsp;    Section 5.3.5)
"

> 3. Section 3.2:
> "QSPEC
>   parameters= are the parameters appearing in a QSPEC, which must
>   in= clude traffic (TMOD),  ..."
>
> I do believe there is a m= issing word between traffic and "(TMOD).
 
Will change "include traffic (TMOD)" to "include the traffic model par= ameter (TMOD)"

> 4. Section 3.2, second paragraph:
>
> "IAN= A
>   assigns a new QSPEC version number when change= s that are not
>   backwards compatible are made to the QSP= EC and this document is
>   reissued. "
>
> an= d
> "Later QSPEC versions MUST be
>   backward compat= ible with earlier QSPEC versions."
>
> The two sentences are c= ontradicting. Please make it clear when new
> version is needed.
 
Will change 
"IANA assigns a new QSPEC version number when changes that are not bac= kwards compatible are made to the QSPEC and this document is reissued."
to
"IANA assigns a new QSPEC version number when the current version= is deprecated or deleted (as required by a specification)."

> 5. Section 3.3.1: The 4 sub-parameters can you please specify= units for
> them?
 

   o rate (r) specified in bytes per secon= d=20

   o bucket size (b) specified in bytes<= /SPAN>=20

   o peak rate (p) specified in bytes per secon= d=20

   o minimum policed unit (m) specified in byte= s=20


> 6. Section 3.3.1: You don't seem to have a definition of what= "minimum
> policed unit" is. I assume that this definition from RFC = 2211 is
> applicable, but still either include it or reference it.
>
>   The minimum policed unit, m, is an integer me= asured in bytes.  All IP
>   datagrams less than size = m will be counted against the token bucket
>   as being of si= ze m."
 
Will include the above definition and also reference RFC 2211.

> 7. Section 3.3.1: What is the definition of peak rate? I unde= rstand that
> the "rate" is a uniform filling rate of the token bucke= t. However, peak
> rate implies that it is not a smoothed value nor h= as its own bucket
> depth parameter. So please provide a definition.<= /DIV>
 
The following definition given in RFC 2212 will be added and refe= renced:
" The peak rate is the maximum rate at which the source and any
&nb= sp;  reshaping points (reshaping points are defined below) may inject<= BR>   bursts of traffic into the network.  More precisely, i= t is a
   requirement that for all time periods the amount of = data sent cannot
   exceed M+pT where M is the maximum datagra= m size and T is the length
   of the time period.  Furthe= rmore, p MUST be greater than or equal to
   the token bucket = rate, r.  If the peak rate is unknown or
   unspecified, = then p MUST be set to infinity."

> 8. Section 3.3.2: " This delay
>   results fr= om the combination of speed-of-light propagation delay,"
>
> Wouldn't it be clearer to say "link" instead = of speed-of-light.
> Especially in cases where the link has retransmi= ssion or other features
> that makes the links propagation delay not = solely be dependent on the
> speed-of-light in the medium used.
 
Agree, will substitute "link" for "speed-of-light".

> 9. Section 3.3.2: "Furthermore, the
>   QNI M= UST add the propagation delay of the ingress link, if this link
>&nbs= p;  exists."
>
> How, is the QNI supposed to know the pro= pagation delay of the ingress
> link? I agree that there are cases wh= ere this can be configured, but
> there appear to be a number of case= s when it would not be the case.
> Therefore I am a bit questioning a= MUST on something that may not be
> possible to perform.
 
Agree, it must be configured.  Will substitute "SHOULD"= for "MUST".

> 10. Section 3.3.2: What is the definition of path error ratio= ?
 
Per the definition in Y.1540 and Y.1541:
"Packet error ratio is the= ratio of total errored IP packet outcomes to the total of successful IP packet transfer outcomes p= lus errored IP packet outcomes in a population of interest, with a resolution of at lea= st 10=E2=80=939.  If lesser resolution is availa= ble in a value, the unused digits shall be set to zero."
Will also add t= hat the number of errored packets observed is directly related to= the confidence in the result. 
 
> 11. This may seem out of context but I do want to know the answer= to how
> the situation is handled when QNI and QNR are neighbors on = a non QoS
> enabled network.
 
What "situation" are you referring to here?  IMO you ca= n't have a QNI and QNR in a "non QoS enabled network".  By definition,= a QNI and QNR are only defined in an NSIS enabled network (i.e., a QoS ena= bled network).

> 12. Section 4.2.1:
> "Note that
>   the= TMOD parameter and all QSPEC parameters with the M flag set MUST
>&n= bsp;  be examined by the RMF, and all QSPEC parameters with the M flag= not
>   set SHOULD be examined by the RMF, and appropriate= ly flagged."
>
> What is meant with appropriately flagged in t= he above sentence?
 
It refers to setting the E flag (which is described in the senten= ce just before the one you quote above in the current qspec document). = ; The above sentence will be further clarified as follows:
"the TMOD parameter and all QSPEC parameters with the M flag set M= UST be examined by the RMF, and all QSPEC parameters with the M flag not se= t SHOULD be examined by the RMF, and the E flag set to indicate whether the parameter cou= ld or could not be satisfied."
 
> 13. Section 5.1.1: Even if version numbers are assigned= by IANA I think
> the spec should be explicit on which version this = one defines. Also as
> being the first version, I think assigning it = yourself would be fully
> appropriate..
 
QSPEC Version 0 is assigned in Section 7 (IANA Considerations), a= s follows:
 
"   QSPEC Version = (4 bits):

   The following value is allocated by this spe= cification:=20

   0: assigned to Version 0 QSPEC"=20

 =20

Will also note this in Section 5.1.1.=20


> 14. Section 5.1.1.: QSPEC Type: I think this should have a po= inter to
> the IANA registry.
 
OK.
 
> 15. Section 5.1.1:
> "   Length: The to= tal length of the QSPEC excluding the common header"
>
> Pleas= e make it clear that you count in 32-bit words (?) and add the "."
> = at the end of the sentence.
 
"Length" is defined at the beginning of Section 5.1 as follows:
"     Value.&nbs= p; If there is no Value, Length=3D0.  The Object l= ength

     excludes the hea= der."

 

The sentence you quote above in Section 5.1.1 will als= o be clarified as follows:

"   Length: T= he total length of the QSPEC (in 32-bit words) excluding the common header"=
 
<= FONT size=3D3 face=3D"">> 16. Section 5.1.2: "Parameter ID: Assigned to = each parameter (see below)"
>
> The text below this does not d= iscuss parameter ID in any useful way.
> Please correct that or provi= de a better reference to where it is discussed.

 =20

Will clarify this senten= ce as follows:=20

"Parameter ID: Assigned = consecutively to each QSPEC parameter (parameter ID's are assigned to = each QSPEC parameter defined in this document in Section 5.2 belo= w and in Section 7/IANA Considerations)"

> 17. Section 5.2.1:
= > "he <TMOD> parameters are represented by three floating point>   numbers in single-precision IEEE floatin= g point format followed by
>   one 32-bit int= eger in network byte order."
>
> Please add a reference for th= e IEEE floating point format.=20

 =20

This is Reference [= IEEE754] now given in Section 11 (Informative References).  Will = give this reference also in the above sentence in Section 5.2.1.

>= ; 18. Section 5.2.1: I don't think the reference in the section title is> particular helping. I definitely prefer explicit references for each<= BR>> item so that you easily can find them. There is also a risk for
= > confusion if multiple references are not agreeing on a parameter
&g= t; definition. For example take the "minimum policed unit". What it is is> defined in RFC 2210, but there is also redundant interpretation text= in
> RFC 2215. I also have a hard time determining if any reference = is missing.=20

 =20

OK, will move the refere= nces into each section, and avoid redundant references.

> 19= . Section 5.2.3: The referenced documents does not define Path
> late= ncy, only minimal path latency. Not obvious that they are the same,
>= for example from a perspective of queuing delay or link ARQ.=20

 =20

The intention of the Pat= h Latency parameter is the same as the Minimal Path Latency parameter defin= ed in Section 3.4 of RFC 2215.  Note that it also says in RFC 2215:=20

 =20

"The purpose of this par= ameter is to provide a baseline minimum path
   latency for us= e with services which provide estimates or bounds on
   additi= onal path delay, such as Guaranteed [RFC 2212]..  Together with
&nb= sp;  the queuing delay bound offered by Guaranteed and similar service= s,
   this parameter gives the application knowledge of both t= he minimum
   and maximum packet delivery delay."=20

 =20

This is also the intent = of the parameter for use in the QSPEC.

> 20. Section 5.2.4: Once = more the references are unclear. Especially as
> RFC 3393 doesn't use= "jitter". You need to be explicit about what is what.=20

 =20

It will be clarified tha= t "jitter" is called "IP Delay Variation" in RFC 3393.  This is actual= ly already stated in Section 3.3.2, but will be reiterated in Section 5.2.4= .=20


> 21. Section 5.2= .5: First of all I am not convinced by looking in Y.1541
> that packet loss ratio has a clear definition. I am = missing what type of
> averaging is assumed in the value. If you goin= g to measure this value
> you need to do it over sufficiently many pa= ckets, measuring over 7
> packets with one loss doesn't say much.=20

 =20

An evaluation interval o= f 1 minute is suggested in Y.1541.  This will be noted in Section 5.2.= 5.  Will also add that the number of losses observed is directly = related to the confidence in the result.

> 22. Section 5.2.5: " A= n
>   individual QNE can advertise a PLR value between zero= and 10^-2
>   and the total PLR added across all QNEs can = range as high as 10^-1."
>
> Isn't the restriction to advertis= e a link PLR no higher than 10^-2 a to
> strict limit. Doesn't there = exist links out there that has that level of
> loss. Maybe not ones t= hat you usually request QoS over, but anyway.=20

 =20

The maximum limit of 10^= -2 on a QNE's local PLR value and the maximum limit (clamp value)= of 10^-1 on accumulated end-to-end PLR value are used to preserve the= accuracy of the simple additive accumulation function specified in the QSP= EC.  It's important to avoid more complex accumulation functions = and stay with the simple additive accumulation function (Y.1541 mentions th= e different methods in section 8.2.2 and 8.2.3).  Furthermore, if thes= e maximums are exceeded, then (as you say) the path wou= ld not have much quality and would likely not meet the QoS o= bjectives anyway.  Finally the word "add" should replace the word "adv= ertise" and the quoted sentence further clarified as follows:

"An individual QNE adds = its local PLR value (up to a maximum of 10^-2) to the total path PLR v= alue (up to a maximum of 10^-1) , where the acceptability of the total= path PLR value added across all QNEs is determined based on the QOSM being= used." =20


> 23. Section 5.2= .11:
> "When the shaping causes
>   unbounded queue g= rowth at the shaper traffic can be dropped."
>
> To me the sha= ping seems unclear, as it contains a unknown factor of the
> queue us= ed. Both queue depth and dropping model would influence how the
> sha= ping happens.=20

 =20

Actually, the bucket siz= e in the TMOD parameter for excess traffic specifies the queuing behavior t= hat is of concern.  The traffic in question here is not only out-of-pr= ofile wrt the primary traffic spec, but it's but it's *also* out of profile= wrt to a secondary traffic spec for excess traffic.  However, we = ;see no problem with saying that any traffic that is excess of the TMOD for= excess traffic MAY be dropped (or even SHOULD be dropped), and will rephra= se the sentence in question as such.=20

 =20

> 24. Section 5.2.11:=
> Remark Value (6 bits): indicates either drop (set to 0) or DSCP>           &nbs= p;            &= nbsp; value [RFC2474] to remark packets to when
>   &n= bsp;            = ;          identified as exces= s
>
> So you can't remark traffic into the best-effort traffic= class? Isn't
> that a severe limitation? And why are there need for = two ways of marking
> drop as excess treatments?=20

 =20

Correct.  The = usual DSCP for best-effort is zero, but the meaning of that value has = been changed to drop in the quoted text.  That makes it impossible to = remark to a DSCP of zero, which is usually the best-effort traffic class.&n= bsp; However, since "drop" is already encoded in the Excess Treatment value= , as you point out, we will remove the ability to encode "drop" h= ere, specifically, remove the words "either drop (set to 0) or" .

&g= t; 25. Section 5.2.12:
>
>   0   &nbs= p;            &= nbsp;  1          &n= bsp;        2    &nb= sp;            =   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |M|E|N|r| &n= bsp;         12   &n= bsp;      |r|r|r|r|     &= nbsp;    1        &n= bsp;   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | DSCP   &= nbsp;  |0 0 0 0 0 0 0 0 0 0|       =      (Reserved)      &nbs= p;  |
>   +---+---+---+---+---+---+---+---+---+---+---= +---+---+---+---+---+
>
> Two comments about the field definit= ion for the third 16-bit word.
>
> First, why is one of the po= ssible field value represented rather than
> giving the field a name. That way one can make it clear that the
> possibility for di= fferent structures in that 16-bit word. I would
> probably have defie= nd it as:
>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> | PH Fie= ld Value            = |EN |
>
> I do understand that would be different from how RFC= 3140 is
> representing the information, but be equivalent. As an alt= ernative I
> would simple change the first diagram to say instead of = DSCP   | 0 0 ...
> to say PHB Field. Anyway, I think the cu= rrent representation is unclear.=20

 =20

What you suggest is= consistent with RFC 3140 and a reasonable way to do this.  We wi= ll substitute the 16 bits you suggest for the DSCP + 10 bits of z= eroes, and explain that the result matches RFC 3140 and that the following = four figures show 4 possible formats based on the value of the EN field. 
> 26. Section 7. There are registries that requires standard = action for
> new registrations. I think that is not consistent with p= ublishing this
> as experimental. Please address.=20

 =20

First, the QSPEC is an *= Informational* document, not experimental.  In any case, we will chang= e "Standards Action" to "Specification Required" in each case.=20


> 27. Section 7..= QSPEC Procedures. This table is so confusing, I can't get
> my head = around what code point space is registered. And if there are a
> seco= nd dimension for certain values and in that case which that is.=20

 =20

The QSPEC Procedure= s object being registered by IANA specifications in Sec= tion 7 is specified in Section 5.1.1 (Common Header Format).  The=  code point space consists of a Message Sequence sub-parameter an= d an Object Combination sub-parameter.  Section 4.3 explains the Messa= ge Sequence and Object Combination sub-parameters.  Object Combination= s 0, 1, and 2 are explained in Section 4.3.1, 4.3.2, and 4.3.3, respectivel= y.  Tables 1, 2, and 3 in Section 4.3 assign the Message Sequence ID t= o Object Combinations 0, 1, and, 2, respectively.  There is an er= ror to be corrected in the IANA specifications: Object Combination 2 (Secti= on 4.3.3) has only one Message Sequence ID, not 3 (this will be corrected.&= nbsp; Hopefully this explains whatever confusion there is here.= =20

 
> 28. Refer= ences: Can you please ensure that there is a blank line between
> eac= h reference. Now it is very difficult to read the list.=20

 =20

OK=20

 =20

> Also, making
>= ; the reference using a hanging style makes it easier to find the
> r= eference identifiers.=20

 =20

Not sure what you mean b= y "hanging style"?  Do you mean to indent the references, e.= g.,=20

 =20

[3GPP-1] 3GPP TS 22.067 V7.0.0 (200= 6-03) Technical Specification, 3rd
      &= nbsp;        Generation Partnership= Project; Technical Specification Group
     &n= bsp;         Services and S= ystem Aspects; enhanced Multi Level Precedence and
   &nb= sp;           Pre= emption service (eMLPP) - Stage 1 (Release 7).

 
If so, OK.
 
> 29. Appendix B has alignment issue= s in the Protocol header length table.

 =20

OK, will fix=20


>
> Cheers=
>
> Magnus Westerlund
>
> IETF Transport Area Di= rector
> ------------------------------------------------------------= ----------
> Multimedia Technologies, Ericsson Research EAB/TVM
&g= t; ----------------------------------------------------------------------> Ericsson AB         &nb= sp;      | Phone  +46 10 7148287
> F=C3= =A4r=C3=B6gatan 6         &nbs= p;      | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailt= o: mag= nus.westerlund@ericsson.com
&g= t; ----------------------------------------------------------------------


=0A=0A=0A=0A --0-215315087-1256088237=:88576-- From magnus.westerlund@ericsson.com Fri Oct 23 02:26:46 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 C2A203A6A04 for ; Fri, 23 Oct 2009 02:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 imaHJao+VwR0 for ; Fri, 23 Oct 2009 02:26:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 07FA83A67EB for ; Fri, 23 Oct 2009 02:26:44 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-17-4ae176dd8f5f Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 4F.80.04191.DD671EA4; Fri, 23 Oct 2009 11:26:54 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 11:26:53 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 11:26:52 +0200 Message-ID: <4AE176DD.2020007@ericsson.com> Date: Fri, 23 Oct 2009 11:26:53 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gerald Ash References: <967329.88200.qm@web63607.mail.re1.yahoo.com> In-Reply-To: <967329.88200.qm@web63607.mail.re1.yahoo.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Oct 2009 09:26:52.0619 (UTC) FILETIME=[F49D49B0:01CA53C2] X-Brightmail-Tracker: AAAAAA== Cc: David Black , draft-ietf-nsis-qspec@tools.ietf.org, NSIS Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21 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, 23 Oct 2009 09:26:46 -0000 Hi Jerry, I suggest changes looks fine unless commented. I have removed everything where your response resolves the issues. Looking forward to a new version. Gerald Ash skrev: >> --- On Fri, 10/2/09, Magnus Westerlund >> wrote: >> 10. Section 3.3.2: What is the definition of path error ratio? > > Per the definition in Y.1540 and Y.1541: > "Packet error ratio is the ratio of total errored IP packet outcomes to > the total of successful IP packet transfer outcomes plus errored IP > packet outcomes in a population of interest, with a resolution of at > least 10–9. If lesser resolution is available in a value, the unused > digits shall be set to zero." > Will also add that the number of errored packets observed is directly > related to the confidence in the result. Thanks, please add a reference to the definition. > >> 11. This may seem out of context but I do want to know the answer to how >> the situation is handled when QNI and QNR are neighbors on a non QoS >> enabled network. > > What "situation" are you referring to here? IMO you can't have a QNI > and QNR in a "non QoS enabled network". By definition, a QNI and QNR > are only defined in an NSIS enabled network (i.e., a QoS enabled network). I am asking what is happening in these cases where a QNI has the QNR as peer and there are no network support. Clearly you will not get any QoS, but is it clear to both QNI and QNR that this is the situation? > >> 15. Section 5.1.1: >> " Length: The total length of the QSPEC excluding the common header" >> >> Please make it clear that you count in 32-bit words (?) and add the "." >> at the end of the sentence. > > "Length" is defined at the beginning of Section 5.1 as follows: > " o Length has the units of 32-bit words, and measures the length of > > Value. If there is no Value, Length=0. The Object length > > excludes the header." > > > > The sentence you quote above in Section 5.1.1 will also be clarified as > follows: > > " Length: The total length of the QSPEC (in 32-bit words) excluding > the common header" > good, because it is not obvious that the text in 5.1 applies to the common header as it isn't a TLV structure. > >> 19. Section 5.2.3: The referenced documents does not define Path >> latency, only minimal path latency. Not obvious that they are the same, >> for example from a perspective of queuing delay or link ARQ. > > > > The intention of the Path Latency parameter is the same as the Minimal > Path Latency parameter defined in Section 3.4 of RFC 2215. Note that it > also says in RFC 2215: > > > > "The purpose of this parameter is to provide a baseline minimum path > latency for use with services which provide estimates or bounds on > additional path delay, such as Guaranteed [RFC 2212].. Together with > the queuing delay bound offered by Guaranteed and similar services, > this parameter gives the application knowledge of both the minimum > and maximum packet delivery delay." > > > > This is also the intent of the parameter for use in the QSPEC. > Yes, but nit-picking here I do think you could make it clear that the QSPEC parameter is defined as "minimal path latency in RFC 2215". > >> 27. Section 7.. QSPEC Procedures. This table is so confusing, I can't get >> my head around what code point space is registered. And if there are a >> second dimension for certain values and in that case which that is. > > > > The QSPEC Procedures object being registered by IANA specifications in > Section 7 is specified in Section 5.1.1 (Common Header Format). > The code point space consists of a Message Sequence sub-parameter and an > Object Combination sub-parameter. Section 4.3 explains the Message > Sequence and Object Combination sub-parameters. Object Combinations 0, > 1, and 2 are explained in Section 4.3.1, 4.3.2, and 4.3.3, > respectively. Tables 1, 2, and 3 in Section 4.3 assign the Message > Sequence ID to Object Combinations 0, 1, and, 2, respectively. There is > an error to be corrected in the IANA specifications: Object Combination > 2 (Section 4.3.3) has only one Message Sequence ID, not 3 (this will be > corrected. Hopefully this explains whatever confusion there is here. > I think one of the bigger issues is that it is compact without any line spacing or indentation to make the structure clear. > >> 28. References: Can you please ensure that there is a blank line between >> each reference. Now it is very difficult to read the list. > > > > OK > > > >> Also, making >> the reference using a hanging style makes it easier to find the >> reference identifiers. > > > > Not sure what you mean by "hanging style"? Do you mean to indent the > references, e.g., > > > > [3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd > Generation Partnership Project; Technical Specification Group > Services and System Aspects; enhanced Multi Level > Precedence and > Preemption service (eMLPP) - Stage 1 (Release 7). > > > If so, OK. Yes, that is what I mean. 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 karagian@cs.utwente.nl Sat Oct 24 00:33: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 8927A3A68A5 for ; Sat, 24 Oct 2009 00:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.005 X-Spam-Level: * X-Spam-Status: No, score=1.005 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396, 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 3CLYtWZqHxPT for ; Sat, 24 Oct 2009 00:33:54 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 985103A67AA for ; Sat, 24 Oct 2009 00:33:54 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id n9O7XuwB008954; Sat, 24 Oct 2009 09:33:57 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 24 Oct 2009 07:33:56 +0000 To: "Magnus Westerlund" , "Gerald Ash" Date: Sat, 24 Oct 2009 07:33:55 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <4AE176DD.2020007@ericsson.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 Cc: NSIS , David Black , "draft-ietf-nsis-qspec@tools.ietf.org" Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21 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, 24 Oct 2009 07:33:55 -0000 Hi Magnus Regarding comment 11: >>> 11. This may seem out of context but I do want to know the answer to how >>> the situation is handled when QNI and QNR are neighbors on a non QoS >>> enabled network. >> =20 >> What "situation" are you referring to here? IMO you can't have a QNI >> and QNR in a "non QoS enabled network". By definition, a QNI and QNR >> are only defined in an NSIS enabled network (i.e., a QoS enabled network). > >I am asking what is happening in these cases where a QNI has the QNR as >peer and there are no network support. Clearly you will not get any QoS, >but is it clear to both QNI and QNR that this is the situation? > I think that the solution for this situation is provided by QoS-NSLP. In particular, this situation is detected by uing the generic flag BREAK (B), see Section 5.1.1 Common header, in the QoS-NSLP draft, see below: BREAK (B) - when set, indicates that there are routers along the path where QoS cannot be provided. Maybe it will be good to add a sentence in the QSPEC draft that emphasizes." "As specified in QoS-NSLP, when there are routers along the path between QNI and QNR where QoS cannot be provided then the QoS-NSLP generic flag BREAK (B) is set." Best regards, Georgios From gash5107@yahoo.com Mon Oct 26 10:47:58 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 4AE3428C11E for ; Mon, 26 Oct 2009 10:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.703 X-Spam-Level: X-Spam-Status: No, score=-99.703 tagged_above=-999 required=5 tests=[AWL=2.334, 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 W9tUcuyWfiaP for ; Mon, 26 Oct 2009 10:47:57 -0700 (PDT) Received: from web63606.mail.re1.yahoo.com (web63606.mail.re1.yahoo.com [69.147.97.76]) by core3.amsl.com (Postfix) with SMTP id CF9AD28C33C for ; Mon, 26 Oct 2009 10:47:55 -0700 (PDT) Received: (qmail 56864 invoked by uid 60001); 26 Oct 2009 17:48:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1256579285; bh=PAFFcqSJ7FkvPf/DHVpLn+e8S7T7wuX4ghx7W78kfC8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PKyESZ7e0mkwSL4dT3WCarJ7FH1BUSicjuvD+UOUqoMS24vcyFgSkhWbGY4YOwhFiStfoYNr/D7iLlPI3AyYxd3Ekdi3AcsiBjhHzuRgMTaqHwXItPXXnI+cdBMUbeIUCgeJROJ+WFFnwArFhtPAg3UzjdNrIkxUByf1stwVBOA= 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=cwYtPooHCyKABfYKlOyW6TsWM6v/5SGcd7Rk+5PUmMzeZraj5l78K1Vm6nmN/2KbqKpkHwz/3dAecEFQ1NEu2OLEXEx4uvw17srVBE2epDvdicxjRpZKqiKWMGcEnRWU2MKwqgFF330mpV86bSlJgKTbErzlshnrcTkW/a0WOsM=; Message-ID: <823546.56279.qm@web63606.mail.re1.yahoo.com> X-YMail-OSG: wXCu0DYVM1m.lO117251aaVyJ8inSxjPb8OqKQw.XdeV28bU7fELmvdQHGVA8tDn29ykPUvK2PQVc_Pr4ohdTj1B14LRRn08oNOMOysFg.d49AvPP5YZe3qT8FTpZQeSl07SQtXm48jJgNm7dw6kBBD6xlMpVBxXKZ.Mj9SxOFxm6oMmfbZW3qEm9VMWtWc9.eRezk2MQxW1xmiqK8kjagrnG39eHshPt_VwZSsp9n2uAKFJP59FOs1WLKpDZCU98r5VSyZN6QscJtoKtnK_l6IEjWN1WZL.M1MMPLjo_wGqK7GFDA0R4UZhHqmIrh1u7ISHG0ZotD_vVp6_OEnk2Lv0pRc6lqZp Received: from [24.91.148.40] by web63606.mail.re1.yahoo.com via HTTP; Mon, 26 Oct 2009 10:48:05 PDT X-Mailer: YahooMailClassic/7.0.14 YahooMailWebService/0.7.347.3 Date: Mon, 26 Oct 2009 10:48:05 -0700 (PDT) From: Gerald Ash To: Magnus Westerlund , Georgios Karagiannis In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1005407972-1256579285=:56279" Cc: NSIS , "draft-ietf-nsis-qspec@tools.ietf.org" , David Black Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21 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, 26 Oct 2009 17:47:58 -0000 --0-1005407972-1256579285=:56279 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Georgios, =A0 I agree with your suggestion, thank you for that. =A0 Magnus, does=A0Georgios' suggestion=A0take care of your comment #11? =A0 Thanks, Regards, Jerry --- On Sat, 10/24/09, Georgios Karagiannis wrote: From: Georgios Karagiannis Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21 To: "Magnus Westerlund" , "Gerald Ash" Cc: "David Black" , "draft-ietf-nsis-qspec@tools.ietf.= org" , "NSIS" Date: Saturday, October 24, 2009, 3:33 AM Hi Magnus Regarding comment 11: >>> 11. This may seem out of context but I do want to know the answer to ho= w >>> the situation is handled when QNI and QNR are neighbors on a non QoS >>> enabled network. >>=A0=20 >> What "situation" are you referring to here?=A0 IMO you can't have a QNI >> and QNR in a "non QoS enabled network".=A0 By definition, a QNI and QNR >> are only defined in an NSIS enabled network (i.e., a QoS enabled network= ). > >I am asking what is happening in these cases where a QNI has the QNR as >peer and there are no network support. Clearly you will not get any QoS, >but is it clear to both QNI and QNR that this is the situation? > I think that the solution for this situation is provided by QoS-NSLP. In particular, this situation is detected by uing the generic flag BREAK (B), see Section 5.1.1 Common header, in the QoS-NSLP draft, see below: BREAK (B) - when set, indicates that there are routers along the path where QoS cannot be provided. Maybe it will be good to add a sentence in the QSPEC draft that emphasizes." "As specified in QoS-NSLP, when there are routers along the path between QNI and QNR where QoS cannot be provided then the QoS-NSLP generic flag BREAK (B) is set." Best regards, Georgios =0A=0A=0A --0-1005407972-1256579285=:56279 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Georgios,
 
I agree with your suggestion, thank you for that.
 
Magnus, does Georgios' suggestion take care of your comment = #11?
 
Thanks,
Regards,
Jerry

--- On Sat, 10/24/09, Georgios Karagiannis <kara= gian@cs.utwente.nl> wrote:

From: Georgios Karagiannis <karagian@cs.utwent= e.nl>
Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21
= To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>, "Gerald Ash= " <gash5107@yahoo.com>
Cc: "David Black" <black_david@emc.com&g= t;, "draft-ietf-nsis-qspec@tools.ietf.org" <draft-ietf-nsis-qspec@tools.= ietf.org>, "NSIS" <nsis@ietf.org>
Date: Saturday, October 24, 2= 009, 3:33 AM

Hi Magnus

Regarding comment 11:
>>&g= t; 11. This may seem out of context but I do want to know the answer to how=
>>> the situation is handled when QNI and QNR are neighbors on= a non QoS
>>> enabled network.
>> 
>> = What "situation" are you referring to here?  IMO you can't have a QNI<= BR>>> and QNR in a "non QoS enabled network".  By definition, a = QNI and QNR
>> are only defined in an NSIS enabled network (i.e., = a QoS enabled network).
>
>I am asking what is happening in the= se cases where a QNI has the QNR as
>peer and there are no network su= pport. Clearly you will not get any QoS,
>but is it clear to both QNI= and QNR that this is the situation?
>

I think that the soluti= on for this situation is provided by QoS-NSLP. In
particular, this situa= tion is detected by uing the generic flag BREAK
(B), see Section 5.1.1 Common header, in the QoS-NSLP draft, see below:

BREAK (B) - = when set, indicates that there are routers along the path
where QoS cann= ot be provided.

Maybe it will be good to add a sentence in the QSPEC= draft that
emphasizes."

"As specified in QoS-NSLP, when there ar= e routers along the path between
QNI and QNR where QoS cannot be provide= d then the QoS-NSLP generic flag
BREAK (B) is set."

Best regards,=
Georgios

=0A=0A --0-1005407972-1256579285=:56279-- From jukka.manner@tkk.fi Mon Oct 26 14:27: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 2A95828C329 for ; Mon, 26 Oct 2009 14:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 n4yQIXXcUIEo for ; Mon, 26 Oct 2009 14:27:58 -0700 (PDT) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by core3.amsl.com (Postfix) with ESMTP id 300EA28C30D for ; Mon, 26 Oct 2009 14:27:58 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id n9QLSAS2023381 for ; Mon, 26 Oct 2009 23:28:10 +0200 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 11156-267 for ; Mon, 26 Oct 2009 23:28:09 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id n9QLS0ia023299 for ; Mon, 26 Oct 2009 23:28:00 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id EF5271E148 for ; Mon, 26 Oct 2009 23:27:59 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dejzRYLrqn6r for ; Mon, 26 Oct 2009 23:27:55 +0200 (EET) Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 754711E140 for ; Mon, 26 Oct 2009 23:27:55 +0200 (EET) Received: from [192.168.0.156] (a91-154-4-72.elisa-laajakaista.fi [91.154.4.72]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id 230D0120050 for ; Mon, 26 Oct 2009 23:27:55 +0200 (EET) Message-ID: <4AE6145B.5070603@tkk.fi> Date: Mon, 26 Oct 2009 23:27:55 +0200 From: Jukka MJ Manner User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NSIS Content-Type: multipart/mixed; boundary="------------050000010606020503000006" X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [NSIS] WG status 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, 26 Oct 2009 21:27:59 -0000 This is a multi-part message in MIME format. --------------050000010606020503000006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, here is a short update on the WG status. GIST: - In RFC Editor queue, waiting for the Extensibility/User Guide draft NSIS ext: - WGLC passed, waiting for Chair's Write-up (Martin) - Then to Magnus for AD review QoS NSLP: - New Rev submitted, then IETF Last Call QSPEC: - New Rev coming up, then IETF Last Call NAT-FW NSLP: - Waiting for AD Review - Has an IPR claim from Nortel Y.1541: - New Rev coming, then IETF Last Call State machine: - In AD review RMD QOSM: - In AD review Mobility applicability: - Missing input from Martin, then to AD review Tunnels: - Would need more discussion, then a decision on how to proceed SCTP: - Would need more discussion, then a decision on how to proceed Authorization (individual): - AD review highlighted again that we would need work on authorization - We have the individual submission, that could be finalized and submitted, if approved by the WG. Regards, Jukka --------------050000010606020503000006 Content-Type: text/x-vcard; charset=utf-8; name="jukka_manner.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jukka_manner.vcf" begin:vcard fn:Jukka Manner n:Manner;Jukka org:Helsinki University of Technology;Department of Communications and Networking (Comnet) adr:(Otakaari 5 A);;P.O.Box 3000;TKK;;02015;Finland email;internet:jukka.manner@tkk.fi title:Professor tel;work:+358-9-4512481 tel;fax:+358-9-4512474 tel;cell:+358-50-5112973 x-mozilla-html:FALSE url:http://comnet.tkk.fi version:2.1 end:vcard --------------050000010606020503000006-- From root@core3.amsl.com Mon Oct 26 14:30:02 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 69AA228C181; Mon, 26 Oct 2009 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026213002.69AA228C181@core3.amsl.com> Date: Mon, 26 Oct 2009 14:30:02 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-qos-nslp-17.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, 26 Oct 2009 21:30:02 -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 : NSLP for Quality-of-Service Signaling Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-qos-nslp-17.txt Pages : 97 Date : 2009-10-26 This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-17.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-qos-nslp-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26142756.I-D@ietf.org> --NextPart-- From magnus.westerlund@ericsson.com Thu Oct 29 09:49:26 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 6951B3A67E7 for ; Thu, 29 Oct 2009 09:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=-0.099, 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 wwWlMYA-szG4 for ; Thu, 29 Oct 2009 09:49:25 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2A7D83A67A3 for ; Thu, 29 Oct 2009 09:49:24 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-74-4ae9c7a38335 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 30.BB.31706.3A7C9EA4; Thu, 29 Oct 2009 17:49:40 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 17:49:39 +0100 Received: from [147.214.183.163] ([147.214.183.163]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 17:49:39 +0100 Message-ID: <4AE9C7A3.7050805@ericsson.com> Date: Thu, 29 Oct 2009 17:49:39 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gerald Ash References: <823546.56279.qm@web63606.mail.re1.yahoo.com> In-Reply-To: <823546.56279.qm@web63606.mail.re1.yahoo.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Oct 2009 16:49:39.0541 (UTC) FILETIME=[CE366050:01CA58B7] X-Brightmail-Tracker: AAAAAA== Cc: NSIS , Georgios Karagiannis , "draft-ietf-nsis-qspec@tools.ietf.org" , David Black Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21 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: Thu, 29 Oct 2009 16:49:26 -0000 Hi, Yes, I was more interested in the answer than necessary addition to the documents. However, the text proposal is good. Sorry for not being able to respond before the cut-off. /Magnus Gerald Ash skrev: > Hi Georgios, > > I agree with your suggestion, thank you for that. > > Magnus, does Georgios' suggestion take care of your comment #11? > > Thanks, > Regards, > Jerry > > --- On *Sat, 10/24/09, Georgios Karagiannis //* > wrote: > > > From: Georgios Karagiannis > Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21 > To: "Magnus Westerlund" , "Gerald > Ash" > Cc: "David Black" , > "draft-ietf-nsis-qspec@tools.ietf.org" > , "NSIS" > Date: Saturday, October 24, 2009, 3:33 AM > > Hi Magnus > > Regarding comment 11: > >>> 11. This may seem out of context but I do want to know the > answer to how > >>> the situation is handled when QNI and QNR are neighbors on a non QoS > >>> enabled network. > >> > >> What "situation" are you referring to here? IMO you can't have a QNI > >> and QNR in a "non QoS enabled network". By definition, a QNI and QNR > >> are only defined in an NSIS enabled network (i.e., a QoS enabled > network). > > > >I am asking what is happening in these cases where a QNI has the QNR as > >peer and there are no network support. Clearly you will not get any > QoS, > >but is it clear to both QNI and QNR that this is the situation? > > > > I think that the solution for this situation is provided by QoS-NSLP. In > particular, this situation is detected by uing the generic flag BREAK > (B), see Section 5.1.1 Common header, in the QoS-NSLP draft, see below: > > BREAK (B) - when set, indicates that there are routers along the path > where QoS cannot be provided. > > Maybe it will be good to add a sentence in the QSPEC draft that > emphasizes." > > "As specified in QoS-NSLP, when there are routers along the path between > QNI and QNR where QoS cannot be provided then the QoS-NSLP generic flag > BREAK (B) is set." > > Best regards, > Georgios > > -- 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 ----------------------------------------------------------------------