From nsis-bounces@ietf.org Sat Jul 01 01:26:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwXzb-0000e6-Lt; Sat, 01 Jul 2006 01:26:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwXzZ-0000dx-MA for nsis@ietf.org; Sat, 01 Jul 2006 01:26:05 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwXzW-0007rZ-5Y for nsis@ietf.org; Sat, 01 Jul 2006 01:26:05 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k615PuZQ008875; Sat, 1 Jul 2006 08:25:56 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Jul 2006 08:25:09 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Jul 2006 08:25:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Legacy NAT traversal for NSIS Date: Sat, 1 Jul 2006 08:25:09 +0300 Message-ID: In-Reply-To: <1151685127.26969.230.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Legacy NAT traversal for NSIS Thread-Index: AcacY0rOlU2dcW/vSJizx/DRBnepBAAazRQQ From: To: , X-OriginalArrivalTime: 01 Jul 2006 05:25:09.0375 (UTC) FILETIME=[B82C60F0:01C69CCE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Saikat, You're observations are right - if we want, we can run GIST over any 'standard' NAT traveral mechanisms (TERADO, STUN, TURN).=20 I think working through this would be a useful exercise. John >On Mon, 2006-06-19 at 15:22 +0200, Pashalidis, Andreas wrote: >> Is anyone interested to make NSIS work through legacy NATs ?? (i.e. >> NSIS-unaware NATs) >>=20 >> Under the following link a preliminary document (in I-D format) can be=20 >> found that describes a solution approach. >>=20 >http://www.tschofenig.priv.at/TEMP/draft-pashalidis-nsis-gist-legac >ynats-00. >> txt >>=20 >> In an exremely small nutshell: the idea is to tunnel both signalling=20 >> and data traffic over a single UDP NAT binding. > >I haven't gone through the document throughly, but the=20 >underlying transport you propose reminds me of TEREDO (which=20 >is over IPv6 over UDP over IPv4, where the UDP=20 >over IPv4 is punched through legacy NATs with the help of=20 >STUN/TURN/ICE etc.) One could potentially run GIST over TEREDO=20 >and keep the signaling and data channel separate in >IPv6 land even though they use the same NAT binding in IPv4 land. > >Alternatively, TURN (public-data-relay protocol for traversing=20 >the worst of NATs) now has some lightweight framing=20 >capability; the framing in TURN could potentially be extended=20 >to carry any in-band signals including GIST.=20 > >-- >Saikat > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 01 15:31:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwlBr-00048c-Ow; Sat, 01 Jul 2006 15:31:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwlBq-00048X-Eu for nsis@ietf.org; Sat, 01 Jul 2006 15:31:38 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwlBo-0007Cr-1M for nsis@ietf.org; Sat, 01 Jul 2006 15:31:38 -0400 Received: (qmail invoked by alias); 01 Jul 2006 19:31:34 -0000 Received: from p549851A0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.160] by mail.gmx.net (mp020) with SMTP; 01 Jul 2006 21:31:34 +0200 X-Authenticated: #29516787 Message-ID: <44A6CD93.90803@gmx.net> Date: Sat, 01 Jul 2006 21:31:31 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] Legacy NAT traversal for NSIS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Andreas.Pashalidis@siemens.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, Hi Saikat, thanks for the feedback. I definitely think that we should explore the usage of these protocols in context with GIST for legacy NAT traversal. Ciao Hannes john.loughney@nokia.com wrote: > Hi Saikat, > > You're observations are right - if we want, we can run GIST over > any 'standard' NAT traveral mechanisms (TERADO, STUN, TURN). > > I think working through this would be a useful exercise. > > John > > >>On Mon, 2006-06-19 at 15:22 +0200, Pashalidis, Andreas wrote: >> >>>Is anyone interested to make NSIS work through legacy NATs ?? (i.e. >>>NSIS-unaware NATs) >>> >>>Under the following link a preliminary document (in I-D format) can > > be > >>>found that describes a solution approach. >>> >> >>http://www.tschofenig.priv.at/TEMP/draft-pashalidis-nsis-gist-legac >>ynats-00. >> >>>txt >>> >>>In an exremely small nutshell: the idea is to tunnel both signalling >>>and data traffic over a single UDP NAT binding. >> >>I haven't gone through the document throughly, but the >>underlying transport you propose reminds me of TEREDO (which >>is over IPv6 over UDP over IPv4, where the UDP >>over IPv4 is punched through legacy NATs with the help of >>STUN/TURN/ICE etc.) One could potentially run GIST over TEREDO >>and keep the signaling and data channel separate in >>IPv6 land even though they use the same NAT binding in IPv4 land. >> >>Alternatively, TURN (public-data-relay protocol for traversing >>the worst of NATs) now has some lightweight framing >>capability; the framing in TURN could potentially be extended >>to carry any in-band signals including GIST. >> >>-- >>Saikat >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 01 16:23:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwlzX-0006EM-K4; Sat, 01 Jul 2006 16:22:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwlzW-00065K-6r for nsis@ietf.org; Sat, 01 Jul 2006 16:22:58 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwlzU-0002Dx-PO for nsis@ietf.org; Sat, 01 Jul 2006 16:22:58 -0400 Received: (qmail invoked by alias); 01 Jul 2006 20:22:55 -0000 Received: from p549851A0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.160] by mail.gmx.net (mp020) with SMTP; 01 Jul 2006 22:22:55 +0200 X-Authenticated: #29516787 Message-ID: <44A6D99C.4030902@gmx.net> Date: Sat, 01 Jul 2006 22:22:52 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <05F34B6959F19F43BBD78FFCD4C15D055DFE57@esealmw116.eemea.ericsson.se> <44A51CDB.7040503@gmx.net> In-Reply-To: <44A51CDB.7040503@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis@ietf.org, =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I should have read the latest QSPEC draft version before I sent this mail. The most recent draft talks about this aspect and it says in Section 4.7: " A QOSM specification MUST define how the mandatory parameters are to be mapped onto the QSPEC parameters used by the QOSM, however the mapping MAY result in slight modification to the intended specification when an exact mapping is not possible. " Attila, you did this for the token bucket parameter and described that it can be mapped to the bandwith parameter. Now, the only question remains whether a QOSM also have to define a mapping for all mandatory parameters. This would address the case mentioned below: The QOSM does not make use of all mandatory parameters listed in the QSPEC. Ciao Hannes Hannes Tschofenig wrote: > Hi Attila, > > Attila Báder (IJ/ETH) wrote: > >> Hi Bernd, This is the case in RMD as well. In RMD domain resource >> reservation is based on one parameter: Bandwidth. If, for example, >> the resource request arriving to the Edge is a token bucket, it >> should be translated to a single Bandwidth parameter. This may be a >> peak value, or an effective value. > > > I guess Bernd's question was focusing on a different aspect. What > happens if you receive a request that contains the parameter 'Y.1541 QoS > Class with the value set for Class 0? > > Ciao > Hannes > > >> >> Best regards, Attila >> >> >>> -----Original Message----- From: Bernd Schloer >>> [mailto:bschloer@cs.uni-goettingen.de] Sent: Thursday, June 29, >>> 2006 3:01 PM To: nsis@ietf.org Subject: [NSIS] >>> draft-qosmodel-controlledload-04 >>> >>> >>> Hi, >>> >>> the first open issue in the appendix B is about what to do with >>> mandatory QSPEC parameters which are not needed for CLS. >>> >>> Does a QOSM have to understand (and provide information about) all >>> mandatory parameters, even if they are not used? The QSPEC-draft >>> says in section 5 that all parameters listed in the next sections >>> are mandatory. The QSPEC-draft also says in section 4.1 that "a >>> given QOSM defines which of the mandatory and optional parameters >>> it uses, ..." >>> >>> Are there any specific parameters which makes the open issue B.1.1. >>> clearer? Following the QSPEC-draft there doesn't seem to be a >>> conflict, if nothing is done with the unneeded parameters. >>> >>> Thanks, Bernd >>> >>> >>> >>> _______________________________________________ nsis mailing list >>> nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis >>> >> >> >> _______________________________________________ nsis mailing list >> nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis >> >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 01 16:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwm2k-0000zI-RG; Sat, 01 Jul 2006 16:26:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwm2j-0000zD-H7 for nsis@ietf.org; Sat, 01 Jul 2006 16:26:17 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fwm2i-0002I0-QI for nsis@ietf.org; Sat, 01 Jul 2006 16:26:17 -0400 Received: (qmail invoked by alias); 01 Jul 2006 20:26:15 -0000 Received: from p549851A0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.160] by mail.gmx.net (mp018) with SMTP; 01 Jul 2006 22:26:15 +0200 X-Authenticated: #29516787 Message-ID: <44A6DA63.8090702@gmx.net> Date: Sat, 01 Jul 2006 22:26:11 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <9473683187ADC049A855ED2DA739ABCA0DDC7A53@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7A53@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, it is true that I haven't read the most recent QSPEC draft when I sent this mail. In the meanwhile I did. Please find a few comments below: Ash, Gerald R (Jerry), ALABS wrote: > Hi Hannes, > > See below. > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Friday, June 30, 2006 8:43 AM >>To: Bernd Schloer >>Cc: nsis@ietf.org >>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >> >>Hi Bernd, >> >>Bernd Schloer wrote: >> >>>Hi, >>> >>>the first open issue in the appendix B is about what to do with >>>mandatory QSPEC parameters which are not needed for CLS. >>> >>>Does a QOSM have to understand (and provide information about) all >>>mandatory parameters, even if they are not used? >> >>I think the question is wrong. What about the following question: >>" >>Does a node that implements a particular QOSM has to understand all >>mandatory parameters listed in the QSPEC template draft (even if the >>QOSM does not make use of them)? >>" >>The answer would be "YES" since the QSPEC template draft says that >>mandatory parameters have to be understood by every NSIS QoS node. >> >>There is only the question what "understands" means. > > > IMO you need to more carefully read the QSPEC I-D document. All > mandatory QSPEC parameters that are populated in the QSPEC must be > interpreted by every QNE, which is explained in the QSPEC I-D: > > It says in Section 4.4.1 (Mandatory and Optional QSPEC Parameters) of > the QSPEC I-D > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: > > " Mandatory QSPEC parameters are treated as follows: > > o A QNI SHOULD populate mandatory QSPEC parameters if applicable to > the underlying QOSM. I don't understand this sentence. What does it mean that a QNI "SHOULD" populate parameters if applicable? > o QNEs MUST interpret mandatory QSPEC parameters, if signaled." > > Furthermore, it says in Section 4.2 (QSPEC Processing): > > " a QNE > MUST at least interpret all the mandatory parameters in a QSPEC even > if it does not support the corresponding QOSM. > > Mandatory parameters provide a minimal subset of parameters. A > QNE MUST either a) strictly interpret a mandatory parameter, or > b) remap the parameter and raise the flag defined in > Section 5.1, where the remapping MUST be specified in the QOSM > specification. Here the terminology 'strictly interpret' means that What is the difference between 'strictly interpret' and 'interpret'? In the rest of the document you use 'interpret'. > the parameter is implemented according to the commonly accepted > definition and/or as specified by references given for each QSPEC > parameter. This means that in case a), a parameter > must be strictly interpreted as a token bucket. However, in case b), > a parameter may be remapped, perhaps to a > parameter. I noticed this text improvement and I am happy to see more text about it. Still, I have some issues with the section: I had a problem with this paragraph following the previous one in the section. The previous paragraph said " However, if a QSPEC arrives at a QNE that does not support the QOSM being signaled, it can still understand the QSPEC content, at least to a basic degree. " When I read through the text I got the impression that the two sections relate to each other and in fact they do not. Hence, I suggest to delete the previous paragraph since this one contains the info already. You might also want to delete the second paragraph as well since it is far too obvious to use RFC2119 language: If you don't support even a single QOSM then why are you a QOS NSLP node in the first place. You might want to highlight the following sentence, tough: " A QNE MUST interpret all mandatory parameters from this document even if it does not support the received QoS NSLP message with the indicated QOSM. " Here is my proposal for the section: " 4.2 QSPEC Processing The QSPEC is opaque to the QoS NSLP processing. The QSPEC control information and the QoS description are interpreted and MAY be modified by the RMF in a QNE (see description in [QoS-SIG]). The QSPEC contains a QOSM ID, i.e. information on what QOSM is being signaled by the QNI. However, if a QSPEC arrives at a QNE that does not support the QOSM being signaled, it can still understand the QSPEC content, at least to a basic degree. This is because mandatory parameters have been defined as a common language. Therefore, a QNE MUST at least interpret all the mandatory parameters in a QSPEC even if it does not support the corresponding QOSM. A QNE MUST either a) interpret a mandatory parameter carried in the QSPEC object, or b) remap the parameter and raise the flag defined in Section 5.1, where the remapping MUST be specified in the QOSM specification. Here the terminology 'interpret' means that the parameter is implemented according to the references given for each QSPEC parameter. If a QSPEC arrives at a QNE that does not support the QOSM being signaled, it can still understand the QSPEC content, at least to a basic degree. Hence, with case (a), a parameter must be strictly interpreted as a token bucket. In case b), a parameter may be remapped, perhaps to a parameter. " Btw, have you noticed that the draft has * a flag (Section 5.1) * a parameter (Section 7.2.1) I think they refer to the same concept... > > In the latter case, the remapping of the to > must be specified in the QOSM specification document. > For example, QOSM X exclusively uses the parameter . It > must define a mapping of the mandatory parameter . > The mapping consists of interpreting the Token Bucket Rate as > the parameter and disregarding the other Token Bucket > parameters. Clearly, some information contained in the Bucket> parameter is lost by this mapping, and the resulting QoS may > not be quite what was intended by the QNI. Therefore, QOSM X also > specifies that the flag be raised. Thus, a QNE using > QOSM X is able to make an informed decision whether to admit a > reservation described in terms of , and at the same > time (by means of ) signals to the QNI/QNR that the > exact intention of the QNI may not be met." > > I think this text is pretty clear as to what is required regarding > interpreting mandatory parameters. If not, please suggest > clarifications. The text in the new draft has improved a lot. Thanks for the update. > > >>Another possible question would be: >>" >>Does a node that implements a particular QOSM has to define mappings >>from all mandatory parameters listed in the QSPEC template >>draft to the QOSM draft (even if the QOSM does not make use of them)? >>" >> >>The answer is "I don't know". > > > A QNE must interpret all mandatory parameters, if populated, as > explained in the above text I quoted. If a QOSM re-maps a mandatory > QSPEC parameter, that re-mapping must be defined in the QOSM > specification. As stated in Section 4.7 (QOSM Specification > Requirements): > > " A QOSM specification MUST define QSPEC parameter behavior for these > cases: a) new optional QSPEC parameters the QOSM specification > defines, and b) remapping of existing mandatory or optional QSPEC > parameters, as described in Section 4.2. Unless otherwise specified > in the QOSM specification document, the behaviors to strictly > interpret the mandatory and optional QSPEC parameters are defined in > this document through the references to RFCs that precisely define > the QSPEC parameter behaviors. > > A QOSM specification MUST define how the mandatory parameters are to > be mapped onto the QSPEC parameters used by the QOSM, however the > mapping MAY result in slight modification to the intended > specification when an exact mapping is not possible. This definition > MUST allow a QNE implementing this QOSM to make a decision as to > whether a reservation described in terms of mandatory parameters can > be admitted. If for a particular mandatory parameter no mapping can > be found that guarantees the desired QoS, the QNE is advised to raise > the flag. In other words, for all mandatory > parameters a mapping must be defined, but it is acknowledged that > this mapping may result in slightly bending the original intention of > the QNI." > > I think this text is pretty clear as to what is required. If not, > please suggest clarifications. I understood the token bucket to bandwidth example. Would the RMD draft, for example, list all mandatory parameters and indicate whether it can map them (and how) to parameters used in the RMD specification? Do you think it is awfully realistic for all QNEs to understand all mandatory parameters? I could imagine that Attila and Georgios are not going to implement stateless interior QNEs in such a way that they understand all the mandatory QSPEC parameters. In fact they don't have todo it since only edge routers are likely to ever see QoS NSLP messages that contain QOSM IDs that they do not understand (otherwise something go terribly wrong). Ciao Hannes > > Thanks, > Jerry > > >>Ciao >>Hannes >> >> The QSPEC-draft says in section 5 >> >>>that >>>all parameters listed in the next sections are mandatory. The >>>QSPEC-draft also >>>says in section 4.1 that "a given QOSM defines which of the >> >>mandatory and >> >>>optional parameters it uses, ..." >>> >>>Are there any specific parameters which makes the open issue B.1.1. >>>clearer? Following the QSPEC-draft there doesn't seem to be >> >>a conflict, >> >>>if nothing is >>>done with the unneeded parameters. >>> >>>Thanks, >>>Bernd > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 04:47:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwxbi-0004YD-Mz; Sun, 02 Jul 2006 04:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwxbh-0004Y8-SR for nsis@ietf.org; Sun, 02 Jul 2006 04:47:09 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fwxbg-0003eb-Ei for nsis@ietf.org; Sun, 02 Jul 2006 04:47:09 -0400 Received: (qmail invoked by alias); 02 Jul 2006 08:47:07 -0000 Received: from p549851A0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.160] by mail.gmx.net (mp033) with SMTP; 02 Jul 2006 10:47:07 +0200 X-Authenticated: #29516787 Message-ID: <44A7880B.3030903@gmx.net> Date: Sun, 02 Jul 2006 10:47:07 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: [NSIS] QSPEC Comment: QSPEC QoS Object Header X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi QSPEC authors, I tried to figure out whether the QSPEC template draft could be used for the AAA work. The QSPEC QoS object header raised a few questions: * Why do you need a length field if all the objects just have a fixed length? * Why do you need an 'M' bit? Whether a parameter is mandatory or not can easily derived from the Parameter ID. * Why do you need the 'T' flag? I don't think that the concept is actually useful. In Section 4.5.3 you write: 4.5.3 QSPEC Tunneled Parameter T-Flag Each QSPEC parameter has an associated 'tunneled-parameter T-flag'. When a RESERVE message is tunneled through a domain, QNEs inside the domain cannot update read-write parameters. [hannes] QNEs MUST NOT update the parameters. That's the idea of tunneling. The egress QNE in a domain has two choices: either a) it is configured to have the knowledge to update the parameters correctly, [hannes] What type of update are you looking for? The reservation within the tunneled region is a separate and independent reservation. or b) it cannot update the parameters. In the latter case it MUST set the tunneled-parameter T-flag to tell the QNI (or QNR) that the information contained in the read-write parameter is most likely incorrect (or a lower bound). [hannes] Which parameters are incorrect? The T-flag is interpreted by the QNI, ingress QNE (start of tunnel in a domain), egress QNE (end of tunnel in a domain), or QNR. [hannes] There are now three 'T' bits flying around in related documents: * T-bit set (RESERVE tear): QoS NSLP * T-bit in the NSIS Tunnel ID * T-bit in the QSPEC draft Neigther the QoS NSLP nor the NSIS Tunnel ID does, to my knowledge, not use the T-bit of the QSPEC document. * Why do you need to put error specific flag in every object (namely 'E and N flag)? Errors should be the exception rather than the norm. I would do something different, namely to put an error object with a list of the Parameter IDs in it. Regarding the parameter encoding: You might want to change the description with regard to the Parameter ID field. Change from: " 7.2.1 Parameter 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|0|T| 0 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NON QOSM Hop | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " to: " 7.2.1 Parameter 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|0|T|00000000000000000000000|r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NON QOSM Hop | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " or: " 7.2.1 Parameter 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|0|T| Parameter ID |r|r|r|r| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NON QOSM Hop | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameter ID: 0 Length: 1 " The Parameter ID is 12 bits long. Is it also encoded in network byte order? The same is true for the Length field. The draft only says that "Network byte order ('big-endian') for all 16- and 32-bit integers, as well as 32-bit floating point numbers, are as specified in [RFC1832, IEEE754, NETWORK-BYTE-ORDER]. " Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 04:47:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwxbe-0004Xp-Ek; Sun, 02 Jul 2006 04:47:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwxbd-0004Xk-Ti for nsis@ietf.org; Sun, 02 Jul 2006 04:47:05 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fwxbc-0003eU-HC for nsis@ietf.org; Sun, 02 Jul 2006 04:47:05 -0400 Received: (qmail invoked by alias); 02 Jul 2006 08:47:02 -0000 Received: from p549851A0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.160] by mail.gmx.net (mp036) with SMTP; 02 Jul 2006 10:47:02 +0200 X-Authenticated: #29516787 Message-ID: <44A78806.8010103@gmx.net> Date: Sun, 02 Jul 2006 10:47:02 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [NSIS] QSPEC Comment: Normative References X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi QSPEC authors, the QSPEC draft lists a number of mandatory attributes. Since mandatory attributes are, although not explicit in the draft, mandatory to implement for every QNE it is necessary to have all references related to mandatory attributes in the normative reference section. Are all the referenced documents publically available? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 06:01:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwylX-00080Z-2p; Sun, 02 Jul 2006 06:01:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwylW-00080U-GB for nsis@ietf.org; Sun, 02 Jul 2006 06:01:22 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwylU-00073A-TB for nsis@ietf.org; Sun, 02 Jul 2006 06:01:22 -0400 Received: (qmail invoked by alias); 02 Jul 2006 10:01:19 -0000 Received: from p549851A0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.160] by mail.gmx.net (mp028) with SMTP; 02 Jul 2006 12:01:19 +0200 X-Authenticated: #29516787 Message-ID: <44A7996F.1040406@gmx.net> Date: Sun, 02 Jul 2006 12:01:19 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Subject: [NSIS] QSPEC Comment: IANA Consideration Section X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi QSPEC authors, let me comment on the IANA consideration section. This specification allocates the following codepoints in existing registries: PHB Class Parameter [RFC3140] (Section 7.2.6.1) The registries needed to use RFC 3140 already exist [DSCP-REGISTRY, PHBID-CODES-REGISTRY]. [hannes] Delete it from the IANA consideration section since you don't request IANA todo anything. This specification creates the following registries with the structures as defined below: Object Types (12 bits): The following values are allocated by this specification: 0-4: assigned as specified in Section 7. The allocation policies for further values are as follows: 5-63: Standards Action 64-127: Private/Experimental Use 128-4095: Reserved [hannes] Don't let IANA search through the document. Provide them the values: Object Type = 0: control information = 1: QoS Desired = 2: QoS Available = 3: QoS Reserved = 4: Minimum QoS [hannes] What does 'reserved' mean? The Object Type has 12 bits and according to Section 7 all of them are used. QSPEC Version (4 bits): The following value is allocated by this specification: 0: assigned to Version 0 QSPEC The allocation policies for further values are as follows: 1-15: Standards Action [hannes] You might want to say something about the allocation registry: * Is it allow to depreciate versions? * Is it allowed to delete versions? * Is it allowed to modify versions? QOSM ID (12 bits): The allocation policies are as follows: 0-63: Specification Required 64-127: Private/Experimental Use 128-4095: Reserved [hannes] What does 'reserved' mean? Note that QOSM ID assignments are normally requested in QOSM specification documents. [hannes] Delete this sentence. * Is it allow to depreciate QOSM IDs? * Is it allowed to delete QOSM IDs? * Is it allowed to modify QOSM IDs? QSPEC Procedure (8 bits): Broken down into Message Sequence (4 bits): The following values are allocated by this specification: 0-2: assigned as specified in Section 7.1 The allocation policies for further values are as follows: 3-15: Standards Action Object Combination: The following values are allocated by this specification: 0-2: assigned as specified in tables in Section 6.1.1 --> 6.1.3 The allocation policies for further values are as follows: 3-15: Standards Action [hannes] I suspect that this be a bit confusing for IANA. You want to create a registry and fill it with values according to: 0: Sender-Initiated Reservations, as defined in Section 6.1.1 1: Receiver-Initiated Reservations, as defined in Section 6.1.2 2: Resource Queries, as defined in Section 6.1.3 [hannes] and then a second registry that should be contained in Section 6.1.1 and 6.1.3. These sections do not exist. Error Code (16 bits) The following values are allocated by this specification: 1-3: assigned as specified in Section 4.5.1 [hannes] Section 4.5.1 does not define error codes! The allocation policies for further values are as follows: 4-127: Specification Required (e.g., QOSM specification document) [hannes] Delete the example. 128-255: Private/Experimental Use 255-65535: Reserved Parameter ID (12 bits): The following values are allocated by this specification: 0-18: assigned as specified in Sections 7.2.1 --> 7.2.12. [hannes] List the values here. The allocation policies for further values are as follows: 19-63: Standards Action (for mandatory parameters) 64-127: Specification Required (for optional parameters) 128-255: Private/Experimental Use 255-4095: Reserved [hannes] Again, what does 'reserved' mean? Note that if additional mandatory parameters are defined in the future, this requires a standards action equivalent to reissuing this document as a QSPEC-bis. Excess Treatment Parameter (8 bits): The following values are allocated by this specification: 0-3: assigned as specified in Section 7.2.2 The allocation policies for further values are as follows: 4-63: Standards Action 64-255: Reserved Y.1541 QoS Class Parameter (12 bits): The following values are allocated by this specification: 0-7: assigned as specified in Section 7.2.6.2 The allocation policies for further values are as follows: 8-63: Standards Action 64-4095: Reserved DSTE Class Type Parameter (12 bits): The following values are allocated by this specification: 0-7: assigned as specified in Section 7.2.6.3 The allocation policies for further values are as follows: 8-63: Standards Action 64-4095: Reserved Admission Priority Parameter (8 bits): The following values are allocated by this specification: 0-2: assigned as specified in Section 7.2.6.2 [hannes] Wrong reference: You have to point to Section 7.2.7.2 The allocation policies for further values are as follows: 3-63: Standards Action 64-255: Reserved RPH Namespace Parameter (16 bits): The following values are allocated by this specification: 0-5: assigned as specified in Section 7.2.7.2 [hannes] Wrong reference: You have to point to Section 7.2.7.3 See, however, my comment regarding the entire section below: The allocation policies for further values are as follows: 6-63: Standards Action 64-65535: Reserved RPH Priority Parameter (8 bits): dsn namespace: The following values are allocated by this specification: 0-4: assigned as specified in Section 7.2.7.2 The allocation policies for further values are as follows: 5-63: Standards Action 64-255: Reserved drsn namespace: The following values are allocated by this specification: 0-5: assigned as specified in Section 7.2.7.2 The allocation policies for further values are as follows: 6-63: Standards Action 64-255: Reserved Q735 namespace: The following values are allocated by this specification: 0-4: assigned as specified in Section 7.2.7.2 The allocation policies for further values are as follows: 5-63: Standards Action 64-255: Reserved ets namespace: The following values are allocated by this specification: 0-4: assigned as specified in Section 7.2.7.2 The allocation policies for further values are as follows: 5-63: Standards Action 64-255: Reserved wts namespace: The following values are allocated by this specification: 0-4: assigned as specified in Section 7.2.7.2 The allocation policies for further values are as follows: 5-63: Standards Action 64-255: Reserved [hannes] The reference in the draft to [SIP-PRIORITY]. [SIP-PRIORITY] is an RFC in the meanwhile: http://www.rfc-editor.org/rfc/rfc4412.txt RFC 4412 creates a registry for these values already. See Section 12.6 of RFC 4412. Why do you need to create another one with the same values? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 06:09:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwytl-0001nY-44; Sun, 02 Jul 2006 06:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwytj-0001nT-JL for nsis@ietf.org; Sun, 02 Jul 2006 06:09:51 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fwyti-0007rE-6Y for nsis@ietf.org; Sun, 02 Jul 2006 06:09:51 -0400 Received: (qmail invoked by alias); 02 Jul 2006 10:09:48 -0000 Received: from p549851A0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.160] by mail.gmx.net (mp028) with SMTP; 02 Jul 2006 12:09:48 +0200 X-Authenticated: #29516787 Message-ID: <44A79B63.60400@gmx.net> Date: Sun, 02 Jul 2006 12:09:39 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [NSIS] QSPEC Comment: References X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi QSPEC authors, I noticed that the reference section is at some places: * incomplete Example: [RMD-QOSM] Bader, A., et. al., " RMD-QOSM: An NSIS QoS Signaling Policy Model for Networks Using Resource Management in DiffServ (RMD)," work in progress. Maybe this points to the RMD draft but I am not sure given that the draft name in -07 is: " RMD-QOSM - The Resource Management in Diffserv QOS Model " * wrong [SIP-PRIORITY] Schulzrinne, H., Polk, J., "Communications Resource Priority for the Session Initiation Protocol(SIP)." work in progress. * not correct See my mail regarding the placement of some references from the informative to the normative section. Another example: [RFC2205] is certainly does not belong to the normative reference section. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 06:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwz8o-0002Ty-SU; Sun, 02 Jul 2006 06:25:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwz8o-0002Tq-89 for nsis@ietf.org; Sun, 02 Jul 2006 06:25:26 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fwz8m-0008Me-R8 for nsis@ietf.org; Sun, 02 Jul 2006 06:25:26 -0400 Received: (qmail invoked by alias); 02 Jul 2006 10:25:24 -0000 Received: from p549851A0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.160] by mail.gmx.net (mp041) with SMTP; 02 Jul 2006 12:25:24 +0200 X-Authenticated: #29516787 Message-ID: <44A79F13.9040604@gmx.net> Date: Sun, 02 Jul 2006 12:25:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [NSIS] QSPEC Comment: Mandatory Attribute List X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi QSPEC authors, Section 7.2 of the QSPEC template draft lists a number of mandatory attributes: * NON QOSM Hop * Excess Treatment * Bandwidth * Token Bucket * PHB Class * Y.1541 QoS Class * DSTE Class Type * & * Admission Priority * RPH Priority A few comments: - The DSTE Class Type' parameter points to a requirements document with respect to its functional specification (see RFC3564). Maybe you placed the wrong reference in here. - I would be more relaxed to see a review of the RFC 4412 authors (James Polk and Henning Schulzrinne) when it comes to the usage of the RPH Priority parameters (defined for SIP) in the QSPEC template draft. - I am not sure why the Y.1541 QoS Class parameter is a mandatory object. - The Admission Priority parameter points to a non-IETF in the informative reference section. - The NON QOSM Hop parameter does not seem to be a QoS parameter at all that belongs to this category. I would rather see it as an error message. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 07:39:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx0Ih-00044X-54; Sun, 02 Jul 2006 07:39:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx0Ig-00044Q-Cv for nsis@ietf.org; Sun, 02 Jul 2006 07:39:42 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fx0Id-00053P-47 for nsis@ietf.org; Sun, 02 Jul 2006 07:39:42 -0400 Received: (qmail invoked by alias); 02 Jul 2006 11:39:37 -0000 Received: from p549851A0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.160] by mail.gmx.net (mp017) with SMTP; 02 Jul 2006 13:39:37 +0200 X-Authenticated: #29516787 Message-ID: <44A7B079.2030404@gmx.net> Date: Sun, 02 Jul 2006 13:39:37 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [NSIS] draft-jeong-nsis-3gpp-qosm X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I wanted to see what different QoSMs do with respect to their QoS parameter description. I remembered this draft: ---------- 3GPP QoS Model for Networks Using 3GPP QoS Classes http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt ---------- It is expired. Are there any plans to resubmit it? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 20:02:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBtO-0005Bq-7s; Sun, 02 Jul 2006 20:02:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBtM-0005Bl-2r for nsis@ietf.org; Sun, 02 Jul 2006 20:02:20 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxBtK-0006oX-Lt for nsis@ietf.org; Sun, 02 Jul 2006 20:02:20 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-126.messagelabs.com!1151884916!1493348!2 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 8976 invoked from network); 3 Jul 2006 00:02:17 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-126.messagelabs.com with SMTP; 3 Jul 2006 00:02:17 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452000E1AED; Sun, 2 Jul 2006 20:02:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] draft-qosmodel-controlledload-04 Date: Sun, 2 Jul 2006 19:02:14 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A65@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44A6D99C.4030902@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] draft-qosmodel-controlledload-04 Thread-Index: AcadTDI15MddIBroSsqhto8zfVzwTAA5wY7Q From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" , X-Spam-Score: 1.1 (+) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: "Ash, Gerald R \(Jerry\), ALABS" , Kappler Cornelia , =?iso-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, See below.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Saturday, July 01, 2006 4:23 PM > To: Hannes Tschofenig > Cc: nsis@ietf.org; "Attila B=E1der (IJ/ETH)" > Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >=20 > Hi all, >=20 > I should have read the latest QSPEC draft version before I sent this=20 > mail. The most recent draft talks about this aspect and it says in=20 > Section 4.7: > " > A QOSM specification MUST define how the mandatory parameters are to > be mapped onto the QSPEC parameters used by the QOSM, however the > mapping MAY result in slight modification to the intended > specification when an exact mapping is not possible. > " >=20 > Attila, you did this for the token bucket parameter and=20 > described that=20 > it can be mapped to the bandwidth parameter. >=20 > Now, the only question remains whether a QOSM also have to define a=20 > mapping for all mandatory parameters. This would address the case=20 > mentioned below: The QOSM does not make use of all mandatory=20 > parameters=20 > listed in the QSPEC. As stated in the QOSM specification requirements in Section 4.7, if a = QOSM remaps a mandatory parameter, the remapping must be defined in the = QOSM specification document. If no such remapping is defined, the = default behavior is that the QOSM must strictly interpret the mandatory = parameter, as defined in Section 5.1: "Here the terminology 'strictly interpret' means that the parameter is implemented according to the commonly accepted definition and/or as specified by references given for each QSPEC parameter." Thanks, Jerry >=20 > Ciao > Hannes >=20 >=20 > Hannes Tschofenig wrote: > > Hi Attila, > >=20 > > Attila B=E1der (IJ/ETH) wrote: > >=20 > >> Hi Bernd, This is the case in RMD as well. In RMD domain resource > >> reservation is based on one parameter: Bandwidth. If, for example, > >> the resource request arriving to the Edge is a token bucket, it > >> should be translated to a single Bandwidth parameter. This may be a > >> peak value, or an effective value. > >=20 > >=20 > > I guess Bernd's question was focusing on a different aspect. What=20 > > happens if you receive a request that contains the=20 > parameter 'Y.1541 QoS=20 > > Class with the value set for Class 0? > >=20 > > Ciao > > Hannes > >=20 > >=20 > >> > >> Best regards, Attila > >> > >> > >>> -----Original Message----- From: Bernd Schloer > >>> [mailto:bschloer@cs.uni-goettingen.de] Sent: Thursday, June 29, > >>> 2006 3:01 PM To: nsis@ietf.org Subject: [NSIS] > >>> draft-qosmodel-controlledload-04 > >>> > >>> > >>> Hi, > >>> > >>> the first open issue in the appendix B is about what to do with > >>> mandatory QSPEC parameters which are not needed for CLS. > >>> > >>> Does a QOSM have to understand (and provide information about) all > >>> mandatory parameters, even if they are not used? The QSPEC-draft > >>> says in section 5 that all parameters listed in the next sections > >>> are mandatory. The QSPEC-draft also says in section 4.1 that "a > >>> given QOSM defines which of the mandatory and optional parameters > >>> it uses, ..." > >>> > >>> Are there any specific parameters which makes the open=20 > issue B.1.1. > >>> clearer? Following the QSPEC-draft there doesn't seem to be a=20 > >>> conflict, if nothing is done with the unneeded parameters. > >>> > >>> Thanks, Bernd > >>> > >>> > >>> > >>> _______________________________________________ nsis mailing list=20 > >>> nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > >>> > >> > >> > >> _______________________________________________ nsis mailing list=20 > >> nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 20:03:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBu3-0005Fz-Ic; Sun, 02 Jul 2006 20:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBu2-0005Fu-M2 for nsis@ietf.org; Sun, 02 Jul 2006 20:03:02 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxBu0-0006pS-UH for nsis@ietf.org; Sun, 02 Jul 2006 20:03:02 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1151884934!11256099!6 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 16544 invoked from network); 3 Jul 2006 00:02:58 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-2.tower-120.messagelabs.com with SMTP; 3 Jul 2006 00:02:58 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452000E1AF7; Sun, 2 Jul 2006 20:02:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] draft-qosmodel-controlledload-04 Date: Sun, 2 Jul 2006 19:02:56 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A66@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44A6DA63.8090702@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] draft-qosmodel-controlledload-04 Thread-Index: AcadTKB+0bt7N483R5KSlvF9yvg0XwAyBOOQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" X-Spam-Score: 1.1 (+) X-Scan-Signature: 441f623df000f14368137198649cb083 Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , nsis@ietf.org, Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, See below.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Saturday, July 01, 2006 4:26 PM > To: Ash, Gerald R (Jerry), ALABS > Cc: nsis@ietf.org > Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >=20 > Hi Jerry, >=20 > it is true that I haven't read the most recent QSPEC draft=20 > when I sent=20 > this mail. In the meanwhile I did. Please find a few comments below: >=20 > Ash, Gerald R (Jerry), ALABS wrote: > > Hi Hannes, > >=20 > > See below.=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > >>Sent: Friday, June 30, 2006 8:43 AM > >>To: Bernd Schloer > >>Cc: nsis@ietf.org > >>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 > >> > >>Hi Bernd, > >> > >>Bernd Schloer wrote: > >> > >>>Hi, > >>> > >>>the first open issue in the appendix B is about what to do with=20 > >>>mandatory QSPEC parameters which are not needed for CLS. > >>> > >>>Does a QOSM have to understand (and provide information about) all=20 > >>>mandatory parameters, even if they are not used? > >> > >>I think the question is wrong. What about the following question: > >>" > >>Does a node that implements a particular QOSM has to understand all > >>mandatory parameters listed in the QSPEC template draft=20 > (even if the=20 > >>QOSM does not make use of them)? > >>" > >>The answer would be "YES" since the QSPEC template draft says that=20 > >>mandatory parameters have to be understood by every NSIS QoS node. > >> > >>There is only the question what "understands" means. > >=20 > >=20 > > IMO you need to more carefully read the QSPEC I-D document. All > > mandatory QSPEC parameters that are populated in the QSPEC must be > > interpreted by every QNE, which is explained in the QSPEC I-D: > >=20 > > It says in Section 4.4.1 (Mandatory and Optional QSPEC=20 > . Parameters) of > > the QSPEC I-D > > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: > >=20 > > " Mandatory QSPEC parameters are treated as follows: > >=20 > > o A QNI SHOULD populate mandatory QSPEC parameters if=20 > . applicable to > > the underlying QOSM. >=20 > I don't understand this sentence. What does it mean that a=20 > QNI "SHOULD"=20 > populate parameters if applicable? It means that a QNI is not required to populate all mandatory = parameters. A QNI would only populated a mandatory parameter if is used = by the QOSM supported by the QNI. =20 > > o QNEs MUST interpret mandatory QSPEC parameters, if signaled." > >=20 > > Furthermore, it says in Section 4.2 (QSPEC Processing): > >=20 > > " a QNE > > MUST at least interpret all the mandatory parameters in=20 > > a QSPEC even > > if it does not support the corresponding QOSM. > >=20 > > Mandatory parameters provide a minimal subset of parameters. A > > QNE MUST either a) strictly interpret a mandatory parameter, or > > b) remap the parameter and raise the flag=20 > > defined in > > Section 5.1, where the remapping MUST be specified in the QOSM > > specification. Here the terminology 'strictly=20 > > interpret' means that >=20 > What is the difference between 'strictly interpret' and=20 > 'interpret'? In=20 > the rest of the document you use 'interpret'. 'Strictly interpret' is defined in the text I quoted from Section 4.2 = (QSPEC Processing), which is given again in the very next sentences I = quoted just below (after you posed your above question :-) " Mandatory parameters provide a minimal subset of parameters. A QNE MUST either a) strictly interpret a mandatory parameter, or b) remap the parameter and raise the flag defined in Section 5.1, where the remapping MUST be specified in the QOSM specification. Here the terminology 'strictly interpret' means that the parameter is implemented according to the commonly accepted definition and/or as specified by references given for each QSPEC parameter. This means that in case a), a parameter must be strictly interpreted as a token bucket. However, in case b), a parameter may be remapped, perhaps to a parameter." In the document, the term 'interpret' a mandatory parameter means either = a) strictly interpret (as defined above), or b) remap (as defined = above). Perhaps this can be made clearer in the text. =20 > > the parameter is implemented according to the commonly accepted > > definition and/or as specified by references given for each QSPEC > > parameter. This means that in case a), a =20 > > parameter > > must be strictly interpreted as a token bucket. =20 > > However, in case b), > > a parameter may be remapped, perhaps to a=20 > > > > parameter. > > I noticed this text improvement and I am happy to see more=20 > text about it. >=20 > Still, I have some issues with the section: >=20 > I had a problem with this paragraph following the previous one in the=20 > section. The previous paragraph said > " > However, if a QSPEC arrives at a QNE that does > not support the QOSM being signaled, it can still understand the > QSPEC content, at least to a basic degree. > " >=20 > When I read through the text I got the impression that the=20 > two sections=20 > relate to each other and in fact they do not. Hence, I=20 > suggest to delete=20 > the previous paragraph since this one contains the info already.=20 I'm unclear as to which paragraph/text you are proposing to delete. > You=20 > might also want to delete the second paragraph as well since=20 > it is far=20 > too obvious to use RFC2119 language: If you don't support=20 > even a single=20 > QOSM then why are you a QOS NSLP node in the first place. I think it important to state that a QNE MUST support at least one QOSM, = even if this is clearly necessary to effectively support QoS-NSLP/QSPEC. > You might want to highlight the following sentence, though: >=20 > " > A QNE MUST interpret all mandatory parameters from this document even > if it does not support the received QoS NSLP message with the=20 > indicated=20 > QOSM. > " >=20 > Here is my proposal for the section: >=20 > " > 4.2 QSPEC Processing >=20 > The QSPEC is opaque to the QoS NSLP processing. The QSPEC control > information and the QoS description are interpreted and MAY be > modified by the RMF in a QNE (see description in [QoS-SIG]). >=20 > The QSPEC contains a QOSM ID, i.e. information on what=20 > QOSM is being > signaled by the QNI. However, if a QSPEC arrives at a=20 > QNE that does > not support the QOSM being signaled, it can still understand the > QSPEC content, at least to a basic degree. This is=20 > because mandatory > parameters have been defined as a common language. =20 > Therefore, a QNE > MUST at least interpret all the mandatory parameters in a=20 > QSPEC even > if it does not support the corresponding QOSM. >=20 > A QNE MUST either >=20 > a) interpret a mandatory parameter carried in the QSPEC object, or >=20 > b) remap the parameter and raise the flag=20 > defined in > Section 5.1, where the remapping MUST be specified in the QOSM > specification. >=20 > Here the terminology 'interpret' means that > the parameter is implemented according to the references=20 > given for=20 > each QSPEC parameter. >=20 > If a QSPEC arrives at a QNE that does not support the QOSM being > signaled, it can still understand the QSPEC content, at least to a > basic degree. Hence, with case (a), a parameter > must be strictly interpreted as a token bucket. >=20 > In case b), a parameter may be remapped,=20 > perhaps to a > parameter. > " I don't see any benefit in redefining what 'interpret' means in the = document. As I mentioned above, the document uses the term 'interpret' = to mean that a mandatory parameter is 'interpreted' if is either = 'strictly interpreted' or it is 'remapped' (where the remapping must be = defined in the QOSM specification document). OTOH, it might be useful = to define a 'remapping' flag to indicated if a mandatory or optional = parameter has been remapped by a QNE in the path. =20 > Btw, have you noticed that the draft has > * a flag (Section 5.1) > * a parameter (Section 7.2.1) >=20 > I think they refer to the same concept... Yes, good catch. is indeed intended to be a flag, and = perhaps one of the QSPEC object flags defined in Section 7.1 could be = used for this purpose, rather than use a full 32-bit parameter for this = purpose, as currently specified in Section 7.2.1. =20 > > In the latter case, the remapping of the to > > must be specified in the QOSM specification document. > > For example, QOSM X exclusively uses the parameter=20 > > . It > > must define a mapping of the mandatory parameter . > > The mapping consists of interpreting the Token Bucket Rate as > > the parameter and disregarding the other Token Bucket > > parameters. Clearly, some information contained in the > Bucket> parameter is lost by this mapping, and the=20 > > resulting QoS may > > not be quite what was intended by the QNI. Therefore,=20 > > QOSM X also > > specifies that the flag be raised. Thus,=20 > > a QNE using > > QOSM X is able to make an informed decision whether to admit a > > reservation described in terms of , and at the same > > time (by means of ) signals to the QNI/QNR that the > > exact intention of the QNI may not be met." > >=20 > > I think this text is pretty clear as to what is required regarding > > interpreting mandatory parameters. If not, please suggest > > clarifications. >=20 > The text in the new draft has improved a lot. > Thanks for the update. >=20 > >=20 > >=20 > >>Another possible question would be: > >>" > >>Does a node that implements a particular QOSM has to define=20 > >>mappings=20 > >>from all mandatory parameters listed in the QSPEC template=20 > >>draft to the QOSM draft (even if the QOSM does not make use=20 > of them)? > >>" > >> > >>The answer is "I don't know". > >=20 > >=20 > > A QNE must interpret all mandatory parameters, if populated, as > > explained in the above text I quoted. If a QOSM re-maps a mandatory > > QSPEC parameter, that re-mapping must be defined in the QOSM > > specification. As stated in Section 4.7 (QOSM Specification > > Requirements): > >=20 > > " A QOSM specification MUST define QSPEC parameter=20 > > behavior for these > > cases: a) new optional QSPEC parameters the QOSM specification > > defines, and b) remapping of existing mandatory or optional QSPEC > > parameters, as described in Section 4.2. Unless=20 > > otherwise specified > > in the QOSM specification document, the behaviors to strictly > > interpret the mandatory and optional QSPEC parameters=20 > > are defined in > > this document through the references to RFCs that=20 > > precisely define > > the QSPEC parameter behaviors. =20 > >=20 > > A QOSM specification MUST define how the mandatory=20 > > parameters are to > > be mapped onto the QSPEC parameters used by the QOSM, however the > > mapping MAY result in slight modification to the intended > > specification when an exact mapping is not possible. =20 > > This definition > > MUST allow a QNE implementing this QOSM to make a decision as to > > whether a reservation described in terms of mandatory=20 > > parameters can > > be admitted. If for a particular mandatory parameter no=20 > > mapping can > > be found that guarantees the desired QoS, the QNE is=20 > > advised to raise > > the flag. In other words, for all mandatory > > parameters a mapping must be defined, but it is acknowledged that > > this mapping may result in slightly bending the original=20 > > intention of > > the QNI." > >=20 > > I think this text is pretty clear as to what is required. If not, > > please suggest clarifications. >=20 > I understood the token bucket to bandwidth example. >=20 > Would the RMD draft, for example, list all mandatory parameters and=20 > indicate whether it can map them (and how) to parameters used=20 > in the RMD=20 > specification? As stated in the QOSM specification requirements in Section 4.7, if a = QOSM remaps a mandatory parameter, the remapping must be defined in the = QOSM specification document. If no such remapping is defined, the = default behavior is that the QOSM must strictly interpret the mandatory = parameter, as defined above. =20 > Do you think it is awfully realistic for all QNEs to understand all=20 > mandatory parameters? I could imagine that Attila and=20 > Georgios are not=20 > going to implement stateless interior QNEs in such a way that they=20 > understand all the mandatory QSPEC parameters. In fact they=20 > don't have=20 > todo it since only edge routers are likely to ever see QoS=20 > NSLP messages=20 > that contain QOSM IDs that they do not understand (otherwise=20 > something=20 > go terribly wrong). It is up the RMD authors to specify how they want RMD to behave wrt = mandatory parameters (and obtain rough consensus, of course). That is, = if a mandatory parameter is remapped and not strictly interpreted, the = remapping must be specified in the QOSM specification document. = Otherwise, the QOSM must strictly interpret the mandatory parameters = that are not remapped, if they are populated by the QNI. There are no restrictions on how the remapping must be done, it can be = as simple as necessary (but no simpler). Thanks, Jerry >=20 >=20 > Ciao > Hannes >=20 > >=20 > > Thanks, > > Jerry > > =20 > >=20 > >>Ciao > >>Hannes > >> > >> The QSPEC-draft says in section 5 > >> > >>>that > >>>all parameters listed in the next sections are mandatory. The=20 > >>>QSPEC-draft also > >>>says in section 4.1 that "a given QOSM defines which of the=20 > >> > >>mandatory and > >> > >>>optional parameters it uses, ..." > >>> > >>>Are there any specific parameters which makes the open=20 > issue B.1.1.=20 > >>>clearer? Following the QSPEC-draft there doesn't seem to be=20 > >> > >>a conflict,=20 > >> > >>>if nothing is > >>>done with the unneeded parameters. > >>> > >>>Thanks, > >>>Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 20:04:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBvD-0005Ot-1f; Sun, 02 Jul 2006 20:04:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBvB-0005On-IQ for nsis@ietf.org; Sun, 02 Jul 2006 20:04:13 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxBvA-0006wU-4M for nsis@ietf.org; Sun, 02 Jul 2006 20:04:13 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1151885048!11132618!2 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 5387 invoked from network); 3 Jul 2006 00:04:10 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-121.messagelabs.com with SMTP; 3 Jul 2006 00:04:10 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452000E1B1E; Sun, 2 Jul 2006 20:04:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: IANA Consideration Section Date: Sun, 2 Jul 2006 19:04:08 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A67@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44A7996F.1040406@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: IANA Consideration Section Thread-Index: AcadvotB2hRTSU5/SFOYjndHYk26PgAahvOg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" , "NSIS" X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, See below. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Sunday, July 02, 2006 6:01 AM > To: NSIS > Subject: [NSIS] QSPEC Comment: IANA Consideration Section >=20 > Hi QSPEC authors, >=20 > let me comment on the IANA consideration section. >=20 >=20 > This specification allocates the following codepoints in existing > registries: >=20 > PHB Class Parameter [RFC3140] (Section 7.2.6.1) >=20 > The registries needed to use RFC 3140 already exist=20 > [DSCP-REGISTRY, > PHBID-CODES-REGISTRY]. >=20 > [hannes] Delete it from the IANA consideration section since=20 > you don't=20 > request IANA todo anything. OK. =20 > This specification creates the following registries with the > structures as defined below: >=20 > Object Types (12 bits): > The following values are allocated by this specification: > 0-4: assigned as specified in Section 7. > The allocation policies for further values are as follows: > 5-63: Standards Action > 64-127: Private/Experimental Use > 128-4095: Reserved >=20 > [hannes] Don't let IANA search through the document. Provide them the=20 > values: >=20 > Object Type =3D 0: control information > =3D 1: QoS Desired > =3D 2: QoS Available > =3D 3: QoS Reserved > =3D 4: Minimum QoS OK. =20 > [hannes] What does 'reserved' mean? The Object Type has 12 bits and=20 > according to Section 7 all of them are used. I'm not sure of your question, Section 9 says: Object Types (12 bits):=20 The following values are allocated by this specification: 0-4: assigned as specified in Section 7. The allocation policies for further values are as follows: 5-63: Standards Action 64-127: Private/Experimental Use 128-4095: Reserved This is how the 12 bits are used in the registry. Perhaps your question = pertains to the "Reserved" above? Here the specified range designated = as 'reserved' is a normal use of allocated space in a registry that is = reserved for future definition by a specification. Future = specifications can redefine the registry allocations, and allocate more = space to various designations, as necessary (e.g., more space allocated = to "Standards Action" or to "Private/Experimental Use", etc.). > QSPEC Version (4 bits): > The following value is allocated by this specification: > 0: assigned to Version 0 QSPEC > The allocation policies for further values are as follows: > 1-15: Standards Action >=20 > [hannes] You might want to say something about the allocation=20 > registry: >=20 > * Is it allow to depreciate versions? > * Is it allowed to delete versions? > * Is it allowed to modify versions? No, no, and no, not without another specification doing that. =20 > QOSM ID (12 bits): > The allocation policies are as follows: > 0-63: Specification Required > 64-127: Private/Experimental Use > 128-4095: Reserved >=20 > [hannes] What does 'reserved' mean? See above for explanation of use of 'reserved' fields in registries. > Note that QOSM ID assignments are normally requested in QOSM > specification documents. >=20 > [hannes] Delete this sentence. Why? I think it just explains why there are no QOSM ID assignments in = this document, and where QOSM ID requests will be found in the future. =20 > * Is it allow to depreciate QOSM IDs? > * Is it allowed to delete QOSM IDs? > * Is it allowed to modify QOSM IDs? No, no, and no. Not without a specification that does that. > QSPEC Procedure (8 bits): > Broken down into > Message Sequence (4 bits): > The following values are allocated by this specification: > 0-2: assigned as specified in Section 7.1 > The allocation policies for further values are as follows: > 3-15: Standards Action > Object Combination: > The following values are allocated by this specification: > 0-2: assigned as specified in tables in Section 6.1.1 --> 6.1.3 >=20 > The allocation policies for further values are as follows: > 3-15: Standards Action >=20 > [hannes] I suspect that this be a bit confusing for IANA. >=20 > You want to create a registry and fill it with values according to: >=20 > 0: Sender-Initiated Reservations, as defined=20 > in Section > 6.1.1 > 1: Receiver-Initiated Reservations, as defined in > Section 6.1.2 > 2: Resource Queries, as defined in Section 6.1.3 >=20 > [hannes] and then a second registry that should be contained=20 > in Section=20 > 6.1.1 and 6.1.3. These sections do not exist. OK, will fix. > Error Code (16 bits) > The following values are allocated by this specification: > 1-3: assigned as specified in Section 4.5.1 >=20 > [hannes] Section 4.5.1 does not define error codes! Yes, you're right. This didn't get updated after all the discussion on = error codes. Will do. =20 > The allocation policies for further values are as follows: > 4-127: Specification Required (e.g., QOSM specification document) >=20 > [hannes] Delete the example. Why, it's just an example? =20 =20 > 128-255: Private/Experimental Use > 255-65535: Reserved > Parameter ID (12 bits): > The following values are allocated by this specification: > 0-18: assigned as specified in Sections 7.2.1 --> 7.2.12. >=20 > [hannes] List the values here. OK. =20 > The allocation policies for further values are as follows: > 19-63: Standards Action (for mandatory parameters) > 64-127: Specification Required (for optional parameters) > 128-255: Private/Experimental Use > 255-4095: Reserved >=20 > [hannes] Again, what does 'reserved' mean? Again, see above explanation of 'reserved'. =20 > Note that if additional mandatory parameters are defined in the > future, this requires a standards action equivalent to reissuing > this document as a QSPEC-bis. >=20 > Excess Treatment Parameter (8 bits): > The following values are allocated by this specification: > 0-3: assigned as specified in Section 7.2.2 > The allocation policies for further values are as follows: > 4-63: Standards Action > 64-255: Reserved >=20 > Y.1541 QoS Class Parameter (12 bits): > The following values are allocated by this specification: > 0-7: assigned as specified in Section 7.2.6.2 > The allocation policies for further values are as follows: > 8-63: Standards Action > 64-4095: Reserved >=20 > DSTE Class Type Parameter (12 bits): > The following values are allocated by this specification: > 0-7: assigned as specified in Section 7.2.6.3 > The allocation policies for further values are as follows: > 8-63: Standards Action > 64-4095: Reserved >=20 > Admission Priority Parameter (8 bits): > The following values are allocated by this specification: > 0-2: assigned as specified in Section 7.2.6.2 >=20 > [hannes] Wrong reference: You have to point to Section 7.2.7.2 OK. =20 > The allocation policies for further values are as follows: > 3-63: Standards Action > 64-255: Reserved >=20 > RPH Namespace Parameter (16 bits): > The following values are allocated by this specification: > 0-5: assigned as specified in Section 7.2.7.2 >=20 > [hannes] Wrong reference: You have to point to Section 7.2.7.3 OK. > See, however, my comment regarding the entire section below: >=20 > The allocation policies for further values are as follows: > 6-63: Standards Action > 64-65535: Reserved >=20 > RPH Priority Parameter (8 bits): > dsn namespace: > The following values are allocated by this specification: > 0-4: assigned as specified in Section 7.2.7.2 > The allocation policies for further values are as follows: > 5-63: Standards Action > 64-255: Reserved > drsn namespace: > The following values are allocated by this specification: > 0-5: assigned as specified in Section 7.2.7.2 > The allocation policies for further values are as follows: > 6-63: Standards Action > 64-255: Reserved > Q735 namespace: > The following values are allocated by this specification: > 0-4: assigned as specified in Section 7.2.7.2 > The allocation policies for further values are as follows: > 5-63: Standards Action > 64-255: Reserved > ets namespace: > The following values are allocated by this specification: > 0-4: assigned as specified in Section 7.2.7.2 > The allocation policies for further values are as follows: > 5-63: Standards Action > 64-255: Reserved > wts namespace: > The following values are allocated by this specification: > 0-4: assigned as specified in Section 7.2.7.2 > The allocation policies for further values are as follows: > 5-63: Standards Action > 64-255: Reserved >=20 > [hannes] The reference in the draft to [SIP-PRIORITY].=20 > [SIP-PRIORITY] is=20 > an RFC in the meanwhile: > http://www.rfc-editor.org/rfc/rfc4412.txt OK. =20 > RFC 4412 creates a registry for these values already. See=20 > Section 12.6=20 > of RFC 4412. Why do you need to create another one with the=20 > same values? Good point. I think this is necessary because the assigned values are = being mapped to QSPEC parameter values. However, I think that this = aspect needs to be pointed out to IANA. Thanks, Jerry >=20 > Ciao > Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 20:05:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBwj-0005WK-Ld; Sun, 02 Jul 2006 20:05:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBwj-0005WF-CY for nsis@ietf.org; Sun, 02 Jul 2006 20:05:49 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxBwi-00073c-3q for nsis@ietf.org; Sun, 02 Jul 2006 20:05:49 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1151885122!8341464!5 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 24477 invoked from network); 3 Jul 2006 00:05:47 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-9.tower-121.messagelabs.com with SMTP; 3 Jul 2006 00:05:47 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452000E1B43; Sun, 2 Jul 2006 20:05:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: Mandatory Attribute List Date: Sun, 2 Jul 2006 19:05:46 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A68@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44A79F13.9040604@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: Mandatory Attribute List Thread-Index: AcadweHnmrIPcdpKT1GiXH9WpOdKQAAbMR6g From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" , "NSIS" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, See below.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Sunday, July 02, 2006 6:25 AM > To: NSIS > Subject: [NSIS] QSPEC Comment: Mandatory Attribute List >=20 > Hi QSPEC authors, >=20 > Section 7.2 of the QSPEC template draft lists a number of mandatory=20 > attributes: >=20 > * NON QOSM Hop > * Excess Treatment > * Bandwidth > * Token Bucket > * PHB Class > * Y.1541 QoS Class > * DSTE Class Type > * & > * Admission Priority > * RPH Priority >=20 > A few comments: >=20 > - The DSTE Class Type' parameter points to a requirements=20 > document with=20 > respect to its functional specification (see RFC3564). Maybe=20 > you placed=20 > the wrong reference in here. OK. A better reference would be RFC 4124 = http://www.ietf.org/rfc/rfc4124.txt?number=3D4124, the DSTE protocol = extensions specification. =20 > - I would be more relaxed to see a review of the RFC 4412=20 > authors (James=20 > Polk and Henning Schulzrinne) when it comes to the usage of the RPH=20 > Priority parameters (defined for SIP) in the QSPEC template draft. As GIST co-author, Henning at least probably monitors this list. In = addition, there was a suggested that we might want to send the last call = on QoS-NSLP and QSPEC to TSVWG as well. > - I am not sure why the Y.1541 QoS Class parameter is a=20 > mandatory object. Actually the mandatory parameter is . As discussed in = Section 7.2.6, consists of the , , or parameter. These are 3 different ways to = specify , and it is expected that at most one is populated. = This can be clarified. =20 > - The Admission Priority parameter points to a non-IETF in the=20 > informative reference section. It should be in the Normative References section, per your previous = comment. Also, it is OK that this is not an RFC, if that is your point. = I checked this out with IANA, normative references that are not RFCs = (e.g., Standards from other SDO's) are certainly permissible as = normative references. > - The NON QOSM Hop parameter does not seem to be a QoS=20 > parameter at all=20 > that belongs to this category. I would rather see it as an=20 > error message. I think it should be a flag, along with the E-Flag for QSPEC objects = specified in Section 7.1, as I suggested in a previous response to one = of your comments. Thanks, Jerry >=20 > Ciao > Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 20:06:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBxD-0005c7-Ve; Sun, 02 Jul 2006 20:06:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBxC-0005c1-Gq for nsis@ietf.org; Sun, 02 Jul 2006 20:06:18 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxBxB-0007BD-67 for nsis@ietf.org; Sun, 02 Jul 2006 20:06:18 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1151885165!9751813!2 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 31253 invoked from network); 3 Jul 2006 00:06:15 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 3 Jul 2006 00:06:15 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452000E1B47; Sun, 2 Jul 2006 20:06:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: Normative References Date: Sun, 2 Jul 2006 19:06:14 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A69@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44A78806.8010103@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: Normative References Thread-Index: AcadtFC18D9/433ERb+wd1woV5f2BwAcqXdQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" , "NSIS" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, See below.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Sunday, July 02, 2006 4:47 AM > To: NSIS > Subject: [NSIS] QSPEC Comment: Normative References >=20 > Hi QSPEC authors, >=20 > the QSPEC draft lists a number of mandatory attributes. Since=20 > mandatory=20 > attributes are, although not explicit in the draft, mandatory to=20 > implement for every QNE it is necessary to have all=20 > references related=20 > to mandatory attributes in the normative reference section. OK, I agree. =20 > Are all the referenced documents publicly available? Yes. Thanks, Jerry > Ciao > Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 20:07:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBxu-0005iN-Dd; Sun, 02 Jul 2006 20:07:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBxs-0005iI-J9 for nsis@ietf.org; Sun, 02 Jul 2006 20:07:00 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxBxs-0007Ha-3e for nsis@ietf.org; Sun, 02 Jul 2006 20:07:00 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1151885216!10443701!3 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 24821 invoked from network); 3 Jul 2006 00:06:58 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-15.tower-120.messagelabs.com with SMTP; 3 Jul 2006 00:06:58 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452000E1B50; Sun, 2 Jul 2006 20:06:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: QSPEC QoS Object Header Date: Sun, 2 Jul 2006 19:06:56 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A6A@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44A7880B.3030903@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: QSPEC QoS Object Header Thread-Index: AcadtFEbbuN+AVd5Q3CwTnY/SJkuiQAaXEdw From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" , "NSIS" X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, See below.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Sunday, July 02, 2006 4:47 AM > To: NSIS > Subject: [NSIS] QSPEC Comment: QSPEC QoS Object Header >=20 > Hi QSPEC authors, >=20 > I tried to figure out whether the QSPEC template draft could=20 > be used for=20 > the AAA work. The QSPEC QoS object header raised a few questions: >=20 > * Why do you need a length field if all the objects just have a fixed=20 > length? The length of various QSPEC parameters is not fixed. E.g., compare = Section 7.2.5 (length=3D5) to Section 7.2.3 = (length=3D1). >=20 > * Why do you need an 'M' bit? Whether a parameter is mandatory or not=20 > can easily derived from the Parameter ID. We were advised that the M flag should be specified for easier QSPEC = processing. In addition, new QSPEC versions specifying new mandatory = parameters and/or unrecognized optional parameters could also mandate = that this flag be used. =20 > * Why do you need the 'T' flag? I don't think that the concept is=20 > actually useful. >=20 > In Section 4.5.3 you write: >=20 > 4.5.3 QSPEC Tunneled Parameter T-Flag >=20 > Each QSPEC parameter has an associated=20 > 'tunneled-parameter T-flag'. > When a RESERVE message is tunneled through a domain, QNEs=20 > inside the > domain cannot update read-write parameters. >=20 > [hannes] QNEs MUST NOT update the parameters. That's the idea=20 > of tunneling. >=20 > The egress QNE in a > domain has two choices: either a) it is configured to have the > knowledge to update the parameters correctly, >=20 > [hannes] What type of update are you looking for? > The reservation within the tunneled region is a separate and=20 > independent=20 > reservation. Not sure what you mean by "separate and independent reservation". We're = talking about an end-to-end reservation where one domain may tunnel the = Initiator QSPEC through the domain. With respect to the 'update', it = refers to the egress QNE in the domain updating a mandatory or optional = QSPEC parameter in the Initiator QSPEC. E.g., if the = parameter (a mandatory QSPEC parameter) is specified in the object in the Initiator QSPEC, and the Initiator QSPEC is = tunneled through a domain, the egress QNE in the domain may be = configured to update this parameter. If it cannot update this = parameter, then it needs to set the T-Flag to so indicate. =20 > or b) it cannot update > the parameters. In the latter case it MUST set the > tunneled-parameter T-flag to tell the QNI (or QNR) that the > information contained in the read-write parameter is most likely > incorrect (or a lower bound). >=20 > [hannes] Which parameters are incorrect? If in the above example, the egress QNE in the domain is unable to = update in the object, it must then set the = T-flag for the parameter. > The T-flag is interpreted by the QNI, > ingress QNE (start of tunnel in a domain), egress QNE=20 > (end of tunnel > in a domain), or QNR. >=20 > [hannes] There are now three 'T' bits flying around in=20 > related documents: >=20 > * T-bit set (RESERVE tear): QoS NSLP > * T-bit in the NSIS Tunnel ID > * T-bit in the QSPEC draft >=20 > Neither the QoS NSLP nor the NSIS Tunnel ID does, to my=20 > knowledge, not=20 > use the T-bit of the QSPEC document. The T-bit in the QSPEC draft is strictly for use by the RMF in QoS = processing, so I think its use is restricted to implementation of the = NSLP/QSPEC/RMF procedures. However, you raise a good point about 3 = different definitions for 'T-bit', and we need to be sure there is no = confusion resulting from this. =20 > * Why do you need to put error specific flag in every object=20 > (namely 'E=20 > and N flag)? Errors should be the exception rather than the norm. I=20 > would do something different, namely to put an error object=20 > with a list=20 > of the Parameter IDs in it. The use of E-Flag is definitely the exception rather than the norm. IMO = the approach defined in Section 4.5.1 is a reasonable approach, that is, = to flag an error according to a specific QSPEC parameter, if possible. = However, as stated in Section 4.5.1, in some error situations it may not = be possible to set the E-Flag for a QSPEC parameter, although it may be = possible to still set the E-Flag for the QSPEC object. The INFO_SPEC in = this case does carry the QSPEC with the erroneous parameters flagged = within it. The alternative you suggest I think is similar to this = approach (this approach agreed to after a very lengthy discussion on = error codes). =20 > Regarding the parameter encoding: >=20 > You might want to change the description with regard to the=20 > Parameter ID=20 > field. Change from: >=20 > " > 7.2.1 Parameter >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|E|0|T| 0 |r|r|r|r| 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NON QOSM Hop | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > " >=20 > to: >=20 > " > 7.2.1 Parameter >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|E|0|T|00000000000000000000000|r|r|r|r| 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NON QOSM Hop | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > " >=20 > or: > " > 7.2.1 Parameter >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|E|0|T| Parameter ID |r|r|r|r| Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NON QOSM Hop | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Parameter ID: 0 >=20 > Length: 1 >=20 > " >=20 > The Parameter ID is 12 bits long. Is it also encoded in network byte=20 > order? The same is true for the Length field. >=20 > The draft only says that > "Network byte order ('big-endian') for all 16- and 32-bit integers, as > well as 32-bit floating point numbers, are as specified=20 > in [RFC1832, > IEEE754, NETWORK-BYTE-ORDER]. > " I'm not sure I get the point you're making here. For the = case, however, perhaps this flag should be coded as a QSPEC object flag = and not a 32-bit parameter, as suggested in the previous message. Thanks, Jerry =20 > Ciao > Hannes=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 02 20:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxByS-0005nt-O4; Sun, 02 Jul 2006 20:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxByR-0005no-1h for nsis@ietf.org; Sun, 02 Jul 2006 20:07:35 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxByP-0007Id-O4 for nsis@ietf.org; Sun, 02 Jul 2006 20:07:35 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1151885252!11256177!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 17628 invoked from network); 3 Jul 2006 00:07:32 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-2.tower-120.messagelabs.com with SMTP; 3 Jul 2006 00:07:32 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452000E1B56; Sun, 2 Jul 2006 20:07:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: References Date: Sun, 2 Jul 2006 19:07:30 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A6B@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44A79B63.60400@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: References Thread-Index: Acadv7DOw/l3EgUcSbC7ZeXWO4oAGAAbWzJg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" , "NSIS" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, See below.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Sunday, July 02, 2006 6:10 AM > To: NSIS > Subject: [NSIS] QSPEC Comment: References >=20 > Hi QSPEC authors, >=20 > I noticed that the reference section is at some places: >=20 > * incomplete >=20 > Example: >=20 > [RMD-QOSM] Bader, A., et. al., " RMD-QOSM: An NSIS QoS Signaling > Policy Model for Networks > Using Resource Management in DiffServ (RMD)," work in progress. >=20 >=20 > Maybe this points to the RMD draft but I am not sure given that the=20 > draft name in -07 is: > " > RMD-QOSM - The Resource Management in Diffserv QOS Model > " OK. > * wrong >=20 > [SIP-PRIORITY] Schulzrinne, H., Polk, J., "Communications Resource > Priority for the Session Initiation Protocol(SIP)." work in > progress. >=20 > * not correct >=20 > See my mail regarding the placement of some references from the=20 > informative to the normative section. OK. =20 > Another example: >=20 > [RFC2205] is certainly does not belong to the normative=20 > reference section. Unclear. Several other RSVP documents belong in the Normative = references, according to your correct suggestion that documents = specifying QSPEC parameter behaviors belong in the Normative References = Section. Thanks, Jerry =20 > Ciao > Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 02:34:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxI1A-00041t-4W; Mon, 03 Jul 2006 02:34:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxI18-00041o-Jn for nsis@ietf.org; Mon, 03 Jul 2006 02:34:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxI17-00028l-OO for nsis@ietf.org; Mon, 03 Jul 2006 02:34:46 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EDA6C500002; Mon, 3 Jul 2006 08:34:44 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 08:34:44 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 08:34:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] draft-qosmodel-controlledload-04 Date: Mon, 3 Jul 2006 08:34:43 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D055DFE5A@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] draft-qosmodel-controlledload-04 Thread-Index: AcadTCSQaK2+FYxeTOKT8C7fEy+i/gBHHa3g From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Hannes Tschofenig" X-OriginalArrivalTime: 03 Jul 2006 06:34:43.0923 (UTC) FILETIME=[C5395A30:01C69E6A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, see below, Attila > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, July 01, 2006 10:23 PM > To: Hannes Tschofenig > Cc: Attila B=E1der (IJ/ETH); nsis@ietf.org > Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >=20 >=20 > Hi all, >=20 > I should have read the latest QSPEC draft version before I sent this=20 > mail. The most recent draft talks about this aspect and it says in=20 > Section 4.7: > " > A QOSM specification MUST define how the mandatory parameters are to > be mapped onto the QSPEC parameters used by the QOSM, however the > mapping MAY result in slight modification to the intended > specification when an exact mapping is not possible. > " >=20 > Attila, you did this for the token bucket parameter and=20 > described that=20 > it can be mapped to the bandwith parameter. >=20 > Now, the only question remains whether a QOSM also have to define a=20 > mapping for all mandatory parameters. This would address the case=20 > mentioned below: The QOSM does not make use of all mandatory=20 > parameters=20 > listed in the QSPEC. >=20 When the QSpec is translated to a local QSpec, I think the relevant = mandatory parameters has to be mapped and this mapping should be defined = in QOSM. Parameters which are not relevant in a QoS domain can be = ignored.=20 The main question is how to fill in mandatory parameters for another = QOSM if it is not appliceble in the local QOSM. This should be defined = in a QOSM. In case of RMD it is not a problem: RMD QOSM is used as a local domain, = and the original parameters are always handed over to the Egress edge, = so all necessary info is available there. > Ciao > Hannes >=20 >=20 > Hannes Tschofenig wrote: > > Hi Attila, > >=20 > > Attila B=E1der (IJ/ETH) wrote: > >=20 > >> Hi Bernd, This is the case in RMD as well. In RMD domain resource > >> reservation is based on one parameter: Bandwidth. If, for example, > >> the resource request arriving to the Edge is a token bucket, it > >> should be translated to a single Bandwidth parameter. This may be a > >> peak value, or an effective value. > >=20 > >=20 > > I guess Bernd's question was focusing on a different aspect. What=20 > > happens if you receive a request that contains the=20 > parameter 'Y.1541 QoS=20 > > Class with the value set for Class 0? > >=20 > > Ciao > > Hannes > >=20 > >=20 > >> > >> Best regards, Attila > >> > >> > >>> -----Original Message----- From: Bernd Schloer > >>> [mailto:bschloer@cs.uni-goettingen.de] Sent: Thursday, June 29, > >>> 2006 3:01 PM To: nsis@ietf.org Subject: [NSIS] > >>> draft-qosmodel-controlledload-04 > >>> > >>> > >>> Hi, > >>> > >>> the first open issue in the appendix B is about what to do with > >>> mandatory QSPEC parameters which are not needed for CLS. > >>> > >>> Does a QOSM have to understand (and provide information about) all > >>> mandatory parameters, even if they are not used? The QSPEC-draft > >>> says in section 5 that all parameters listed in the next sections > >>> are mandatory. The QSPEC-draft also says in section 4.1 that "a > >>> given QOSM defines which of the mandatory and optional parameters > >>> it uses, ..." > >>> > >>> Are there any specific parameters which makes the open=20 > issue B.1.1. > >>> clearer? Following the QSPEC-draft there doesn't seem to be a=20 > >>> conflict, if nothing is done with the unneeded parameters. > >>> > >>> Thanks, Bernd > >>> > >>> > >>> > >>> _______________________________________________ nsis mailing list=20 > >>> nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > >>> > >> > >> > >> _______________________________________________ nsis mailing list=20 > >> nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 03:57:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJIj-0003nH-90; Mon, 03 Jul 2006 03:57:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJIh-0003n7-GR for nsis@ietf.org; Mon, 03 Jul 2006 03:56:59 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxJIf-0001x4-NM for nsis@ietf.org; Mon, 03 Jul 2006 03:56:59 -0400 Received: (qmail invoked by alias); 03 Jul 2006 07:56:56 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp042) with SMTP; 03 Jul 2006 09:56:56 +0200 X-Authenticated: #29516787 Message-ID: <44A8CDC6.3030007@gmx.net> Date: Mon, 03 Jul 2006 09:56:54 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] QSPEC Comment: IANA Consideration Section References: <9473683187ADC049A855ED2DA739ABCA0DDC7A67@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7A67@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: f0ea5880a0890be2408609376fa519aa Cc: =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, thanks for your quick feedback. Please find my comment below: Ash, Gerald R (Jerry), ALABS wrote: > Hi Hannes, > > See below. > > >> -----Original Message----- From: Hannes Tschofenig >> [mailto:Hannes.Tschofenig@gmx.net] Sent: Sunday, July 02, 2006 6:01 >> AM To: NSIS Subject: [NSIS] QSPEC Comment: IANA Consideration >> Section >> >> Hi QSPEC authors, >> >> let me comment on the IANA consideration section. >> >> >> This specification allocates the following codepoints in existing >> registries: >> >> PHB Class Parameter [RFC3140] (Section 7.2.6.1) >> >> The registries needed to use RFC 3140 already exist [DSCP-REGISTRY, >> PHBID-CODES-REGISTRY]. >> >> [hannes] Delete it from the IANA consideration section since you >> don't request IANA todo anything. > > > OK. > > >> This specification creates the following registries with the >> structures as defined below: >> >> Object Types (12 bits): The following values are allocated by this >> specification: 0-4: assigned as specified in Section 7. The >> allocation policies for further values are as follows: 5-63: >> Standards Action 64-127: Private/Experimental Use 128-4095: >> Reserved >> >> [hannes] Don't let IANA search through the document. Provide them >> the values: >> >> Object Type = 0: control information = 1: QoS Desired = 2: QoS >> Available = 3: QoS Reserved = 4: Minimum QoS > > > OK. > > >> [hannes] What does 'reserved' mean? The Object Type has 12 bits and >> according to Section 7 all of them are used. > > > I'm not sure of your question, Section 9 says: > > Object Types (12 bits): The following values are allocated by this > specification: 0-4: assigned as specified in Section 7. The > allocation policies for further values are as follows: 5-63: > Standards Action 64-127: Private/Experimental Use 128-4095: Reserved > > This is how the 12 bits are used in the registry. Perhaps your > question pertains to the "Reserved" above? The packet format looks as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|E|r|r| Object Type |r|r|r|r| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Object Type has 12 bytes but in the IANA consideration section you define more bytes as reserved. This means: A few bytes are reserved in the Object Type and then followed by a few bytes that are reserved. The meaning of the two reserved is different: The 'r's from the above figure indicate padding and the other reserved mean for undefined future use. Then, there are the 'r's at the beginning of the object that mean 'will be specified if you add something to the registry'. Sounds confusing to me. Here the specified range > designated as 'reserved' is a normal use of allocated space in a > registry that is reserved for future definition by a specification. > Future specifications can redefine the registry allocations, and > allocate more space to various designations, as necessary (e.g., more > space allocated to "Standards Action" or to "Private/Experimental > Use", etc.). I am not so sure that this is common and useful practice. The IANA consideration section already indicates that a fraction of the namespace requires standards track actions. > > >> QSPEC Version (4 bits): The following value is allocated by this >> specification: 0: assigned to Version 0 QSPEC The allocation >> policies for further values are as follows: 1-15: Standards Action >> >> [hannes] You might want to say something about the allocation >> registry: >> >> * Is it allow to depreciate versions? * Is it allowed to delete >> versions? * Is it allowed to modify versions? > > > No, no, and no, not without another specification doing that. You need to tell IANA this fact. IANA is not going to read through your draft. They look at the IANA consideration section and create a registry with a specific policy. > > >> QOSM ID (12 bits): The allocation policies are as follows: 0-63: >> Specification Required 64-127: Private/Experimental Use 128-4095: >> Reserved >> >> [hannes] What does 'reserved' mean? > > > See above for explanation of use of 'reserved' fields in registries. Again, I think that this is not a particularly good use. IANA wouldn't know what todo with it. > > >> Note that QOSM ID assignments are normally requested in QOSM >> specification documents. >> >> [hannes] Delete this sentence. > > > Why? I think it just explains why there are no QOSM ID assignments > in this document, and where QOSM ID requests will be found in the > future. IANA does not need these types of notes. > > >> * Is it allow to depreciate QOSM IDs? * Is it allowed to delete >> QOSM IDs? * Is it allowed to modify QOSM IDs? > > > No, no, and no. Not without a specification that does that. But are specifications allowed todo it. YOU need to specify the policy. How should IANA know it? > > >> QSPEC Procedure (8 bits): Broken down into Message Sequence (4 >> bits): The following values are allocated by this specification: >> 0-2: assigned as specified in Section 7.1 The allocation policies >> for further values are as follows: 3-15: Standards Action Object >> Combination: The following values are allocated by this >> specification: 0-2: assigned as specified in tables in Section >> 6.1.1 --> 6.1.3 >> >> The allocation policies for further values are as follows: 3-15: >> Standards Action >> >> [hannes] I suspect that this be a bit confusing for IANA. >> >> You want to create a registry and fill it with values according to: >> >> >> 0: Sender-Initiated Reservations, as defined in Section 6.1.1 1: >> Receiver-Initiated Reservations, as defined in Section 6.1.2 2: >> Resource Queries, as defined in Section 6.1.3 What about telling IANA the following: You need a Value, a token and the semantic associated with it for this registry. This document creates three values, namely: Value: (0) Token: Sender-Initiated Reservations Semantic: See Section 6.1.1 1: Value: (1) Token: Receiver-Initiated Reservations Semantic: See Section 6.1.2 Value: (2) Token: Resource Queries Semantic: See Section 6.1.3 Then, you tell IANA that the policies for defining new values in the namespace.... Then, you tell them that new entires need to define a token and a semantic for the token. Maybe you want to let them know whether it is possible to replace or delete entries in the registry (with a specification, obviously). >> >> [hannes] and then a second registry that should be contained in >> Section 6.1.1 and 6.1.3. These sections do not exist. > > > OK, will fix. > > >> Error Code (16 bits) The following values are allocated by this >> specification: 1-3: assigned as specified in Section 4.5.1 >> >> [hannes] Section 4.5.1 does not define error codes! > > > Yes, you're right. This didn't get updated after all the discussion > on error codes. Will do. > > >> The allocation policies for further values are as follows: 4-127: >> Specification Required (e.g., QOSM specification document) >> >> [hannes] Delete the example. > > > Why, it's just an example? Think as an IANA person. They just want to know their info and not any examples. It does not tell them anything. > > >> 128-255: Private/Experimental Use 255-65535: Reserved Parameter ID >> (12 bits): The following values are allocated by this >> specification: 0-18: assigned as specified in Sections 7.2.1 --> >> 7.2.12. >> >> [hannes] List the values here. > > > OK. > > >> The allocation policies for further values are as follows: 19-63: >> Standards Action (for mandatory parameters) 64-127: Specification >> Required (for optional parameters) 128-255: Private/Experimental >> Use 255-4095: Reserved >> >> [hannes] Again, what does 'reserved' mean? > > > Again, see above explanation of 'reserved'. > > >> Note that if additional mandatory parameters are defined in the >> future, this requires a standards action equivalent to reissuing >> this document as a QSPEC-bis. >> >> Excess Treatment Parameter (8 bits): The following values are >> allocated by this specification: 0-3: assigned as specified in >> Section 7.2.2 The allocation policies for further values are as >> follows: 4-63: Standards Action 64-255: Reserved >> >> Y.1541 QoS Class Parameter (12 bits): The following values are >> allocated by this specification: 0-7: assigned as specified in >> Section 7.2.6.2 The allocation policies for further values are as >> follows: 8-63: Standards Action 64-4095: Reserved >> >> DSTE Class Type Parameter (12 bits): The following values are >> allocated by this specification: 0-7: assigned as specified in >> Section 7.2.6.3 The allocation policies for further values are as >> follows: 8-63: Standards Action 64-4095: Reserved >> >> Admission Priority Parameter (8 bits): The following values are >> allocated by this specification: 0-2: assigned as specified in >> Section 7.2.6.2 >> >> [hannes] Wrong reference: You have to point to Section 7.2.7.2 > > > OK. > > >> The allocation policies for further values are as follows: 3-63: >> Standards Action 64-255: Reserved >> >> RPH Namespace Parameter (16 bits): The following values are >> allocated by this specification: 0-5: assigned as specified in >> Section 7.2.7.2 >> >> [hannes] Wrong reference: You have to point to Section 7.2.7.3 > > > OK. > > >> See, however, my comment regarding the entire section below: >> >> The allocation policies for further values are as follows: 6-63: >> Standards Action 64-65535: Reserved >> >> RPH Priority Parameter (8 bits): dsn namespace: The following >> values are allocated by this specification: 0-4: assigned as >> specified in Section 7.2.7.2 The allocation policies for further >> values are as follows: 5-63: Standards Action 64-255: Reserved drsn >> namespace: The following values are allocated by this >> specification: 0-5: assigned as specified in Section 7.2.7.2 The >> allocation policies for further values are as follows: 6-63: >> Standards Action 64-255: Reserved Q735 namespace: The following >> values are allocated by this specification: 0-4: assigned as >> specified in Section 7.2.7.2 The allocation policies for further >> values are as follows: 5-63: Standards Action 64-255: Reserved ets >> namespace: The following values are allocated by this >> specification: 0-4: assigned as specified in Section 7.2.7.2 The >> allocation policies for further values are as follows: 5-63: >> Standards Action 64-255: Reserved wts namespace: The following >> values are allocated by this specification: 0-4: assigned as >> specified in Section 7.2.7.2 The allocation policies for further >> values are as follows: 5-63: Standards Action 64-255: Reserved >> >> [hannes] The reference in the draft to [SIP-PRIORITY]. >> [SIP-PRIORITY] is an RFC in the meanwhile: >> http://www.rfc-editor.org/rfc/rfc4412.txt > > > OK. > > >> RFC 4412 creates a registry for these values already. See Section >> 12.6 of RFC 4412. Why do you need to create another one with the >> same values? > > > Good point. I think this is necessary because the assigned values > are being mapped to QSPEC parameter values. However, I think that > this aspect needs to be pointed out to IANA. Why cannot you use the values directly? Ciao Hannes > > Thanks, Jerry > > >> Ciao Hannes > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 04:10:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJW9-0002KM-Hv; Mon, 03 Jul 2006 04:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJW8-0002Ik-6Y for nsis@ietf.org; Mon, 03 Jul 2006 04:10:52 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxJW6-0002ub-PT for nsis@ietf.org; Mon, 03 Jul 2006 04:10:52 -0400 Received: (qmail invoked by alias); 03 Jul 2006 08:04:10 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp037) with SMTP; 03 Jul 2006 10:04:10 +0200 X-Authenticated: #29516787 Message-ID: <44A8CF7C.7070103@gmx.net> Date: Mon, 03 Jul 2006 10:04:12 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] QSPEC Comment: Normative References References: <9473683187ADC049A855ED2DA739ABCA0DDC7A69@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7A69@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Thanks. I have no further comment on this aspect. Ciao Hannes Ash, Gerald R (Jerry), ALABS wrote: > Hi Hannes, > > See below. > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Sunday, July 02, 2006 4:47 AM >>To: NSIS >>Subject: [NSIS] QSPEC Comment: Normative References >> >>Hi QSPEC authors, >> >>the QSPEC draft lists a number of mandatory attributes. Since >>mandatory >>attributes are, although not explicit in the draft, mandatory to >>implement for every QNE it is necessary to have all >>references related >>to mandatory attributes in the normative reference section. > > > OK, I agree. > > >>Are all the referenced documents publicly available? > > > Yes. > > Thanks, > Jerry > > >>Ciao >>Hannes > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 04:12:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJXN-00048q-91; Mon, 03 Jul 2006 04:12:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJXL-0003ws-2g for nsis@ietf.org; Mon, 03 Jul 2006 04:12:07 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxJXJ-0002x1-K6 for nsis@ietf.org; Mon, 03 Jul 2006 04:12:07 -0400 Received: (qmail invoked by alias); 03 Jul 2006 08:05:23 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp006) with SMTP; 03 Jul 2006 10:05:23 +0200 X-Authenticated: #29516787 Message-ID: <44A8CFC5.7010802@gmx.net> Date: Mon, 03 Jul 2006 10:05:25 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] QSPEC Comment: Mandatory Attribute List References: <9473683187ADC049A855ED2DA739ABCA0DDC7A68@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7A68@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, please find my comments below: Ash, Gerald R (Jerry), ALABS wrote: > Hi Hannes, > > See below. > > >> -----Original Message----- From: Hannes Tschofenig >> [mailto:Hannes.Tschofenig@gmx.net] Sent: Sunday, July 02, 2006 6:25 >> AM To: NSIS Subject: [NSIS] QSPEC Comment: Mandatory Attribute List >> >> >> Hi QSPEC authors, >> >> Section 7.2 of the QSPEC template draft lists a number of mandatory >> attributes: >> >> * NON QOSM Hop * Excess Treatment * Bandwidth * Token Bucket * PHB >> Class * Y.1541 QoS Class * DSTE Class Type * >> & * Admission Priority * RPH Priority >> >> A few comments: >> >> - The DSTE Class Type' parameter points to a requirements document >> with respect to its functional specification (see RFC3564). Maybe >> you placed the wrong reference in here. > > > OK. A better reference would be RFC 4124 http://www.ietf.org/rfc/rfc4124.txt?number=4124, the DSTE protocol extensions specification. > > >> - I would be more relaxed to see a review of the RFC 4412 authors >> (James Polk and Henning Schulzrinne) when it comes to the usage of >> the RPH Priority parameters (defined for SIP) in the QSPEC template >> draft. > > > As GIST co-author, Henning at least probably monitors this list. In > addition, there was a suggested that we might want to send the last > call on QoS-NSLP and QSPEC to TSVWG as well. > Maybe you want to point the respective person explicitly to this aspect. Henning and the TSVWG list is busy with many other things.... > >> - I am not sure why the Y.1541 QoS Class parameter is a mandatory >> object. > > > Actually the mandatory parameter is . As discussed in > Section 7.2.6, consists of the , Class>, or parameter. These are 3 different ways > to specify , and it is expected that at most one is > populated. This can be clarified. Hmmm. How should this work. QoS Class is just a container. Is it necessary for a QNE to understand the , the , and the parameter to realize the concept of a mandatory attribute? I don't see how it could work if you indicate that the QoS class parameter is a mandatory attribute but the individual child elements are not all mandatory... > > >> - The Admission Priority parameter points to a non-IETF in the >> informative reference section. > > > It should be in the Normative References section, per your previous > comment. Also, it is OK that this is not an RFC, if that is your > point. I checked this out with IANA, normative references that are > not RFCs (e.g., Standards from other SDO's) are certainly permissible > as normative references. I know that it does not necessarily needs to be an RFC but it might raise some eyebrows particularly if everyone has to implement it. I recall the difficult discussions in the context of MLPP with the different priority levels.... Then, there is also the IPR question. Are you aware of any IPR related to this document (and hence to the documents referenced by it)? > > >> - The NON QOSM Hop parameter does not seem to be a QoS parameter at >> all that belongs to this category. I would rather see it as an >> error message. > > > I think it should be a flag, along with the E-Flag for QSPEC objects > specified in Section 7.1, as I suggested in a previous response to > one of your comments. Fine. Ciao Hannes > > Thanks, Jerry > > >> Ciao Hannes > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 04:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJfF-00036V-H1; Mon, 03 Jul 2006 04:20:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJfE-00032Z-Er for nsis@ietf.org; Mon, 03 Jul 2006 04:20:16 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxJfD-0003C6-Po for nsis@ietf.org; Mon, 03 Jul 2006 04:20:16 -0400 Received: (qmail invoked by alias); 03 Jul 2006 08:20:14 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp019) with SMTP; 03 Jul 2006 10:20:14 +0200 X-Authenticated: #29516787 Message-ID: <44A8D33D.7020803@gmx.net> Date: Mon, 03 Jul 2006 10:20:13 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] QSPEC Comment: QSPEC QoS Object Header References: <9473683187ADC049A855ED2DA739ABCA0DDC7A6A@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7A6A@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, please find my response below: Ash, Gerald R (Jerry), ALABS wrote: > Hi Hannes, > > See below. > > >> -----Original Message----- From: Hannes Tschofenig >> [mailto:Hannes.Tschofenig@gmx.net] Sent: Sunday, July 02, 2006 4:47 >> AM To: NSIS Subject: [NSIS] QSPEC Comment: QSPEC QoS Object Header >> >> Hi QSPEC authors, >> >> I tried to figure out whether the QSPEC template draft could be >> used for the AAA work. The QSPEC QoS object header raised a few >> questions: >> >> * Why do you need a length field if all the objects just have a >> fixed length? > > > The length of various QSPEC parameters is not fixed. E.g., compare > Section 7.2.5 (length=5) to Section 7.2.3 > (length=1). No, I meant that the Parameter ID would immediately tell you the length of the respective attribute. For every object the length of the object cannot be variable. > >> * Why do you need an 'M' bit? Whether a parameter is mandatory or >> not can easily derived from the Parameter ID. > > > We were advised that the M flag should be specified for easier QSPEC > processing. I don't see the big advantage. Instead of looking at the flag and then processing the Parameter ID I would have to look at the Parameter ID and then see immediately whether it is a mandatory attribute or not. In addition, new QSPEC versions specifying new mandatory > parameters and/or unrecognized optional parameters could also mandate > that this flag be used. The current text in the draft does not provide a solid story about the QSPEC version updates. It says " Additional mandatory parameters may be defined in the future. However, since this requires an update of all QNEs, this should be considered carefully. " If this is the requirement then it can never happen that a QNE sees a mandatory parameter that it does not understand. > > >> * Why do you need the 'T' flag? I don't think that the concept is >> actually useful. >> >> In Section 4.5.3 you write: >> >> 4.5.3 QSPEC Tunneled Parameter T-Flag >> >> Each QSPEC parameter has an associated 'tunneled-parameter T-flag'. >> When a RESERVE message is tunneled through a domain, QNEs inside >> the domain cannot update read-write parameters. >> >> [hannes] QNEs MUST NOT update the parameters. That's the idea of >> tunneling. >> >> The egress QNE in a domain has two choices: either a) it is >> configured to have the knowledge to update the parameters >> correctly, >> >> [hannes] What type of update are you looking for? The reservation >> within the tunneled region is a separate and independent >> reservation. > > > Not sure what you mean by "separate and independent reservation". See Section 4.6 of http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt and http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-00.txt Figure 12 in ection 4.6 of http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt is particularly nice since it shows that the RESERVE'/RESPONSE' within the domain are independent of the E2E RESERVE/RESPONSE. > We're talking about an end-to-end reservation where one domain may > tunnel the Initiator QSPEC through the domain. With respect to the > 'update', it refers to the egress QNE in the domain updating a > mandatory or optional QSPEC parameter in the Initiator QSPEC. E.g., > if the parameter (a mandatory QSPEC parameter) is > specified in the object in the Initiator QSPEC, and > the Initiator QSPEC is tunneled through a domain, the egress QNE in > the domain may be configured to update this parameter. Why would it want to update the parameter? If it cannot > update this parameter, then it needs to set the T-Flag to so > indicate. If he wants to update the parameter why would there be a problem with it? > > >> or b) it cannot update the parameters. In the latter case it MUST >> set the tunneled-parameter T-flag to tell the QNI (or QNR) that the >> information contained in the read-write parameter is most likely >> incorrect (or a lower bound). >> >> [hannes] Which parameters are incorrect? > > > If in the above example, the egress QNE in the domain is unable to > update in the object, it must then set > the T-flag for the parameter. > > >> The T-flag is interpreted by the QNI, ingress QNE (start of tunnel >> in a domain), egress QNE (end of tunnel in a domain), or QNR. >> >> [hannes] There are now three 'T' bits flying around in related >> documents: >> >> * T-bit set (RESERVE tear): QoS NSLP * T-bit in the NSIS Tunnel ID >> * T-bit in the QSPEC draft >> >> Neither the QoS NSLP nor the NSIS Tunnel ID does, to my knowledge, >> not use the T-bit of the QSPEC document. > > > The T-bit in the QSPEC draft is strictly for use by the RMF in QoS > processing, so I think its use is restricted to implementation of the > NSLP/QSPEC/RMF procedures. However, you raise a good point about 3 > different definitions for 'T-bit', and we need to be sure there is no > confusion resulting from this. > Why does the RMF need this info? > >> * Why do you need to put error specific flag in every object >> (namely 'E and N flag)? Errors should be the exception rather than >> the norm. I would do something different, namely to put an error >> object with a list of the Parameter IDs in it. > > > The use of E-Flag is definitely the exception rather than the norm. > IMO the approach defined in Section 4.5.1 is a reasonable approach, > that is, to flag an error according to a specific QSPEC parameter, if > possible. However, as stated in Section 4.5.1, in some error > situations it may not be possible to set the E-Flag for a QSPEC > parameter, although it may be possible to still set the E-Flag for > the QSPEC object. The INFO_SPEC in this case does carry the QSPEC > with the erroneous parameters flagged within it. The alternative you > suggest I think is similar to this approach (this approach agreed to > after a very lengthy discussion on error codes). > So, what you are going todo? > >> Regarding the parameter encoding: >> >> You might want to change the description with regard to the >> Parameter ID field. Change from: >> >> " 7.2.1 Parameter >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1|E|0|T| 0 |r|r|r|r| 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> NON QOSM Hop | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " >> >> >> to: >> >> " 7.2.1 Parameter >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1|E|0|T|00000000000000000000000|r|r|r|r| 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> NON QOSM Hop | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " >> >> >> or: " 7.2.1 Parameter >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1|E|0|T| Parameter ID |r|r|r|r| Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> NON QOSM Hop | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Parameter ID: 0 >> >> Length: 1 >> >> " >> >> The Parameter ID is 12 bits long. Is it also encoded in network >> byte order? The same is true for the Length field. >> >> The draft only says that "Network byte order ('big-endian') for all >> 16- and 32-bit integers, as well as 32-bit floating point numbers, >> are as specified in [RFC1832, IEEE754, NETWORK-BYTE-ORDER]. " > > > I'm not sure I get the point you're making here. The point is: What is the encoding of the parameters. The text and the figure does not provide enough details to figure it out. For the HOP> case, however, perhaps this flag should be coded as a QSPEC > object flag and not a 32-bit parameter, as suggested in the previous > message. Ciao Hannes > > Thanks, Jerry > > >> Ciao Hannes > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 04:22:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJhO-000874-QM; Mon, 03 Jul 2006 04:22:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJhN-00086z-Fm for nsis@ietf.org; Mon, 03 Jul 2006 04:22:29 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxJhM-0003G6-3D for nsis@ietf.org; Mon, 03 Jul 2006 04:22:29 -0400 Received: (qmail invoked by alias); 03 Jul 2006 08:22:27 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp029) with SMTP; 03 Jul 2006 10:22:27 +0200 X-Authenticated: #29516787 Message-ID: <44A8D3C5.80100@gmx.net> Date: Mon, 03 Jul 2006 10:22:29 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] QSPEC Comment: References References: <9473683187ADC049A855ED2DA739ABCA0DDC7A6B@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7A6B@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, please find a comment below: Ash, Gerald R (Jerry), ALABS wrote: > Hi Hannes, > > See below. > > >> -----Original Message----- From: Hannes Tschofenig >> [mailto:Hannes.Tschofenig@gmx.net] Sent: Sunday, July 02, 2006 6:10 >> AM To: NSIS Subject: [NSIS] QSPEC Comment: References >> >> Hi QSPEC authors, >> >> I noticed that the reference section is at some places: >> >> * incomplete >> >> Example: >> >> [RMD-QOSM] Bader, A., et. al., " RMD-QOSM: An NSIS QoS Signaling >> Policy Model for Networks Using Resource Management in DiffServ >> (RMD)," work in progress. >> >> >> Maybe this points to the RMD draft but I am not sure given that the >> draft name in -07 is: " RMD-QOSM - The Resource Management in >> Diffserv QOS Model " > > > OK. > > >> * wrong >> >> [SIP-PRIORITY] Schulzrinne, H., Polk, J., "Communications Resource >> Priority for the Session Initiation Protocol(SIP)." work in >> progress. >> >> * not correct >> >> See my mail regarding the placement of some references from the >> informative to the normative section. > > > OK. > > >> Another example: >> >> [RFC2205] is certainly does not belong to the normative reference >> section. > > > Unclear. Several other RSVP documents belong in the Normative > references, according to your correct suggestion that documents > specifying QSPEC parameter behaviors belong in the Normative > References Section. RFC 2205 is only referenced here: 2. Introduction The QoS NSIS signaling layer protocol (NSLP) [QoS-SIG] establishes and maintains state at nodes along the path of a data flow for the purpose of providing forwarding resources (QoS) for that flow. The design of QoS NSLP is conceptually similar to RSVP [RFC2205], and meets the requirements of [RFC3726]. This looks like an informative reference to me. Ciao Hannes > > Thanks, Jerry > > >> Ciao Hannes > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 04:27:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJlt-0008PN-4G; Mon, 03 Jul 2006 04:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJlr-0008PI-Jc for nsis@ietf.org; Mon, 03 Jul 2006 04:27:07 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxJlq-0003O6-RG for nsis@ietf.org; Mon, 03 Jul 2006 04:27:07 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k638QsiW010173; Mon, 3 Jul 2006 09:26:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: QSPEC QoS Object Header Date: Mon, 3 Jul 2006 09:27:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: QSPEC QoS Object Header Thread-Index: Acaeebc8oSVYKs1bQSyNcMLjyNkNhQAACgTA From: "Hancock, Robert" To: "Hannes Tschofenig" , "Ash, Gerald R \(Jerry\), ALABS" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: Kappler Cornelia , NSIS , =?iso-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, just a comment on length fields and M-bits: > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 03 July 2006 09:20 > To: Ash, Gerald R (Jerry), ALABS > Cc: "Attila B=E1der (IJ/ETH)"; NSIS; Kappler Cornelia > Subject: Re: [NSIS] QSPEC Comment: QSPEC QoS Object Header >=20 >=20 > Hi Jerry, >=20 > please find my response below: >=20 > Ash, Gerald R (Jerry), ALABS wrote: > > Hi Hannes, > >=20 > > See below. > >=20 > >=20 > >> -----Original Message----- From: Hannes Tschofenig > >> [mailto:Hannes.Tschofenig@gmx.net] Sent: Sunday, July 02, 2006 4:47 > >> AM To: NSIS Subject: [NSIS] QSPEC Comment: QSPEC QoS Object Header > >>=20 > >> Hi QSPEC authors, > >>=20 > >> I tried to figure out whether the QSPEC template draft could be > >> used for the AAA work. The QSPEC QoS object header raised a few > >> questions: > >>=20 > >> * Why do you need a length field if all the objects just have a > >> fixed length? > >=20 > >=20 > > The length of various QSPEC parameters is not fixed. E.g., compare > > Section 7.2.5 (length=3D5) to Section 7.2.3 = > > (length=3D1). >=20 >=20 > No, I meant that the Parameter ID would immediately tell you=20 > the length=20 > of the respective attribute. >=20 > For every object the length of the object cannot be variable. what if the parameter ID is a new one unknown at the receiver of the message (e.g. for an optional object)? you may still want to parse the rest of the message, and you need to know what to skip over. >=20 > >=20 > >> * Why do you need an 'M' bit? Whether a parameter is mandatory or > >> not can easily derived from the Parameter ID. > >=20 > >=20 > > We were advised that the M flag should be specified for easier QSPEC > > processing. >=20 > I don't see the big advantage. Instead of looking at the flag=20 > and then=20 > processing the Parameter ID I would have to look at the=20 > Parameter ID and=20 > then see immediately whether it is a mandatory attribute or not. same comment on unknown IDs; and see below. >=20 >=20 > In addition, new QSPEC versions specifying new mandatory > > parameters and/or unrecognized optional parameters could=20 > also mandate > > that this flag be used. >=20 > The current text in the draft does not provide a solid story=20 > about the=20 > QSPEC version updates. It says > " > Additional mandatory parameters may be defined in the future. > However, since this requires an update of all QNEs, this should be > considered carefully. > " >=20 > If this is the requirement then it can never happen that a QNE sees a=20 > mandatory parameter that it does not understand. i think this is a pointer that a tradeoff needs to be made. if you decide to use a new mandatory parameter, then be aware that error messages may come back that it is not understood. it should still be possible to define new mandatory parameters, but it just has to be done with care and caution. robert h. >=20 >=20 > >=20 > >=20 > >> * Why do you need the 'T' flag? I don't think that the concept is=20 > >> actually useful. > >>=20 > >> In Section 4.5.3 you write: > >>=20 > >> 4.5.3 QSPEC Tunneled Parameter T-Flag > >>=20 > >> Each QSPEC parameter has an associated 'tunneled-parameter T-flag'. > >> When a RESERVE message is tunneled through a domain, QNEs inside > >> the domain cannot update read-write parameters. > >>=20 > >> [hannes] QNEs MUST NOT update the parameters. That's the idea of > >> tunneling. > >>=20 > >> The egress QNE in a domain has two choices: either a) it is > >> configured to have the knowledge to update the parameters > >> correctly, > >>=20 > >> [hannes] What type of update are you looking for? The reservation > >> within the tunneled region is a separate and independent=20 > >> reservation. > >=20 > >=20 > > Not sure what you mean by "separate and independent reservation". >=20 > See Section 4.6 of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt > and > http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-00.txt >=20 > Figure 12 in ection 4.6 of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt > is particularly nice since it shows that the=20 > RESERVE'/RESPONSE' within=20 > the domain are independent of the E2E RESERVE/RESPONSE. >=20 > > We're talking about an end-to-end reservation where one domain may > > tunnel the Initiator QSPEC through the domain. With respect to the > > 'update', it refers to the egress QNE in the domain updating a > > mandatory or optional QSPEC parameter in the Initiator QSPEC. E.g., > > if the parameter (a mandatory QSPEC parameter) is > > specified in the object in the Initiator QSPEC, and > > the Initiator QSPEC is tunneled through a domain, the egress QNE in > > the domain may be configured to update this parameter. >=20 > Why would it want to update the parameter? >=20 > If it cannot > > update this parameter, then it needs to set the T-Flag to so > > indicate. >=20 > If he wants to update the parameter why would there be a=20 > problem with it? >=20 > >=20 > >=20 > >> or b) it cannot update the parameters. In the latter case it MUST > >> set the tunneled-parameter T-flag to tell the QNI (or QNR) that the > >> information contained in the read-write parameter is most likely=20 > >> incorrect (or a lower bound). > >>=20 > >> [hannes] Which parameters are incorrect? > >=20 > >=20 > > If in the above example, the egress QNE in the domain is unable to > > update in the object, it must then set > > the T-flag for the parameter. > >=20 > >=20 > >> The T-flag is interpreted by the QNI, ingress QNE (start of tunnel > >> in a domain), egress QNE (end of tunnel in a domain), or QNR. > >>=20 > >> [hannes] There are now three 'T' bits flying around in related > >> documents: > >>=20 > >> * T-bit set (RESERVE tear): QoS NSLP * T-bit in the NSIS Tunnel ID=20 > >> * T-bit in the QSPEC draft > >>=20 > >> Neither the QoS NSLP nor the NSIS Tunnel ID does, to my knowledge, > >> not use the T-bit of the QSPEC document. > >=20 > >=20 > > The T-bit in the QSPEC draft is strictly for use by the RMF in QoS > > processing, so I think its use is restricted to=20 > implementation of the > > NSLP/QSPEC/RMF procedures. However, you raise a good point about 3 > > different definitions for 'T-bit', and we need to be sure=20 > there is no > > confusion resulting from this. > >=20 >=20 > Why does the RMF need this info? >=20 > >=20 > >> * Why do you need to put error specific flag in every object=20 > >> (namely 'E and N flag)? Errors should be the exception rather than > >> the norm. I would do something different, namely to put an error > >> object with a list of the Parameter IDs in it. > >=20 > >=20 > > The use of E-Flag is definitely the exception rather than the norm. > > IMO the approach defined in Section 4.5.1 is a reasonable approach, > > that is, to flag an error according to a specific QSPEC=20 > parameter, if > > possible. However, as stated in Section 4.5.1, in some error > > situations it may not be possible to set the E-Flag for a QSPEC > > parameter, although it may be possible to still set the E-Flag for > > the QSPEC object. The INFO_SPEC in this case does carry the QSPEC > > with the erroneous parameters flagged within it. The=20 > alternative you > > suggest I think is similar to this approach (this approach agreed to > > after a very lengthy discussion on error codes). > >=20 >=20 > So, what you are going todo? >=20 > >=20 > >> Regarding the parameter encoding: > >>=20 > >> You might want to change the description with regard to the=20 > >> Parameter ID field. Change from: > >>=20 > >> " 7.2.1 Parameter > >>=20 > >> 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=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > >> |1|E|0|T| 0 |r|r|r|r| 1 |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > >> NON QOSM Hop | Reserved |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " > >>=20 > >>=20 > >> to: > >>=20 > >> " 7.2.1 Parameter > >>=20 > >> 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=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > >> |1|E|0|T|00000000000000000000000|r|r|r|r| 1 |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > >> NON QOSM Hop | Reserved |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " > >>=20 > >>=20 > >> or: " 7.2.1 Parameter > >>=20 > >> 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=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > >> |1|E|0|T| Parameter ID |r|r|r|r| Length |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > >> NON QOSM Hop | Reserved |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>=20 > >> Parameter ID: 0 > >>=20 > >> Length: 1 > >>=20 > >> " > >>=20 > >> The Parameter ID is 12 bits long. Is it also encoded in network > >> byte order? The same is true for the Length field. > >>=20 > >> The draft only says that "Network byte order ('big-endian') for all > >> 16- and 32-bit integers, as well as 32-bit floating point numbers, > >> are as specified in [RFC1832, IEEE754, NETWORK-BYTE-ORDER]. " > >=20 > >=20 > > I'm not sure I get the point you're making here. >=20 >=20 > The point is: What is the encoding of the parameters. > The text and the figure does not provide enough details to=20 > figure it out. >=20 >=20 > For the > HOP> case, however, perhaps this flag should be coded as a QSPEC > > object flag and not a 32-bit parameter, as suggested in the previous > > message. >=20 >=20 > Ciao > Hannes >=20 >=20 > >=20 > > Thanks, Jerry > >=20 > >=20 > >> Ciao Hannes > >=20 > >=20 > >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 04:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJmd-000086-Uw; Mon, 03 Jul 2006 04:27:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxJmc-00007y-Ju for nsis@ietf.org; Mon, 03 Jul 2006 04:27:54 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxJmc-0003Px-59 for nsis@ietf.org; Mon, 03 Jul 2006 04:27:54 -0400 Received: (qmail invoked by alias); 03 Jul 2006 08:27:53 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp031) with SMTP; 03 Jul 2006 10:27:53 +0200 X-Authenticated: #29516787 Message-ID: <44A8D50B.4090400@gmx.net> Date: Mon, 03 Jul 2006 10:27:55 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <05F34B6959F19F43BBD78FFCD4C15D055DFE5A@esealmw116.eemea.ericsson.se> In-Reply-To: <05F34B6959F19F43BBD78FFCD4C15D055DFE5A@esealmw116.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Attila, please find my comment below: Attila Báder (IJ/ETH) wrote: > Hi Hannes, see below, > > Attila > >> -----Original Message----- From: Hannes Tschofenig >> [mailto:Hannes.Tschofenig@gmx.net] Sent: Saturday, July 01, 2006 >> 10:23 PM To: Hannes Tschofenig Cc: Attila Báder (IJ/ETH); >> nsis@ietf.org Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >> >> >> Hi all, >> >> I should have read the latest QSPEC draft version before I sent >> this mail. The most recent draft talks about this aspect and it >> says in Section 4.7: " A QOSM specification MUST define how the >> mandatory parameters are to be mapped onto the QSPEC parameters >> used by the QOSM, however the mapping MAY result in slight >> modification to the intended specification when an exact mapping is >> not possible. " >> >> Attila, you did this for the token bucket parameter and described >> that it can be mapped to the bandwith parameter. >> >> Now, the only question remains whether a QOSM also have to define a >> mapping for all mandatory parameters. This would address the case >> mentioned below: The QOSM does not make use of all mandatory >> parameters listed in the QSPEC. >> > > > When the QSpec is translated to a local QSpec, I think the relevant > mandatory parameters has to be mapped and this mapping should be > defined in QOSM. Parameters which are not relevant in a QoS domain > can be ignored. The QSPEC template draft does not say anything like that. I wonder whether this is inline with th mandatory parameter concept. If your QOSM does not understand it then it ignores it does not sound like "must be interpreted". In fact, Section 4.6 (about QSPEC Extensibility) says about defining a new QSPEC draft version: " Furthermore, all QOSM definitions must be updated to include how the new mandatory parameter is to be interpreted in the respective QOSM. " To me that indicates that the new mandatory parameter (which was obviously not relevant in the QOSM previously) needs to be dealt with. > > The main question is how to fill in mandatory parameters for another > QOSM if it is not appliceble in the local QOSM. This should be > defined in a QOSM. I am not sure I understood this statement. Can you reformulate it a bit? > > In case of RMD it is not a problem: RMD QOSM is used as a local > domain, and the original parameters are always handed over to the > Egress edge, so all necessary info is available there. Ciao Hannes > > > >> Ciao Hannes >> >> >> Hannes Tschofenig wrote: >> >>> Hi Attila, >>> >>> Attila Báder (IJ/ETH) wrote: >>> >>> >>>> Hi Bernd, This is the case in RMD as well. In RMD domain >>>> resource reservation is based on one parameter: Bandwidth. If, >>>> for example, the resource request arriving to the Edge is a >>>> token bucket, it should be translated to a single Bandwidth >>>> parameter. This may be a peak value, or an effective value. >>> >>> >>> I guess Bernd's question was focusing on a different aspect. What >>> happens if you receive a request that contains the >> >> parameter 'Y.1541 QoS >> >>> Class with the value set for Class 0? >>> >>> Ciao Hannes >>> >>> >>> >>>> Best regards, Attila >>>> >>>> >>>> >>>>> -----Original Message----- From: Bernd Schloer >>>>> [mailto:bschloer@cs.uni-goettingen.de] Sent: Thursday, June >>>>> 29, 2006 3:01 PM To: nsis@ietf.org Subject: [NSIS] >>>>> draft-qosmodel-controlledload-04 >>>>> >>>>> >>>>> Hi, >>>>> >>>>> the first open issue in the appendix B is about what to do >>>>> with mandatory QSPEC parameters which are not needed for CLS. >>>>> >>>>> >>>>> Does a QOSM have to understand (and provide information >>>>> about) all mandatory parameters, even if they are not used? >>>>> The QSPEC-draft says in section 5 that all parameters listed >>>>> in the next sections are mandatory. The QSPEC-draft also says >>>>> in section 4.1 that "a given QOSM defines which of the >>>>> mandatory and optional parameters it uses, ..." >>>>> >>>>> Are there any specific parameters which makes the open >> >> issue B.1.1. >> >>>>> clearer? Following the QSPEC-draft there doesn't seem to be a >>>>> conflict, if nothing is done with the unneeded parameters. >>>>> >>>>> Thanks, Bernd >>>>> >>>>> >>>>> >>>>> _______________________________________________ nsis mailing >>>>> list nsis@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>>> >>>> >>>> >>>> _______________________________________________ nsis mailing >>>> list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis >>>> >>>> >>> >>> >>> _______________________________________________ nsis mailing list >>> nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >> >> > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 04:44:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxK2b-0001fN-N7; Mon, 03 Jul 2006 04:44:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxK2a-0001fF-4e for nsis@ietf.org; Mon, 03 Jul 2006 04:44:24 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxK2Z-0004gq-Cz for nsis@ietf.org; Mon, 03 Jul 2006 04:44:24 -0400 Received: (qmail invoked by alias); 03 Jul 2006 08:44:20 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp036) with SMTP; 03 Jul 2006 10:44:20 +0200 X-Authenticated: #29516787 Message-ID: <44A8D8E6.2090602@gmx.net> Date: Mon, 03 Jul 2006 10:44:22 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] QSPEC Comment: QSPEC QoS Object Header References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?ISO-8859-1?Q?tila_B=E1der_=28IJ/ETH=29=22?= , Kappler Cornelia , NSIS , =?ISO-8859-1?Q?=22At?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, please find my response below: Hancock, Robert wrote: > hi all, > > just a comment on length fields and M-bits: > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: 03 July 2006 09:20 >>To: Ash, Gerald R (Jerry), ALABS >>Cc: "Attila Báder (IJ/ETH)"; NSIS; Kappler Cornelia >>Subject: Re: [NSIS] QSPEC Comment: QSPEC QoS Object Header >> >> >>Hi Jerry, >> >>please find my response below: >> >>Ash, Gerald R (Jerry), ALABS wrote: >> >>>Hi Hannes, >>> >>>See below. >>> >>> >>> >>>>-----Original Message----- From: Hannes Tschofenig >>>>[mailto:Hannes.Tschofenig@gmx.net] Sent: Sunday, July 02, 2006 4:47 >>>>AM To: NSIS Subject: [NSIS] QSPEC Comment: QSPEC QoS Object Header >>>> >>>>Hi QSPEC authors, >>>> >>>>I tried to figure out whether the QSPEC template draft could be >>>>used for the AAA work. The QSPEC QoS object header raised a few >>>>questions: >>>> >>>>* Why do you need a length field if all the objects just have a >>>>fixed length? >>> >>> >>>The length of various QSPEC parameters is not fixed. E.g., compare >>>Section 7.2.5 (length=5) to Section 7.2.3 >>>(length=1). >> >> >>No, I meant that the Parameter ID would immediately tell you >>the length >>of the respective attribute. >> >>For every object the length of the object cannot be variable. > > > what if the parameter ID is a new one unknown at the receiver of the > message (e.g. for an optional object)? you may still want to parse > the rest of the message, and you need to know what to skip over. You are definitely right. Bogus idea. I guess what I would like to see is a simple TLV structure so that I could also use it for RADIUS and Diameter. I was also curious about the 32 bit alignment. For some reason this was done in the QoS NSLP (maybe in GIST as well) but why is this helpful here? > > >>>>* Why do you need an 'M' bit? Whether a parameter is mandatory or >>>>not can easily derived from the Parameter ID. >>> >>> >>>We were advised that the M flag should be specified for easier QSPEC >>>processing. >> >>I don't see the big advantage. Instead of looking at the flag >>and then >>processing the Parameter ID I would have to look at the >>Parameter ID and >>then see immediately whether it is a mandatory attribute or not. > > > same comment on unknown IDs; and see below. > > >> >> In addition, new QSPEC versions specifying new mandatory >> >>>parameters and/or unrecognized optional parameters could >> >>also mandate >> >>>that this flag be used. >> >>The current text in the draft does not provide a solid story >>about the >>QSPEC version updates. It says >>" >>Additional mandatory parameters may be defined in the future. >> However, since this requires an update of all QNEs, this should be >> considered carefully. >>" >> >>If this is the requirement then it can never happen that a QNE sees a >>mandatory parameter that it does not understand. > > > i think this is a pointer that a tradeoff needs to be made. if > you decide to use a new mandatory parameter, then be aware that > error messages may come back that it is not understood. it > should still be possible to define new mandatory parameters, but > it just has to be done with care and caution. I think that the addition of new mandatory parameters requires a second thought and a bit more text. Ciao Hannes > > robert h. > > >> >>> >>>>* Why do you need the 'T' flag? I don't think that the concept is >>>>actually useful. >>>> >>>>In Section 4.5.3 you write: >>>> >>>>4.5.3 QSPEC Tunneled Parameter T-Flag >>>> >>>>Each QSPEC parameter has an associated 'tunneled-parameter T-flag'. >>>> When a RESERVE message is tunneled through a domain, QNEs inside >>>>the domain cannot update read-write parameters. >>>> >>>>[hannes] QNEs MUST NOT update the parameters. That's the idea of >>>>tunneling. >>>> >>>>The egress QNE in a domain has two choices: either a) it is >>>>configured to have the knowledge to update the parameters >>>>correctly, >>>> >>>>[hannes] What type of update are you looking for? The reservation >>>>within the tunneled region is a separate and independent >>>>reservation. >>> >>> >>>Not sure what you mean by "separate and independent reservation". >> >>See Section 4.6 of >>http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt >>and >>http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-00.txt >> >>Figure 12 in ection 4.6 of >>http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt >>is particularly nice since it shows that the >>RESERVE'/RESPONSE' within >>the domain are independent of the E2E RESERVE/RESPONSE. >> >> >>>We're talking about an end-to-end reservation where one domain may >>>tunnel the Initiator QSPEC through the domain. With respect to the >>>'update', it refers to the egress QNE in the domain updating a >>>mandatory or optional QSPEC parameter in the Initiator QSPEC. E.g., >>>if the parameter (a mandatory QSPEC parameter) is >>>specified in the object in the Initiator QSPEC, and >>>the Initiator QSPEC is tunneled through a domain, the egress QNE in >>>the domain may be configured to update this parameter. >> >>Why would it want to update the parameter? >> >> If it cannot >> >>>update this parameter, then it needs to set the T-Flag to so >>>indicate. >> >>If he wants to update the parameter why would there be a >>problem with it? >> >> >>> >>>>or b) it cannot update the parameters. In the latter case it MUST >>>>set the tunneled-parameter T-flag to tell the QNI (or QNR) that the >>>> information contained in the read-write parameter is most likely >>>>incorrect (or a lower bound). >>>> >>>>[hannes] Which parameters are incorrect? >>> >>> >>>If in the above example, the egress QNE in the domain is unable to >>>update in the object, it must then set >>>the T-flag for the parameter. >>> >>> >>> >>>>The T-flag is interpreted by the QNI, ingress QNE (start of tunnel >>>>in a domain), egress QNE (end of tunnel in a domain), or QNR. >>>> >>>>[hannes] There are now three 'T' bits flying around in related >>>>documents: >>>> >>>>* T-bit set (RESERVE tear): QoS NSLP * T-bit in the NSIS Tunnel ID >>>>* T-bit in the QSPEC draft >>>> >>>>Neither the QoS NSLP nor the NSIS Tunnel ID does, to my knowledge, >>>>not use the T-bit of the QSPEC document. >>> >>> >>>The T-bit in the QSPEC draft is strictly for use by the RMF in QoS >>>processing, so I think its use is restricted to >> >>implementation of the >> >>>NSLP/QSPEC/RMF procedures. However, you raise a good point about 3 >>>different definitions for 'T-bit', and we need to be sure >> >>there is no >> >>>confusion resulting from this. >>> >> >>Why does the RMF need this info? >> >> >>>>* Why do you need to put error specific flag in every object >>>>(namely 'E and N flag)? Errors should be the exception rather than >>>>the norm. I would do something different, namely to put an error >>>>object with a list of the Parameter IDs in it. >>> >>> >>>The use of E-Flag is definitely the exception rather than the norm. >>>IMO the approach defined in Section 4.5.1 is a reasonable approach, >>>that is, to flag an error according to a specific QSPEC >> >>parameter, if >> >>>possible. However, as stated in Section 4.5.1, in some error >>>situations it may not be possible to set the E-Flag for a QSPEC >>>parameter, although it may be possible to still set the E-Flag for >>>the QSPEC object. The INFO_SPEC in this case does carry the QSPEC >>>with the erroneous parameters flagged within it. The >> >>alternative you >> >>>suggest I think is similar to this approach (this approach agreed to >>>after a very lengthy discussion on error codes). >>> >> >>So, what you are going todo? >> >> >>>>Regarding the parameter encoding: >>>> >>>>You might want to change the description with regard to the >>>>Parameter ID field. Change from: >>>> >>>>" 7.2.1 Parameter >>>> >>>>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 >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>|1|E|0|T| 0 |r|r|r|r| 1 | >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>>>NON QOSM Hop | Reserved | >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " >>>> >>>> >>>>to: >>>> >>>>" 7.2.1 Parameter >>>> >>>>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 >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>|1|E|0|T|00000000000000000000000|r|r|r|r| 1 | >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>>>NON QOSM Hop | Reserved | >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " >>>> >>>> >>>>or: " 7.2.1 Parameter >>>> >>>>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 >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>|1|E|0|T| Parameter ID |r|r|r|r| Length | >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>>>NON QOSM Hop | Reserved | >>>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>>Parameter ID: 0 >>>> >>>>Length: 1 >>>> >>>>" >>>> >>>>The Parameter ID is 12 bits long. Is it also encoded in network >>>>byte order? The same is true for the Length field. >>>> >>>>The draft only says that "Network byte order ('big-endian') for all >>>>16- and 32-bit integers, as well as 32-bit floating point numbers, >>>>are as specified in [RFC1832, IEEE754, NETWORK-BYTE-ORDER]. " >>> >>> >>>I'm not sure I get the point you're making here. >> >> >>The point is: What is the encoding of the parameters. >>The text and the figure does not provide enough details to >>figure it out. >> >> >> For the > >>>HOP> case, however, perhaps this flag should be coded as a QSPEC >>>object flag and not a 32-bit parameter, as suggested in the previous >>>message. >> >> >>Ciao >>Hannes >> >> >> >>>Thanks, Jerry >>> >>> >>> >>>>Ciao Hannes >>> >>> >>> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 07:29:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxMca-00034r-RW; Mon, 03 Jul 2006 07:29:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxMcZ-00034m-K9 for nsis@ietf.org; Mon, 03 Jul 2006 07:29:43 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxMcY-0001p9-PL for nsis@ietf.org; Mon, 03 Jul 2006 07:29:43 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k63BTN3o012106; Mon, 3 Jul 2006 13:29:33 +0200 (MEST) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] draft-qosmodel-controlledload-04 Date: Mon, 3 Jul 2006 13:29:23 +0200 Message-ID: <001b01c69e93$f0393560$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7A66@KCCLUST06EVS1.ugd.att.com> Thread-Index: AcadTKB+0bt7N483R5KSlvF9yvg0XwAyBOOQAB3Ig6A= X-Spam-Score: -5.013 () ALL_TRUSTED,AWL,BAYES_00,SUBJ_HAS_UNIQ_ID X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 03 Jul 2006 13:29:37 +0200 (MEST) X-Spam-Score: 1.1 (+) X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75 Cc: 'Kappler Cornelia' , nsis@ietf.org, =?iso-8859-1?Q?'Attila_B=E1der_=28IJ/ETH=29'?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry=20 Regarding your last point: >>Hannes: >> Do you think it is awfully realistic for all QNEs to understand all=20 >> mandatory parameters? I could imagine that Attila and=20 >> Georgios are not=20 >> going to implement stateless interior QNEs in such a way that they=20 >> understand all the mandatory QSPEC parameters. In fact they=20 >> don't have=20 >> todo it since only edge routers are likely to ever see QoS=20 >> NSLP messages=20 >> that contain QOSM IDs that they do not understand (otherwise=20 >> something=20 >> go terribly wrong). >Jerry: It is up the RMD authors to specify how they want RMD=20 >> to behave wrt mandatory parameters (and obtain rough=20 >> consensus, of course). That is, if a mandatory parameter=20 >> is remapped and not strictly interpreted, the remapping=20 >> must be specified in the QOSM specification document. =20 >> Otherwise, the QOSM must strictly interpret the mandatory=20 >> parameters that are not remapped, if they are populated by the QNI. >> There are no restrictions on how the remapping must be done,=20 >> it can be as simple as necessary (but no simpler). Georgios: Jerry, I think that the point raised by Hannes is related to how the QNE's interior to the RMD domain will have to comply to the mandatory descriptions specified in the QSPEC template.=20 An interior QNE (in RMD-QOSM) will not process=20 the end to end QSpec. The only QSpec that will be processed by the=20 interior QNE is the RMD Qsepc that is initiated by the=20 ingress node (i.e., QNI for the RMD local session).=20 Note that the above observation is valid for all local QOSMs. However, the above is not allowed due to the following text that is=20 included in the QSpec template draft: "A QNE MUST interpret all mandatory parameters from this document even=20 if it does not support the received QoS NSLP message with the=20 indicated QOSM." Therefore, in my opinion it is required to modify the above sentence in something like: "A QNE SHOULD interpret all mandatory parameters from this document even = if it does not support the received QoS NSLP message with the=20 indicated QOSM. A QNE that supports a local QOSM, does not have to = interpret all mandatory parameters carried by a QSpec that was generated by a QNI=20 located outside the domain that supports the given local QOSM."=20 Best regards, Georgios -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 Sent: maandag 3 juli 2006 2:03 To: Hannes Tschofenig Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH); = nsis@ietf.org; Kappler Cornelia Subject: RE: [NSIS] draft-qosmodel-controlledload-04 Hi Hannes, See below.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, July 01, 2006 4:26 PM > To: Ash, Gerald R (Jerry), ALABS > Cc: nsis@ietf.org > Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >=20 > Hi Jerry, >=20 > it is true that I haven't read the most recent QSPEC draft when I sent = > this mail. In the meanwhile I did. Please find a few comments below: >=20 > Ash, Gerald R (Jerry), ALABS wrote: > > Hi Hannes, > >=20 > > See below.=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>Sent: Friday, June 30, 2006 8:43 AM > >>To: Bernd Schloer > >>Cc: nsis@ietf.org > >>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 > >> > >>Hi Bernd, > >> > >>Bernd Schloer wrote: > >> > >>>Hi, > >>> > >>>the first open issue in the appendix B is about what to do with=20 > >>>mandatory QSPEC parameters which are not needed for CLS. > >>> > >>>Does a QOSM have to understand (and provide information about) all=20 > >>>mandatory parameters, even if they are not used? > >> > >>I think the question is wrong. What about the following question: > >>" > >>Does a node that implements a particular QOSM has to understand all=20 > >>mandatory parameters listed in the QSPEC template draft > (even if the > >>QOSM does not make use of them)? > >>" > >>The answer would be "YES" since the QSPEC template draft says that=20 > >>mandatory parameters have to be understood by every NSIS QoS node. > >> > >>There is only the question what "understands" means. > >=20 > >=20 > > IMO you need to more carefully read the QSPEC I-D document. All=20 > > mandatory QSPEC parameters that are populated in the QSPEC must be=20 > > interpreted by every QNE, which is explained in the QSPEC I-D: > >=20 > > It says in Section 4.4.1 (Mandatory and Optional QSPEC > . Parameters) of > > the QSPEC I-D > > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: > >=20 > > " Mandatory QSPEC parameters are treated as follows: > >=20 > > o A QNI SHOULD populate mandatory QSPEC parameters if > . applicable to > > the underlying QOSM. >=20 > I don't understand this sentence. What does it mean that a QNI=20 > "SHOULD" > populate parameters if applicable? It means that a QNI is not required to populate all mandatory = parameters. A QNI would only populated a mandatory parameter if is used by the QOSM supported by the QNI. =20 > > o QNEs MUST interpret mandatory QSPEC parameters, if signaled." > >=20 > > Furthermore, it says in Section 4.2 (QSPEC Processing): > >=20 > > " a QNE > > MUST at least interpret all the mandatory parameters in=20 > > a QSPEC even > > if it does not support the corresponding QOSM. > >=20 > > Mandatory parameters provide a minimal subset of parameters. A > > QNE MUST either a) strictly interpret a mandatory parameter, or > > b) remap the parameter and raise the flag=20 > > defined in > > Section 5.1, where the remapping MUST be specified in the QOSM > > specification. Here the terminology 'strictly=20 > > interpret' means that >=20 > What is the difference between 'strictly interpret' and 'interpret'?=20 > In the rest of the document you use 'interpret'. 'Strictly interpret' is defined in the text I quoted from Section 4.2 = (QSPEC Processing), which is given again in the very next sentences I quoted = just below (after you posed your above question :-) " Mandatory parameters provide a minimal subset of parameters. A QNE MUST either a) strictly interpret a mandatory parameter, or b) remap the parameter and raise the flag defined in Section 5.1, where the remapping MUST be specified in the QOSM specification. Here the terminology 'strictly interpret' means that the parameter is implemented according to the commonly accepted definition and/or as specified by references given for each QSPEC parameter. This means that in case a), a parameter must be strictly interpreted as a token bucket. However, in case b), a parameter may be remapped, perhaps to a parameter." In the document, the term 'interpret' a mandatory parameter means either = a) strictly interpret (as defined above), or b) remap (as defined above). Perhaps this can be made clearer in the text. =20 > > the parameter is implemented according to the commonly accepted > > definition and/or as specified by references given for each QSPEC > > parameter. This means that in case a), a =20 > > parameter > > must be strictly interpreted as a token bucket. =20 > > However, in case b), > > a parameter may be remapped, perhaps to a=20 > > > > parameter. > > I noticed this text improvement and I am happy to see more text about=20 > it. >=20 > Still, I have some issues with the section: >=20 > I had a problem with this paragraph following the previous one in the=20 > section. The previous paragraph said " > However, if a QSPEC arrives at a QNE that does > not support the QOSM being signaled, it can still understand the > QSPEC content, at least to a basic degree. > " >=20 > When I read through the text I got the impression that the two=20 > sections relate to each other and in fact they do not. Hence, I=20 > suggest to delete the previous paragraph since this one contains the=20 > info already. I'm unclear as to which paragraph/text you are proposing to delete. > You > might also want to delete the second paragraph as well since it is far = > too obvious to use RFC2119 language: If you don't support even a=20 > single QOSM then why are you a QOS NSLP node in the first place. I think it important to state that a QNE MUST support at least one QOSM, even if this is clearly necessary to effectively support QoS-NSLP/QSPEC. > You might want to highlight the following sentence, though: >=20 > " > A QNE MUST interpret all mandatory parameters from this document even=20 > if it does not support the received QoS NSLP message with the=20 > indicated QOSM. > " >=20 > Here is my proposal for the section: >=20 > " > 4.2 QSPEC Processing >=20 > The QSPEC is opaque to the QoS NSLP processing. The QSPEC control > information and the QoS description are interpreted and MAY be > modified by the RMF in a QNE (see description in [QoS-SIG]). >=20 > The QSPEC contains a QOSM ID, i.e. information on what=20 > QOSM is being > signaled by the QNI. However, if a QSPEC arrives at a=20 > QNE that does > not support the QOSM being signaled, it can still understand the > QSPEC content, at least to a basic degree. This is=20 > because mandatory > parameters have been defined as a common language. =20 > Therefore, a QNE > MUST at least interpret all the mandatory parameters in a=20 > QSPEC even > if it does not support the corresponding QOSM. >=20 > A QNE MUST either >=20 > a) interpret a mandatory parameter carried in the QSPEC object, or >=20 > b) remap the parameter and raise the flag=20 > defined in > Section 5.1, where the remapping MUST be specified in the QOSM > specification. >=20 > Here the terminology 'interpret' means that > the parameter is implemented according to the references=20 > given for=20 > each QSPEC parameter. >=20 > If a QSPEC arrives at a QNE that does not support the QOSM being > signaled, it can still understand the QSPEC content, at least to a > basic degree. Hence, with case (a), a parameter > must be strictly interpreted as a token bucket. >=20 > In case b), a parameter may be remapped,=20 > perhaps to a > parameter. > " I don't see any benefit in redefining what 'interpret' means in the document. As I mentioned above, the document uses the term 'interpret' = to mean that a mandatory parameter is 'interpreted' if is either 'strictly interpreted' or it is 'remapped' (where the remapping must be defined in = the QOSM specification document). OTOH, it might be useful to define a 'remapping' flag to indicated if a mandatory or optional parameter has = been remapped by a QNE in the path. =20 > Btw, have you noticed that the draft has > * a flag (Section 5.1) > * a parameter (Section 7.2.1) >=20 > I think they refer to the same concept... Yes, good catch. is indeed intended to be a flag, and perhaps one of the QSPEC object flags defined in Section 7.1 could be = used for this purpose, rather than use a full 32-bit parameter for this = purpose, as currently specified in Section 7.2.1. =20 > > In the latter case, the remapping of the to > > must be specified in the QOSM specification document. > > For example, QOSM X exclusively uses the parameter=20 > > . It > > must define a mapping of the mandatory parameter . > > The mapping consists of interpreting the Token Bucket Rate as > > the parameter and disregarding the other Token Bucket > > parameters. Clearly, some information contained in the > Bucket> parameter is lost by this mapping, and the=20 > > resulting QoS may > > not be quite what was intended by the QNI. Therefore,=20 > > QOSM X also > > specifies that the flag be raised. Thus,=20 > > a QNE using > > QOSM X is able to make an informed decision whether to admit a > > reservation described in terms of , and at the same > > time (by means of ) signals to the QNI/QNR that the > > exact intention of the QNI may not be met." > >=20 > > I think this text is pretty clear as to what is required regarding=20 > > interpreting mandatory parameters. If not, please suggest=20 > > clarifications. >=20 > The text in the new draft has improved a lot. > Thanks for the update. >=20 > >=20 > >=20 > >>Another possible question would be: > >>" > >>Does a node that implements a particular QOSM has to define mappings = > >>from all mandatory parameters listed in the QSPEC template draft to=20 > >>the QOSM draft (even if the QOSM does not make use > of them)? > >>" > >> > >>The answer is "I don't know". > >=20 > >=20 > > A QNE must interpret all mandatory parameters, if populated, as > > explained in the above text I quoted. If a QOSM re-maps a mandatory > > QSPEC parameter, that re-mapping must be defined in the QOSM > > specification. As stated in Section 4.7 (QOSM Specification > > Requirements): > >=20 > > " A QOSM specification MUST define QSPEC parameter=20 > > behavior for these > > cases: a) new optional QSPEC parameters the QOSM specification > > defines, and b) remapping of existing mandatory or optional QSPEC > > parameters, as described in Section 4.2. Unless=20 > > otherwise specified > > in the QOSM specification document, the behaviors to strictly > > interpret the mandatory and optional QSPEC parameters=20 > > are defined in > > this document through the references to RFCs that=20 > > precisely define > > the QSPEC parameter behaviors. =20 > >=20 > > A QOSM specification MUST define how the mandatory=20 > > parameters are to > > be mapped onto the QSPEC parameters used by the QOSM, however the > > mapping MAY result in slight modification to the intended > > specification when an exact mapping is not possible. =20 > > This definition > > MUST allow a QNE implementing this QOSM to make a decision as to > > whether a reservation described in terms of mandatory=20 > > parameters can > > be admitted. If for a particular mandatory parameter no=20 > > mapping can > > be found that guarantees the desired QoS, the QNE is=20 > > advised to raise > > the flag. In other words, for all mandatory > > parameters a mapping must be defined, but it is acknowledged that > > this mapping may result in slightly bending the original=20 > > intention of > > the QNI." > >=20 > > I think this text is pretty clear as to what is required. If not, > > please suggest clarifications. >=20 > I understood the token bucket to bandwidth example. >=20 > Would the RMD draft, for example, list all mandatory parameters and=20 > indicate whether it can map them (and how) to parameters used=20 > in the RMD=20 > specification? As stated in the QOSM specification requirements in Section 4.7, if a = QOSM remaps a mandatory parameter, the remapping must be defined in the QOSM specification document. If no such remapping is defined, the default behavior is that the QOSM must strictly interpret the mandatory = parameter, as defined above. =20 > Do you think it is awfully realistic for all QNEs to understand all=20 > mandatory parameters? I could imagine that Attila and=20 > Georgios are not=20 > going to implement stateless interior QNEs in such a way that they=20 > understand all the mandatory QSPEC parameters. In fact they=20 > don't have=20 > todo it since only edge routers are likely to ever see QoS=20 > NSLP messages=20 > that contain QOSM IDs that they do not understand (otherwise=20 > something=20 > go terribly wrong). It is up the RMD authors to specify how they want RMD to behave wrt mandatory parameters (and obtain rough consensus, of course). That is, = if a mandatory parameter is remapped and not strictly interpreted, the = remapping must be specified in the QOSM specification document. Otherwise, the = QOSM must strictly interpret the mandatory parameters that are not remapped, = if they are populated by the QNI. There are no restrictions on how the remapping must be done, it can be = as simple as necessary (but no simpler). Thanks, Jerry >=20 >=20 > Ciao > Hannes >=20 > >=20 > > Thanks, > > Jerry > > =20 > >=20 > >>Ciao > >>Hannes > >> > >> The QSPEC-draft says in section 5 > >> > >>>that > >>>all parameters listed in the next sections are mandatory. The=20 > >>>QSPEC-draft also > >>>says in section 4.1 that "a given QOSM defines which of the=20 > >> > >>mandatory and > >> > >>>optional parameters it uses, ..." > >>> > >>>Are there any specific parameters which makes the open=20 > issue B.1.1.=20 > >>>clearer? Following the QSPEC-draft there doesn't seem to be=20 > >> > >>a conflict,=20 > >> > >>>if nothing is > >>>done with the unneeded parameters. > >>> > >>>Thanks, > >>>Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 09:21:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOMM-0004oP-80; Mon, 03 Jul 2006 09:21:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOMK-0004eM-8i for nsis@ietf.org; Mon, 03 Jul 2006 09:21:04 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxOMI-0002DR-DQ for nsis@ietf.org; Mon, 03 Jul 2006 09:21:04 -0400 Received: (qmail invoked by alias); 03 Jul 2006 13:21:00 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp003) with SMTP; 03 Jul 2006 15:21:00 +0200 X-Authenticated: #29516787 Message-ID: <44A919BD.2080400@gmx.net> Date: Mon, 03 Jul 2006 15:21:01 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <9473683187ADC049A855ED2DA739ABCA0DDC7A66@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7A66@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.1 (+) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= , nsis@ietf.org, Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, thanks for your response. Please find my comments below: ~snip~ >>> " Mandatory QSPEC parameters are treated as follows: >>> >>> o A QNI SHOULD populate mandatory QSPEC parameters if >> >> . applicable to >> >>> the underlying QOSM. >> >> I don't understand this sentence. What does it mean that a QNI >> "SHOULD" populate parameters if applicable? > > > It means that a QNI is not required to populate all mandatory > parameters. A QNI would only populated a mandatory parameter if is > used by the QOSM supported by the QNI. > Let us, for illustration, assume that the QNI is an end host. The NSIS QoS NSLP daemon does not start signaling on its own. It gets triggered by something else. An application might trigger the QoS NSLP daemon. The behavior you seem to describe seems to refer to the application layer to NSIS daemon interaction. Right? A QoS NSLP daemon that supports a particular QOSM would only signal what the QOSM supports and what it actually received as input. I think the QSPEC template draft should not describe aspect where the QoS NSLP daemon receives (a) more parameter than the QOSM understands or (b) not enough parameters required by the QOSM. > >>> o QNEs MUST interpret mandatory QSPEC parameters, if signaled." >>> >>> Furthermore, it says in Section 4.2 (QSPEC Processing): >>> >>> " a QNE MUST at least interpret all the mandatory parameters in >>> a QSPEC even if it does not support the corresponding QOSM. >>> >>> Mandatory parameters provide a minimal subset of parameters. A >>> QNE MUST either a) strictly interpret a mandatory parameter, or >>> b) remap the parameter and raise the flag defined >>> in Section 5.1, where the remapping MUST be specified in the QOSM >>> specification. Here the terminology 'strictly interpret' means >>> that >> >> What is the difference between 'strictly interpret' and >> 'interpret'? In the rest of the document you use 'interpret'. > > > 'Strictly interpret' is defined in the text I quoted from Section 4.2 > (QSPEC Processing), which is given again in the very next sentences I > quoted just below (after you posed your above question :-) > > " Mandatory parameters provide a minimal subset of parameters. A > QNE MUST either a) strictly interpret a mandatory parameter, or b) > remap the parameter and raise the flag defined in > Section 5.1, where the remapping MUST be specified in the QOSM > specification. Here the terminology 'strictly interpret' means that > the parameter is implemented according to the commonly accepted > definition and/or as specified by references given for each QSPEC > parameter. This means that in case a), a parameter > must be strictly interpreted as a token bucket. However, in case b), > a parameter may be remapped, perhaps to a > parameter." > > In the document, the term 'interpret' a mandatory parameter means > either a) strictly interpret (as defined above), or b) remap (as > defined above). Perhaps this can be made clearer in the text. > I might got confused with the 'interpreted' and 'strictly interpreted' terminology because the term 'interpreted' appears many times in the entire document with different meanings. With this mailing list discussion I, however, understood your ideas behind it. > >>> the parameter is implemented according to the commonly accepted >>> definition and/or as specified by references given for each QSPEC >>> parameter. This means that in case a), a >>> parameter must be strictly interpreted as a token bucket. >>> However, in case b), a parameter may be remapped, >>> perhaps to a parameter. >> >> I noticed this text improvement and I am happy to see more text >> about it. >> >> Still, I have some issues with the section: >> >> I had a problem with this paragraph following the previous one in >> the section. The previous paragraph said " However, if a QSPEC >> arrives at a QNE that does not support the QOSM being signaled, it >> can still understand the QSPEC content, at least to a basic degree. >> " >> >> When I read through the text I got the impression that the two >> sections relate to each other and in fact they do not. Hence, I >> suggest to delete the previous paragraph since this one contains >> the info already. > > > I'm unclear as to which paragraph/text you are proposing to delete. > I guess you have later seen my full text proposal below. > >> You might also want to delete the second paragraph as well since it >> is far too obvious to use RFC2119 language: If you don't support >> even a single QOSM then why are you a QOS NSLP node in the first >> place. > > > I think it important to state that a QNE MUST support at least one > QOSM, even if this is clearly necessary to effectively support > QoS-NSLP/QSPEC. > > >> You might want to highlight the following sentence, though: >> >> " A QNE MUST interpret all mandatory parameters from this document >> even if it does not support the received QoS NSLP message with the >> indicated QOSM. " >> >> Here is my proposal for the section: >> >> " 4.2 QSPEC Processing >> >> The QSPEC is opaque to the QoS NSLP processing. The QSPEC control >> information and the QoS description are interpreted and MAY be >> modified by the RMF in a QNE (see description in [QoS-SIG]). >> >> The QSPEC contains a QOSM ID, i.e. information on what QOSM is >> being signaled by the QNI. However, if a QSPEC arrives at a QNE >> that does not support the QOSM being signaled, it can still >> understand the QSPEC content, at least to a basic degree. This is >> because mandatory parameters have been defined as a common >> language. Therefore, a QNE MUST at least interpret all the >> mandatory parameters in a QSPEC even if it does not support the >> corresponding QOSM. >> >> A QNE MUST either >> >> a) interpret a mandatory parameter carried in the QSPEC object, or >> >> b) remap the parameter and raise the flag defined in >> Section 5.1, where the remapping MUST be specified in the QOSM >> specification. >> >> Here the terminology 'interpret' means that the parameter is >> implemented according to the references given for each QSPEC >> parameter. >> >> If a QSPEC arrives at a QNE that does not support the QOSM being >> signaled, it can still understand the QSPEC content, at least to a >> basic degree. Hence, with case (a), a parameter must >> be strictly interpreted as a token bucket. >> >> In case b), a parameter may be remapped, perhaps to >> a parameter. " > > > I don't see any benefit in redefining what 'interpret' means in the > document. As I mentioned above, the document uses the term > 'interpret' to mean that a mandatory parameter is 'interpreted' if is > either 'strictly interpreted' or it is 'remapped' (where the > remapping must be defined in the QOSM specification document). OTOH, > it might be useful to define a 'remapping' flag to indicated if a > mandatory or optional parameter has been remapped by a QNE in the > path. I just wanted to be constructive and to propose something. > > >> Btw, have you noticed that the draft has * a flag >> (Section 5.1) * a parameter (Section 7.2.1) >> >> I think they refer to the same concept... > > > Yes, good catch. is indeed intended to be a flag, and > perhaps one of the QSPEC object flags defined in Section 7.1 could be > used for this purpose, rather than use a full 32-bit parameter for > this purpose, as currently specified in Section 7.2.1. > > >>> In the latter case, the remapping of the to >>> must be specified in the QOSM specification document. >>> For example, QOSM X exclusively uses the parameter . >>> It must define a mapping of the mandatory parameter >> Bucket>. The mapping consists of interpreting the Token Bucket >>> Rate as the parameter and disregarding the other >>> Token Bucket parameters. Clearly, some information contained in >>> the parameter is lost by this mapping, and the >>> resulting QoS may not be quite what was intended by the QNI. >>> Therefore, QOSM X also specifies that the flag be >>> raised. Thus, a QNE using QOSM X is able to make an informed >>> decision whether to admit a reservation described in terms of >>> , and at the same time (by means of ) >>> signals to the QNI/QNR that the exact intention of the QNI may >>> not be met." >>> >>> I think this text is pretty clear as to what is required >>> regarding interpreting mandatory parameters. If not, please >>> suggest clarifications. >> >> The text in the new draft has improved a lot. Thanks for the >> update. >> >> >>> >>>> Another possible question would be: " Does a node that >>>> implements a particular QOSM has to define mappings >>> >>>> from all mandatory parameters listed in the QSPEC template >>> >>>> draft to the QOSM draft (even if the QOSM does not make use >> >> of them)? >> >>>> " >>>> >>>> The answer is "I don't know". >>> >>> >>> A QNE must interpret all mandatory parameters, if populated, as >>> explained in the above text I quoted. If a QOSM re-maps a >>> mandatory QSPEC parameter, that re-mapping must be defined in the >>> QOSM specification. As stated in Section 4.7 (QOSM Specification >>> Requirements): >>> >>> " A QOSM specification MUST define QSPEC parameter behavior for >>> these cases: a) new optional QSPEC parameters the QOSM >>> specification defines, and b) remapping of existing mandatory or >>> optional QSPEC parameters, as described in Section 4.2. Unless >>> otherwise specified in the QOSM specification document, the >>> behaviors to strictly interpret the mandatory and optional QSPEC >>> parameters are defined in this document through the references to >>> RFCs that precisely define the QSPEC parameter behaviors. >>> >>> A QOSM specification MUST define how the mandatory parameters are >>> to be mapped onto the QSPEC parameters used by the QOSM, however >>> the mapping MAY result in slight modification to the intended >>> specification when an exact mapping is not possible. This >>> definition MUST allow a QNE implementing this QOSM to make a >>> decision as to whether a reservation described in terms of >>> mandatory parameters can be admitted. If for a particular >>> mandatory parameter no mapping can be found that guarantees the >>> desired QoS, the QNE is advised to raise the flag. >>> In other words, for all mandatory parameters a mapping must be >>> defined, but it is acknowledged that this mapping may result in >>> slightly bending the original intention of the QNI." >>> >>> I think this text is pretty clear as to what is required. If >>> not, please suggest clarifications. >> >> I understood the token bucket to bandwidth example. >> >> Would the RMD draft, for example, list all mandatory parameters and >> indicate whether it can map them (and how) to parameters used in >> the RMD specification? > > > As stated in the QOSM specification requirements in Section 4.7, if a > QOSM remaps a mandatory parameter, the remapping must be defined in > the QOSM specification document. If no such remapping is defined, > the default behavior is that the QOSM must strictly interpret the > mandatory parameter, as defined above. Got it as well. > > >> Do you think it is awfully realistic for all QNEs to understand all >> mandatory parameters? I could imagine that Attila and Georgios are >> not going to implement stateless interior QNEs in such a way that >> they understand all the mandatory QSPEC parameters. In fact they >> don't have todo it since only edge routers are likely to ever see >> QoS NSLP messages that contain QOSM IDs that they do not understand >> (otherwise something go terribly wrong). > > > It is up the RMD authors to specify how they want RMD to behave wrt > mandatory parameters (and obtain rough consensus, of course). That > is, if a mandatory parameter is remapped and not strictly > interpreted, the remapping must be specified in the QOSM > specification document. Otherwise, the QOSM must strictly interpret > the mandatory parameters that are not remapped, if they are populated > by the QNI. > > There are no restrictions on how the remapping must be done, it can > be as simple as necessary (but no simpler). I will review the QOSM documents to see how these remapping have been defined. Ciao Hannes > > Thanks, Jerry > > >> >> Ciao Hannes >> >> >>> Thanks, Jerry >>> >>> >>> >>>> Ciao Hannes >>>> >>>> The QSPEC-draft says in section 5 >>>> >>>> >>>>> that all parameters listed in the next sections are >>>>> mandatory. The QSPEC-draft also says in section 4.1 that "a >>>>> given QOSM defines which of the >>>> >>>> mandatory and >>>> >>>> >>>>> optional parameters it uses, ..." >>>>> >>>>> Are there any specific parameters which makes the open >> >> issue B.1.1. >> >>>>> clearer? Following the QSPEC-draft there doesn't seem to be >>>> >>>> a conflict, >>>> >>>> >>>>> if nothing is done with the unneeded parameters. >>>>> >>>>> Thanks, Bernd > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 10:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPBt-0002LD-Vj; Mon, 03 Jul 2006 10:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPBs-0002Im-3p for nsis@ietf.org; Mon, 03 Jul 2006 10:14:20 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxPBq-0008Pm-Pi for nsis@ietf.org; Mon, 03 Jul 2006 10:14:20 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k63EEIsk009689; Mon, 3 Jul 2006 10:14:18 -0400 (EDT) In-Reply-To: <44A8CFC5.7010802@gmx.net> Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List To: "Ash, Gerald R \(Jerry\), ALABS" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Mon, 3 Jul 2006 10:14:15 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/03/2006 10:13:12 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: John Rosenberg , Kappler Cornelia , NSIS , Attila =?ISO-8859-1?Q?B=E1der_=28IJ=2FETH=29?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Nits with regard to RPH. References should be updated to include RFC4412 (instead of just the ID) In section 7.2.7.3 you show a mapping between the text values and numeric values for RPH priority. (The mappings for ets and wps are fine) For dsn and drsn you show 4 - dsn.routine 3 - dsn.priority 2 - dsn.immediate 1 - dsn.flash 0 - dsn.flash-override 5 - drsn.routine 4 - drsn.priority 3 - drsn.immediate 2 - drsn.flash 1 - drsn.flash-override 0 - drsn.flash-override-override You might want to check with the intended users of those namesapces, as I understand (see recent email on the IEPREP mailing list) that DISA intends to use a quite different numerical mapping, with "0" for routine in all cases. "The current DISA specification for MLPP on VoIP networks specifies RPH r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of priority (e.g. 0 = Routine and 9 = F-O-O)." It will be very confusing if one numeric mapping is used in SIP and a different, opposing, mapping is used in QSPEC. Thanks 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. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 10:21:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPIp-000430-QZ; Mon, 03 Jul 2006 10:21:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPIo-00042v-SI for nsis@ietf.org; Mon, 03 Jul 2006 10:21:30 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxPIo-0000AR-AQ for nsis@ietf.org; Mon, 03 Jul 2006 10:21:30 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k63ELNWQ003543; Mon, 3 Jul 2006 15:21:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Legacy NAT traversal for NSIS Date: Mon, 3 Jul 2006 15:22:24 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Legacy NAT traversal for NSIS Thread-Index: AcadRTG2CJAETM0lT4iiyEbOcHvg6QBYpi1A From: "Hancock, Robert" To: "Hannes Tschofenig" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Andreas.Pashalidis@siemens.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, i think this topic is certainly necessary to discuss, and this is an interesting approach. essentially, the way i would see it is that you use a UDP tunnel between GIST peers to traverse the dumb NAT so it can do basically nothing to the traffic/signalling stream, and instead have proper GIST-aware NAT functionality at the nodes either side. this sounds architecturally neat (in so far as that phrase could be applied to NATs...), and relatively robust. my biggest question about the approach is that the discussion is mostly about a flow which goes through the legacy NAT in the=20 internal->external direction (same as the initial Query for the signalling). how does one handle a flow in the other direction?=20 it's a different flow, so either one needs a technique to get the Query through the NAT the other way, or to rely on the upstream=20 encapsulation. Each has its tricky side. This has struck me in=20 the past as the hardest part of the problem. some more detailed comments: section 2: you refer to the GIST spec for NI/NR/DS/DR but actually that document doesn't define or use the terms. in particular, I think of NI/NR as NSLP layer terminology which might not be appropriate here. section 4 bullet 2: i don't see the need for precise matching of packets to interfaces. wouldn't arriving on the correct 'side' of the NAT be enough? section 4 bullet 3: strictly, GIST can indicate a possible=20 routing change in some of these circumstances (e.g. if inbound/ outbound interfaces change, or a TTL changes). i don't think this changes the argument however. page 7 last bullet: the phrasing of this condition might need to be refined if you consider the upstream query as well. general question: how should the upstream node handle refreshing Queries? i guess it should generate 'normal' queries (with the=20 RAO included and not tunnelled), but then there would be a question of whether it should use the existing UDP source port or a new one (thus creating a new binding at the NAT). page 8: i'm not sure about extending the stack proposal this way, but it's not a critical issue for the basic form of the solution. page 9 first para: the packet analysis rules are not quite perfect. for example, a Query would be identified as a data packet, as would any GIST message if the GIST node in question was also the flow endpoint. however, the standard GIST rules should be able to cover these cases. page 9, penultimate paragraph: i think full NAT processing=20 (whatever that means) is required here, including e.g. source port remapping, checksum fixups and so on, not just source address rewriting. (consider the case of two nodes behind the same NAT.) cheers, robert h. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 01 July 2006 20:32 > To: john.loughney@nokia.com > Cc: Andreas.Pashalidis@siemens.com; nsis@ietf.org > Subject: Re: [NSIS] Legacy NAT traversal for NSIS >=20 >=20 > Hi John, > Hi Saikat, >=20 > thanks for the feedback. I definitely think that we should=20 > explore the=20 > usage of these protocols in context with GIST for legacy NAT=20 > traversal. >=20 > Ciao > Hannes >=20 > john.loughney@nokia.com wrote: > > Hi Saikat, > >=20 > > You're observations are right - if we want, we can run GIST over > > any 'standard' NAT traveral mechanisms (TERADO, STUN, TURN).=20 > >=20 > > I think working through this would be a useful exercise. > >=20 > > John > >=20 > >=20 > >>On Mon, 2006-06-19 at 15:22 +0200, Pashalidis, Andreas wrote: > >> > >>>Is anyone interested to make NSIS work through legacy NATs ?? (i.e. > >>>NSIS-unaware NATs) > >>> > >>>Under the following link a preliminary document (in I-D format) can > >=20 > > be=20 > >=20 > >>>found that describes a solution approach. > >>> > >> > >>http://www.tschofenig.priv.at/TEMP/draft-pashalidis-nsis-gist-legac > >>ynats-00. > >> > >>>txt > >>> > >>>In an exremely small nutshell: the idea is to tunnel both=20 > signalling=20 > >>>and data traffic over a single UDP NAT binding. > >> > >>I haven't gone through the document throughly, but the=20 > >>underlying transport you propose reminds me of TEREDO (which=20 > >>is over IPv6 over UDP over IPv4, where the UDP=20 > >>over IPv4 is punched through legacy NATs with the help of=20 > >>STUN/TURN/ICE etc.) One could potentially run GIST over TEREDO=20 > >>and keep the signaling and data channel separate in > >>IPv6 land even though they use the same NAT binding in IPv4 land. > >> > >>Alternatively, TURN (public-data-relay protocol for traversing=20 > >>the worst of NATs) now has some lightweight framing=20 > >>capability; the framing in TURN could potentially be extended=20 > >>to carry any in-band signals including GIST.=20 > >> > >>-- > >>Saikat > >> > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 10:36:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPXW-0006BO-VM; Mon, 03 Jul 2006 10:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPXW-0006BI-1p for nsis@ietf.org; Mon, 03 Jul 2006 10:36:42 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxPXV-0000hI-3N for nsis@ietf.org; Mon, 03 Jul 2006 10:36:42 -0400 Received: (qmail invoked by alias); 03 Jul 2006 14:36:40 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp029) with SMTP; 03 Jul 2006 16:36:40 +0200 X-Authenticated: #29516787 Message-ID: <44A92B78.7020905@gmx.net> Date: Mon, 03 Jul 2006 16:36:40 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <001b01c69e93$f0393560$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <001b01c69e93$f0393560$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 56904003e9d74831849863e83b1962ec Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , 'Kappler Cornelia' , nsis@ietf.org, =?ISO-8859-1?Q?=22=27Attila_B=E1der_=28IJ/ETH=29=27=22?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, please find my comment below: Georgios Karagiannis wrote: > Hi Jerry > > Regarding your last point: > >>>Hannes: >>>Do you think it is awfully realistic for all QNEs to understand all >>>mandatory parameters? I could imagine that Attila and >>>Georgios are not >>>going to implement stateless interior QNEs in such a way that they >>>understand all the mandatory QSPEC parameters. In fact they >>>don't have >>>todo it since only edge routers are likely to ever see QoS >>>NSLP messages >>>that contain QOSM IDs that they do not understand (otherwise >>>something >>>go terribly wrong). > > >>Jerry: It is up the RMD authors to specify how they want RMD >> >>>to behave wrt mandatory parameters (and obtain rough >>>consensus, of course). That is, if a mandatory parameter >>>is remapped and not strictly interpreted, the remapping >>>must be specified in the QOSM specification document. >>>Otherwise, the QOSM must strictly interpret the mandatory >>>parameters that are not remapped, if they are populated by the QNI. >>>There are no restrictions on how the remapping must be done, >>>it can be as simple as necessary (but no simpler). > > > Georgios: > Jerry, I think that the point raised by Hannes is related to > how the QNE's interior to the RMD domain will have to comply to the > mandatory descriptions specified in the QSPEC template. > An interior QNE (in RMD-QOSM) will not process > the end to end QSpec. The only QSpec that will be processed by the > interior QNE is the RMD Qsepc that is initiated by the > ingress node (i.e., QNI for the RMD local session). > Note that the above observation is valid for all local QOSMs. > However, the above is not allowed due to the following text that is > included in the QSpec template draft: > > "A QNE MUST interpret all mandatory parameters from this document even > if it does not support the received QoS NSLP message with the > indicated QOSM." > > Therefore, in my opinion it is required to modify the above sentence in > something like: > > "A QNE SHOULD interpret all mandatory parameters from this document even > if it does not support the received QoS NSLP message with the > indicated QOSM. A QNE that supports a local QOSM, does not have to interpret > > all mandatory parameters carried by a QSpec that was generated by a QNI > located outside the domain that supports the given local QOSM." Something along these lines would probably be more realistic, I guess. Ciao Hannes > Best regards, > Georgios > > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: maandag 3 juli 2006 2:03 > To: Hannes Tschofenig > Cc: Ash, Gerald R (Jerry), ALABS; Attila Báder (IJ/ETH); nsis@ietf.org; > Kappler Cornelia > Subject: RE: [NSIS] draft-qosmodel-controlledload-04 > > Hi Hannes, > > See below. > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Saturday, July 01, 2006 4:26 PM >>To: Ash, Gerald R (Jerry), ALABS >>Cc: nsis@ietf.org >>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >> >>Hi Jerry, >> >>it is true that I haven't read the most recent QSPEC draft when I sent >>this mail. In the meanwhile I did. Please find a few comments below: >> >>Ash, Gerald R (Jerry), ALABS wrote: >> >>>Hi Hannes, >>> >>>See below. >>> >>> >>> >>>>-----Original Message----- >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>Sent: Friday, June 30, 2006 8:43 AM >>>>To: Bernd Schloer >>>>Cc: nsis@ietf.org >>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>> >>>>Hi Bernd, >>>> >>>>Bernd Schloer wrote: >>>> >>>> >>>>>Hi, >>>>> >>>>>the first open issue in the appendix B is about what to do with >>>>>mandatory QSPEC parameters which are not needed for CLS. >>>>> >>>>>Does a QOSM have to understand (and provide information about) all >>>>>mandatory parameters, even if they are not used? >>>> >>>>I think the question is wrong. What about the following question: >>>>" >>>>Does a node that implements a particular QOSM has to understand all >>>>mandatory parameters listed in the QSPEC template draft >> >>(even if the >> >>>>QOSM does not make use of them)? >>>>" >>>>The answer would be "YES" since the QSPEC template draft says that >>>>mandatory parameters have to be understood by every NSIS QoS node. >>>> >>>>There is only the question what "understands" means. >>> >>> >>>IMO you need to more carefully read the QSPEC I-D document. All >>>mandatory QSPEC parameters that are populated in the QSPEC must be >>>interpreted by every QNE, which is explained in the QSPEC I-D: >>> >>>It says in Section 4.4.1 (Mandatory and Optional QSPEC >> >>. Parameters) of >> >>>the QSPEC I-D >>>http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: >>> >>>" Mandatory QSPEC parameters are treated as follows: >>> >>> o A QNI SHOULD populate mandatory QSPEC parameters if >> >>. applicable to >> >>> the underlying QOSM. >> >>I don't understand this sentence. What does it mean that a QNI >>"SHOULD" >>populate parameters if applicable? > > > It means that a QNI is not required to populate all mandatory parameters. A > QNI would only populated a mandatory parameter if is used by the QOSM > supported by the QNI. > > >>> o QNEs MUST interpret mandatory QSPEC parameters, if signaled." >>> >>>Furthermore, it says in Section 4.2 (QSPEC Processing): >>> >>>" a QNE >>> MUST at least interpret all the mandatory parameters in >>> a QSPEC even >>> if it does not support the corresponding QOSM. >>> >>> Mandatory parameters provide a minimal subset of parameters. A >>> QNE MUST either a) strictly interpret a mandatory parameter, or >>> b) remap the parameter and raise the flag >>> defined in >>> Section 5.1, where the remapping MUST be specified in the QOSM >>> specification. Here the terminology 'strictly >>> interpret' means that >> >>What is the difference between 'strictly interpret' and 'interpret'? >>In the rest of the document you use 'interpret'. > > > 'Strictly interpret' is defined in the text I quoted from Section 4.2 (QSPEC > Processing), which is given again in the very next sentences I quoted just > below (after you posed your above question :-) > > " Mandatory parameters provide a minimal subset of parameters. A > QNE MUST either a) strictly interpret a mandatory parameter, or > b) remap the parameter and raise the flag defined in > Section 5.1, where the remapping MUST be specified in the QOSM > specification. Here the terminology 'strictly interpret' means that > the parameter is implemented according to the commonly accepted > definition and/or as specified by references given for each QSPEC > parameter. This means that in case a), a parameter > must be strictly interpreted as a token bucket. However, in case b), > a parameter may be remapped, perhaps to a > parameter." > > In the document, the term 'interpret' a mandatory parameter means either a) > strictly interpret (as defined above), or b) remap (as defined above). > Perhaps this can be made clearer in the text. > > >>> the parameter is implemented according to the commonly accepted >>> definition and/or as specified by references given for each QSPEC >>> parameter. This means that in case a), a >>> parameter >>> must be strictly interpreted as a token bucket. >>> However, in case b), >>> a parameter may be remapped, perhaps to a >>> >>> parameter. >> >>I noticed this text improvement and I am happy to see more text about >>it. >> >>Still, I have some issues with the section: >> >>I had a problem with this paragraph following the previous one in the >>section. The previous paragraph said " >>However, if a QSPEC arrives at a QNE that does >> not support the QOSM being signaled, it can still understand the >> QSPEC content, at least to a basic degree. >>" >> >>When I read through the text I got the impression that the two >>sections relate to each other and in fact they do not. Hence, I >>suggest to delete the previous paragraph since this one contains the >>info already. > > > I'm unclear as to which paragraph/text you are proposing to delete. > > >>You >>might also want to delete the second paragraph as well since it is far >>too obvious to use RFC2119 language: If you don't support even a >>single QOSM then why are you a QOS NSLP node in the first place. > > > I think it important to state that a QNE MUST support at least one QOSM, > even if this is clearly necessary to effectively support QoS-NSLP/QSPEC. > > >>You might want to highlight the following sentence, though: >> >>" >>A QNE MUST interpret all mandatory parameters from this document even >>if it does not support the received QoS NSLP message with the >>indicated QOSM. >>" >> >>Here is my proposal for the section: >> >>" >>4.2 QSPEC Processing >> >> The QSPEC is opaque to the QoS NSLP processing. The QSPEC control >> information and the QoS description are interpreted and MAY be >> modified by the RMF in a QNE (see description in [QoS-SIG]). >> >> The QSPEC contains a QOSM ID, i.e. information on what >> QOSM is being >> signaled by the QNI. However, if a QSPEC arrives at a >> QNE that does >> not support the QOSM being signaled, it can still understand the >> QSPEC content, at least to a basic degree. This is >> because mandatory >> parameters have been defined as a common language. >> Therefore, a QNE >> MUST at least interpret all the mandatory parameters in a >> QSPEC even >> if it does not support the corresponding QOSM. >> >> A QNE MUST either >> >> a) interpret a mandatory parameter carried in the QSPEC object, or >> >> b) remap the parameter and raise the flag >> defined in >> Section 5.1, where the remapping MUST be specified in the QOSM >> specification. >> >> Here the terminology 'interpret' means that >> the parameter is implemented according to the references >> given for >> each QSPEC parameter. >> >> If a QSPEC arrives at a QNE that does not support the QOSM being >> signaled, it can still understand the QSPEC content, at least to a >> basic degree. Hence, with case (a), a parameter >> must be strictly interpreted as a token bucket. >> >> In case b), a parameter may be remapped, >> perhaps to a >> parameter. >>" > > > I don't see any benefit in redefining what 'interpret' means in the > document. As I mentioned above, the document uses the term 'interpret' to > mean that a mandatory parameter is 'interpreted' if is either 'strictly > interpreted' or it is 'remapped' (where the remapping must be defined in the > QOSM specification document). OTOH, it might be useful to define a > 'remapping' flag to indicated if a mandatory or optional parameter has been > remapped by a QNE in the path. > > >>Btw, have you noticed that the draft has >>* a flag (Section 5.1) >>* a parameter (Section 7.2.1) >> >>I think they refer to the same concept... > > > Yes, good catch. is indeed intended to be a flag, and > perhaps one of the QSPEC object flags defined in Section 7.1 could be used > for this purpose, rather than use a full 32-bit parameter for this purpose, > as currently specified in Section 7.2.1. > > >>> In the latter case, the remapping of the to >>> must be specified in the QOSM specification document. >>> For example, QOSM X exclusively uses the parameter >>> . It >>> must define a mapping of the mandatory parameter . >>> The mapping consists of interpreting the Token Bucket Rate as >>> the parameter and disregarding the other Token Bucket >>> parameters. Clearly, some information contained in the >> Bucket> parameter is lost by this mapping, and the >>> resulting QoS may >>> not be quite what was intended by the QNI. Therefore, >>> QOSM X also >>> specifies that the flag be raised. Thus, >>> a QNE using >>> QOSM X is able to make an informed decision whether to admit a >>> reservation described in terms of , and at the same >>> time (by means of ) signals to the QNI/QNR that the >>> exact intention of the QNI may not be met." >>> >>>I think this text is pretty clear as to what is required regarding >>>interpreting mandatory parameters. If not, please suggest >>>clarifications. >> >>The text in the new draft has improved a lot. >>Thanks for the update. >> >> >>> >>>>Another possible question would be: >>>>" >>>>Does a node that implements a particular QOSM has to define mappings >>> >>>>from all mandatory parameters listed in the QSPEC template draft to >>> >>>>the QOSM draft (even if the QOSM does not make use >> >>of them)? >> >>>>" >>>> >>>>The answer is "I don't know". >>> >>> >>>A QNE must interpret all mandatory parameters, if populated, as >>>explained in the above text I quoted. If a QOSM re-maps a mandatory >>>QSPEC parameter, that re-mapping must be defined in the QOSM >>>specification. As stated in Section 4.7 (QOSM Specification >>>Requirements): >>> >>>" A QOSM specification MUST define QSPEC parameter >>> behavior for these >>> cases: a) new optional QSPEC parameters the QOSM specification >>> defines, and b) remapping of existing mandatory or optional QSPEC >>> parameters, as described in Section 4.2. Unless >>> otherwise specified >>> in the QOSM specification document, the behaviors to strictly >>> interpret the mandatory and optional QSPEC parameters >>> are defined in >>> this document through the references to RFCs that >>> precisely define >>> the QSPEC parameter behaviors. >>> >>> A QOSM specification MUST define how the mandatory >>> parameters are to >>> be mapped onto the QSPEC parameters used by the QOSM, however the >>> mapping MAY result in slight modification to the intended >>> specification when an exact mapping is not possible. >>> This definition >>> MUST allow a QNE implementing this QOSM to make a decision as to >>> whether a reservation described in terms of mandatory >>> parameters can >>> be admitted. If for a particular mandatory parameter no >>> mapping can >>> be found that guarantees the desired QoS, the QNE is >>> advised to raise >>> the flag. In other words, for all mandatory >>> parameters a mapping must be defined, but it is acknowledged that >>> this mapping may result in slightly bending the original >>> intention of >>> the QNI." >>> >>>I think this text is pretty clear as to what is required. If not, >>>please suggest clarifications. >> >>I understood the token bucket to bandwidth example. >> >>Would the RMD draft, for example, list all mandatory parameters and >>indicate whether it can map them (and how) to parameters used >>in the RMD >>specification? > > > As stated in the QOSM specification requirements in Section 4.7, if a QOSM > remaps a mandatory parameter, the remapping must be defined in the QOSM > specification document. If no such remapping is defined, the default > behavior is that the QOSM must strictly interpret the mandatory parameter, > as defined above. > > >>Do you think it is awfully realistic for all QNEs to understand all >>mandatory parameters? I could imagine that Attila and >>Georgios are not >>going to implement stateless interior QNEs in such a way that they >>understand all the mandatory QSPEC parameters. In fact they >>don't have >>todo it since only edge routers are likely to ever see QoS >>NSLP messages >>that contain QOSM IDs that they do not understand (otherwise >>something >>go terribly wrong). > > > It is up the RMD authors to specify how they want RMD to behave wrt > mandatory parameters (and obtain rough consensus, of course). That is, if a > mandatory parameter is remapped and not strictly interpreted, the remapping > must be specified in the QOSM specification document. Otherwise, the QOSM > must strictly interpret the mandatory parameters that are not remapped, if > they are populated by the QNI. > > There are no restrictions on how the remapping must be done, it can be as > simple as necessary (but no simpler). > > Thanks, > Jerry > > >> >>Ciao >>Hannes >> >> >>>Thanks, >>>Jerry >>> >>> >>> >>>>Ciao >>>>Hannes >>>> >>>> The QSPEC-draft says in section 5 >>>> >>>> >>>>>that >>>>>all parameters listed in the next sections are mandatory. The >>>>>QSPEC-draft also >>>>>says in section 4.1 that "a given QOSM defines which of the >>>> >>>>mandatory and >>>> >>>> >>>>>optional parameters it uses, ..." >>>>> >>>>>Are there any specific parameters which makes the open >> >>issue B.1.1. >> >>>>>clearer? Following the QSPEC-draft there doesn't seem to be >>>> >>>>a conflict, >>>> >>>> >>>>>if nothing is >>>>>done with the unneeded parameters. >>>>> >>>>>Thanks, >>>>>Bernd > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 11:07:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQ1A-0004S0-Fg; Mon, 03 Jul 2006 11:07:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQ18-0004Rv-Tw for nsis@ietf.org; Mon, 03 Jul 2006 11:07:18 -0400 Received: from [203.232.224.4] (helo=www.hufs.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQ0u-0004nN-GS for nsis@ietf.org; Mon, 03 Jul 2006 11:07:18 -0400 Received: from www.hufs.ac.kr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0E24C24A026; Tue, 4 Jul 2006 00:04:03 +0900 (KST) X-GSRefID: str=0001.0A090207.44A93054.006E,ss=1,fgs=0 X-GSRefID: str=0001.0A090208.44A93053.0085,ss=1,fgs=0 Received: from 127.0.0.1 by 127.0.0.1(smtpfilter) with ESMTP; Tue, 04 Jul 2006 00:04:01 +0900 (KST) X-Mail-from: Received: from hufsshjeong (unknown [203.253.70.47]) by www.hufs.ac.kr (Postfix) with ESMTP; Tue, 4 Jul 2006 00:04:01 +0900 (KST) From: "Seong-Ho Jeong" To: "'Hannes Tschofenig'" , "'NSIS'" Subject: RE: [NSIS] draft-jeong-nsis-3gpp-qosm Date: Tue, 4 Jul 2006 00:06:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <44A7B079.2030404@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcadzADcpXaQvsAhTouwqoo8zANmxQA34G+A Message-Id: <20060703150403.0E24C24A026@www.hufs.ac.kr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, We are still interested to resubmit the draft. Liaison between 3GPP and IETF regarding the use of NSIS in 3GPP networks might be good for further progress. Thanks and regards, Seong-Ho >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: Sunday, July 02, 2006 8:40 PM >To: NSIS >Subject: [NSIS] draft-jeong-nsis-3gpp-qosm > >Hi all, > >I wanted to see what different QoSMs do with respect to their >QoS parameter description. I remembered this draft: > >---------- >3GPP QoS Model for Networks Using 3GPP QoS Classes >http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt >---------- > >It is expired. Are there any plans to resubmit it? > >Ciao >Hannes > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 11:11:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQ4o-0005ad-Mx; Mon, 03 Jul 2006 11:11:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQ4n-0005aY-N5 for nsis@ietf.org; Mon, 03 Jul 2006 11:11:05 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQ4m-0004yH-Ey for nsis@ietf.org; Mon, 03 Jul 2006 11:11:05 -0400 Received: from sundial.cs.cornell.edu ([128.84.96.115]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 11:11:03 -0400 Received: from himalaya.cs.cornell.edu (himalaya.cs.cornell.edu [128.84.223.110]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.25) with ESMTP id k63FB3v25115; Mon, 3 Jul 2006 11:11:03 -0400 (EDT) Subject: RE: [NSIS] Legacy NAT traversal for NSIS From: Saikat Guha To: "Hancock, Robert" In-Reply-To: References: Date: Mon, 03 Jul 2006 16:11:03 +0100 Message-Id: <1151939463.10751.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-OriginalArrivalTime: 03 Jul 2006 15:11:03.0920 (UTC) FILETIME=[E6BDBF00:01C69EB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: john.loughney@nokia.com, nsis@ietf.org, Andreas.Pashalidis@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1313287794==" Errors-To: nsis-bounces@ietf.org --===============1313287794== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jyS+IWTm3wMz0i4IxVns" --=-jyS+IWTm3wMz0i4IxVns Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2006-07-03 at 15:22 +0100, Hancock, Robert wrote: > my biggest question about the approach is that the discussion > is mostly about a flow which goes through the legacy NAT in the=20 > internal->external direction (same as the initial Query for the > signalling). how does one handle a flow in the other direction?=20 > it's a different flow, so either one needs a technique to get the > Query through the NAT the other way, or to rely on the upstream=20 > encapsulation. Each has its tricky side. This has struck me in=20 > the past as the hardest part of the problem. Are you referring to an inbound GIST flow to a NAT'ed peer that is not expecting it, or an inbound flow in response to an outbound flow. (apologies for not having enough GIST context). If it is the former, i.e. an out-of-the-blue inbound GIST flow to a NAT'ed peer, then you would need legacy NAT traversal involving some sort of a rendezvous service to get that peer to know when to punch open holes in its NAT. If it is the latter, i.e. inbound flow in response to an existing flow, then the NAT'ed peer may be able to receive the new flow as-is (for certain types of NATs), or be required punch the holes for the new flow by using the existing flow as the rendezvous channel. --=20 Saikat --=-jyS+IWTm3wMz0i4IxVns Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQBEqTOHnFltqi691/oRAssuAJ0dhMxoJI9+WZOBc/UFT/ozPIhoqgCcD+zt cf9580NBvrj45/4ktC5pe+w= =vCTe -----END PGP SIGNATURE----- --=-jyS+IWTm3wMz0i4IxVns-- --===============1313287794== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1313287794==-- From nsis-bounces@ietf.org Mon Jul 03 11:22:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQFN-0008Bp-Nc; Mon, 03 Jul 2006 11:22:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQFM-0008Bk-D4 for nsis@ietf.org; Mon, 03 Jul 2006 11:22:00 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQFI-0005HP-VO for nsis@ietf.org; Mon, 03 Jul 2006 11:22:00 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0FB02560003; Mon, 3 Jul 2006 17:21:56 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 17:21:54 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 17:21:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] draft-qosmodel-controlledload-04 Date: Mon, 3 Jul 2006 17:21:53 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D055DFE60@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] draft-qosmodel-controlledload-04 Thread-Index: AcaerhrDt1QnY4ZpTtaSvEqATx1ERwABOGXA From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Hannes Tschofenig" , "Georgios Karagiannis" X-OriginalArrivalTime: 03 Jul 2006 15:21:53.0928 (UTC) FILETIME=[6A2D1880:01C69EB4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 8104b3fcabb4d2dfaed548848b9dc80f Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org, Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi All, If "ignore" is not a type interpretation, I also think that it should be = reformulated. In general, to understend mandatory parameters that is not used in a = local QoSM, I see less problem. If a QOSM has to fill in mandatory = parameters that is not used in this QOSM, seems to be more difficult. Best regards, Attila > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, July 03, 2006 4:37 PM > To: Georgios Karagiannis > Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila B=E1der (IJ/ETH); > nsis@ietf.org; 'Kappler Cornelia' > Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >=20 >=20 > Hi Georgios, >=20 > please find my comment below: >=20 > Georgios Karagiannis wrote: > > Hi Jerry=20 > >=20 > > Regarding your last point: > >=20 > >>>Hannes: > >>>Do you think it is awfully realistic for all QNEs to=20 > understand all=20 > >>>mandatory parameters? I could imagine that Attila and=20 > >>>Georgios are not=20 > >>>going to implement stateless interior QNEs in such a way that they=20 > >>>understand all the mandatory QSPEC parameters. In fact they=20 > >>>don't have=20 > >>>todo it since only edge routers are likely to ever see QoS=20 > >>>NSLP messages=20 > >>>that contain QOSM IDs that they do not understand (otherwise=20 > >>>something=20 > >>>go terribly wrong). > >=20 > >=20 > >>Jerry: It is up the RMD authors to specify how they want RMD=20 > >> > >>>to behave wrt mandatory parameters (and obtain rough=20 > >>>consensus, of course). That is, if a mandatory parameter=20 > >>>is remapped and not strictly interpreted, the remapping=20 > >>>must be specified in the QOSM specification document. =20 > >>>Otherwise, the QOSM must strictly interpret the mandatory=20 > >>>parameters that are not remapped, if they are populated by the QNI. > >>>There are no restrictions on how the remapping must be done,=20 > >>>it can be as simple as necessary (but no simpler). > >=20 > >=20 > > Georgios: > > Jerry, I think that the point raised by Hannes is related to > > how the QNE's interior to the RMD domain will have to comply to the > > mandatory descriptions specified in the QSPEC template.=20 > > An interior QNE (in RMD-QOSM) will not process=20 > > the end to end QSpec. The only QSpec that will be processed by the=20 > > interior QNE is the RMD Qsepc that is initiated by the=20 > > ingress node (i.e., QNI for the RMD local session).=20 > > Note that the above observation is valid for all local QOSMs. > > However, the above is not allowed due to the following text that is=20 > > included in the QSpec template draft: > >=20 > > "A QNE MUST interpret all mandatory parameters from this=20 > document even=20 > > if it does not support the received QoS NSLP message with the=20 > > indicated QOSM." > >=20 > > Therefore, in my opinion it is required to modify the above=20 > sentence in > > something like: > >=20 > > "A QNE SHOULD interpret all mandatory parameters from this=20 > document even=20 > > if it does not support the received QoS NSLP message with the=20 > > indicated QOSM. A QNE that supports a local QOSM, does not=20 > have to interpret > >=20 > > all mandatory parameters carried by a QSpec that was=20 > generated by a QNI=20 > > located outside the domain that supports the given local QOSM."=20 > Something along these lines would probably be more realistic, I guess. >=20 > Ciao > Hannes >=20 > > Best regards, > > Georgios > >=20 > > -----Original Message----- > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > > Sent: maandag 3 juli 2006 2:03 > > To: Hannes Tschofenig > > Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH);=20 > nsis@ietf.org; > > Kappler Cornelia > > Subject: RE: [NSIS] draft-qosmodel-controlledload-04 > >=20 > > Hi Hannes, > >=20 > > See below.=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>Sent: Saturday, July 01, 2006 4:26 PM > >>To: Ash, Gerald R (Jerry), ALABS > >>Cc: nsis@ietf.org > >>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 > >> > >>Hi Jerry, > >> > >>it is true that I haven't read the most recent QSPEC draft=20 > when I sent=20 > >>this mail. In the meanwhile I did. Please find a few comments below: > >> > >>Ash, Gerald R (Jerry), ALABS wrote: > >> > >>>Hi Hannes, > >>> > >>>See below.=20 > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>Sent: Friday, June 30, 2006 8:43 AM > >>>>To: Bernd Schloer > >>>>Cc: nsis@ietf.org > >>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 > >>>> > >>>>Hi Bernd, > >>>> > >>>>Bernd Schloer wrote: > >>>> > >>>> > >>>>>Hi, > >>>>> > >>>>>the first open issue in the appendix B is about what to do with=20 > >>>>>mandatory QSPEC parameters which are not needed for CLS. > >>>>> > >>>>>Does a QOSM have to understand (and provide information=20 > about) all=20 > >>>>>mandatory parameters, even if they are not used? > >>>> > >>>>I think the question is wrong. What about the following question: > >>>>" > >>>>Does a node that implements a particular QOSM has to=20 > understand all=20 > >>>>mandatory parameters listed in the QSPEC template draft > >> > >>(even if the > >> > >>>>QOSM does not make use of them)? > >>>>" > >>>>The answer would be "YES" since the QSPEC template draft=20 > says that=20 > >>>>mandatory parameters have to be understood by every NSIS QoS node. > >>>> > >>>>There is only the question what "understands" means. > >>> > >>> > >>>IMO you need to more carefully read the QSPEC I-D document. All=20 > >>>mandatory QSPEC parameters that are populated in the QSPEC must be=20 > >>>interpreted by every QNE, which is explained in the QSPEC I-D: > >>> > >>>It says in Section 4.4.1 (Mandatory and Optional QSPEC > >> > >>. Parameters) of > >> > >>>the QSPEC I-D > >>>http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: > >>> > >>>" Mandatory QSPEC parameters are treated as follows: > >>> > >>> o A QNI SHOULD populate mandatory QSPEC parameters if > >> > >>. applicable to > >> > >>> the underlying QOSM. > >> > >>I don't understand this sentence. What does it mean that a QNI=20 > >>"SHOULD" > >>populate parameters if applicable? > >=20 > >=20 > > It means that a QNI is not required to populate all=20 > mandatory parameters. A > > QNI would only populated a mandatory parameter if is used=20 > by the QOSM > > supported by the QNI. > > =20 > >=20 > >>> o QNEs MUST interpret mandatory QSPEC parameters, if signaled." > >>> > >>>Furthermore, it says in Section 4.2 (QSPEC Processing): > >>> > >>>" a QNE > >>> MUST at least interpret all the mandatory parameters in=20 > >>> a QSPEC even > >>> if it does not support the corresponding QOSM. > >>> > >>> Mandatory parameters provide a minimal subset of parameters. A > >>> QNE MUST either a) strictly interpret a mandatory parameter, or > >>> b) remap the parameter and raise the flag=20 > >>> defined in > >>> Section 5.1, where the remapping MUST be specified in the QOSM > >>> specification. Here the terminology 'strictly=20 > >>> interpret' means that > >> > >>What is the difference between 'strictly interpret' and=20 > 'interpret'?=20 > >>In the rest of the document you use 'interpret'. > >=20 > >=20 > > 'Strictly interpret' is defined in the text I quoted from=20 > Section 4.2 (QSPEC > > Processing), which is given again in the very next=20 > sentences I quoted just > > below (after you posed your above question :-) > >=20 > > " Mandatory parameters provide a minimal subset of parameters. A > > QNE MUST either a) strictly interpret a mandatory parameter, or > > b) remap the parameter and raise the flag=20 > defined in > > Section 5.1, where the remapping MUST be specified in the QOSM > > specification. Here the terminology 'strictly=20 > interpret' means that > > the parameter is implemented according to the commonly accepted > > definition and/or as specified by references given for each QSPEC > > parameter. This means that in case a), a =20 > parameter > > must be strictly interpreted as a token bucket. =20 > However, in case b), > > a parameter may be remapped, perhaps to a=20 > > > parameter." > >=20 > > In the document, the term 'interpret' a mandatory parameter=20 > means either a) > > strictly interpret (as defined above), or b) remap (as=20 > defined above). > > Perhaps this can be made clearer in the text. > > =20 > >=20 > >>> the parameter is implemented according to the commonly accepted > >>> definition and/or as specified by references given for=20 > each QSPEC > >>> parameter. This means that in case a), a =20 > >>> parameter > >>> must be strictly interpreted as a token bucket. =20 > >>> However, in case b), > >>> a parameter may be remapped, perhaps to a=20 > >>> > >>> parameter. > >> > >>I noticed this text improvement and I am happy to see more=20 > text about=20 > >>it. > >> > >>Still, I have some issues with the section: > >> > >>I had a problem with this paragraph following the previous=20 > one in the=20 > >>section. The previous paragraph said " > >>However, if a QSPEC arrives at a QNE that does > >> not support the QOSM being signaled, it can still understand the > >> QSPEC content, at least to a basic degree. > >>" > >> > >>When I read through the text I got the impression that the two=20 > >>sections relate to each other and in fact they do not. Hence, I=20 > >>suggest to delete the previous paragraph since this one=20 > contains the=20 > >>info already. > >=20 > >=20 > > I'm unclear as to which paragraph/text you are proposing to delete. > >=20 > >=20 > >>You > >>might also want to delete the second paragraph as well=20 > since it is far=20 > >>too obvious to use RFC2119 language: If you don't support even a=20 > >>single QOSM then why are you a QOS NSLP node in the first place. > >=20 > >=20 > > I think it important to state that a QNE MUST support at=20 > least one QOSM, > > even if this is clearly necessary to effectively support=20 > QoS-NSLP/QSPEC. > >=20 > >=20 > >>You might want to highlight the following sentence, though: > >> > >>" > >>A QNE MUST interpret all mandatory parameters from this=20 > document even=20 > >>if it does not support the received QoS NSLP message with the=20 > >>indicated QOSM. > >>" > >> > >>Here is my proposal for the section: > >> > >>" > >>4.2 QSPEC Processing > >> > >> The QSPEC is opaque to the QoS NSLP processing. The=20 > QSPEC control > >> information and the QoS description are interpreted and MAY be > >> modified by the RMF in a QNE (see description in [QoS-SIG]). > >> > >> The QSPEC contains a QOSM ID, i.e. information on what=20 > >> QOSM is being > >> signaled by the QNI. However, if a QSPEC arrives at a=20 > >> QNE that does > >> not support the QOSM being signaled, it can still understand the > >> QSPEC content, at least to a basic degree. This is=20 > >> because mandatory > >> parameters have been defined as a common language. =20 > >> Therefore, a QNE > >> MUST at least interpret all the mandatory parameters in a=20 > >> QSPEC even > >> if it does not support the corresponding QOSM. > >> > >> A QNE MUST either > >> > >> a) interpret a mandatory parameter carried in the QSPEC=20 > object, or > >> > >> b) remap the parameter and raise the flag=20 > >> defined in > >> Section 5.1, where the remapping MUST be specified in the QOSM > >> specification. > >> > >> Here the terminology 'interpret' means that > >> the parameter is implemented according to the references=20 > >> given for=20 > >> each QSPEC parameter. > >> > >> If a QSPEC arrives at a QNE that does not support the QOSM being > >> signaled, it can still understand the QSPEC content, at=20 > least to a > >> basic degree. Hence, with case (a), a parameter > >> must be strictly interpreted as a token bucket. > >> > >> In case b), a parameter may be remapped,=20 > >> perhaps to a > >> parameter. > >>" > >=20 > >=20 > > I don't see any benefit in redefining what 'interpret' means in the > > document. As I mentioned above, the document uses the term=20 > 'interpret' to > > mean that a mandatory parameter is 'interpreted' if is=20 > either 'strictly > > interpreted' or it is 'remapped' (where the remapping must=20 > be defined in the > > QOSM specification document). OTOH, it might be useful to define a > > 'remapping' flag to indicated if a mandatory or optional=20 > parameter has been > > remapped by a QNE in the path. > > =20 > >=20 > >>Btw, have you noticed that the draft has > >>* a flag (Section 5.1) > >>* a parameter (Section 7.2.1) > >> > >>I think they refer to the same concept... > >=20 > >=20 > > Yes, good catch. is indeed intended to be a=20 > flag, and > > perhaps one of the QSPEC object flags defined in Section=20 > 7.1 could be used > > for this purpose, rather than use a full 32-bit parameter=20 > for this purpose, > > as currently specified in Section 7.2.1. > > =20 > >=20 > >>> In the latter case, the remapping of the to > >>> must be specified in the QOSM specification=20 > document. > >>> For example, QOSM X exclusively uses the parameter=20 > >>> . It > >>> must define a mapping of the mandatory parameter . > >>> The mapping consists of interpreting the Token Bucket Rate as > >>> the parameter and disregarding the other=20 > Token Bucket > >>> parameters. Clearly, some information contained in the >>> Bucket> parameter is lost by this mapping, and the=20 > >>> resulting QoS may > >>> not be quite what was intended by the QNI. Therefore,=20 > >>> QOSM X also > >>> specifies that the flag be raised. Thus,=20 > >>> a QNE using > >>> QOSM X is able to make an informed decision whether to admit a > >>> reservation described in terms of , and=20 > at the same > >>> time (by means of ) signals to the=20 > QNI/QNR that the > >>> exact intention of the QNI may not be met." > >>> > >>>I think this text is pretty clear as to what is required regarding=20 > >>>interpreting mandatory parameters. If not, please suggest=20 > >>>clarifications. > >> > >>The text in the new draft has improved a lot. > >>Thanks for the update. > >> > >> > >>> > >>>>Another possible question would be: > >>>>" > >>>>Does a node that implements a particular QOSM has to=20 > define mappings=20 > >>> > >>>>from all mandatory parameters listed in the QSPEC=20 > template draft to=20 > >>> > >>>>the QOSM draft (even if the QOSM does not make use > >> > >>of them)? > >> > >>>>" > >>>> > >>>>The answer is "I don't know". > >>> > >>> > >>>A QNE must interpret all mandatory parameters, if populated, as > >>>explained in the above text I quoted. If a QOSM re-maps a=20 > mandatory > >>>QSPEC parameter, that re-mapping must be defined in the QOSM > >>>specification. As stated in Section 4.7 (QOSM Specification > >>>Requirements): > >>> > >>>" A QOSM specification MUST define QSPEC parameter=20 > >>> behavior for these > >>> cases: a) new optional QSPEC parameters the QOSM specification > >>> defines, and b) remapping of existing mandatory or=20 > optional QSPEC > >>> parameters, as described in Section 4.2. Unless=20 > >>> otherwise specified > >>> in the QOSM specification document, the behaviors to strictly > >>> interpret the mandatory and optional QSPEC parameters=20 > >>> are defined in > >>> this document through the references to RFCs that=20 > >>> precisely define > >>> the QSPEC parameter behaviors. =20 > >>> > >>> A QOSM specification MUST define how the mandatory=20 > >>> parameters are to > >>> be mapped onto the QSPEC parameters used by the QOSM,=20 > however the > >>> mapping MAY result in slight modification to the intended > >>> specification when an exact mapping is not possible. =20 > >>> This definition > >>> MUST allow a QNE implementing this QOSM to make a decision as to > >>> whether a reservation described in terms of mandatory=20 > >>> parameters can > >>> be admitted. If for a particular mandatory parameter no=20 > >>> mapping can > >>> be found that guarantees the desired QoS, the QNE is=20 > >>> advised to raise > >>> the flag. In other words, for all mandatory > >>> parameters a mapping must be defined, but it is=20 > acknowledged that > >>> this mapping may result in slightly bending the original=20 > >>> intention of > >>> the QNI." > >>> > >>>I think this text is pretty clear as to what is required. If not, > >>>please suggest clarifications. > >> > >>I understood the token bucket to bandwidth example. > >> > >>Would the RMD draft, for example, list all mandatory parameters and=20 > >>indicate whether it can map them (and how) to parameters used=20 > >>in the RMD=20 > >>specification? > >=20 > >=20 > > As stated in the QOSM specification requirements in Section=20 > 4.7, if a QOSM > > remaps a mandatory parameter, the remapping must be defined=20 > in the QOSM > > specification document. If no such remapping is defined,=20 > the default > > behavior is that the QOSM must strictly interpret the=20 > mandatory parameter, > > as defined above. > > =20 > >=20 > >>Do you think it is awfully realistic for all QNEs to understand all=20 > >>mandatory parameters? I could imagine that Attila and=20 > >>Georgios are not=20 > >>going to implement stateless interior QNEs in such a way that they=20 > >>understand all the mandatory QSPEC parameters. In fact they=20 > >>don't have=20 > >>todo it since only edge routers are likely to ever see QoS=20 > >>NSLP messages=20 > >>that contain QOSM IDs that they do not understand (otherwise=20 > >>something=20 > >>go terribly wrong). > >=20 > >=20 > > It is up the RMD authors to specify how they want RMD to behave wrt > > mandatory parameters (and obtain rough consensus, of=20 > course). That is, if a > > mandatory parameter is remapped and not strictly=20 > interpreted, the remapping > > must be specified in the QOSM specification document. =20 > Otherwise, the QOSM > > must strictly interpret the mandatory parameters that are=20 > not remapped, if > > they are populated by the QNI. > >=20 > > There are no restrictions on how the remapping must be=20 > done, it can be as > > simple as necessary (but no simpler). > >=20 > > Thanks, > > Jerry > >=20 > >=20 > >> > >>Ciao > >>Hannes > >> > >> > >>>Thanks, > >>>Jerry > >>>=20 > >>> > >>> > >>>>Ciao > >>>>Hannes > >>>> > >>>> The QSPEC-draft says in section 5 > >>>> > >>>> > >>>>>that > >>>>>all parameters listed in the next sections are mandatory. The=20 > >>>>>QSPEC-draft also > >>>>>says in section 4.1 that "a given QOSM defines which of the=20 > >>>> > >>>>mandatory and > >>>> > >>>> > >>>>>optional parameters it uses, ..." > >>>>> > >>>>>Are there any specific parameters which makes the open=20 > >> > >>issue B.1.1.=20 > >> > >>>>>clearer? Following the QSPEC-draft there doesn't seem to be=20 > >>>> > >>>>a conflict,=20 > >>>> > >>>> > >>>>>if nothing is > >>>>>done with the unneeded parameters. > >>>>> > >>>>>Thanks, > >>>>>Bernd > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 18:17:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWjZ-00079L-3e; Mon, 03 Jul 2006 18:17:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWjX-00079E-Rf for nsis@ietf.org; Mon, 03 Jul 2006 18:17:35 -0400 Received: from natreg.rzone.de ([81.169.145.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxWjW-0002W1-TI for nsis@ietf.org; Mon, 03 Jul 2006 18:17:35 -0400 Received: from [192.168.178.200] (p5484CAE8.dip0.t-ipconnect.de [84.132.202.232]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k63MH8re013897; Tue, 4 Jul 2006 00:17:10 +0200 (MEST) Message-ID: <44A996C2.7010602@cs.uni-goettingen.de> Date: Tue, 04 Jul 2006 00:14:26 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <05F34B6959F19F43BBD78FFCD4C15D055DFE60@esealmw116.eemea.ericsson.se> In-Reply-To: <05F34B6959F19F43BBD78FFCD4C15D055DFE60@esealmw116.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: d70738b58489ee14fb507f541b784688 Cc: "Ash, Gerald R \(Jerry\), ALABS" , Georgios Karagiannis , nsis@ietf.org, Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, just an idea: Token Bucket is the only mandatory parameter. It is interpreted by CLS an= d=20 Y.1541. RMD can map it to Bandwidth. Other Parameters, like Path Latency,etc. are optional. If a QOSM doesn't = support=20 it, it can be skipped. Mainly two types of parameters are left: Delay, Priority. If supported by= two=20 different QOSMs, the following mapping could be tried: Delay: can be mapped to , ,= Priority: , , , Here should rather be derived from th= an vice=20 versa, as is more complex. Or in general the simple parame= ters=20 should be derived from the more complex one. The only problem I see: Do I know the QOSM of my neighbor domain? Do I ha= ve to=20 consider this when sending the initiator QSPEC? Bernd Attila B=E1der (IJ/ETH) wrote: > Hi All, >=20 > If "ignore" is not a type interpretation, I also think that it should b= e reformulated. >=20 > In general, to understend mandatory parameters that is not used in a lo= cal QoSM, I see less problem. If a QOSM has to fill in mandatory paramete= rs that is not used in this QOSM, seems to be more difficult. >=20 > Best regards, Attila >=20 >=20 >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Monday, July 03, 2006 4:37 PM >>To: Georgios Karagiannis >>Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila B=E1der (IJ/ETH); >>nsis@ietf.org; 'Kappler Cornelia' >>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >> >> >>Hi Georgios, >> >>please find my comment below: >> >>Georgios Karagiannis wrote: >> >>>Hi Jerry=20 >>> >>>Regarding your last point: >>> >>> >>>>>Hannes: >>>>>Do you think it is awfully realistic for all QNEs to=20 >> >>understand all=20 >> >>>>>mandatory parameters? I could imagine that Attila and=20 >>>>>Georgios are not=20 >>>>>going to implement stateless interior QNEs in such a way that they=20 >>>>>understand all the mandatory QSPEC parameters. In fact they=20 >>>>>don't have=20 >>>>>todo it since only edge routers are likely to ever see QoS=20 >>>>>NSLP messages=20 >>>>>that contain QOSM IDs that they do not understand (otherwise=20 >>>>>something=20 >>>>>go terribly wrong). >>> >>> >>>>Jerry: It is up the RMD authors to specify how they want RMD=20 >>>> >>>> >>>>>to behave wrt mandatory parameters (and obtain rough=20 >>>>>consensus, of course). That is, if a mandatory parameter=20 >>>>>is remapped and not strictly interpreted, the remapping=20 >>>>>must be specified in the QOSM specification document. =20 >>>>>Otherwise, the QOSM must strictly interpret the mandatory=20 >>>>>parameters that are not remapped, if they are populated by the QNI. >>>>>There are no restrictions on how the remapping must be done,=20 >>>>>it can be as simple as necessary (but no simpler). >>> >>> >>>Georgios: >>>Jerry, I think that the point raised by Hannes is related to >>>how the QNE's interior to the RMD domain will have to comply to the >>>mandatory descriptions specified in the QSPEC template.=20 >>>An interior QNE (in RMD-QOSM) will not process=20 >>>the end to end QSpec. The only QSpec that will be processed by the=20 >>>interior QNE is the RMD Qsepc that is initiated by the=20 >>>ingress node (i.e., QNI for the RMD local session).=20 >>>Note that the above observation is valid for all local QOSMs. >>>However, the above is not allowed due to the following text that is=20 >>>included in the QSpec template draft: >>> >>>"A QNE MUST interpret all mandatory parameters from this=20 >> >>document even=20 >> >>>if it does not support the received QoS NSLP message with the=20 >>>indicated QOSM." >>> >>>Therefore, in my opinion it is required to modify the above=20 >> >>sentence in >> >>>something like: >>> >>>"A QNE SHOULD interpret all mandatory parameters from this=20 >> >>document even=20 >> >>>if it does not support the received QoS NSLP message with the=20 >>>indicated QOSM. A QNE that supports a local QOSM, does not=20 >> >>have to interpret >> >>>all mandatory parameters carried by a QSpec that was=20 >> >>generated by a QNI=20 >> >>>located outside the domain that supports the given local QOSM."=20 >> >>Something along these lines would probably be more realistic, I guess. >> >>Ciao >>Hannes >> >> >>>Best regards, >>>Georgios >>> >>>-----Original Message----- >>>From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 >>>Sent: maandag 3 juli 2006 2:03 >>>To: Hannes Tschofenig >>>Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH);=20 >> >>nsis@ietf.org; >> >>>Kappler Cornelia >>>Subject: RE: [NSIS] draft-qosmodel-controlledload-04 >>> >>>Hi Hannes, >>> >>>See below.=20 >>> >>> >>> >>>>-----Original Message----- >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>Sent: Saturday, July 01, 2006 4:26 PM >>>>To: Ash, Gerald R (Jerry), ALABS >>>>Cc: nsis@ietf.org >>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>> >>>>Hi Jerry, >>>> >>>>it is true that I haven't read the most recent QSPEC draft=20 >> >>when I sent=20 >> >>>>this mail. In the meanwhile I did. Please find a few comments below: >>>> >>>>Ash, Gerald R (Jerry), ALABS wrote: >>>> >>>> >>>>>Hi Hannes, >>>>> >>>>>See below.=20 >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>Sent: Friday, June 30, 2006 8:43 AM >>>>>>To: Bernd Schloer >>>>>>Cc: nsis@ietf.org >>>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>> >>>>>>Hi Bernd, >>>>>> >>>>>>Bernd Schloer wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>the first open issue in the appendix B is about what to do with=20 >>>>>>>mandatory QSPEC parameters which are not needed for CLS. >>>>>>> >>>>>>>Does a QOSM have to understand (and provide information=20 >> >>about) all=20 >> >>>>>>>mandatory parameters, even if they are not used? >>>>>> >>>>>>I think the question is wrong. What about the following question: >>>>>>" >>>>>>Does a node that implements a particular QOSM has to=20 >> >>understand all=20 >> >>>>>>mandatory parameters listed in the QSPEC template draft >>>> >>>>(even if the >>>> >>>> >>>>>>QOSM does not make use of them)? >>>>>>" >>>>>>The answer would be "YES" since the QSPEC template draft=20 >> >>says that=20 >> >>>>>>mandatory parameters have to be understood by every NSIS QoS node. >>>>>> >>>>>>There is only the question what "understands" means. >>>>> >>>>> >>>>>IMO you need to more carefully read the QSPEC I-D document. All=20 >>>>>mandatory QSPEC parameters that are populated in the QSPEC must be=20 >>>>>interpreted by every QNE, which is explained in the QSPEC I-D: >>>>> >>>>>It says in Section 4.4.1 (Mandatory and Optional QSPEC >>>> >>>>. Parameters) of >>>> >>>> >>>>>the QSPEC I-D >>>>>http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: >>>>> >>>>>" Mandatory QSPEC parameters are treated as follows: >>>>> >>>>> o A QNI SHOULD populate mandatory QSPEC parameters if >>>> >>>>. applicable to >>>> >>>> >>>>> the underlying QOSM. >>>> >>>>I don't understand this sentence. What does it mean that a QNI=20 >>>>"SHOULD" >>>>populate parameters if applicable? >>> >>> >>>It means that a QNI is not required to populate all=20 >> >>mandatory parameters. A >> >>>QNI would only populated a mandatory parameter if is used=20 >> >>by the QOSM >> >>>supported by the QNI. >>>=20 >>> >>> >>>>> o QNEs MUST interpret mandatory QSPEC parameters, if signaled." >>>>> >>>>>Furthermore, it says in Section 4.2 (QSPEC Processing): >>>>> >>>>>" a QNE >>>>> MUST at least interpret all the mandatory parameters in=20 >>>>> a QSPEC even >>>>> if it does not support the corresponding QOSM. >>>>> >>>>> Mandatory parameters provide a minimal subset of parameters. A >>>>> QNE MUST either a) strictly interpret a mandatory parameter, or >>>>> b) remap the parameter and raise the flag=20 >>>>> defined in >>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>> specification. Here the terminology 'strictly=20 >>>>> interpret' means that >>>> >>>>What is the difference between 'strictly interpret' and=20 >> >>'interpret'?=20 >> >>>>In the rest of the document you use 'interpret'. >>> >>> >>>'Strictly interpret' is defined in the text I quoted from=20 >> >>Section 4.2 (QSPEC >> >>>Processing), which is given again in the very next=20 >> >>sentences I quoted just >> >>>below (after you posed your above question :-) >>> >>>" Mandatory parameters provide a minimal subset of parameters. A >>> QNE MUST either a) strictly interpret a mandatory parameter, or >>> b) remap the parameter and raise the flag=20 >> >>defined in >> >>> Section 5.1, where the remapping MUST be specified in the QOSM >>> specification. Here the terminology 'strictly=20 >> >>interpret' means that >> >>> the parameter is implemented according to the commonly accepted >>> definition and/or as specified by references given for each QSPEC >>> parameter. This means that in case a), a =20 >> >>parameter >> >>> must be strictly interpreted as a token bucket. =20 >> >>However, in case b), >> >>> a parameter may be remapped, perhaps to a=20 >> >> >> >>> parameter." >>> >>>In the document, the term 'interpret' a mandatory parameter=20 >> >>means either a) >> >>>strictly interpret (as defined above), or b) remap (as=20 >> >>defined above). >> >>>Perhaps this can be made clearer in the text. >>>=20 >>> >>> >>>>> the parameter is implemented according to the commonly accepted >>>>> definition and/or as specified by references given for=20 >> >>each QSPEC >> >>>>> parameter. This means that in case a), a =20 >>>>> parameter >>>>> must be strictly interpreted as a token bucket. =20 >>>>> However, in case b), >>>>> a parameter may be remapped, perhaps to a=20 >>>>> >>>>> parameter. >>>> >>>>I noticed this text improvement and I am happy to see more=20 >> >>text about=20 >> >>>>it. >>>> >>>>Still, I have some issues with the section: >>>> >>>>I had a problem with this paragraph following the previous=20 >> >>one in the=20 >> >>>>section. The previous paragraph said " >>>>However, if a QSPEC arrives at a QNE that does >>>> not support the QOSM being signaled, it can still understand the >>>> QSPEC content, at least to a basic degree. >>>>" >>>> >>>>When I read through the text I got the impression that the two=20 >>>>sections relate to each other and in fact they do not. Hence, I=20 >>>>suggest to delete the previous paragraph since this one=20 >> >>contains the=20 >> >>>>info already. >>> >>> >>>I'm unclear as to which paragraph/text you are proposing to delete. >>> >>> >>> >>>>You >>>>might also want to delete the second paragraph as well=20 >> >>since it is far=20 >> >>>>too obvious to use RFC2119 language: If you don't support even a=20 >>>>single QOSM then why are you a QOS NSLP node in the first place. >>> >>> >>>I think it important to state that a QNE MUST support at=20 >> >>least one QOSM, >> >>>even if this is clearly necessary to effectively support=20 >> >>QoS-NSLP/QSPEC. >> >>> >>>>You might want to highlight the following sentence, though: >>>> >>>>" >>>>A QNE MUST interpret all mandatory parameters from this=20 >> >>document even=20 >> >>>>if it does not support the received QoS NSLP message with the=20 >>>>indicated QOSM. >>>>" >>>> >>>>Here is my proposal for the section: >>>> >>>>" >>>>4.2 QSPEC Processing >>>> >>>> The QSPEC is opaque to the QoS NSLP processing. The=20 >> >>QSPEC control >> >>>> information and the QoS description are interpreted and MAY be >>>> modified by the RMF in a QNE (see description in [QoS-SIG]). >>>> >>>> The QSPEC contains a QOSM ID, i.e. information on what=20 >>>> QOSM is being >>>> signaled by the QNI. However, if a QSPEC arrives at a=20 >>>> QNE that does >>>> not support the QOSM being signaled, it can still understand the >>>> QSPEC content, at least to a basic degree. This is=20 >>>> because mandatory >>>> parameters have been defined as a common language. =20 >>>> Therefore, a QNE >>>> MUST at least interpret all the mandatory parameters in a=20 >>>> QSPEC even >>>> if it does not support the corresponding QOSM. >>>> >>>> A QNE MUST either >>>> >>>> a) interpret a mandatory parameter carried in the QSPEC=20 >> >>object, or >> >>>> b) remap the parameter and raise the flag=20 >>>> defined in >>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>> specification. >>>> >>>> Here the terminology 'interpret' means that >>>> the parameter is implemented according to the references=20 >>>> given for=20 >>>> each QSPEC parameter. >>>> >>>> If a QSPEC arrives at a QNE that does not support the QOSM being >>>> signaled, it can still understand the QSPEC content, at=20 >> >>least to a >> >>>> basic degree. Hence, with case (a), a parameter >>>> must be strictly interpreted as a token bucket. >>>> >>>> In case b), a parameter may be remapped,=20 >>>> perhaps to a >>>> parameter. >>>>" >>> >>> >>>I don't see any benefit in redefining what 'interpret' means in the >>>document. As I mentioned above, the document uses the term=20 >> >>'interpret' to >> >>>mean that a mandatory parameter is 'interpreted' if is=20 >> >>either 'strictly >> >>>interpreted' or it is 'remapped' (where the remapping must=20 >> >>be defined in the >> >>>QOSM specification document). OTOH, it might be useful to define a >>>'remapping' flag to indicated if a mandatory or optional=20 >> >>parameter has been >> >>>remapped by a QNE in the path. >>>=20 >>> >>> >>>>Btw, have you noticed that the draft has >>>>* a flag (Section 5.1) >>>>* a parameter (Section 7.2.1) >>>> >>>>I think they refer to the same concept... >>> >>> >>>Yes, good catch. is indeed intended to be a=20 >> >>flag, and >> >>>perhaps one of the QSPEC object flags defined in Section=20 >> >>7.1 could be used >> >>>for this purpose, rather than use a full 32-bit parameter=20 >> >>for this purpose, >> >>>as currently specified in Section 7.2.1. >>>=20 >>> >>> >>>>> In the latter case, the remapping of the to >>>>> must be specified in the QOSM specification=20 >> >>document. >> >>>>> For example, QOSM X exclusively uses the parameter=20 >>>>> . It >>>>> must define a mapping of the mandatory parameter . >>>>> The mapping consists of interpreting the Token Bucket Rate as >>>>> the parameter and disregarding the other=20 >> >>Token Bucket >> >>>>> parameters. Clearly, some information contained in the >>>> Bucket> parameter is lost by this mapping, and the=20 >>>>> resulting QoS may >>>>> not be quite what was intended by the QNI. Therefore,=20 >>>>> QOSM X also >>>>> specifies that the flag be raised. Thus,=20 >>>>> a QNE using >>>>> QOSM X is able to make an informed decision whether to admit a >>>>> reservation described in terms of , and=20 >> >>at the same >> >>>>> time (by means of ) signals to the=20 >> >>QNI/QNR that the >> >>>>> exact intention of the QNI may not be met." >>>>> >>>>>I think this text is pretty clear as to what is required regarding=20 >>>>>interpreting mandatory parameters. If not, please suggest=20 >>>>>clarifications. >>>> >>>>The text in the new draft has improved a lot. >>>>Thanks for the update. >>>> >>>> >>>> >>>>>>Another possible question would be: >>>>>>" >>>>>>Does a node that implements a particular QOSM has to=20 >> >>define mappings=20 >> >>>>>>from all mandatory parameters listed in the QSPEC=20 >> >>template draft to=20 >> >>>>>>the QOSM draft (even if the QOSM does not make use >>>> >>>>of them)? >>>> >>>> >>>>>>" >>>>>> >>>>>>The answer is "I don't know". >>>>> >>>>> >>>>>A QNE must interpret all mandatory parameters, if populated, as >>>>>explained in the above text I quoted. If a QOSM re-maps a=20 >> >>mandatory >> >>>>>QSPEC parameter, that re-mapping must be defined in the QOSM >>>>>specification. As stated in Section 4.7 (QOSM Specification >>>>>Requirements): >>>>> >>>>>" A QOSM specification MUST define QSPEC parameter=20 >>>>> behavior for these >>>>> cases: a) new optional QSPEC parameters the QOSM specification >>>>> defines, and b) remapping of existing mandatory or=20 >> >>optional QSPEC >> >>>>> parameters, as described in Section 4.2. Unless=20 >>>>> otherwise specified >>>>> in the QOSM specification document, the behaviors to strictly >>>>> interpret the mandatory and optional QSPEC parameters=20 >>>>> are defined in >>>>> this document through the references to RFCs that=20 >>>>> precisely define >>>>> the QSPEC parameter behaviors. =20 >>>>> >>>>> A QOSM specification MUST define how the mandatory=20 >>>>> parameters are to >>>>> be mapped onto the QSPEC parameters used by the QOSM,=20 >> >>however the >> >>>>> mapping MAY result in slight modification to the intended >>>>> specification when an exact mapping is not possible. =20 >>>>> This definition >>>>> MUST allow a QNE implementing this QOSM to make a decision as to >>>>> whether a reservation described in terms of mandatory=20 >>>>> parameters can >>>>> be admitted. If for a particular mandatory parameter no=20 >>>>> mapping can >>>>> be found that guarantees the desired QoS, the QNE is=20 >>>>> advised to raise >>>>> the flag. In other words, for all mandatory >>>>> parameters a mapping must be defined, but it is=20 >> >>acknowledged that >> >>>>> this mapping may result in slightly bending the original=20 >>>>> intention of >>>>> the QNI." >>>>> >>>>>I think this text is pretty clear as to what is required. If not, >>>>>please suggest clarifications. >>>> >>>>I understood the token bucket to bandwidth example. >>>> >>>>Would the RMD draft, for example, list all mandatory parameters and=20 >>>>indicate whether it can map them (and how) to parameters used=20 >>>>in the RMD=20 >>>>specification? >>> >>> >>>As stated in the QOSM specification requirements in Section=20 >> >>4.7, if a QOSM >> >>>remaps a mandatory parameter, the remapping must be defined=20 >> >>in the QOSM >> >>>specification document. If no such remapping is defined,=20 >> >>the default >> >>>behavior is that the QOSM must strictly interpret the=20 >> >>mandatory parameter, >> >>>as defined above. >>>=20 >>> >>> >>>>Do you think it is awfully realistic for all QNEs to understand all=20 >>>>mandatory parameters? I could imagine that Attila and=20 >>>>Georgios are not=20 >>>>going to implement stateless interior QNEs in such a way that they=20 >>>>understand all the mandatory QSPEC parameters. In fact they=20 >>>>don't have=20 >>>>todo it since only edge routers are likely to ever see QoS=20 >>>>NSLP messages=20 >>>>that contain QOSM IDs that they do not understand (otherwise=20 >>>>something=20 >>>>go terribly wrong). >>> >>> >>>It is up the RMD authors to specify how they want RMD to behave wrt >>>mandatory parameters (and obtain rough consensus, of=20 >> >>course). That is, if a >> >>>mandatory parameter is remapped and not strictly=20 >> >>interpreted, the remapping >> >>>must be specified in the QOSM specification document. =20 >> >>Otherwise, the QOSM >> >>>must strictly interpret the mandatory parameters that are=20 >> >>not remapped, if >> >>>they are populated by the QNI. >>> >>>There are no restrictions on how the remapping must be=20 >> >>done, it can be as >> >>>simple as necessary (but no simpler). >>> >>>Thanks, >>>Jerry >>> >>> >>> >>>>Ciao >>>>Hannes >>>> >>>> >>>> >>>>>Thanks, >>>>>Jerry >>>>> >>>>> >>>>> >>>>> >>>>>>Ciao >>>>>>Hannes >>>>>> >>>>>>The QSPEC-draft says in section 5 >>>>>> >>>>>> >>>>>> >>>>>>>that >>>>>>>all parameters listed in the next sections are mandatory. The=20 >>>>>>>QSPEC-draft also >>>>>>>says in section 4.1 that "a given QOSM defines which of the=20 >>>>>> >>>>>>mandatory and >>>>>> >>>>>> >>>>>> >>>>>>>optional parameters it uses, ..." >>>>>>> >>>>>>>Are there any specific parameters which makes the open=20 >>>> >>>>issue B.1.1.=20 >>>> >>>> >>>>>>>clearer? Following the QSPEC-draft there doesn't seem to be=20 >>>>>> >>>>>>a conflict,=20 >>>>>> >>>>>> >>>>>> >>>>>>>if nothing is >>>>>>>done with the unneeded parameters. >>>>>>> >>>>>>>Thanks, >>>>>>>Bernd >>> >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >>> >> >> >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 18:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWyd-0008TW-1u; Mon, 03 Jul 2006 18:33:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWyb-0008TR-Nd for nsis@ietf.org; Mon, 03 Jul 2006 18:33:09 -0400 Received: from natreg.rzone.de ([81.169.145.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxWya-0003DA-Ai for nsis@ietf.org; Mon, 03 Jul 2006 18:33:09 -0400 Received: from [192.168.178.200] (p5484CAE8.dip0.t-ipconnect.de [84.132.202.232]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k63MX6rw026988; Tue, 4 Jul 2006 00:33:06 +0200 (MEST) Message-ID: <44A99A80.2060904@cs.uni-goettingen.de> Date: Tue, 04 Jul 2006 00:30:24 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jmanner@cs.Helsinki.FI Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: nsis@ietf.org Subject: [NSIS] Receiver Initiated Reservation - Teardown X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, RSVP has two types of teardown-messages: PathTear and ResvTear. The QoS NSLP is only allowed to send a RESERVE towards the QNR. How can a receiver initiated reservation be torn down? The QNR is not allowed. Section 5.4.2, p. 61: 3576 Note that QUERY messages with the RESERVE-INIT flag set MUST be 3577 answered by the QNR. Isn't this the QNI who should answer the QUERY, since the QNR is the sender? Thanks, Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 20:06:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYQv-0003SM-UI; Mon, 03 Jul 2006 20:06:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYQu-0003QD-DL for nsis@ietf.org; Mon, 03 Jul 2006 20:06:28 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxYQt-0005mY-Pa for nsis@ietf.org; Mon, 03 Jul 2006 20:06:28 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-126.messagelabs.com!1151971505!9707431!11 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 21435 invoked from network); 4 Jul 2006 00:06:26 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-126.messagelabs.com with SMTP; 4 Jul 2006 00:06:26 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452000F93B3; Mon, 3 Jul 2006 20:06:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: QSPEC QoS Object Header Date: Mon, 3 Jul 2006 19:06:23 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A75@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44A8D33D.7020803@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: QSPEC QoS Object Header Thread-Index: AcaeeYg8S/atjK86Q9GdTxw+L7iukwAe6D9A From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" X-Spam-Score: 1.8 (+) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, See below. > >> * Why do you need the 'T' flag? I don't think that the concept is=20 > >> actually useful. > >>=20 > >> In Section 4.5.3 you write: > >>=20 > >> 4.5.3 QSPEC Tunneled Parameter T-Flag > >>=20 > >> Each QSPEC parameter has an associated 'tunneled-parameter T-flag'. > >> When a RESERVE message is tunneled through a domain, QNEs inside > >> the domain cannot update read-write parameters. > >>=20 > >> [hannes] QNEs MUST NOT update the parameters. That's the idea of > >> tunneling. > >>=20 > >> The egress QNE in a domain has two choices: either a) it is > >> configured to have the knowledge to update the parameters > >> correctly, > >>=20 > >> [hannes] What type of update are you looking for? The reservation > >> within the tunneled region is a separate and independent=20 > >> reservation. > >=20 > >=20 > > Not sure what you mean by "separate and independent reservation". >=20 > See Section 4.6 of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt > and > http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-00.txt >=20 > Figure 12 in Section 4.6 of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt > is particularly nice since it shows that the=20 > RESERVE'/RESPONSE' within=20 > the domain are independent of the E2E RESERVE/RESPONSE. I think the interpretation of tunneling in the QSPEC I-D is consistent = with this description in QoS-NSLP. I think I know what you mean by = "independent", but what happens inside the local domain and outside the = local domain is all part of the same NSIS reservation from QNI to QNR. = In particular, the QOSM treatment in the local domain is not independent = of the QOSM treatment outside the local domain, and specifically what = QOSM procedures are followed by the QNI (or QNR). =20 > > We're talking about an end-to-end reservation where one domain may > > tunnel the Initiator QSPEC through the domain. With respect to the > > 'update', it refers to the egress QNE in the domain updating a > > mandatory or optional QSPEC parameter in the Initiator QSPEC. E.g., > > if the parameter (a mandatory QSPEC parameter) is > > specified in the object in the Initiator QSPEC, and > > the Initiator QSPEC is tunneled through a domain, the egress QNE in > > the domain may be configured to update this parameter. >=20 > Why would it want to update the parameter? Well, as you know, is a mandatory parameter and therefore it = is mandatory to update the parameter in the Initiator QSPEC, = since in this example is populated in the Initiator QSPEC. =20 =20 > > If it cannot > > update this parameter, then it needs to set the T-Flag to so > > indicate. >=20 > If he wants to update the parameter why would there be a=20 > problem with it? There may be a problem because the egress QNE in the local domain may = not have the necessary information to update the parameter. = This is because the Initiator QSPEC is tunneled through the local = domain, and there is no update of the parameter in the = Initiator QSPEC in the local domain. However, the T-Flag allows the = egress QNE in the local domain to mark the parameter in the = Initiator QSPEC to indicate that it "cannot be updated". IMO, this is a = way for a local QOSM in a local domain to "ignore" mandatory QSPEC = parameters populated in the Initiator QSPEC if necessary. That is, the = egress QNE in the local domain can set the T-flag for any mandatory = parameters that cannot be interpreted in the local domain. IMO this = point addresses several other comments today about a QOSM "ignoring" = mandatory parameters. Mandatory parameters can, in effect, be "ignored" = if necessary with the use of the T-flag. It is then up to the QNI (or = QNR) to decide if the reservation is accepted or rejected, in light of = T-flags being set for some (possibly mandatory) parameters. =20 > >> or b) it cannot update the parameters. In the latter case it MUST > >> set the tunneled-parameter T-flag to tell the QNI (or QNR) that the > >> information contained in the read-write parameter is most likely=20 > >> incorrect (or a lower bound). > >>=20 > >> [hannes] Which parameters are incorrect? > >=20 > > If in the above example, the egress QNE in the domain is unable to > > update in the object, it must then set > > the T-flag for the parameter. > >=20 > >=20 > >> The T-flag is interpreted by the QNI, ingress QNE (start of tunnel > >> in a domain), egress QNE (end of tunnel in a domain), or QNR. > >>=20 > >> [hannes] There are now three 'T' bits flying around in related > >> documents: > >>=20 > >> * T-bit set (RESERVE tear): QoS NSLP * T-bit in the NSIS Tunnel ID=20 > >> * T-bit in the QSPEC draft > >>=20 > >> Neither the QoS NSLP nor the NSIS Tunnel ID does, to my knowledge, > >> not use the T-bit of the QSPEC document. > >=20 > > The T-bit in the QSPEC draft is strictly for use by the RMF in QoS > > processing, so I think its use is restricted to=20 > > implementation of the > > NSLP/QSPEC/RMF procedures. However, you raise a good point about 3 > > different definitions for 'T-bit', and we need to be sure=20 > > there is no > > confusion resulting from this. >=20 > Why does the RMF need this info? The RMF needs to know if a mandatory parameter "was not interpreted" by = a local domain (e.g., as indicated by the T-flag being set), in order to = decide whether to accept or reject the reservation at the QNI (or QNR). > >> * Why do you need to put error specific flag in every object=20 > >> (namely 'E and N flag)? Errors should be the exception rather than > >> the norm. I would do something different, namely to put an error > >> object with a list of the Parameter IDs in it. > >=20 > > The use of E-Flag is definitely the exception rather than the norm. > > IMO the approach defined in Section 4.5.1 is a reasonable approach, > > that is, to flag an error according to a specific QSPEC=20 > > parameter, if > > possible. However, as stated in Section 4.5.1, in some error > > situations it may not be possible to set the E-Flag for a QSPEC > > parameter, although it may be possible to still set the E-Flag for > > the QSPEC object. The INFO_SPEC in this case does carry the QSPEC > > with the erroneous parameters flagged within it. The=20 > > alternative you > > suggest I think is similar to this approach (this approach agreed to > > after a very lengthy discussion on error codes). >=20 > So, what you are going todo? We're going to follow what's stated in Section 4.5.1, unless there is = some agreement to change that. =20 > >> Regarding the parameter encoding: > >>=20 > >> You might want to change the description with regard to the=20 > >> Parameter ID field. Change from: > >>=20 > >> " 7.2.1 Parameter > >>=20 > >> 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=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > >> |1|E|0|T| 0 |r|r|r|r| 1 |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > >> NON QOSM Hop | Reserved |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " > >>=20 > >>=20 > >> to: > >>=20 > >> " 7.2.1 Parameter > >>=20 > >> 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=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > >> |1|E|0|T|00000000000000000000000|r|r|r|r| 1 |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > >> NON QOSM Hop | Reserved |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " > >>=20 > >>=20 > >> or: " 7.2.1 Parameter > >>=20 > >> 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=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > >> |1|E|0|T| Parameter ID |r|r|r|r| Length |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > >> NON QOSM Hop | Reserved |=20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>=20 > >> Parameter ID: 0 > >>=20 > >> Length: 1 > >>=20 > >> " > >>=20 > >> The Parameter ID is 12 bits long. Is it also encoded in network > >> byte order? The same is true for the Length field. > >>=20 > >> The draft only says that "Network byte order ('big-endian') for all > >> 16- and 32-bit integers, as well as 32-bit floating point numbers, > >> are as specified in [RFC1832, IEEE754, NETWORK-BYTE-ORDER]. " > >=20 > >=20 > > I'm not sure I get the point you're making here. >=20 >=20 > The point is: What is the encoding of the parameters. > The text and the figure does not provide enough details to=20 > figure it out. OK, can you suggest text to fix the problem you see. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 03 20:07:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYRf-0003la-U9; Mon, 03 Jul 2006 20:07:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYRf-0003lV-JF for nsis@ietf.org; Mon, 03 Jul 2006 20:07:15 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxYRe-0005oL-8d for nsis@ietf.org; Mon, 03 Jul 2006 20:07:15 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1151971614!9790649!2 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15906 invoked from network); 4 Jul 2006 00:07:13 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 4 Jul 2006 00:07:13 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452000F93C9; Mon, 3 Jul 2006 20:07:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List Date: Mon, 3 Jul 2006 19:07:11 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A76@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List Thread-Index: AcaeqwMBvNWaYo40RX+o3MieI/BTTAAT8CHQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Janet P Gunn" X-Spam-Score: 1.8 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "Ash, Gerald R \(Jerry\), ALABS" , Kappler Cornelia , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , NSIS , John Rosenberg X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Janet, See below.=20 > -----Original Message----- > From: Janet P Gunn [mailto:jgunn6@csc.com]=20 > Sent: Monday, July 03, 2006 10:14 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH) > Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List >=20 > Nits with regard to RPH. >=20 > References should be updated to include RFC4412 (instead of=20 > just the ID) >=20 > In section 7.2.7.3 you show a mapping between the text values=20 > and numeric > values for RPH priority. (The mappings for ets and wps are fine) >=20 > For dsn and drsn you show >=20 > 4 - dsn.routine > 3 - dsn.priority > 2 - dsn.immediate > 1 - dsn.flash > 0 - dsn.flash-override >=20 > 5 - drsn.routine > 4 - drsn.priority > 3 - drsn.immediate > 2 - drsn.flash > 1 - drsn.flash-override > 0 - drsn.flash-override-override >=20 > You might want to check with the intended users of those=20 > namesapces, as I > understand (see recent email on the IEPREP mailing list) that=20 > DISA intends > to use a quite different numerical mapping, with "0" for=20 > routine in all > cases. >=20 > "The current DISA specification for MLPP on VoIP networks=20 > specifies RPH > r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of=20 > priority (e.g. > 0 =3D Routine and 9 =3D F-O-O)." >=20 > It will be very confusing if one numeric mapping is used in SIP and a > different, opposing, mapping is used in QSPEC. Agreed. We'll check the referenced specification and align the mapping = in the QSPEC. =20 Thanks a lot for pointing this out. Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 03:08:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxf1R-0005CC-Fz; Tue, 04 Jul 2006 03:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxf1P-0005Ad-TF for nsis@ietf.org; Tue, 04 Jul 2006 03:08:35 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxf1O-0003rE-RB for nsis@ietf.org; Tue, 04 Jul 2006 03:08:35 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 4 Jul 2006 09:08:31 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id <3GKSV1GK>; Tue, 4 Jul 2006 09:08:31 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E63FF@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: bschloer@cs.uni-goettingen.de, attila.bader@ericsson.com Subject: RE: [NSIS] draft-qosmodel-controlledload-04 Date: Tue, 4 Jul 2006 09:08:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: 63de1eb80dd4230367fc1d266729643d Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Bernd, Attila, Attila raised concerns about mappings of mandatory parameters=20 being difficult. Bernd proposed a definition of mappings=20 (omitted here) and concludes: |The only problem I see: Do I know the QOSM of my neighbor=20 |domain? Do I have to consider this when sending the=20 |initiator QSPEC? What you discuss is an interworking or a partial interworking=20 between different services. Interworkings are common in=20 the telephony world. It is important to be aware where they=20 happen and to know their characteristics, meaning they need=20 to be specified.=20 Unspecified mappings of parameters should therefore not occur.=20 The spec should say that. If a parameter isn't interpreted=20 and this is a "specified behaviour" known to all parties, that may still be tolerable, I think. Regards, R=FCdiger | |Attila B=E1der (IJ/ETH) wrote: |> Hi All, |>=20 |> If "ignore" is not a type interpretation, I also think that=20 |> it should be reformulated. |>=20 |> In general, to understend mandatory parameters that is not=20 |> used in a local QoSM, I see less problem. If a QOSM has to=20 |> fill in mandatory parameters that is not used in this QOSM,=20 |> seems to be more difficult. |>=20 |> Best regards, Attila |>=20 |>=20 |>>-----Original Message----- |>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] |>>Sent: Monday, July 03, 2006 4:37 PM |>>To: Georgios Karagiannis |>>Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila B=E1der (IJ/ETH); |>>nsis@ietf.org; 'Kappler Cornelia' |>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 |>> |>> |>>Hi Georgios, |>> |>>please find my comment below: |>> |>>Georgios Karagiannis wrote: |>> |>>>Hi Jerry=20 |>>> |>>>Regarding your last point: |>>> |>>> |>>>>>Hannes: |>>>>>Do you think it is awfully realistic for all QNEs to=20 |>> |>>understand all=20 |>> |>>>>>mandatory parameters? I could imagine that Attila and=20 |>>>>>Georgios are not=20 |>>>>>going to implement stateless interior QNEs in such a way=20 |that they=20 |>>>>>understand all the mandatory QSPEC parameters. In fact they=20 |>>>>>don't have=20 |>>>>>todo it since only edge routers are likely to ever see QoS=20 |>>>>>NSLP messages=20 |>>>>>that contain QOSM IDs that they do not understand (otherwise=20 |>>>>>something=20 |>>>>>go terribly wrong). |>>> |>>> |>>>>Jerry: It is up the RMD authors to specify how they want RMD=20 |>>>> |>>>> |>>>>>to behave wrt mandatory parameters (and obtain rough=20 |>>>>>consensus, of course). That is, if a mandatory parameter=20 |>>>>>is remapped and not strictly interpreted, the remapping=20 |>>>>>must be specified in the QOSM specification document. =20 |>>>>>Otherwise, the QOSM must strictly interpret the mandatory=20 |>>>>>parameters that are not remapped, if they are populated=20 |by the QNI. |>>>>>There are no restrictions on how the remapping must be done,=20 |>>>>>it can be as simple as necessary (but no simpler). |>>> |>>> |>>>Georgios: |>>>Jerry, I think that the point raised by Hannes is related to |>>>how the QNE's interior to the RMD domain will have to comply to the |>>>mandatory descriptions specified in the QSPEC template.=20 |>>>An interior QNE (in RMD-QOSM) will not process=20 |>>>the end to end QSpec. The only QSpec that will be processed by the=20 |>>>interior QNE is the RMD Qsepc that is initiated by the=20 |>>>ingress node (i.e., QNI for the RMD local session).=20 |>>>Note that the above observation is valid for all local QOSMs. |>>>However, the above is not allowed due to the following text that is = |>>>included in the QSpec template draft: |>>> |>>>"A QNE MUST interpret all mandatory parameters from this=20 |>> |>>document even=20 |>> |>>>if it does not support the received QoS NSLP message with the=20 |>>>indicated QOSM." |>>> |>>>Therefore, in my opinion it is required to modify the above=20 |>> |>>sentence in |>> |>>>something like: |>>> |>>>"A QNE SHOULD interpret all mandatory parameters from this=20 |>> |>>document even=20 |>> |>>>if it does not support the received QoS NSLP message with the=20 |>>>indicated QOSM. A QNE that supports a local QOSM, does not=20 |>> |>>have to interpret |>> |>>>all mandatory parameters carried by a QSpec that was=20 |>> |>>generated by a QNI=20 |>> |>>>located outside the domain that supports the given local QOSM."=20 |>> |>>Something along these lines would probably be more=20 |realistic, I guess. |>> |>>Ciao |>>Hannes |>> |>> |>>>Best regards, |>>>Georgios |>>> |>>>-----Original Message----- |>>>From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 |>>>Sent: maandag 3 juli 2006 2:03 |>>>To: Hannes Tschofenig |>>>Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH);=20 |>> |>>nsis@ietf.org; |>> |>>>Kappler Cornelia |>>>Subject: RE: [NSIS] draft-qosmodel-controlledload-04 |>>> |>>>Hi Hannes, |>>> |>>>See below.=20 |>>> |>>> |>>> |>>>>-----Original Message----- |>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] |>>>>Sent: Saturday, July 01, 2006 4:26 PM |>>>>To: Ash, Gerald R (Jerry), ALABS |>>>>Cc: nsis@ietf.org |>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 |>>>> |>>>>Hi Jerry, |>>>> |>>>>it is true that I haven't read the most recent QSPEC draft=20 |>> |>>when I sent=20 |>> |>>>>this mail. In the meanwhile I did. Please find a few=20 |comments below: |>>>> |>>>>Ash, Gerald R (Jerry), ALABS wrote: |>>>> |>>>> |>>>>>Hi Hannes, |>>>>> |>>>>>See below.=20 |>>>>> |>>>>> |>>>>> |>>>>> |>>>>>>-----Original Message----- |>>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] |>>>>>>Sent: Friday, June 30, 2006 8:43 AM |>>>>>>To: Bernd Schloer |>>>>>>Cc: nsis@ietf.org |>>>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 |>>>>>> |>>>>>>Hi Bernd, |>>>>>> |>>>>>>Bernd Schloer wrote: |>>>>>> |>>>>>> |>>>>>> |>>>>>>>Hi, |>>>>>>> |>>>>>>>the first open issue in the appendix B is about what to do with = |>>>>>>>mandatory QSPEC parameters which are not needed for CLS. |>>>>>>> |>>>>>>>Does a QOSM have to understand (and provide information=20 |>> |>>about) all=20 |>> |>>>>>>>mandatory parameters, even if they are not used? |>>>>>> |>>>>>>I think the question is wrong. What about the following = question: |>>>>>>" |>>>>>>Does a node that implements a particular QOSM has to=20 |>> |>>understand all=20 |>> |>>>>>>mandatory parameters listed in the QSPEC template draft |>>>> |>>>>(even if the |>>>> |>>>> |>>>>>>QOSM does not make use of them)? |>>>>>>" |>>>>>>The answer would be "YES" since the QSPEC template draft=20 |>> |>>says that=20 |>> |>>>>>>mandatory parameters have to be understood by every NSIS=20 |QoS node. |>>>>>> |>>>>>>There is only the question what "understands" means. |>>>>> |>>>>> |>>>>>IMO you need to more carefully read the QSPEC I-D document. All=20 |>>>>>mandatory QSPEC parameters that are populated in the=20 |QSPEC must be=20 |>>>>>interpreted by every QNE, which is explained in the QSPEC I-D: |>>>>> |>>>>>It says in Section 4.4.1 (Mandatory and Optional QSPEC |>>>> |>>>>. Parameters) of |>>>> |>>>> |>>>>>the QSPEC I-D |>>>>>http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: |>>>>> |>>>>>" Mandatory QSPEC parameters are treated as follows: |>>>>> |>>>>> o A QNI SHOULD populate mandatory QSPEC parameters if |>>>> |>>>>. applicable to |>>>> |>>>> |>>>>> the underlying QOSM. |>>>> |>>>>I don't understand this sentence. What does it mean that a QNI=20 |>>>>"SHOULD" |>>>>populate parameters if applicable? |>>> |>>> |>>>It means that a QNI is not required to populate all=20 |>> |>>mandatory parameters. A |>> |>>>QNI would only populated a mandatory parameter if is used=20 |>> |>>by the QOSM |>> |>>>supported by the QNI. |>>>=20 |>>> |>>> |>>>>> o QNEs MUST interpret mandatory QSPEC parameters, if signaled." |>>>>> |>>>>>Furthermore, it says in Section 4.2 (QSPEC Processing): |>>>>> |>>>>>" a QNE |>>>>> MUST at least interpret all the mandatory parameters in=20 |>>>>> a QSPEC even |>>>>> if it does not support the corresponding QOSM. |>>>>> |>>>>> Mandatory parameters provide a minimal subset of parameters. A |>>>>> QNE MUST either a) strictly interpret a mandatory parameter, or |>>>>> b) remap the parameter and raise the flag=20 |>>>>> defined in |>>>>> Section 5.1, where the remapping MUST be specified in the QOSM |>>>>> specification. Here the terminology 'strictly=20 |>>>>> interpret' means that |>>>> |>>>>What is the difference between 'strictly interpret' and=20 |>> |>>'interpret'?=20 |>> |>>>>In the rest of the document you use 'interpret'. |>>> |>>> |>>>'Strictly interpret' is defined in the text I quoted from=20 |>> |>>Section 4.2 (QSPEC |>> |>>>Processing), which is given again in the very next=20 |>> |>>sentences I quoted just |>> |>>>below (after you posed your above question :-) |>>> |>>>" Mandatory parameters provide a minimal subset of parameters. A |>>> QNE MUST either a) strictly interpret a mandatory parameter, or |>>> b) remap the parameter and raise the flag=20 |>> |>>defined in |>> |>>> Section 5.1, where the remapping MUST be specified in the QOSM |>>> specification. Here the terminology 'strictly=20 |>> |>>interpret' means that |>> |>>> the parameter is implemented according to the commonly accepted |>>> definition and/or as specified by references given for each = QSPEC |>>> parameter. This means that in case a), a =20 |>> |>>parameter |>> |>>> must be strictly interpreted as a token bucket. =20 |>> |>>However, in case b), |>> |>>> a parameter may be remapped, perhaps to a=20 |>> |>> |>> |>>> parameter." |>>> |>>>In the document, the term 'interpret' a mandatory parameter=20 |>> |>>means either a) |>> |>>>strictly interpret (as defined above), or b) remap (as=20 |>> |>>defined above). |>> |>>>Perhaps this can be made clearer in the text. |>>>=20 |>>> |>>> |>>>>> the parameter is implemented according to the commonly accepted |>>>>> definition and/or as specified by references given for=20 |>> |>>each QSPEC |>> |>>>>> parameter. This means that in case a), a =20 |>>>>> parameter |>>>>> must be strictly interpreted as a token bucket. =20 |>>>>> However, in case b), |>>>>> a parameter may be remapped, perhaps to a=20 |>>>>> |>>>>> parameter. |>>>> |>>>>I noticed this text improvement and I am happy to see more=20 |>> |>>text about=20 |>> |>>>>it. |>>>> |>>>>Still, I have some issues with the section: |>>>> |>>>>I had a problem with this paragraph following the previous=20 |>> |>>one in the=20 |>> |>>>>section. The previous paragraph said " |>>>>However, if a QSPEC arrives at a QNE that does |>>>> not support the QOSM being signaled, it can still understand = the |>>>> QSPEC content, at least to a basic degree. |>>>>" |>>>> |>>>>When I read through the text I got the impression that the two=20 |>>>>sections relate to each other and in fact they do not. Hence, I=20 |>>>>suggest to delete the previous paragraph since this one=20 |>> |>>contains the=20 |>> |>>>>info already. |>>> |>>> |>>>I'm unclear as to which paragraph/text you are proposing to delete. |>>> |>>> |>>> |>>>>You |>>>>might also want to delete the second paragraph as well=20 |>> |>>since it is far=20 |>> |>>>>too obvious to use RFC2119 language: If you don't support even a=20 |>>>>single QOSM then why are you a QOS NSLP node in the first place. |>>> |>>> |>>>I think it important to state that a QNE MUST support at=20 |>> |>>least one QOSM, |>> |>>>even if this is clearly necessary to effectively support=20 |>> |>>QoS-NSLP/QSPEC. |>> |>>> |>>>>You might want to highlight the following sentence, though: |>>>> |>>>>" |>>>>A QNE MUST interpret all mandatory parameters from this=20 |>> |>>document even=20 |>> |>>>>if it does not support the received QoS NSLP message with the=20 |>>>>indicated QOSM. |>>>>" |>>>> |>>>>Here is my proposal for the section: |>>>> |>>>>" |>>>>4.2 QSPEC Processing |>>>> |>>>> The QSPEC is opaque to the QoS NSLP processing. The=20 |>> |>>QSPEC control |>> |>>>> information and the QoS description are interpreted and MAY be |>>>> modified by the RMF in a QNE (see description in [QoS-SIG]). |>>>> |>>>> The QSPEC contains a QOSM ID, i.e. information on what=20 |>>>> QOSM is being |>>>> signaled by the QNI. However, if a QSPEC arrives at a=20 |>>>> QNE that does |>>>> not support the QOSM being signaled, it can still understand = the |>>>> QSPEC content, at least to a basic degree. This is=20 |>>>> because mandatory |>>>> parameters have been defined as a common language. =20 |>>>> Therefore, a QNE |>>>> MUST at least interpret all the mandatory parameters in a=20 |>>>> QSPEC even |>>>> if it does not support the corresponding QOSM. |>>>> |>>>> A QNE MUST either |>>>> |>>>> a) interpret a mandatory parameter carried in the QSPEC=20 |>> |>>object, or |>> |>>>> b) remap the parameter and raise the flag=20 |>>>> defined in |>>>> Section 5.1, where the remapping MUST be specified in the QOSM |>>>> specification. |>>>> |>>>> Here the terminology 'interpret' means that |>>>> the parameter is implemented according to the references=20 |>>>> given for=20 |>>>> each QSPEC parameter. |>>>> |>>>> If a QSPEC arrives at a QNE that does not support the QOSM = being |>>>> signaled, it can still understand the QSPEC content, at=20 |>> |>>least to a |>> |>>>> basic degree. Hence, with case (a), a parameter |>>>> must be strictly interpreted as a token bucket. |>>>> |>>>> In case b), a parameter may be remapped,=20 |>>>> perhaps to a |>>>> parameter. |>>>>" |>>> |>>> |>>>I don't see any benefit in redefining what 'interpret' means in the |>>>document. As I mentioned above, the document uses the term=20 |>> |>>'interpret' to |>> |>>>mean that a mandatory parameter is 'interpreted' if is=20 |>> |>>either 'strictly |>> |>>>interpreted' or it is 'remapped' (where the remapping must=20 |>> |>>be defined in the |>> |>>>QOSM specification document). OTOH, it might be useful to define a |>>>'remapping' flag to indicated if a mandatory or optional=20 |>> |>>parameter has been |>> |>>>remapped by a QNE in the path. |>>>=20 |>>> |>>> |>>>>Btw, have you noticed that the draft has |>>>>* a flag (Section 5.1) |>>>>* a parameter (Section 7.2.1) |>>>> |>>>>I think they refer to the same concept... |>>> |>>> |>>>Yes, good catch. is indeed intended to be a=20 |>> |>>flag, and |>> |>>>perhaps one of the QSPEC object flags defined in Section=20 |>> |>>7.1 could be used |>> |>>>for this purpose, rather than use a full 32-bit parameter=20 |>> |>>for this purpose, |>> |>>>as currently specified in Section 7.2.1. |>>>=20 |>>> |>>> |>>>>> In the latter case, the remapping of the to |>>>>> must be specified in the QOSM specification=20 |>> |>>document. |>> |>>>>> For example, QOSM X exclusively uses the parameter=20 |>>>>> . It |>>>>> must define a mapping of the mandatory parameter . |>>>>> The mapping consists of interpreting the Token Bucket Rate as |>>>>> the parameter and disregarding the other=20 |>> |>>Token Bucket |>> |>>>>> parameters. Clearly, some information contained in the >>>> Bucket> parameter is lost by this mapping, and the=20 |>>>>> resulting QoS may |>>>>> not be quite what was intended by the QNI. Therefore,=20 |>>>>> QOSM X also |>>>>> specifies that the flag be raised. Thus,=20 |>>>>> a QNE using |>>>>> QOSM X is able to make an informed decision whether to admit a |>>>>> reservation described in terms of , and=20 |>> |>>at the same |>> |>>>>> time (by means of ) signals to the=20 |>> |>>QNI/QNR that the |>> |>>>>> exact intention of the QNI may not be met." |>>>>> |>>>>>I think this text is pretty clear as to what is required=20 |regarding=20 |>>>>>interpreting mandatory parameters. If not, please suggest=20 |>>>>>clarifications. |>>>> |>>>>The text in the new draft has improved a lot. |>>>>Thanks for the update. |>>>> |>>>> |>>>> |>>>>>>Another possible question would be: |>>>>>>" |>>>>>>Does a node that implements a particular QOSM has to=20 |>> |>>define mappings=20 |>> |>>>>>>from all mandatory parameters listed in the QSPEC=20 |>> |>>template draft to=20 |>> |>>>>>>the QOSM draft (even if the QOSM does not make use |>>>> |>>>>of them)? |>>>> |>>>> |>>>>>>" |>>>>>> |>>>>>>The answer is "I don't know". |>>>>> |>>>>> |>>>>>A QNE must interpret all mandatory parameters, if populated, as |>>>>>explained in the above text I quoted. If a QOSM re-maps a=20 |>> |>>mandatory |>> |>>>>>QSPEC parameter, that re-mapping must be defined in the QOSM |>>>>>specification. As stated in Section 4.7 (QOSM Specification |>>>>>Requirements): |>>>>> |>>>>>" A QOSM specification MUST define QSPEC parameter=20 |>>>>> behavior for these |>>>>> cases: a) new optional QSPEC parameters the QOSM specification |>>>>> defines, and b) remapping of existing mandatory or=20 |>> |>>optional QSPEC |>> |>>>>> parameters, as described in Section 4.2. Unless=20 |>>>>> otherwise specified |>>>>> in the QOSM specification document, the behaviors to strictly |>>>>> interpret the mandatory and optional QSPEC parameters=20 |>>>>> are defined in |>>>>> this document through the references to RFCs that=20 |>>>>> precisely define |>>>>> the QSPEC parameter behaviors. =20 |>>>>> |>>>>> A QOSM specification MUST define how the mandatory=20 |>>>>> parameters are to |>>>>> be mapped onto the QSPEC parameters used by the QOSM,=20 |>> |>>however the |>> |>>>>> mapping MAY result in slight modification to the intended |>>>>> specification when an exact mapping is not possible. =20 |>>>>> This definition |>>>>> MUST allow a QNE implementing this QOSM to make a decision as = to |>>>>> whether a reservation described in terms of mandatory=20 |>>>>> parameters can |>>>>> be admitted. If for a particular mandatory parameter no=20 |>>>>> mapping can |>>>>> be found that guarantees the desired QoS, the QNE is=20 |>>>>> advised to raise |>>>>> the flag. In other words, for all mandatory |>>>>> parameters a mapping must be defined, but it is=20 |>> |>>acknowledged that |>> |>>>>> this mapping may result in slightly bending the original=20 |>>>>> intention of |>>>>> the QNI." |>>>>> |>>>>>I think this text is pretty clear as to what is required. If = not, |>>>>>please suggest clarifications. |>>>> |>>>>I understood the token bucket to bandwidth example. |>>>> |>>>>Would the RMD draft, for example, list all mandatory=20 |parameters and=20 |>>>>indicate whether it can map them (and how) to parameters used=20 |>>>>in the RMD=20 |>>>>specification? |>>> |>>> |>>>As stated in the QOSM specification requirements in Section=20 |>> |>>4.7, if a QOSM |>> |>>>remaps a mandatory parameter, the remapping must be defined=20 |>> |>>in the QOSM |>> |>>>specification document. If no such remapping is defined,=20 |>> |>>the default |>> |>>>behavior is that the QOSM must strictly interpret the=20 |>> |>>mandatory parameter, |>> |>>>as defined above. |>>>=20 |>>> |>>> |>>>>Do you think it is awfully realistic for all QNEs to=20 |understand all=20 |>>>>mandatory parameters? I could imagine that Attila and=20 |>>>>Georgios are not=20 |>>>>going to implement stateless interior QNEs in such a way that they = |>>>>understand all the mandatory QSPEC parameters. In fact they=20 |>>>>don't have=20 |>>>>todo it since only edge routers are likely to ever see QoS=20 |>>>>NSLP messages=20 |>>>>that contain QOSM IDs that they do not understand (otherwise=20 |>>>>something=20 |>>>>go terribly wrong). |>>> |>>> |>>>It is up the RMD authors to specify how they want RMD to behave wrt |>>>mandatory parameters (and obtain rough consensus, of=20 |>> |>>course). That is, if a |>> |>>>mandatory parameter is remapped and not strictly=20 |>> |>>interpreted, the remapping |>> |>>>must be specified in the QOSM specification document. =20 |>> |>>Otherwise, the QOSM |>> |>>>must strictly interpret the mandatory parameters that are=20 |>> |>>not remapped, if |>> |>>>they are populated by the QNI. |>>> |>>>There are no restrictions on how the remapping must be=20 |>> |>>done, it can be as |>> |>>>simple as necessary (but no simpler). |>>> |>>>Thanks, |>>>Jerry |>>> |>>> |>>> |>>>>Ciao |>>>>Hannes |>>>> |>>>> |>>>> |>>>>>Thanks, |>>>>>Jerry |>>>>> |>>>>> |>>>>> |>>>>> |>>>>>>Ciao |>>>>>>Hannes |>>>>>> |>>>>>>The QSPEC-draft says in section 5 |>>>>>> |>>>>>> |>>>>>> |>>>>>>>that |>>>>>>>all parameters listed in the next sections are mandatory. The=20 |>>>>>>>QSPEC-draft also |>>>>>>>says in section 4.1 that "a given QOSM defines which of the=20 |>>>>>> |>>>>>>mandatory and |>>>>>> |>>>>>> |>>>>>> |>>>>>>>optional parameters it uses, ..." |>>>>>>> |>>>>>>>Are there any specific parameters which makes the open=20 |>>>> |>>>>issue B.1.1.=20 |>>>> |>>>> |>>>>>>>clearer? Following the QSPEC-draft there doesn't seem to be=20 |>>>>>> |>>>>>>a conflict,=20 |>>>>>> |>>>>>> |>>>>>> |>>>>>>>if nothing is |>>>>>>>done with the unneeded parameters. |>>>>>>> |>>>>>>>Thanks, |>>>>>>>Bernd |>>> |>>> |>>>_______________________________________________ |>>>nsis mailing list |>>>nsis@ietf.org |>>>https://www1.ietf.org/mailman/listinfo/nsis |>>> |>>> |>>> |>> |>> |>=20 |> _______________________________________________ |> nsis mailing list |> nsis@ietf.org |> https://www1.ietf.org/mailman/listinfo/nsis |>=20 | | |_______________________________________________ |nsis mailing list |nsis@ietf.org |https://www1.ietf.org/mailman/listinfo/nsis | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 03:47:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxfcd-00031s-Ol; Tue, 04 Jul 2006 03:47:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxfcc-0002zl-3t for nsis@ietf.org; Tue, 04 Jul 2006 03:47:02 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxfVv-0004je-Oc for nsis@ietf.org; Tue, 04 Jul 2006 03:40:10 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k647dkJI018467; Tue, 4 Jul 2006 08:39:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Legacy NAT traversal for NSIS Date: Tue, 4 Jul 2006 08:40:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Legacy NAT traversal for NSIS Thread-Index: AcaesxcHUOnvrrU7S+CNkYUrhQ8vwwAiHZZw From: "Hancock, Robert" To: "Saikat Guha" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: john.loughney@nokia.com, Andreas.Pashalidis@siemens.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, > -----Original Message----- > From: Saikat Guha [mailto:saikat@cs.cornell.edu]=20 > Sent: 03 July 2006 16:11 > To: Hancock, Robert > Cc: john.loughney@nokia.com; nsis@ietf.org;=20 > Andreas.Pashalidis@siemens.com > Subject: RE: [NSIS] Legacy NAT traversal for NSIS >=20 >=20 > On Mon, 2006-07-03 at 15:22 +0100, Hancock, Robert wrote: > > my biggest question about the approach is that the discussion > > is mostly about a flow which goes through the legacy NAT in the=20 > > internal->external direction (same as the initial Query for the > > signalling). how does one handle a flow in the other direction?=20 > > it's a different flow, so either one needs a technique to get the > > Query through the NAT the other way, or to rely on the upstream=20 > > encapsulation. Each has its tricky side. This has struck me in=20 > > the past as the hardest part of the problem. >=20 > Are you referring to an inbound GIST flow to a NAT'ed peer that is not > expecting it, or an inbound flow in response to an outbound flow. > (apologies for not having enough GIST context). both >=20 > If it is the former, i.e. an out-of-the-blue inbound GIST flow to a > NAT'ed peer, then you would need legacy NAT traversal involving some > sort of a rendezvous service to get that peer to know when to=20 > punch open > holes in its NAT. yes, but that is not uncommon today. (trivial example: i run a webserver behind my NAT and configure the NAT to forward port 80 to a particular internal address.) >=20 > If it is the latter, i.e. inbound flow in response to an=20 > existing flow, > then the NAT'ed peer may be able to receive the new flow as-is (for > certain types of NATs), or be required punch the holes for=20 > the new flow > by using the existing flow as the rendezvous channel. it's not so much a problem for the NAT, since the inbound/outbound flows are almost certainly pinned to go through the same NAT (on topology and addressing grounds). the problem is that we now have to consider the inbound/outbound flow paths on the external side=20 of the NAT, which are very likely to see different GIST nodes=20 because of routing asymmetry. how does the (new) GIST node for the inbound flow know to use an existing tunnel? r. >=20 > --=20 > Saikat >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 06:17:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxhxr-00073M-Fo; Tue, 04 Jul 2006 06:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxhxp-00071p-Pj for nsis@ietf.org; Tue, 04 Jul 2006 06:17:05 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxhxo-0002Fa-S4 for nsis@ietf.org; Tue, 04 Jul 2006 06:17:05 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k64AGZgd006017; Tue, 4 Jul 2006 12:16:44 +0200 (MEST) From: "Georgios Karagiannis" To: "'Bernd Schloer'" , "=?iso-8859-1?Q?'=22Attila_B=E1der_=28IJ/ETH=29=22'?=" Subject: RE: [NSIS] draft-qosmodel-controlledload-04 Date: Tue, 4 Jul 2006 12:16:37 +0200 Message-ID: <002501c69f52$f2090590$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: Acae8V/of4syIrKJR1Sct+BtX/6JwwAYUYtQ In-Reply-To: <44A996C2.7010602@cs.uni-goettingen.de> X-Spam-Score: -4.713 () ALL_TRUSTED, AWL, BAYES_00, J_CHICKENPOX_73, SUBJ_HAS_UNIQ_ID X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 04 Jul 2006 12:16:49 +0200 (MEST) X-Spam-Score: 1.1 (+) X-Scan-Signature: edafdfdf1a7c40feead31b1909b66c9e Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , nsis@ietf.org, 'Kappler Cornelia' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd Are you proposing that the only mandory parameter should be: =3D =20 Best Regards, Georgios -----Original Message----- From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 Sent: dinsdag 4 juli 2006 0:14 To: "Attila B=E1der (IJ/ETH)" Cc: Hannes Tschofenig; Georgios Karagiannis; Ash, Gerald R (Jerry), = ALABS; nsis@ietf.org; Kappler Cornelia Subject: Re: [NSIS] draft-qosmodel-controlledload-04 Hi all, just an idea: Token Bucket is the only mandatory parameter. It is interpreted by CLS = and Y.1541. RMD can map it to Bandwidth. Other Parameters, like Path Latency,etc. are optional. If a QOSM doesn't support it, it can be skipped. Mainly two types of parameters are left: Delay, Priority. If supported = by two different QOSMs, the following mapping could be tried: Delay: can be mapped to , , Priority: , , , Here should rather be derived from = than vice versa, as is more complex. Or in general the simple parameters should be derived from the more complex one. The only problem I see: Do I know the QOSM of my neighbor domain? Do I = have to consider this when sending the initiator QSPEC? Bernd Attila B=E1der (IJ/ETH) wrote: > Hi All, >=20 > If "ignore" is not a type interpretation, I also think that it should = be reformulated. >=20 > In general, to understend mandatory parameters that is not used in a = local QoSM, I see less problem. If a QOSM has to fill in mandatory parameters = that is not used in this QOSM, seems to be more difficult. >=20 > Best regards, Attila >=20 >=20 >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Monday, July 03, 2006 4:37 PM >>To: Georgios Karagiannis >>Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila B=E1der (IJ/ETH);=20 >>nsis@ietf.org; 'Kappler Cornelia' >>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >> >> >>Hi Georgios, >> >>please find my comment below: >> >>Georgios Karagiannis wrote: >> >>>Hi Jerry >>> >>>Regarding your last point: >>> >>> >>>>>Hannes: >>>>>Do you think it is awfully realistic for all QNEs to >> >>understand all >> >>>>>mandatory parameters? I could imagine that Attila and Georgios are=20 >>>>>not going to implement stateless interior QNEs in such a way that=20 >>>>>they understand all the mandatory QSPEC parameters. In fact they=20 >>>>>don't have todo it since only edge routers are likely to ever see=20 >>>>>QoS NSLP messages that contain QOSM IDs that they do not understand = >>>>>(otherwise something go terribly wrong). >>> >>> >>>>Jerry: It is up the RMD authors to specify how they want RMD >>>> >>>> >>>>>to behave wrt mandatory parameters (and obtain rough consensus, of=20 >>>>>course). That is, if a mandatory parameter is remapped and not=20 >>>>>strictly interpreted, the remapping must be specified in the QOSM=20 >>>>>specification document. >>>>>Otherwise, the QOSM must strictly interpret the mandatory=20 >>>>>parameters that are not remapped, if they are populated by the QNI. >>>>>There are no restrictions on how the remapping must be done, it can = >>>>>be as simple as necessary (but no simpler). >>> >>> >>>Georgios: >>>Jerry, I think that the point raised by Hannes is related to how the=20 >>>QNE's interior to the RMD domain will have to comply to the mandatory = =20 >>>descriptions specified in the QSPEC template. >>>An interior QNE (in RMD-QOSM) will not process the end to end QSpec.=20 >>>The only QSpec that will be processed by the interior QNE is the RMD=20 >>>Qsepc that is initiated by the ingress node (i.e., QNI for the RMD=20 >>>local session). >>>Note that the above observation is valid for all local QOSMs. >>>However, the above is not allowed due to the following text that is=20 >>>included in the QSpec template draft: >>> >>>"A QNE MUST interpret all mandatory parameters from this >> >>document even >> >>>if it does not support the received QoS NSLP message with the=20 >>>indicated QOSM." >>> >>>Therefore, in my opinion it is required to modify the above >> >>sentence in >> >>>something like: >>> >>>"A QNE SHOULD interpret all mandatory parameters from this >> >>document even >> >>>if it does not support the received QoS NSLP message with the=20 >>>indicated QOSM. A QNE that supports a local QOSM, does not >> >>have to interpret >> >>>all mandatory parameters carried by a QSpec that was >> >>generated by a QNI >> >>>located outside the domain that supports the given local QOSM."=20 >> >>Something along these lines would probably be more realistic, I guess. >> >>Ciao >>Hannes >> >> >>>Best regards, >>>Georgios >>> >>>-----Original Message----- >>>From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>>Sent: maandag 3 juli 2006 2:03 >>>To: Hannes Tschofenig >>>Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH); >> >>nsis@ietf.org; >> >>>Kappler Cornelia >>>Subject: RE: [NSIS] draft-qosmodel-controlledload-04 >>> >>>Hi Hannes, >>> >>>See below.=20 >>> >>> >>> >>>>-----Original Message----- >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>Sent: Saturday, July 01, 2006 4:26 PM >>>>To: Ash, Gerald R (Jerry), ALABS >>>>Cc: nsis@ietf.org >>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>> >>>>Hi Jerry, >>>> >>>>it is true that I haven't read the most recent QSPEC draft >> >>when I sent >> >>>>this mail. In the meanwhile I did. Please find a few comments below: >>>> >>>>Ash, Gerald R (Jerry), ALABS wrote: >>>> >>>> >>>>>Hi Hannes, >>>>> >>>>>See below.=20 >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>Sent: Friday, June 30, 2006 8:43 AM >>>>>>To: Bernd Schloer >>>>>>Cc: nsis@ietf.org >>>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>> >>>>>>Hi Bernd, >>>>>> >>>>>>Bernd Schloer wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>the first open issue in the appendix B is about what to do with=20 >>>>>>>mandatory QSPEC parameters which are not needed for CLS. >>>>>>> >>>>>>>Does a QOSM have to understand (and provide information >> >>about) all >> >>>>>>>mandatory parameters, even if they are not used? >>>>>> >>>>>>I think the question is wrong. What about the following question: >>>>>>" >>>>>>Does a node that implements a particular QOSM has to >> >>understand all >> >>>>>>mandatory parameters listed in the QSPEC template draft >>>> >>>>(even if the >>>> >>>> >>>>>>QOSM does not make use of them)? >>>>>>" >>>>>>The answer would be "YES" since the QSPEC template draft >> >>says that >> >>>>>>mandatory parameters have to be understood by every NSIS QoS node. >>>>>> >>>>>>There is only the question what "understands" means. >>>>> >>>>> >>>>>IMO you need to more carefully read the QSPEC I-D document. All=20 >>>>>mandatory QSPEC parameters that are populated in the QSPEC must be=20 >>>>>interpreted by every QNE, which is explained in the QSPEC I-D: >>>>> >>>>>It says in Section 4.4.1 (Mandatory and Optional QSPEC >>>> >>>>. Parameters) of >>>> >>>> >>>>>the QSPEC I-D >>>>>http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: >>>>> >>>>>" Mandatory QSPEC parameters are treated as follows: >>>>> >>>>> o A QNI SHOULD populate mandatory QSPEC parameters if >>>> >>>>. applicable to >>>> >>>> >>>>> the underlying QOSM. >>>> >>>>I don't understand this sentence. What does it mean that a QNI=20 >>>>"SHOULD" >>>>populate parameters if applicable? >>> >>> >>>It means that a QNI is not required to populate all >> >>mandatory parameters. A >> >>>QNI would only populated a mandatory parameter if is used >> >>by the QOSM >> >>>supported by the QNI. >>>=20 >>> >>> >>>>> o QNEs MUST interpret mandatory QSPEC parameters, if signaled." >>>>> >>>>>Furthermore, it says in Section 4.2 (QSPEC Processing): >>>>> >>>>>" a QNE >>>>> MUST at least interpret all the mandatory parameters in >>>>> a QSPEC even >>>>> if it does not support the corresponding QOSM. >>>>> >>>>> Mandatory parameters provide a minimal subset of parameters. A =20 >>>>> QNE MUST either a) strictly interpret a mandatory parameter, or >>>>> b) remap the parameter and raise the flag defined = >>>>> in Section 5.1, where the remapping MUST be specified in the QOSM = =20 >>>>> specification. Here the terminology 'strictly interpret' means=20 >>>>> that >>>> >>>>What is the difference between 'strictly interpret' and >> >>'interpret'?=20 >> >>>>In the rest of the document you use 'interpret'. >>> >>> >>>'Strictly interpret' is defined in the text I quoted from >> >>Section 4.2 (QSPEC >> >>>Processing), which is given again in the very next >> >>sentences I quoted just >> >>>below (after you posed your above question :-) >>> >>>" Mandatory parameters provide a minimal subset of parameters. A >>> QNE MUST either a) strictly interpret a mandatory parameter, or >>> b) remap the parameter and raise the flag >> >>defined in >> >>> Section 5.1, where the remapping MUST be specified in the QOSM >>> specification. Here the terminology 'strictly >> >>interpret' means that >> >>> the parameter is implemented according to the commonly accepted >>> definition and/or as specified by references given for each QSPEC >>> parameter. This means that in case a), a >> >>parameter >> >>> must be strictly interpreted as a token bucket. =20 >> >>However, in case b), >> >>> a parameter may be remapped, perhaps to a >> >> >> >>> parameter." >>> >>>In the document, the term 'interpret' a mandatory parameter >> >>means either a) >> >>>strictly interpret (as defined above), or b) remap (as >> >>defined above). >> >>>Perhaps this can be made clearer in the text. >>>=20 >>> >>> >>>>> the parameter is implemented according to the commonly accepted =20 >>>>> definition and/or as specified by references given for >> >>each QSPEC >> >>>>> parameter. This means that in case a), a =20 >>>>> parameter must be strictly interpreted as a token bucket. >>>>> However, in case b), >>>>> a parameter may be remapped, perhaps to a =20 >>>>> parameter. >>>> >>>>I noticed this text improvement and I am happy to see more >> >>text about >> >>>>it. >>>> >>>>Still, I have some issues with the section: >>>> >>>>I had a problem with this paragraph following the previous >> >>one in the >> >>>>section. The previous paragraph said " >>>>However, if a QSPEC arrives at a QNE that does >>>> not support the QOSM being signaled, it can still understand the >>>> QSPEC content, at least to a basic degree. >>>>" >>>> >>>>When I read through the text I got the impression that the two=20 >>>>sections relate to each other and in fact they do not. Hence, I=20 >>>>suggest to delete the previous paragraph since this one >> >>contains the >> >>>>info already. >>> >>> >>>I'm unclear as to which paragraph/text you are proposing to delete. >>> >>> >>> >>>>You >>>>might also want to delete the second paragraph as well >> >>since it is far >> >>>>too obvious to use RFC2119 language: If you don't support even a=20 >>>>single QOSM then why are you a QOS NSLP node in the first place. >>> >>> >>>I think it important to state that a QNE MUST support at >> >>least one QOSM, >> >>>even if this is clearly necessary to effectively support >> >>QoS-NSLP/QSPEC. >> >>> >>>>You might want to highlight the following sentence, though: >>>> >>>>" >>>>A QNE MUST interpret all mandatory parameters from this >> >>document even >> >>>>if it does not support the received QoS NSLP message with the=20 >>>>indicated QOSM. >>>>" >>>> >>>>Here is my proposal for the section: >>>> >>>>" >>>>4.2 QSPEC Processing >>>> >>>> The QSPEC is opaque to the QoS NSLP processing. The >> >>QSPEC control >> >>>> information and the QoS description are interpreted and MAY be >>>> modified by the RMF in a QNE (see description in [QoS-SIG]). >>>> >>>> The QSPEC contains a QOSM ID, i.e. information on what=20 >>>> QOSM is being >>>> signaled by the QNI. However, if a QSPEC arrives at a=20 >>>> QNE that does >>>> not support the QOSM being signaled, it can still understand the >>>> QSPEC content, at least to a basic degree. This is=20 >>>> because mandatory >>>> parameters have been defined as a common language. =20 >>>> Therefore, a QNE >>>> MUST at least interpret all the mandatory parameters in a=20 >>>> QSPEC even >>>> if it does not support the corresponding QOSM. >>>> >>>> A QNE MUST either >>>> >>>> a) interpret a mandatory parameter carried in the QSPEC >> >>object, or >> >>>> b) remap the parameter and raise the flag=20 >>>> defined in >>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>> specification. >>>> >>>> Here the terminology 'interpret' means that >>>> the parameter is implemented according to the references=20 >>>> given for=20 >>>> each QSPEC parameter. >>>> >>>> If a QSPEC arrives at a QNE that does not support the QOSM being >>>> signaled, it can still understand the QSPEC content, at >> >>least to a >> >>>> basic degree. Hence, with case (a), a parameter >>>> must be strictly interpreted as a token bucket. >>>> >>>> In case b), a parameter may be remapped,=20 >>>> perhaps to a >>>> parameter. >>>>" >>> >>> >>>I don't see any benefit in redefining what 'interpret' means in the=20 >>>document. As I mentioned above, the document uses the term >> >>'interpret' to >> >>>mean that a mandatory parameter is 'interpreted' if is >> >>either 'strictly >> >>>interpreted' or it is 'remapped' (where the remapping must >> >>be defined in the >> >>>QOSM specification document). OTOH, it might be useful to define a=20 >>>'remapping' flag to indicated if a mandatory or optional >> >>parameter has been >> >>>remapped by a QNE in the path. >>>=20 >>> >>> >>>>Btw, have you noticed that the draft has >>>>* a flag (Section 5.1) >>>>* a parameter (Section 7.2.1) >>>> >>>>I think they refer to the same concept... >>> >>> >>>Yes, good catch. is indeed intended to be a >> >>flag, and >> >>>perhaps one of the QSPEC object flags defined in Section >> >>7.1 could be used >> >>>for this purpose, rather than use a full 32-bit parameter >> >>for this purpose, >> >>>as currently specified in Section 7.2.1. >>>=20 >>> >>> >>>>> In the latter case, the remapping of the to =20 >>>>> must be specified in the QOSM specification >> >>document. >> >>>>> For example, QOSM X exclusively uses the parameter . = >>>>> It must define a mapping of the mandatory parameter >>>> Bucket>. >>>>> The mapping consists of interpreting the Token Bucket Rate as =20 >>>>> the parameter and disregarding the other >> >>Token Bucket >> >>>>> parameters. Clearly, some information contained in the >>>> Bucket> parameter is lost by this mapping, and the resulting QoS=20 >>>>> may not be quite what was intended by the QNI. Therefore, QOSM=20 >>>>> X also specifies that the flag be raised. Thus, =20 >>>>> a QNE using QOSM X is able to make an informed decision whether=20 >>>>> to admit a reservation described in terms of , and >> >>at the same >> >>>>> time (by means of ) signals to the >> >>QNI/QNR that the >> >>>>> exact intention of the QNI may not be met." >>>>> >>>>>I think this text is pretty clear as to what is required regarding=20 >>>>>interpreting mandatory parameters. If not, please suggest=20 >>>>>clarifications. >>>> >>>>The text in the new draft has improved a lot. >>>>Thanks for the update. >>>> >>>> >>>> >>>>>>Another possible question would be: >>>>>>" >>>>>>Does a node that implements a particular QOSM has to >> >>define mappings >> >>>>>>from all mandatory parameters listed in the QSPEC >> >>template draft to >> >>>>>>the QOSM draft (even if the QOSM does not make use >>>> >>>>of them)? >>>> >>>> >>>>>>" >>>>>> >>>>>>The answer is "I don't know". >>>>> >>>>> >>>>>A QNE must interpret all mandatory parameters, if populated, as=20 >>>>>explained in the above text I quoted. If a QOSM re-maps a >> >>mandatory >> >>>>>QSPEC parameter, that re-mapping must be defined in the QOSM=20 >>>>>specification. As stated in Section 4.7 (QOSM Specification >>>>>Requirements): >>>>> >>>>>" A QOSM specification MUST define QSPEC parameter=20 >>>>> behavior for these >>>>> cases: a) new optional QSPEC parameters the QOSM specification >>>>> defines, and b) remapping of existing mandatory or >> >>optional QSPEC >> >>>>> parameters, as described in Section 4.2. Unless otherwise=20 >>>>> specified in the QOSM specification document, the behaviors to=20 >>>>> strictly interpret the mandatory and optional QSPEC parameters =20 >>>>> are defined in this document through the references to RFCs that = >>>>> precisely define the QSPEC parameter behaviors. >>>>> >>>>> A QOSM specification MUST define how the mandatory parameters=20 >>>>> are to be mapped onto the QSPEC parameters used by the QOSM, >> >>however the >> >>>>> mapping MAY result in slight modification to the intended =20 >>>>> specification when an exact mapping is not possible. >>>>> This definition >>>>> MUST allow a QNE implementing this QOSM to make a decision as to = >>>>> whether a reservation described in terms of mandatory parameters=20 >>>>> can be admitted. If for a particular mandatory parameter no =20 >>>>> mapping can be found that guarantees the desired QoS, the QNE is = >>>>> advised to raise the flag. In other words, for=20 >>>>> all mandatory parameters a mapping must be defined, but it is >> >>acknowledged that >> >>>>> this mapping may result in slightly bending the original =20 >>>>> intention of the QNI." >>>>> >>>>>I think this text is pretty clear as to what is required. If not,=20 >>>>>please suggest clarifications. >>>> >>>>I understood the token bucket to bandwidth example. >>>> >>>>Would the RMD draft, for example, list all mandatory parameters and=20 >>>>indicate whether it can map them (and how) to parameters used in the = >>>>RMD specification? >>> >>> >>>As stated in the QOSM specification requirements in Section >> >>4.7, if a QOSM >> >>>remaps a mandatory parameter, the remapping must be defined >> >>in the QOSM >> >>>specification document. If no such remapping is defined, >> >>the default >> >>>behavior is that the QOSM must strictly interpret the >> >>mandatory parameter, >> >>>as defined above. >>>=20 >>> >>> >>>>Do you think it is awfully realistic for all QNEs to understand all=20 >>>>mandatory parameters? I could imagine that Attila and Georgios are=20 >>>>not going to implement stateless interior QNEs in such a way that=20 >>>>they understand all the mandatory QSPEC parameters. In fact they=20 >>>>don't have todo it since only edge routers are likely to ever see=20 >>>>QoS NSLP messages that contain QOSM IDs that they do not understand=20 >>>>(otherwise something go terribly wrong). >>> >>> >>>It is up the RMD authors to specify how they want RMD to behave wrt=20 >>>mandatory parameters (and obtain rough consensus, of >> >>course). That is, if a >> >>>mandatory parameter is remapped and not strictly >> >>interpreted, the remapping >> >>>must be specified in the QOSM specification document. =20 >> >>Otherwise, the QOSM >> >>>must strictly interpret the mandatory parameters that are >> >>not remapped, if >> >>>they are populated by the QNI. >>> >>>There are no restrictions on how the remapping must be >> >>done, it can be as >> >>>simple as necessary (but no simpler). >>> >>>Thanks, >>>Jerry >>> >>> >>> >>>>Ciao >>>>Hannes >>>> >>>> >>>> >>>>>Thanks, >>>>>Jerry >>>>> >>>>> >>>>> >>>>> >>>>>>Ciao >>>>>>Hannes >>>>>> >>>>>>The QSPEC-draft says in section 5 >>>>>> >>>>>> >>>>>> >>>>>>>that >>>>>>>all parameters listed in the next sections are mandatory. The=20 >>>>>>>QSPEC-draft also says in section 4.1 that "a given QOSM defines=20 >>>>>>>which of the >>>>>> >>>>>>mandatory and >>>>>> >>>>>> >>>>>> >>>>>>>optional parameters it uses, ..." >>>>>>> >>>>>>>Are there any specific parameters which makes the open >>>> >>>>issue B.1.1.=20 >>>> >>>> >>>>>>>clearer? Following the QSPEC-draft there doesn't seem to be >>>>>> >>>>>>a conflict, >>>>>> >>>>>> >>>>>> >>>>>>>if nothing is >>>>>>>done with the unneeded parameters. >>>>>>> >>>>>>>Thanks, >>>>>>>Bernd >>> >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >>> >> >> >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 06:26:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxi6k-0008Oc-3o; Tue, 04 Jul 2006 06:26:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxi6j-0008OX-5l for nsis@ietf.org; Tue, 04 Jul 2006 06:26:17 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fxi6i-000392-0W for nsis@ietf.org; Tue, 04 Jul 2006 06:26:17 -0400 Received: (qmail invoked by alias); 04 Jul 2006 10:26:14 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp017) with SMTP; 04 Jul 2006 12:26:14 +0200 X-Authenticated: #29516787 Message-ID: <44AA4247.9010605@gmx.net> Date: Tue, 04 Jul 2006 12:26:15 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernd Schloer Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <05F34B6959F19F43BBD78FFCD4C15D055DFE60@esealmw116.eemea.ericsson.se> <44A996C2.7010602@cs.uni-goettingen.de> In-Reply-To: <44A996C2.7010602@cs.uni-goettingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 3d9377227c64d8007f9382a92e11ad5d Cc: "Ash, Gerald R \(Jerry\), ALABS" , Georgios Karagiannis , Kappler Cornelia , nsis@ietf.org, =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd, Bernd Schloer wrote: > Hi all, > > just an idea: > > Token Bucket is the only mandatory parameter. There are several mandatory parameters defined in the QSPEC, namely: * NON QOSM Hop * Excess Treatment * Bandwidth * Token Bucket * PHB Class * Y.1541 QoS Class * DSTE Class Type * & * Admission Priority * RPH Priority Are you suggesting to reduce the list to a single mandatory parameter? It is interpreted by CLS > and Y.1541. RMD can map it to Bandwidth. CLS and Y.1541 use the token bucket parameter. RMD says that it can be mapped to bandwidth if the e2e message contains the token bucket parameter in a QOSM that is not understood. > > Other Parameters, like Path Latency,etc. are optional. If a QOSM doesn't > support it, it can be skipped. Correct. > > Mainly two types of parameters are left: Delay, Priority. If supported > by two different QOSMs, the following mapping could be tried: > > Delay: can be mapped to , Jitter>, > > Priority: , , Priority>, > Here should rather be derived from > than vice versa, as is more complex. Or in general the > simple parameters should be derived from the more complex one. I do not quite follow this idea. > > The only problem I see: Do I know the QOSM of my neighbor domain? Do I > have to consider this when sending the initiator QSPEC? Note that you do not necessarily only need to know your neighoring domain. Consider the migration scenario where many networks don't understand the QoS signaling message at all. For example, you might consider the case where only the access networks inspect the NSIS signaling messages. Ciao Hannes > > Bernd > > > > > Attila Báder (IJ/ETH) wrote: > >> Hi All, >> >> If "ignore" is not a type interpretation, I also think that it should >> be reformulated. >> >> In general, to understend mandatory parameters that is not used in a >> local QoSM, I see less problem. If a QOSM has to fill in mandatory >> parameters that is not used in this QOSM, seems to be more difficult. >> >> Best regards, Attila >> >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Monday, July 03, 2006 4:37 PM >>> To: Georgios Karagiannis >>> Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila Báder (IJ/ETH); >>> nsis@ietf.org; 'Kappler Cornelia' >>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>> >>> >>> Hi Georgios, >>> >>> please find my comment below: >>> >>> Georgios Karagiannis wrote: >>> >>>> Hi Jerry >>>> Regarding your last point: >>>> >>>> >>>>>> Hannes: >>>>>> Do you think it is awfully realistic for all QNEs to >>> >>> >>> understand all >>> >>>>>> mandatory parameters? I could imagine that Attila and Georgios are >>>>>> not going to implement stateless interior QNEs in such a way that >>>>>> they understand all the mandatory QSPEC parameters. In fact they >>>>>> don't have todo it since only edge routers are likely to ever see >>>>>> QoS NSLP messages that contain QOSM IDs that they do not >>>>>> understand (otherwise something go terribly wrong). >>>> >>>> >>>> >>>>> Jerry: It is up the RMD authors to specify how they want RMD >>>>> >>>>>> to behave wrt mandatory parameters (and obtain rough consensus, of >>>>>> course). That is, if a mandatory parameter is remapped and not >>>>>> strictly interpreted, the remapping must be specified in the QOSM >>>>>> specification document. Otherwise, the QOSM must strictly >>>>>> interpret the mandatory parameters that are not remapped, if they >>>>>> are populated by the QNI. >>>>>> There are no restrictions on how the remapping must be done, it >>>>>> can be as simple as necessary (but no simpler). >>>> >>>> >>>> >>>> Georgios: >>>> Jerry, I think that the point raised by Hannes is related to >>>> how the QNE's interior to the RMD domain will have to comply to the >>>> mandatory descriptions specified in the QSPEC template. An interior >>>> QNE (in RMD-QOSM) will not process the end to end QSpec. The only >>>> QSpec that will be processed by the interior QNE is the RMD Qsepc >>>> that is initiated by the ingress node (i.e., QNI for the RMD local >>>> session). Note that the above observation is valid for all local QOSMs. >>>> However, the above is not allowed due to the following text that is >>>> included in the QSpec template draft: >>>> >>>> "A QNE MUST interpret all mandatory parameters from this >>> >>> >>> document even >>> >>>> if it does not support the received QoS NSLP message with the >>>> indicated QOSM." >>>> >>>> Therefore, in my opinion it is required to modify the above >>> >>> >>> sentence in >>> >>>> something like: >>>> >>>> "A QNE SHOULD interpret all mandatory parameters from this >>> >>> >>> document even >>> >>>> if it does not support the received QoS NSLP message with the >>>> indicated QOSM. A QNE that supports a local QOSM, does not >>> >>> >>> have to interpret >>> >>>> all mandatory parameters carried by a QSpec that was >>> >>> >>> generated by a QNI >>> >>>> located outside the domain that supports the given local QOSM." >>> >>> >>> Something along these lines would probably be more realistic, I guess. >>> >>> Ciao >>> Hannes >>> >>> >>>> Best regards, >>>> Georgios >>>> >>>> -----Original Message----- >>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] Sent: >>>> maandag 3 juli 2006 2:03 >>>> To: Hannes Tschofenig >>>> Cc: Ash, Gerald R (Jerry), ALABS; Attila Báder (IJ/ETH); >>> >>> >>> nsis@ietf.org; >>> >>>> Kappler Cornelia >>>> Subject: RE: [NSIS] draft-qosmodel-controlledload-04 >>>> >>>> Hi Hannes, >>>> >>>> See below. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Saturday, July 01, 2006 4:26 PM >>>>> To: Ash, Gerald R (Jerry), ALABS >>>>> Cc: nsis@ietf.org >>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>> >>>>> Hi Jerry, >>>>> >>>>> it is true that I haven't read the most recent QSPEC draft >>> >>> >>> when I sent >>> >>>>> this mail. In the meanwhile I did. Please find a few comments below: >>>>> >>>>> Ash, Gerald R (Jerry), ALABS wrote: >>>>> >>>>> >>>>>> Hi Hannes, >>>>>> >>>>>> See below. >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Friday, June 30, 2006 8:43 AM >>>>>>> To: Bernd Schloer >>>>>>> Cc: nsis@ietf.org >>>>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>>> >>>>>>> Hi Bernd, >>>>>>> >>>>>>> Bernd Schloer wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> the first open issue in the appendix B is about what to do with >>>>>>>> mandatory QSPEC parameters which are not needed for CLS. >>>>>>>> >>>>>>>> Does a QOSM have to understand (and provide information >>> >>> >>> about) all >>> >>>>>>>> mandatory parameters, even if they are not used? >>>>>>> >>>>>>> >>>>>>> I think the question is wrong. What about the following question: >>>>>>> " >>>>>>> Does a node that implements a particular QOSM has to >>> >>> >>> understand all >>> >>>>>>> mandatory parameters listed in the QSPEC template draft >>>>> >>>>> >>>>> (even if the >>>>> >>>>> >>>>>>> QOSM does not make use of them)? >>>>>>> " >>>>>>> The answer would be "YES" since the QSPEC template draft >>> >>> >>> says that >>> >>>>>>> mandatory parameters have to be understood by every NSIS QoS node. >>>>>>> >>>>>>> There is only the question what "understands" means. >>>>>> >>>>>> >>>>>> >>>>>> IMO you need to more carefully read the QSPEC I-D document. All >>>>>> mandatory QSPEC parameters that are populated in the QSPEC must be >>>>>> interpreted by every QNE, which is explained in the QSPEC I-D: >>>>>> >>>>>> It says in Section 4.4.1 (Mandatory and Optional QSPEC >>>>> >>>>> >>>>> . Parameters) of >>>>> >>>>> >>>>>> the QSPEC I-D >>>>>> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: >>>>>> >>>>>> " Mandatory QSPEC parameters are treated as follows: >>>>>> >>>>>> o A QNI SHOULD populate mandatory QSPEC parameters if >>>>> >>>>> >>>>> . applicable to >>>>> >>>>> >>>>>> the underlying QOSM. >>>>> >>>>> >>>>> I don't understand this sentence. What does it mean that a QNI >>>>> "SHOULD" >>>>> populate parameters if applicable? >>>> >>>> >>>> >>>> It means that a QNI is not required to populate all >>> >>> >>> mandatory parameters. A >>> >>>> QNI would only populated a mandatory parameter if is used >>> >>> >>> by the QOSM >>> >>>> supported by the QNI. >>>> >>>> >>>> >>>>>> o QNEs MUST interpret mandatory QSPEC parameters, if signaled." >>>>>> >>>>>> Furthermore, it says in Section 4.2 (QSPEC Processing): >>>>>> >>>>>> " a QNE >>>>>> MUST at least interpret all the mandatory parameters in a QSPEC >>>>>> even >>>>>> if it does not support the corresponding QOSM. >>>>>> >>>>>> Mandatory parameters provide a minimal subset of parameters. A >>>>>> QNE MUST either a) strictly interpret a mandatory parameter, or >>>>>> b) remap the parameter and raise the flag defined in >>>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>>> specification. Here the terminology 'strictly interpret' means >>>>>> that >>>>> >>>>> >>>>> What is the difference between 'strictly interpret' and >>> >>> >>> 'interpret'? >>> >>>>> In the rest of the document you use 'interpret'. >>>> >>>> >>>> >>>> 'Strictly interpret' is defined in the text I quoted from >>> >>> >>> Section 4.2 (QSPEC >>> >>>> Processing), which is given again in the very next >>> >>> >>> sentences I quoted just >>> >>>> below (after you posed your above question :-) >>>> >>>> " Mandatory parameters provide a minimal subset of parameters. A >>>> QNE MUST either a) strictly interpret a mandatory parameter, or >>>> b) remap the parameter and raise the flag >>> >>> >>> defined in >>> >>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>> specification. Here the terminology 'strictly >>> >>> >>> interpret' means that >>> >>>> the parameter is implemented according to the commonly accepted >>>> definition and/or as specified by references given for each QSPEC >>>> parameter. This means that in case a), a >>> >>> >>> parameter >>> >>>> must be strictly interpreted as a token bucket. >>> >>> >>> However, in case b), >>> >>>> a parameter may be remapped, perhaps to a >>> >>> >>> >>> >>>> parameter." >>>> >>>> In the document, the term 'interpret' a mandatory parameter >>> >>> >>> means either a) >>> >>>> strictly interpret (as defined above), or b) remap (as >>> >>> >>> defined above). >>> >>>> Perhaps this can be made clearer in the text. >>>> >>>> >>>> >>>>>> the parameter is implemented according to the commonly accepted >>>>>> definition and/or as specified by references given for >>> >>> >>> each QSPEC >>> >>>>>> parameter. This means that in case a), a parameter >>>>>> must be strictly interpreted as a token bucket. However, in >>>>>> case b), >>>>>> a parameter may be remapped, perhaps to a >>>>>> >>>>>> parameter. >>>>> >>>>> >>>>> I noticed this text improvement and I am happy to see more >>> >>> >>> text about >>> >>>>> it. >>>>> >>>>> Still, I have some issues with the section: >>>>> >>>>> I had a problem with this paragraph following the previous >>> >>> >>> one in the >>> >>>>> section. The previous paragraph said " >>>>> However, if a QSPEC arrives at a QNE that does >>>>> not support the QOSM being signaled, it can still understand the >>>>> QSPEC content, at least to a basic degree. >>>>> " >>>>> >>>>> When I read through the text I got the impression that the two >>>>> sections relate to each other and in fact they do not. Hence, I >>>>> suggest to delete the previous paragraph since this one >>> >>> >>> contains the >>> >>>>> info already. >>>> >>>> >>>> >>>> I'm unclear as to which paragraph/text you are proposing to delete. >>>> >>>> >>>> >>>>> You >>>>> might also want to delete the second paragraph as well >>> >>> >>> since it is far >>> >>>>> too obvious to use RFC2119 language: If you don't support even a >>>>> single QOSM then why are you a QOS NSLP node in the first place. >>>> >>>> >>>> >>>> I think it important to state that a QNE MUST support at >>> >>> >>> least one QOSM, >>> >>>> even if this is clearly necessary to effectively support >>> >>> >>> QoS-NSLP/QSPEC. >>> >>>> >>>>> You might want to highlight the following sentence, though: >>>>> >>>>> " >>>>> A QNE MUST interpret all mandatory parameters from this >>> >>> >>> document even >>> >>>>> if it does not support the received QoS NSLP message with the >>>>> indicated QOSM. >>>>> " >>>>> >>>>> Here is my proposal for the section: >>>>> >>>>> " >>>>> 4.2 QSPEC Processing >>>>> >>>>> The QSPEC is opaque to the QoS NSLP processing. The >>> >>> >>> QSPEC control >>> >>>>> information and the QoS description are interpreted and MAY be >>>>> modified by the RMF in a QNE (see description in [QoS-SIG]). >>>>> >>>>> The QSPEC contains a QOSM ID, i.e. information on what QOSM is >>>>> being >>>>> signaled by the QNI. However, if a QSPEC arrives at a QNE that >>>>> does >>>>> not support the QOSM being signaled, it can still understand the >>>>> QSPEC content, at least to a basic degree. This is because >>>>> mandatory >>>>> parameters have been defined as a common language. Therefore, >>>>> a QNE >>>>> MUST at least interpret all the mandatory parameters in a QSPEC >>>>> even >>>>> if it does not support the corresponding QOSM. >>>>> >>>>> A QNE MUST either >>>>> >>>>> a) interpret a mandatory parameter carried in the QSPEC >>> >>> >>> object, or >>> >>>>> b) remap the parameter and raise the flag >>>>> defined in >>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>> specification. >>>>> >>>>> Here the terminology 'interpret' means that >>>>> the parameter is implemented according to the references given >>>>> for each QSPEC parameter. >>>>> >>>>> If a QSPEC arrives at a QNE that does not support the QOSM being >>>>> signaled, it can still understand the QSPEC content, at >>> >>> >>> least to a >>> >>>>> basic degree. Hence, with case (a), a parameter >>>>> must be strictly interpreted as a token bucket. >>>>> >>>>> In case b), a parameter may be remapped, perhaps >>>>> to a >>>>> parameter. >>>>> " >>>> >>>> >>>> >>>> I don't see any benefit in redefining what 'interpret' means in the >>>> document. As I mentioned above, the document uses the term >>> >>> >>> 'interpret' to >>> >>>> mean that a mandatory parameter is 'interpreted' if is >>> >>> >>> either 'strictly >>> >>>> interpreted' or it is 'remapped' (where the remapping must >>> >>> >>> be defined in the >>> >>>> QOSM specification document). OTOH, it might be useful to define a >>>> 'remapping' flag to indicated if a mandatory or optional >>> >>> >>> parameter has been >>> >>>> remapped by a QNE in the path. >>>> >>>> >>>> >>>>> Btw, have you noticed that the draft has >>>>> * a flag (Section 5.1) >>>>> * a parameter (Section 7.2.1) >>>>> >>>>> I think they refer to the same concept... >>>> >>>> >>>> >>>> Yes, good catch. is indeed intended to be a >>> >>> >>> flag, and >>> >>>> perhaps one of the QSPEC object flags defined in Section >>> >>> >>> 7.1 could be used >>> >>>> for this purpose, rather than use a full 32-bit parameter >>> >>> >>> for this purpose, >>> >>>> as currently specified in Section 7.2.1. >>>> >>>> >>>> >>>>>> In the latter case, the remapping of the to >>>>>> must be specified in the QOSM specification >>> >>> >>> document. >>> >>>>>> For example, QOSM X exclusively uses the parameter . It >>>>>> must define a mapping of the mandatory parameter . >>>>>> The mapping consists of interpreting the Token Bucket Rate as >>>>>> the parameter and disregarding the other >>> >>> >>> Token Bucket >>> >>>>>> parameters. Clearly, some information contained in the >>>>> Bucket> parameter is lost by this mapping, and the resulting QoS >>>>>> may >>>>>> not be quite what was intended by the QNI. Therefore, QOSM X also >>>>>> specifies that the flag be raised. Thus, a QNE >>>>>> using >>>>>> QOSM X is able to make an informed decision whether to admit a >>>>>> reservation described in terms of , and >>> >>> >>> at the same >>> >>>>>> time (by means of ) signals to the >>> >>> >>> QNI/QNR that the >>> >>>>>> exact intention of the QNI may not be met." >>>>>> >>>>>> I think this text is pretty clear as to what is required regarding >>>>>> interpreting mandatory parameters. If not, please suggest >>>>>> clarifications. >>>>> >>>>> >>>>> The text in the new draft has improved a lot. >>>>> Thanks for the update. >>>>> >>>>> >>>>> >>>>>>> Another possible question would be: >>>>>>> " >>>>>>> Does a node that implements a particular QOSM has to >>> >>> >>> define mappings >>> >>>>>>> from all mandatory parameters listed in the QSPEC >>> >>> >>> template draft to >>> >>>>>>> the QOSM draft (even if the QOSM does not make use >>>>> >>>>> >>>>> of them)? >>>>> >>>>> >>>>>>> " >>>>>>> >>>>>>> The answer is "I don't know". >>>>>> >>>>>> >>>>>> >>>>>> A QNE must interpret all mandatory parameters, if populated, as >>>>>> explained in the above text I quoted. If a QOSM re-maps a >>> >>> >>> mandatory >>> >>>>>> QSPEC parameter, that re-mapping must be defined in the QOSM >>>>>> specification. As stated in Section 4.7 (QOSM Specification >>>>>> Requirements): >>>>>> >>>>>> " A QOSM specification MUST define QSPEC parameter behavior for >>>>>> these >>>>>> cases: a) new optional QSPEC parameters the QOSM specification >>>>>> defines, and b) remapping of existing mandatory or >>> >>> >>> optional QSPEC >>> >>>>>> parameters, as described in Section 4.2. Unless otherwise >>>>>> specified >>>>>> in the QOSM specification document, the behaviors to strictly >>>>>> interpret the mandatory and optional QSPEC parameters are >>>>>> defined in >>>>>> this document through the references to RFCs that precisely define >>>>>> the QSPEC parameter behaviors. >>>>>> A QOSM specification MUST define how the mandatory parameters >>>>>> are to >>>>>> be mapped onto the QSPEC parameters used by the QOSM, >>> >>> >>> however the >>> >>>>>> mapping MAY result in slight modification to the intended >>>>>> specification when an exact mapping is not possible. This >>>>>> definition >>>>>> MUST allow a QNE implementing this QOSM to make a decision as to >>>>>> whether a reservation described in terms of mandatory parameters >>>>>> can >>>>>> be admitted. If for a particular mandatory parameter no mapping >>>>>> can >>>>>> be found that guarantees the desired QoS, the QNE is advised to >>>>>> raise >>>>>> the flag. In other words, for all mandatory >>>>>> parameters a mapping must be defined, but it is >>> >>> >>> acknowledged that >>> >>>>>> this mapping may result in slightly bending the original >>>>>> intention of >>>>>> the QNI." >>>>>> >>>>>> I think this text is pretty clear as to what is required. If not, >>>>>> please suggest clarifications. >>>>> >>>>> >>>>> I understood the token bucket to bandwidth example. >>>>> >>>>> Would the RMD draft, for example, list all mandatory parameters and >>>>> indicate whether it can map them (and how) to parameters used in >>>>> the RMD specification? >>>> >>>> >>>> >>>> As stated in the QOSM specification requirements in Section >>> >>> >>> 4.7, if a QOSM >>> >>>> remaps a mandatory parameter, the remapping must be defined >>> >>> >>> in the QOSM >>> >>>> specification document. If no such remapping is defined, >>> >>> >>> the default >>> >>>> behavior is that the QOSM must strictly interpret the >>> >>> >>> mandatory parameter, >>> >>>> as defined above. >>>> >>>> >>>> >>>>> Do you think it is awfully realistic for all QNEs to understand all >>>>> mandatory parameters? I could imagine that Attila and Georgios are >>>>> not going to implement stateless interior QNEs in such a way that >>>>> they understand all the mandatory QSPEC parameters. In fact they >>>>> don't have todo it since only edge routers are likely to ever see >>>>> QoS NSLP messages that contain QOSM IDs that they do not understand >>>>> (otherwise something go terribly wrong). >>>> >>>> >>>> >>>> It is up the RMD authors to specify how they want RMD to behave wrt >>>> mandatory parameters (and obtain rough consensus, of >>> >>> >>> course). That is, if a >>> >>>> mandatory parameter is remapped and not strictly >>> >>> >>> interpreted, the remapping >>> >>>> must be specified in the QOSM specification document. >>> >>> >>> Otherwise, the QOSM >>> >>>> must strictly interpret the mandatory parameters that are >>> >>> >>> not remapped, if >>> >>>> they are populated by the QNI. >>>> >>>> There are no restrictions on how the remapping must be >>> >>> >>> done, it can be as >>> >>>> simple as necessary (but no simpler). >>>> >>>> Thanks, >>>> Jerry >>>> >>>> >>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> Jerry >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> The QSPEC-draft says in section 5 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> that >>>>>>>> all parameters listed in the next sections are mandatory. The >>>>>>>> QSPEC-draft also >>>>>>>> says in section 4.1 that "a given QOSM defines which of the >>>>>>> >>>>>>> >>>>>>> mandatory and >>>>>>> >>>>>>> >>>>>>> >>>>>>>> optional parameters it uses, ..." >>>>>>>> >>>>>>>> Are there any specific parameters which makes the open >>>>> >>>>> >>>>> issue B.1.1. >>>>> >>>>>>>> clearer? Following the QSPEC-draft there doesn't seem to be >>>>>>> >>>>>>> >>>>>>> a conflict, >>>>>>> >>>>>>> >>>>>>>> if nothing is >>>>>>>> done with the unneeded parameters. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bernd >>>> >>>> >>>> >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/nsis >>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 06:54:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxiY7-0007Tk-BV; Tue, 04 Jul 2006 06:54:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxiY5-0007Tf-E6 for nsis@ietf.org; Tue, 04 Jul 2006 06:54:33 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxiY4-0004YZ-1D for nsis@ietf.org; Tue, 04 Jul 2006 06:54:33 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k64AsIqh008978; Tue, 4 Jul 2006 12:54:26 +0200 (MEST) From: "Georgios Karagiannis" To: , Subject: RE: [NSIS] Revised WGLC on RMD & new WGLC on Y1541 Date: Tue, 4 Jul 2006 12:54:20 +0200 Message-ID: <003101c69f58$36c20060$4c0d5982@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: AcacQt/F6eJBvNXpSt+MxfHV+3J+JwDFLK8A In-Reply-To: X-Spam-Score: -5.681 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 04 Jul 2006 12:54:29 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John Maybe one week after the WGLC is expired it will be enough! Could you please set the WGLC deadline for RMD-QOSM and Y1541-QOSM on July 14th, instead of 20th? Note that many of us will start their holidays after the IETF meeting! Best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: vrijdag 30 juni 2006 14:44 To: nsis@ietf.org Subject: [NSIS] Revised WGLC on RMD & new WGLC on Y1541 Hi all, RMD is currently in WGLC, but as it is dependent on the QoS NSLP & QoS Template document, I will need to push back the WGLC on it. The WGLC will runn until July 20th, just in case there are any issues on either the QoS NSLP or QoS Template document. Feel free to review it now, though. http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-07.txt This draft is also ready for WGLC: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-02.txt and I will also start WGLC, going until July 20th. Again, send comments early. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 07:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxizX-0005Rf-UH; Tue, 04 Jul 2006 07:22:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxizW-0005RX-6y for nsis@ietf.org; Tue, 04 Jul 2006 07:22:54 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxizU-0007NY-K5 for nsis@ietf.org; Tue, 04 Jul 2006 07:22:54 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 772396E0002; Tue, 4 Jul 2006 13:22:47 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 13:22:46 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 13:22:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] draft-qosmodel-controlledload-04 Date: Tue, 4 Jul 2006 13:22:46 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D055DFE66@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] draft-qosmodel-controlledload-04 Thread-Index: AcafOKqk8mVkO3+5SY6IEBO7B3XfIwAH8vrQ From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Geib, Ruediger" , X-OriginalArrivalTime: 04 Jul 2006 11:22:46.0648 (UTC) FILETIME=[2CF1A780:01C69F5C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 285c5d2442d4c903d8dda55de04f5334 Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi R=FCdiger and All,=20 The mapping should be defined, the question is where. The current QSPEC = assumes that it is defined in the QoS model drafts, since the mapping = may depends on the QoS models.=20 Best regards, Attila > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Tuesday, July 04, 2006 9:08 AM > To: bschloer@cs.uni-goettingen.de; Attila B=E1der (IJ/ETH) > Cc: gash@att.com; nsis@ietf.org > Subject: RE: [NSIS] draft-qosmodel-controlledload-04 >=20 >=20 > Bernd, Attila, >=20 > Attila raised concerns about mappings of mandatory parameters=20 > being difficult. Bernd proposed a definition of mappings=20 > (omitted here) and concludes: >=20 > |The only problem I see: Do I know the QOSM of my neighbor=20 > |domain? Do I have to consider this when sending the=20 > |initiator QSPEC? >=20 > What you discuss is an interworking or a partial interworking=20 > between different services. Interworkings are common in=20 > the telephony world. It is important to be aware where they=20 > happen and to know their characteristics, meaning they need=20 > to be specified.=20 >=20 > Unspecified mappings of parameters should therefore not occur.=20 > The spec should say that. If a parameter isn't interpreted=20 > and this is a "specified behaviour" known to all parties, > that may still be tolerable, I think. >=20 > Regards, >=20 > R=FCdiger >=20 >=20 > | > |Attila B=E1der (IJ/ETH) wrote: > |> Hi All, > |>=20 > |> If "ignore" is not a type interpretation, I also think that=20 > |> it should be reformulated. > |>=20 > |> In general, to understend mandatory parameters that is not=20 > |> used in a local QoSM, I see less problem. If a QOSM has to=20 > |> fill in mandatory parameters that is not used in this QOSM,=20 > |> seems to be more difficult. > |>=20 > |> Best regards, Attila > |>=20 > |>=20 > |>>-----Original Message----- > |>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > |>>Sent: Monday, July 03, 2006 4:37 PM > |>>To: Georgios Karagiannis > |>>Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila B=E1der (IJ/ETH); > |>>nsis@ietf.org; 'Kappler Cornelia' > |>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 > |>> > |>> > |>>Hi Georgios, > |>> > |>>please find my comment below: > |>> > |>>Georgios Karagiannis wrote: > |>> > |>>>Hi Jerry=20 > |>>> > |>>>Regarding your last point: > |>>> > |>>> > |>>>>>Hannes: > |>>>>>Do you think it is awfully realistic for all QNEs to=20 > |>> > |>>understand all=20 > |>> > |>>>>>mandatory parameters? I could imagine that Attila and=20 > |>>>>>Georgios are not=20 > |>>>>>going to implement stateless interior QNEs in such a way=20 > |that they=20 > |>>>>>understand all the mandatory QSPEC parameters. In fact they=20 > |>>>>>don't have=20 > |>>>>>todo it since only edge routers are likely to ever see QoS=20 > |>>>>>NSLP messages=20 > |>>>>>that contain QOSM IDs that they do not understand (otherwise=20 > |>>>>>something=20 > |>>>>>go terribly wrong). > |>>> > |>>> > |>>>>Jerry: It is up the RMD authors to specify how they want RMD=20 > |>>>> > |>>>> > |>>>>>to behave wrt mandatory parameters (and obtain rough=20 > |>>>>>consensus, of course). That is, if a mandatory parameter=20 > |>>>>>is remapped and not strictly interpreted, the remapping=20 > |>>>>>must be specified in the QOSM specification document. =20 > |>>>>>Otherwise, the QOSM must strictly interpret the mandatory=20 > |>>>>>parameters that are not remapped, if they are populated=20 > |by the QNI. > |>>>>>There are no restrictions on how the remapping must be done,=20 > |>>>>>it can be as simple as necessary (but no simpler). > |>>> > |>>> > |>>>Georgios: > |>>>Jerry, I think that the point raised by Hannes is related to > |>>>how the QNE's interior to the RMD domain will have to=20 > comply to the > |>>>mandatory descriptions specified in the QSPEC template.=20 > |>>>An interior QNE (in RMD-QOSM) will not process=20 > |>>>the end to end QSpec. The only QSpec that will be=20 > processed by the=20 > |>>>interior QNE is the RMD Qsepc that is initiated by the=20 > |>>>ingress node (i.e., QNI for the RMD local session).=20 > |>>>Note that the above observation is valid for all local QOSMs. > |>>>However, the above is not allowed due to the following=20 > text that is=20 > |>>>included in the QSpec template draft: > |>>> > |>>>"A QNE MUST interpret all mandatory parameters from this=20 > |>> > |>>document even=20 > |>> > |>>>if it does not support the received QoS NSLP message with the=20 > |>>>indicated QOSM." > |>>> > |>>>Therefore, in my opinion it is required to modify the above=20 > |>> > |>>sentence in > |>> > |>>>something like: > |>>> > |>>>"A QNE SHOULD interpret all mandatory parameters from this=20 > |>> > |>>document even=20 > |>> > |>>>if it does not support the received QoS NSLP message with the=20 > |>>>indicated QOSM. A QNE that supports a local QOSM, does not=20 > |>> > |>>have to interpret > |>> > |>>>all mandatory parameters carried by a QSpec that was=20 > |>> > |>>generated by a QNI=20 > |>> > |>>>located outside the domain that supports the given local QOSM."=20 > |>> > |>>Something along these lines would probably be more=20 > |realistic, I guess. > |>> > |>>Ciao > |>>Hannes > |>> > |>> > |>>>Best regards, > |>>>Georgios > |>>> > |>>>-----Original Message----- > |>>>From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > |>>>Sent: maandag 3 juli 2006 2:03 > |>>>To: Hannes Tschofenig > |>>>Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH);=20 > |>> > |>>nsis@ietf.org; > |>> > |>>>Kappler Cornelia > |>>>Subject: RE: [NSIS] draft-qosmodel-controlledload-04 > |>>> > |>>>Hi Hannes, > |>>> > |>>>See below.=20 > |>>> > |>>> > |>>> > |>>>>-----Original Message----- > |>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > |>>>>Sent: Saturday, July 01, 2006 4:26 PM > |>>>>To: Ash, Gerald R (Jerry), ALABS > |>>>>Cc: nsis@ietf.org > |>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 > |>>>> > |>>>>Hi Jerry, > |>>>> > |>>>>it is true that I haven't read the most recent QSPEC draft=20 > |>> > |>>when I sent=20 > |>> > |>>>>this mail. In the meanwhile I did. Please find a few=20 > |comments below: > |>>>> > |>>>>Ash, Gerald R (Jerry), ALABS wrote: > |>>>> > |>>>> > |>>>>>Hi Hannes, > |>>>>> > |>>>>>See below.=20 > |>>>>> > |>>>>> > |>>>>> > |>>>>> > |>>>>>>-----Original Message----- > |>>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > |>>>>>>Sent: Friday, June 30, 2006 8:43 AM > |>>>>>>To: Bernd Schloer > |>>>>>>Cc: nsis@ietf.org > |>>>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 > |>>>>>> > |>>>>>>Hi Bernd, > |>>>>>> > |>>>>>>Bernd Schloer wrote: > |>>>>>> > |>>>>>> > |>>>>>> > |>>>>>>>Hi, > |>>>>>>> > |>>>>>>>the first open issue in the appendix B is about what=20 > to do with=20 > |>>>>>>>mandatory QSPEC parameters which are not needed for CLS. > |>>>>>>> > |>>>>>>>Does a QOSM have to understand (and provide information=20 > |>> > |>>about) all=20 > |>> > |>>>>>>>mandatory parameters, even if they are not used? > |>>>>>> > |>>>>>>I think the question is wrong. What about the=20 > following question: > |>>>>>>" > |>>>>>>Does a node that implements a particular QOSM has to=20 > |>> > |>>understand all=20 > |>> > |>>>>>>mandatory parameters listed in the QSPEC template draft > |>>>> > |>>>>(even if the > |>>>> > |>>>> > |>>>>>>QOSM does not make use of them)? > |>>>>>>" > |>>>>>>The answer would be "YES" since the QSPEC template draft=20 > |>> > |>>says that=20 > |>> > |>>>>>>mandatory parameters have to be understood by every NSIS=20 > |QoS node. > |>>>>>> > |>>>>>>There is only the question what "understands" means. > |>>>>> > |>>>>> > |>>>>>IMO you need to more carefully read the QSPEC I-D=20 > document. All=20 > |>>>>>mandatory QSPEC parameters that are populated in the=20 > |QSPEC must be=20 > |>>>>>interpreted by every QNE, which is explained in the QSPEC I-D: > |>>>>> > |>>>>>It says in Section 4.4.1 (Mandatory and Optional QSPEC > |>>>> > |>>>>. Parameters) of > |>>>> > |>>>> > |>>>>>the QSPEC I-D > |>>>>>http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: > |>>>>> > |>>>>>" Mandatory QSPEC parameters are treated as follows: > |>>>>> > |>>>>> o A QNI SHOULD populate mandatory QSPEC parameters if > |>>>> > |>>>>. applicable to > |>>>> > |>>>> > |>>>>> the underlying QOSM. > |>>>> > |>>>>I don't understand this sentence. What does it mean that a QNI=20 > |>>>>"SHOULD" > |>>>>populate parameters if applicable? > |>>> > |>>> > |>>>It means that a QNI is not required to populate all=20 > |>> > |>>mandatory parameters. A > |>> > |>>>QNI would only populated a mandatory parameter if is used=20 > |>> > |>>by the QOSM > |>> > |>>>supported by the QNI. > |>>>=20 > |>>> > |>>> > |>>>>> o QNEs MUST interpret mandatory QSPEC parameters, if=20 > signaled." > |>>>>> > |>>>>>Furthermore, it says in Section 4.2 (QSPEC Processing): > |>>>>> > |>>>>>" a QNE > |>>>>> MUST at least interpret all the mandatory parameters in=20 > |>>>>> a QSPEC even > |>>>>> if it does not support the corresponding QOSM. > |>>>>> > |>>>>> Mandatory parameters provide a minimal subset of parameters. A > |>>>>> QNE MUST either a) strictly interpret a mandatory=20 > parameter, or > |>>>>> b) remap the parameter and raise the flag=20 > |>>>>> defined in > |>>>>> Section 5.1, where the remapping MUST be specified in the QOSM > |>>>>> specification. Here the terminology 'strictly=20 > |>>>>> interpret' means that > |>>>> > |>>>>What is the difference between 'strictly interpret' and=20 > |>> > |>>'interpret'?=20 > |>> > |>>>>In the rest of the document you use 'interpret'. > |>>> > |>>> > |>>>'Strictly interpret' is defined in the text I quoted from=20 > |>> > |>>Section 4.2 (QSPEC > |>> > |>>>Processing), which is given again in the very next=20 > |>> > |>>sentences I quoted just > |>> > |>>>below (after you posed your above question :-) > |>>> > |>>>" Mandatory parameters provide a minimal subset of parameters. A > |>>> QNE MUST either a) strictly interpret a mandatory parameter, or > |>>> b) remap the parameter and raise the flag=20 > |>> > |>>defined in > |>> > |>>> Section 5.1, where the remapping MUST be specified in the QOSM > |>>> specification. Here the terminology 'strictly=20 > |>> > |>>interpret' means that > |>> > |>>> the parameter is implemented according to the commonly accepted > |>>> definition and/or as specified by references given for=20 > each QSPEC > |>>> parameter. This means that in case a), a =20 > |>> > |>>parameter > |>> > |>>> must be strictly interpreted as a token bucket. =20 > |>> > |>>However, in case b), > |>> > |>>> a parameter may be remapped, perhaps to a=20 > |>> > |>> > |>> > |>>> parameter." > |>>> > |>>>In the document, the term 'interpret' a mandatory parameter=20 > |>> > |>>means either a) > |>> > |>>>strictly interpret (as defined above), or b) remap (as=20 > |>> > |>>defined above). > |>> > |>>>Perhaps this can be made clearer in the text. > |>>>=20 > |>>> > |>>> > |>>>>> the parameter is implemented according to the=20 > commonly accepted > |>>>>> definition and/or as specified by references given for=20 > |>> > |>>each QSPEC > |>> > |>>>>> parameter. This means that in case a), a =20 > |>>>>> parameter > |>>>>> must be strictly interpreted as a token bucket. =20 > |>>>>> However, in case b), > |>>>>> a parameter may be remapped, perhaps to a=20 > |>>>>> > |>>>>> parameter. > |>>>> > |>>>>I noticed this text improvement and I am happy to see more=20 > |>> > |>>text about=20 > |>> > |>>>>it. > |>>>> > |>>>>Still, I have some issues with the section: > |>>>> > |>>>>I had a problem with this paragraph following the previous=20 > |>> > |>>one in the=20 > |>> > |>>>>section. The previous paragraph said " > |>>>>However, if a QSPEC arrives at a QNE that does > |>>>> not support the QOSM being signaled, it can still=20 > understand the > |>>>> QSPEC content, at least to a basic degree. > |>>>>" > |>>>> > |>>>>When I read through the text I got the impression that the two=20 > |>>>>sections relate to each other and in fact they do not. Hence, I=20 > |>>>>suggest to delete the previous paragraph since this one=20 > |>> > |>>contains the=20 > |>> > |>>>>info already. > |>>> > |>>> > |>>>I'm unclear as to which paragraph/text you are proposing=20 > to delete. > |>>> > |>>> > |>>> > |>>>>You > |>>>>might also want to delete the second paragraph as well=20 > |>> > |>>since it is far=20 > |>> > |>>>>too obvious to use RFC2119 language: If you don't support even a=20 > |>>>>single QOSM then why are you a QOS NSLP node in the first place. > |>>> > |>>> > |>>>I think it important to state that a QNE MUST support at=20 > |>> > |>>least one QOSM, > |>> > |>>>even if this is clearly necessary to effectively support=20 > |>> > |>>QoS-NSLP/QSPEC. > |>> > |>>> > |>>>>You might want to highlight the following sentence, though: > |>>>> > |>>>>" > |>>>>A QNE MUST interpret all mandatory parameters from this=20 > |>> > |>>document even=20 > |>> > |>>>>if it does not support the received QoS NSLP message with the=20 > |>>>>indicated QOSM. > |>>>>" > |>>>> > |>>>>Here is my proposal for the section: > |>>>> > |>>>>" > |>>>>4.2 QSPEC Processing > |>>>> > |>>>> The QSPEC is opaque to the QoS NSLP processing. The=20 > |>> > |>>QSPEC control > |>> > |>>>> information and the QoS description are interpreted and MAY be > |>>>> modified by the RMF in a QNE (see description in [QoS-SIG]). > |>>>> > |>>>> The QSPEC contains a QOSM ID, i.e. information on what=20 > |>>>> QOSM is being > |>>>> signaled by the QNI. However, if a QSPEC arrives at a=20 > |>>>> QNE that does > |>>>> not support the QOSM being signaled, it can still=20 > understand the > |>>>> QSPEC content, at least to a basic degree. This is=20 > |>>>> because mandatory > |>>>> parameters have been defined as a common language. =20 > |>>>> Therefore, a QNE > |>>>> MUST at least interpret all the mandatory parameters in a=20 > |>>>> QSPEC even > |>>>> if it does not support the corresponding QOSM. > |>>>> > |>>>> A QNE MUST either > |>>>> > |>>>> a) interpret a mandatory parameter carried in the QSPEC=20 > |>> > |>>object, or > |>> > |>>>> b) remap the parameter and raise the flag=20 > |>>>> defined in > |>>>> Section 5.1, where the remapping MUST be specified in the QOSM > |>>>> specification. > |>>>> > |>>>> Here the terminology 'interpret' means that > |>>>> the parameter is implemented according to the references=20 > |>>>> given for=20 > |>>>> each QSPEC parameter. > |>>>> > |>>>> If a QSPEC arrives at a QNE that does not support the=20 > QOSM being > |>>>> signaled, it can still understand the QSPEC content, at=20 > |>> > |>>least to a > |>> > |>>>> basic degree. Hence, with case (a), a parameter > |>>>> must be strictly interpreted as a token bucket. > |>>>> > |>>>> In case b), a parameter may be remapped,=20 > |>>>> perhaps to a > |>>>> parameter. > |>>>>" > |>>> > |>>> > |>>>I don't see any benefit in redefining what 'interpret'=20 > means in the > |>>>document. As I mentioned above, the document uses the term=20 > |>> > |>>'interpret' to > |>> > |>>>mean that a mandatory parameter is 'interpreted' if is=20 > |>> > |>>either 'strictly > |>> > |>>>interpreted' or it is 'remapped' (where the remapping must=20 > |>> > |>>be defined in the > |>> > |>>>QOSM specification document). OTOH, it might be useful=20 > to define a > |>>>'remapping' flag to indicated if a mandatory or optional=20 > |>> > |>>parameter has been > |>> > |>>>remapped by a QNE in the path. > |>>>=20 > |>>> > |>>> > |>>>>Btw, have you noticed that the draft has > |>>>>* a flag (Section 5.1) > |>>>>* a parameter (Section 7.2.1) > |>>>> > |>>>>I think they refer to the same concept... > |>>> > |>>> > |>>>Yes, good catch. is indeed intended to be a=20 > |>> > |>>flag, and > |>> > |>>>perhaps one of the QSPEC object flags defined in Section=20 > |>> > |>>7.1 could be used > |>> > |>>>for this purpose, rather than use a full 32-bit parameter=20 > |>> > |>>for this purpose, > |>> > |>>>as currently specified in Section 7.2.1. > |>>>=20 > |>>> > |>>> > |>>>>> In the latter case, the remapping of the to > |>>>>> must be specified in the QOSM specification=20 > |>> > |>>document. > |>> > |>>>>> For example, QOSM X exclusively uses the parameter=20 > |>>>>> . It > |>>>>> must define a mapping of the mandatory parameter=20 > . > |>>>>> The mapping consists of interpreting the Token Bucket Rate as > |>>>>> the parameter and disregarding the other=20 > |>> > |>>Token Bucket > |>> > |>>>>> parameters. Clearly, some information contained in the |>>>>> Bucket> parameter is lost by this mapping, and the=20 > |>>>>> resulting QoS may > |>>>>> not be quite what was intended by the QNI. Therefore,=20 > |>>>>> QOSM X also > |>>>>> specifies that the flag be raised. Thus,=20 > |>>>>> a QNE using > |>>>>> QOSM X is able to make an informed decision whether to admit a > |>>>>> reservation described in terms of , and=20 > |>> > |>>at the same > |>> > |>>>>> time (by means of ) signals to the=20 > |>> > |>>QNI/QNR that the > |>> > |>>>>> exact intention of the QNI may not be met." > |>>>>> > |>>>>>I think this text is pretty clear as to what is required=20 > |regarding=20 > |>>>>>interpreting mandatory parameters. If not, please suggest=20 > |>>>>>clarifications. > |>>>> > |>>>>The text in the new draft has improved a lot. > |>>>>Thanks for the update. > |>>>> > |>>>> > |>>>> > |>>>>>>Another possible question would be: > |>>>>>>" > |>>>>>>Does a node that implements a particular QOSM has to=20 > |>> > |>>define mappings=20 > |>> > |>>>>>>from all mandatory parameters listed in the QSPEC=20 > |>> > |>>template draft to=20 > |>> > |>>>>>>the QOSM draft (even if the QOSM does not make use > |>>>> > |>>>>of them)? > |>>>> > |>>>> > |>>>>>>" > |>>>>>> > |>>>>>>The answer is "I don't know". > |>>>>> > |>>>>> > |>>>>>A QNE must interpret all mandatory parameters, if populated, as > |>>>>>explained in the above text I quoted. If a QOSM re-maps a=20 > |>> > |>>mandatory > |>> > |>>>>>QSPEC parameter, that re-mapping must be defined in the QOSM > |>>>>>specification. As stated in Section 4.7 (QOSM Specification > |>>>>>Requirements): > |>>>>> > |>>>>>" A QOSM specification MUST define QSPEC parameter=20 > |>>>>> behavior for these > |>>>>> cases: a) new optional QSPEC parameters the QOSM specification > |>>>>> defines, and b) remapping of existing mandatory or=20 > |>> > |>>optional QSPEC > |>> > |>>>>> parameters, as described in Section 4.2. Unless=20 > |>>>>> otherwise specified > |>>>>> in the QOSM specification document, the behaviors to strictly > |>>>>> interpret the mandatory and optional QSPEC parameters=20 > |>>>>> are defined in > |>>>>> this document through the references to RFCs that=20 > |>>>>> precisely define > |>>>>> the QSPEC parameter behaviors. =20 > |>>>>> > |>>>>> A QOSM specification MUST define how the mandatory=20 > |>>>>> parameters are to > |>>>>> be mapped onto the QSPEC parameters used by the QOSM,=20 > |>> > |>>however the > |>> > |>>>>> mapping MAY result in slight modification to the intended > |>>>>> specification when an exact mapping is not possible. =20 > |>>>>> This definition > |>>>>> MUST allow a QNE implementing this QOSM to make a=20 > decision as to > |>>>>> whether a reservation described in terms of mandatory=20 > |>>>>> parameters can > |>>>>> be admitted. If for a particular mandatory parameter no=20 > |>>>>> mapping can > |>>>>> be found that guarantees the desired QoS, the QNE is=20 > |>>>>> advised to raise > |>>>>> the flag. In other words, for all mandatory > |>>>>> parameters a mapping must be defined, but it is=20 > |>> > |>>acknowledged that > |>> > |>>>>> this mapping may result in slightly bending the original=20 > |>>>>> intention of > |>>>>> the QNI." > |>>>>> > |>>>>>I think this text is pretty clear as to what is=20 > required. If not, > |>>>>>please suggest clarifications. > |>>>> > |>>>>I understood the token bucket to bandwidth example. > |>>>> > |>>>>Would the RMD draft, for example, list all mandatory=20 > |parameters and=20 > |>>>>indicate whether it can map them (and how) to parameters used=20 > |>>>>in the RMD=20 > |>>>>specification? > |>>> > |>>> > |>>>As stated in the QOSM specification requirements in Section=20 > |>> > |>>4.7, if a QOSM > |>> > |>>>remaps a mandatory parameter, the remapping must be defined=20 > |>> > |>>in the QOSM > |>> > |>>>specification document. If no such remapping is defined,=20 > |>> > |>>the default > |>> > |>>>behavior is that the QOSM must strictly interpret the=20 > |>> > |>>mandatory parameter, > |>> > |>>>as defined above. > |>>>=20 > |>>> > |>>> > |>>>>Do you think it is awfully realistic for all QNEs to=20 > |understand all=20 > |>>>>mandatory parameters? I could imagine that Attila and=20 > |>>>>Georgios are not=20 > |>>>>going to implement stateless interior QNEs in such a way=20 > that they=20 > |>>>>understand all the mandatory QSPEC parameters. In fact they=20 > |>>>>don't have=20 > |>>>>todo it since only edge routers are likely to ever see QoS=20 > |>>>>NSLP messages=20 > |>>>>that contain QOSM IDs that they do not understand (otherwise=20 > |>>>>something=20 > |>>>>go terribly wrong). > |>>> > |>>> > |>>>It is up the RMD authors to specify how they want RMD to=20 > behave wrt > |>>>mandatory parameters (and obtain rough consensus, of=20 > |>> > |>>course). That is, if a > |>> > |>>>mandatory parameter is remapped and not strictly=20 > |>> > |>>interpreted, the remapping > |>> > |>>>must be specified in the QOSM specification document. =20 > |>> > |>>Otherwise, the QOSM > |>> > |>>>must strictly interpret the mandatory parameters that are=20 > |>> > |>>not remapped, if > |>> > |>>>they are populated by the QNI. > |>>> > |>>>There are no restrictions on how the remapping must be=20 > |>> > |>>done, it can be as > |>> > |>>>simple as necessary (but no simpler). > |>>> > |>>>Thanks, > |>>>Jerry > |>>> > |>>> > |>>> > |>>>>Ciao > |>>>>Hannes > |>>>> > |>>>> > |>>>> > |>>>>>Thanks, > |>>>>>Jerry > |>>>>> > |>>>>> > |>>>>> > |>>>>> > |>>>>>>Ciao > |>>>>>>Hannes > |>>>>>> > |>>>>>>The QSPEC-draft says in section 5 > |>>>>>> > |>>>>>> > |>>>>>> > |>>>>>>>that > |>>>>>>>all parameters listed in the next sections are mandatory. The=20 > |>>>>>>>QSPEC-draft also > |>>>>>>>says in section 4.1 that "a given QOSM defines which of the=20 > |>>>>>> > |>>>>>>mandatory and > |>>>>>> > |>>>>>> > |>>>>>> > |>>>>>>>optional parameters it uses, ..." > |>>>>>>> > |>>>>>>>Are there any specific parameters which makes the open=20 > |>>>> > |>>>>issue B.1.1.=20 > |>>>> > |>>>> > |>>>>>>>clearer? Following the QSPEC-draft there doesn't seem to be=20 > |>>>>>> > |>>>>>>a conflict,=20 > |>>>>>> > |>>>>>> > |>>>>>> > |>>>>>>>if nothing is > |>>>>>>>done with the unneeded parameters. > |>>>>>>> > |>>>>>>>Thanks, > |>>>>>>>Bernd > |>>> > |>>> > |>>>_______________________________________________ > |>>>nsis mailing list > |>>>nsis@ietf.org > |>>>https://www1.ietf.org/mailman/listinfo/nsis > |>>> > |>>> > |>>> > |>> > |>> > |>=20 > |> _______________________________________________ > |> nsis mailing list > |> nsis@ietf.org > |> https://www1.ietf.org/mailman/listinfo/nsis > |>=20 > | > | > |_______________________________________________ > |nsis mailing list > |nsis@ietf.org > |https://www1.ietf.org/mailman/listinfo/nsis > | >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 07:23:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxizi-0005VK-6F; Tue, 04 Jul 2006 07:23:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxizh-0005VF-CB for nsis@ietf.org; Tue, 04 Jul 2006 07:23:05 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxizg-0007OX-2z for nsis@ietf.org; Tue, 04 Jul 2006 07:23:05 -0400 Received: from [192.168.178.200] (p5484B402.dip0.t-ipconnect.de [84.132.180.2]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k64BMWFK012303; Tue, 4 Jul 2006 13:22:33 +0200 (MEST) Message-ID: <44AA4ED7.3030007@schloer.net> Date: Tue, 04 Jul 2006 13:19:51 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <002501c69f52$f2090590$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <002501c69f52$f2090590$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: 06f60f0744e48a3e4358b40a71e32d86 Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , nsis@ietf.org, =?ISO-8859-1?Q?=22=27?=, =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29=27=22?= , 'Kappler Cornelia' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, maybe two parameters. We could also integrate the ping tool so that every= QNE=20 can provide information about the Path Latency. But how does f= it in=20 there? CLS is not using it, e.g. Bernd Georgios Karagiannis wrote: > Hi Bernd >=20 > Are you proposing that the only mandory parameter should be: > =3D =20 >=20 > Best Regards, > Georgios >=20 > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 > Sent: dinsdag 4 juli 2006 0:14 > To: "Attila B=E1der (IJ/ETH)" > Cc: Hannes Tschofenig; Georgios Karagiannis; Ash, Gerald R (Jerry), ALA= BS; > nsis@ietf.org; Kappler Cornelia > Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >=20 > Hi all, >=20 > just an idea: >=20 > Token Bucket is the only mandatory parameter. It is interpreted by CLS = and > Y.1541. RMD can map it to Bandwidth. >=20 > Other Parameters, like Path Latency,etc. are optional. If a QOSM doesn'= t > support it, it can be skipped. >=20 > Mainly two types of parameters are left: Delay, Priority. If supported = by > two different QOSMs, the following mapping could be tried: >=20 > Delay: can be mapped to , , > >=20 > Priority: , , , > Priority> > Here should rather be derived from = than > vice versa, as is more complex. Or in general the simple= > parameters should be derived from the more complex one. >=20 > The only problem I see: Do I know the QOSM of my neighbor domain? Do I = have > to consider this when sending the initiator QSPEC? >=20 > Bernd >=20 >=20 >=20 >=20 > Attila B=E1der (IJ/ETH) wrote: >=20 >>Hi All, >> >>If "ignore" is not a type interpretation, I also think that it should b= e >=20 > reformulated. >=20 >>In general, to understend mandatory parameters that is not used in a lo= cal >=20 > QoSM, I see less problem. If a QOSM has to fill in mandatory parameters= that > is not used in this QOSM, seems to be more difficult. >=20 >>Best regards, Attila >> >> >> >>>-----Original Message----- >>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>Sent: Monday, July 03, 2006 4:37 PM >>>To: Georgios Karagiannis >>>Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila B=E1der (IJ/ETH);=20 >>>nsis@ietf.org; 'Kappler Cornelia' >>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>> >>> >>>Hi Georgios, >>> >>>please find my comment below: >>> >>>Georgios Karagiannis wrote: >>> >>> >>>>Hi Jerry >>>> >>>>Regarding your last point: >>>> >>>> >>>> >>>>>>Hannes: >>>>>>Do you think it is awfully realistic for all QNEs to >>> >>>understand all >>> >>> >>>>>>mandatory parameters? I could imagine that Attila and Georgios are = >>>>>>not going to implement stateless interior QNEs in such a way that=20 >>>>>>they understand all the mandatory QSPEC parameters. In fact they=20 >>>>>>don't have todo it since only edge routers are likely to ever see=20 >>>>>>QoS NSLP messages that contain QOSM IDs that they do not understand= =20 >>>>>>(otherwise something go terribly wrong). >>>> >>>> >>>>>Jerry: It is up the RMD authors to specify how they want RMD >>>>> >>>>> >>>>> >>>>>>to behave wrt mandatory parameters (and obtain rough consensus, of = >>>>>>course). That is, if a mandatory parameter is remapped and not=20 >>>>>>strictly interpreted, the remapping must be specified in the QOSM=20 >>>>>>specification document. >>>>>>Otherwise, the QOSM must strictly interpret the mandatory=20 >>>>>>parameters that are not remapped, if they are populated by the QNI.= >>>>>>There are no restrictions on how the remapping must be done, it can= =20 >>>>>>be as simple as necessary (but no simpler). >>>> >>>> >>>>Georgios: >>>>Jerry, I think that the point raised by Hannes is related to how the = >>>>QNE's interior to the RMD domain will have to comply to the mandatory= =20 >>>>descriptions specified in the QSPEC template. >>>>An interior QNE (in RMD-QOSM) will not process the end to end QSpec. = >>>>The only QSpec that will be processed by the interior QNE is the RMD = >>>>Qsepc that is initiated by the ingress node (i.e., QNI for the RMD=20 >>>>local session). >>>>Note that the above observation is valid for all local QOSMs. >>>>However, the above is not allowed due to the following text that is=20 >>>>included in the QSpec template draft: >>>> >>>>"A QNE MUST interpret all mandatory parameters from this >>> >>>document even >>> >>> >>>>if it does not support the received QoS NSLP message with the=20 >>>>indicated QOSM." >>>> >>>>Therefore, in my opinion it is required to modify the above >>> >>>sentence in >>> >>> >>>>something like: >>>> >>>>"A QNE SHOULD interpret all mandatory parameters from this >>> >>>document even >>> >>> >>>>if it does not support the received QoS NSLP message with the=20 >>>>indicated QOSM. A QNE that supports a local QOSM, does not >>> >>>have to interpret >>> >>> >>>>all mandatory parameters carried by a QSpec that was >>> >>>generated by a QNI >>> >>> >>>>located outside the domain that supports the given local QOSM."=20 >>> >>>Something along these lines would probably be more realistic, I guess.= >>> >>>Ciao >>>Hannes >>> >>> >>> >>>>Best regards, >>>>Georgios >>>> >>>>-----Original Message----- >>>>From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>>>Sent: maandag 3 juli 2006 2:03 >>>>To: Hannes Tschofenig >>>>Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH); >>> >>>nsis@ietf.org; >>> >>> >>>>Kappler Cornelia >>>>Subject: RE: [NSIS] draft-qosmodel-controlledload-04 >>>> >>>>Hi Hannes, >>>> >>>>See below.=20 >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>Sent: Saturday, July 01, 2006 4:26 PM >>>>>To: Ash, Gerald R (Jerry), ALABS >>>>>Cc: nsis@ietf.org >>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>> >>>>>Hi Jerry, >>>>> >>>>>it is true that I haven't read the most recent QSPEC draft >>> >>>when I sent >>> >>> >>>>>this mail. In the meanwhile I did. Please find a few comments below:= >>>>> >>>>>Ash, Gerald R (Jerry), ALABS wrote: >>>>> >>>>> >>>>> >>>>>>Hi Hannes, >>>>>> >>>>>>See below.=20 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>Sent: Friday, June 30, 2006 8:43 AM >>>>>>>To: Bernd Schloer >>>>>>>Cc: nsis@ietf.org >>>>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>>> >>>>>>>Hi Bernd, >>>>>>> >>>>>>>Bernd Schloer wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi, >>>>>>>> >>>>>>>>the first open issue in the appendix B is about what to do with=20 >>>>>>>>mandatory QSPEC parameters which are not needed for CLS. >>>>>>>> >>>>>>>>Does a QOSM have to understand (and provide information >>> >>>about) all >>> >>> >>>>>>>>mandatory parameters, even if they are not used? >>>>>>> >>>>>>>I think the question is wrong. What about the following question: >>>>>>>" >>>>>>>Does a node that implements a particular QOSM has to >>> >>>understand all >>> >>> >>>>>>>mandatory parameters listed in the QSPEC template draft >>>>> >>>>>(even if the >>>>> >>>>> >>>>> >>>>>>>QOSM does not make use of them)? >>>>>>>" >>>>>>>The answer would be "YES" since the QSPEC template draft >>> >>>says that >>> >>> >>>>>>>mandatory parameters have to be understood by every NSIS QoS node.= >>>>>>> >>>>>>>There is only the question what "understands" means. >>>>>> >>>>>> >>>>>>IMO you need to more carefully read the QSPEC I-D document. All=20 >>>>>>mandatory QSPEC parameters that are populated in the QSPEC must be = >>>>>>interpreted by every QNE, which is explained in the QSPEC I-D: >>>>>> >>>>>>It says in Section 4.4.1 (Mandatory and Optional QSPEC >>>>> >>>>>. Parameters) of >>>>> >>>>> >>>>> >>>>>>the QSPEC I-D >>>>>>http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: >>>>>> >>>>>>" Mandatory QSPEC parameters are treated as follows: >>>>>> >>>>>> o A QNI SHOULD populate mandatory QSPEC parameters if >>>>> >>>>>. applicable to >>>>> >>>>> >>>>> >>>>>> the underlying QOSM. >>>>> >>>>>I don't understand this sentence. What does it mean that a QNI=20 >>>>>"SHOULD" >>>>>populate parameters if applicable? >>>> >>>> >>>>It means that a QNI is not required to populate all >>> >>>mandatory parameters. A >>> >>> >>>>QNI would only populated a mandatory parameter if is used >>> >>>by the QOSM >>> >>> >>>>supported by the QNI. >>>> >>>> >>>> >>>> >>>>>> o QNEs MUST interpret mandatory QSPEC parameters, if signaled." >>>>>> >>>>>>Furthermore, it says in Section 4.2 (QSPEC Processing): >>>>>> >>>>>>" a QNE >>>>>> MUST at least interpret all the mandatory parameters in >>>>>> a QSPEC even >>>>>> if it does not support the corresponding QOSM. >>>>>> >>>>>> Mandatory parameters provide a minimal subset of parameters. A =20 >>>>>>QNE MUST either a) strictly interpret a mandatory parameter, or >>>>>> b) remap the parameter and raise the flag defined = >>>>>>in Section 5.1, where the remapping MUST be specified in the QOSM = =20 >>>>>>specification. Here the terminology 'strictly interpret' means=20 >>>>>>that >>>>> >>>>>What is the difference between 'strictly interpret' and >>> >>>'interpret'?=20 >>> >>> >>>>>In the rest of the document you use 'interpret'. >>>> >>>> >>>>'Strictly interpret' is defined in the text I quoted from >>> >>>Section 4.2 (QSPEC >>> >>> >>>>Processing), which is given again in the very next >>> >>>sentences I quoted just >>> >>> >>>>below (after you posed your above question :-) >>>> >>>>" Mandatory parameters provide a minimal subset of parameters. A >>>> QNE MUST either a) strictly interpret a mandatory parameter, or >>>> b) remap the parameter and raise the flag >>> >>>defined in >>> >>> >>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>> specification. Here the terminology 'strictly >>> >>>interpret' means that >>> >>> >>>> the parameter is implemented according to the commonly accepted >>>> definition and/or as specified by references given for each QSPEC >>>> parameter. This means that in case a), a >>> >>>parameter >>> >>> >>>> must be strictly interpreted as a token bucket. =20 >>> >>>However, in case b), >>> >>> >>>> a parameter may be remapped, perhaps to a >>> >>> >>> >>>> parameter." >>>> >>>>In the document, the term 'interpret' a mandatory parameter >>> >>>means either a) >>> >>> >>>>strictly interpret (as defined above), or b) remap (as >>> >>>defined above). >>> >>> >>>>Perhaps this can be made clearer in the text. >>>> >>>> >>>> >>>> >>>>>> the parameter is implemented according to the commonly accepted =20 >>>>>>definition and/or as specified by references given for >>> >>>each QSPEC >>> >>> >>>>>> parameter. This means that in case a), a =20 >>>>>>parameter must be strictly interpreted as a token bucket. >>>>>> However, in case b), >>>>>> a parameter may be remapped, perhaps to a =20 >>>>>> parameter. >>>>> >>>>>I noticed this text improvement and I am happy to see more >>> >>>text about >>> >>> >>>>>it. >>>>> >>>>>Still, I have some issues with the section: >>>>> >>>>>I had a problem with this paragraph following the previous >>> >>>one in the >>> >>> >>>>>section. The previous paragraph said " >>>>>However, if a QSPEC arrives at a QNE that does >>>>> not support the QOSM being signaled, it can still understand the >>>>> QSPEC content, at least to a basic degree. >>>>>" >>>>> >>>>>When I read through the text I got the impression that the two=20 >>>>>sections relate to each other and in fact they do not. Hence, I=20 >>>>>suggest to delete the previous paragraph since this one >>> >>>contains the >>> >>> >>>>>info already. >>>> >>>> >>>>I'm unclear as to which paragraph/text you are proposing to delete. >>>> >>>> >>>> >>>> >>>>>You >>>>>might also want to delete the second paragraph as well >>> >>>since it is far >>> >>> >>>>>too obvious to use RFC2119 language: If you don't support even a=20 >>>>>single QOSM then why are you a QOS NSLP node in the first place. >>>> >>>> >>>>I think it important to state that a QNE MUST support at >>> >>>least one QOSM, >>> >>> >>>>even if this is clearly necessary to effectively support >>> >>>QoS-NSLP/QSPEC. >>> >>> >>>>>You might want to highlight the following sentence, though: >>>>> >>>>>" >>>>>A QNE MUST interpret all mandatory parameters from this >>> >>>document even >>> >>> >>>>>if it does not support the received QoS NSLP message with the=20 >>>>>indicated QOSM. >>>>>" >>>>> >>>>>Here is my proposal for the section: >>>>> >>>>>" >>>>>4.2 QSPEC Processing >>>>> >>>>> The QSPEC is opaque to the QoS NSLP processing. The >>> >>>QSPEC control >>> >>> >>>>> information and the QoS description are interpreted and MAY be >>>>> modified by the RMF in a QNE (see description in [QoS-SIG]). >>>>> >>>>> The QSPEC contains a QOSM ID, i.e. information on what=20 >>>>> QOSM is being >>>>> signaled by the QNI. However, if a QSPEC arrives at a=20 >>>>> QNE that does >>>>> not support the QOSM being signaled, it can still understand the >>>>> QSPEC content, at least to a basic degree. This is=20 >>>>> because mandatory >>>>> parameters have been defined as a common language. =20 >>>>> Therefore, a QNE >>>>> MUST at least interpret all the mandatory parameters in a=20 >>>>> QSPEC even >>>>> if it does not support the corresponding QOSM. >>>>> >>>>> A QNE MUST either >>>>> >>>>> a) interpret a mandatory parameter carried in the QSPEC >>> >>>object, or >>> >>> >>>>> b) remap the parameter and raise the flag=20 >>>>> defined in >>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>> specification. >>>>> >>>>> Here the terminology 'interpret' means that >>>>> the parameter is implemented according to the references=20 >>>>> given for=20 >>>>> each QSPEC parameter. >>>>> >>>>> If a QSPEC arrives at a QNE that does not support the QOSM being >>>>> signaled, it can still understand the QSPEC content, at >>> >>>least to a >>> >>> >>>>> basic degree. Hence, with case (a), a parameter >>>>> must be strictly interpreted as a token bucket. >>>>> >>>>> In case b), a parameter may be remapped,=20 >>>>> perhaps to a >>>>> parameter. >>>>>" >>>> >>>> >>>>I don't see any benefit in redefining what 'interpret' means in the=20 >>>>document. As I mentioned above, the document uses the term >>> >>>'interpret' to >>> >>> >>>>mean that a mandatory parameter is 'interpreted' if is >>> >>>either 'strictly >>> >>> >>>>interpreted' or it is 'remapped' (where the remapping must >>> >>>be defined in the >>> >>> >>>>QOSM specification document). OTOH, it might be useful to define a=20 >>>>'remapping' flag to indicated if a mandatory or optional >>> >>>parameter has been >>> >>> >>>>remapped by a QNE in the path. >>>> >>>> >>>> >>>> >>>>>Btw, have you noticed that the draft has >>>>>* a flag (Section 5.1) >>>>>* a parameter (Section 7.2.1) >>>>> >>>>>I think they refer to the same concept... >>>> >>>> >>>>Yes, good catch. is indeed intended to be a >>> >>>flag, and >>> >>> >>>>perhaps one of the QSPEC object flags defined in Section >>> >>>7.1 could be used >>> >>> >>>>for this purpose, rather than use a full 32-bit parameter >>> >>>for this purpose, >>> >>> >>>>as currently specified in Section 7.2.1. >>>> >>>> >>>> >>>> >>>>>> In the latter case, the remapping of the to =20 >>>>>> must be specified in the QOSM specification >>> >>>document. >>> >>> >>>>>> For example, QOSM X exclusively uses the parameter . = >>>>>>It must define a mapping of the mandatory parameter >>>>>Bucket>. >>>>>> The mapping consists of interpreting the Token Bucket Rate as =20 >>>>>>the parameter and disregarding the other >>> >>>Token Bucket >>> >>> >>>>>> parameters. Clearly, some information contained in the >>>>>Bucket> parameter is lost by this mapping, and the resulting QoS=20 >>>>>>may not be quite what was intended by the QNI. Therefore, QOSM=20 >>>>>>X also specifies that the flag be raised. Thus, =20 >>>>>>a QNE using QOSM X is able to make an informed decision whether=20 >>>>>>to admit a reservation described in terms of , and >>> >>>at the same >>> >>> >>>>>> time (by means of ) signals to the >>> >>>QNI/QNR that the >>> >>> >>>>>> exact intention of the QNI may not be met." >>>>>> >>>>>>I think this text is pretty clear as to what is required regarding = >>>>>>interpreting mandatory parameters. If not, please suggest=20 >>>>>>clarifications. >>>>> >>>>>The text in the new draft has improved a lot. >>>>>Thanks for the update. >>>>> >>>>> >>>>> >>>>> >>>>>>>Another possible question would be: >>>>>>>" >>>>>>>Does a node that implements a particular QOSM has to >>> >>>define mappings >>> >>> >>>>>>>from all mandatory parameters listed in the QSPEC >>> >>>template draft to >>> >>> >>>>>>>the QOSM draft (even if the QOSM does not make use >>>>> >>>>>of them)? >>>>> >>>>> >>>>> >>>>>>>" >>>>>>> >>>>>>>The answer is "I don't know". >>>>>> >>>>>> >>>>>>A QNE must interpret all mandatory parameters, if populated, as=20 >>>>>>explained in the above text I quoted. If a QOSM re-maps a >>> >>>mandatory >>> >>> >>>>>>QSPEC parameter, that re-mapping must be defined in the QOSM=20 >>>>>>specification. As stated in Section 4.7 (QOSM Specification >>>>>>Requirements): >>>>>> >>>>>>" A QOSM specification MUST define QSPEC parameter=20 >>>>>> behavior for these >>>>>> cases: a) new optional QSPEC parameters the QOSM specification >>>>>> defines, and b) remapping of existing mandatory or >>> >>>optional QSPEC >>> >>> >>>>>> parameters, as described in Section 4.2. Unless otherwise=20 >>>>>>specified in the QOSM specification document, the behaviors to=20 >>>>>>strictly interpret the mandatory and optional QSPEC parameters =20 >>>>>>are defined in this document through the references to RFCs that = >>>>>>precisely define the QSPEC parameter behaviors. >>>>>> >>>>>> A QOSM specification MUST define how the mandatory parameters=20 >>>>>>are to be mapped onto the QSPEC parameters used by the QOSM, >>> >>>however the >>> >>> >>>>>> mapping MAY result in slight modification to the intended =20 >>>>>>specification when an exact mapping is not possible. >>>>>> This definition >>>>>> MUST allow a QNE implementing this QOSM to make a decision as to = >>>>>>whether a reservation described in terms of mandatory parameters=20 >>>>>>can be admitted. If for a particular mandatory parameter no =20 >>>>>>mapping can be found that guarantees the desired QoS, the QNE is = >>>>>>advised to raise the flag. In other words, for=20 >>>>>>all mandatory parameters a mapping must be defined, but it is >>> >>>acknowledged that >>> >>> >>>>>> this mapping may result in slightly bending the original =20 >>>>>>intention of the QNI." >>>>>> >>>>>>I think this text is pretty clear as to what is required. If not, = >>>>>>please suggest clarifications. >>>>> >>>>>I understood the token bucket to bandwidth example. >>>>> >>>>>Would the RMD draft, for example, list all mandatory parameters and = >>>>>indicate whether it can map them (and how) to parameters used in the= =20 >>>>>RMD specification? >>>> >>>> >>>>As stated in the QOSM specification requirements in Section >>> >>>4.7, if a QOSM >>> >>> >>>>remaps a mandatory parameter, the remapping must be defined >>> >>>in the QOSM >>> >>> >>>>specification document. If no such remapping is defined, >>> >>>the default >>> >>> >>>>behavior is that the QOSM must strictly interpret the >>> >>>mandatory parameter, >>> >>> >>>>as defined above. >>>> >>>> >>>> >>>> >>>>>Do you think it is awfully realistic for all QNEs to understand all = >>>>>mandatory parameters? I could imagine that Attila and Georgios are=20 >>>>>not going to implement stateless interior QNEs in such a way that=20 >>>>>they understand all the mandatory QSPEC parameters. In fact they=20 >>>>>don't have todo it since only edge routers are likely to ever see=20 >>>>>QoS NSLP messages that contain QOSM IDs that they do not understand = >>>>>(otherwise something go terribly wrong). >>>> >>>> >>>>It is up the RMD authors to specify how they want RMD to behave wrt=20 >>>>mandatory parameters (and obtain rough consensus, of >>> >>>course). That is, if a >>> >>> >>>>mandatory parameter is remapped and not strictly >>> >>>interpreted, the remapping >>> >>> >>>>must be specified in the QOSM specification document. =20 >>> >>>Otherwise, the QOSM >>> >>> >>>>must strictly interpret the mandatory parameters that are >>> >>>not remapped, if >>> >>> >>>>they are populated by the QNI. >>>> >>>>There are no restrictions on how the remapping must be >>> >>>done, it can be as >>> >>> >>>>simple as necessary (but no simpler). >>>> >>>>Thanks, >>>>Jerry >>>> >>>> >>>> >>>> >>>>>Ciao >>>>>Hannes >>>>> >>>>> >>>>> >>>>> >>>>>>Thanks, >>>>>>Jerry >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Ciao >>>>>>>Hannes >>>>>>> >>>>>>>The QSPEC-draft says in section 5 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>that >>>>>>>>all parameters listed in the next sections are mandatory. The=20 >>>>>>>>QSPEC-draft also says in section 4.1 that "a given QOSM defines=20 >>>>>>>>which of the >>>>>>> >>>>>>>mandatory and >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>optional parameters it uses, ..." >>>>>>>> >>>>>>>>Are there any specific parameters which makes the open >>>>> >>>>>issue B.1.1.=20 >>>>> >>>>> >>>>> >>>>>>>>clearer? Following the QSPEC-draft there doesn't seem to be >>>>>>> >>>>>>>a conflict, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>if nothing is >>>>>>>>done with the unneeded parameters. >>>>>>>> >>>>>>>>Thanks, >>>>>>>>Bernd >>>> >>>> >>>>_______________________________________________ >>>>nsis mailing list >>>>nsis@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/nsis >>>> >>>> >>>> >>> >>> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 07:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxjDI-0007OO-8q; Tue, 04 Jul 2006 07:37:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxjDG-0007NC-Qn for nsis@ietf.org; Tue, 04 Jul 2006 07:37:06 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxjDF-0008K6-7T for nsis@ietf.org; Tue, 04 Jul 2006 07:37:06 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k64BasJa026945; Tue, 4 Jul 2006 12:36:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NATFW and the GIST API Date: Tue, 4 Jul 2006 12:36:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW and the GIST API Thread-Index: AcaZsWlQVzksCwEkQLyfRZXlnvjmFwFqfMIg From: "Hancock, Robert" To: "Matthias Friedrich" , "Henning Peters" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, it seems reasonable to me to add something about the receive interface to RecvMessage. I am tempted to leave the detailed syntax open in the spec, but my preference would be for GIST to classify the interface according to some logical rather than physical aspects. see the new open issue http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue110 i'd rather however leave the MessageStatus as it is. logically it is a call about a particular message and the message handle is precisely what is needed (no more, no less). if there is some special reason why it is overweight in particular cases there is no rule not to hack the api, e.g. put the session id in the=20 message handle :-) but once you put the SID in, there is no=20 reason not to put everything else about the message in as well. robert h. > -----Original Message----- > From: Matthias Friedrich [mailto:matt@mafr.de]=20 > Sent: 27 June 2006 07:17 > To: Henning Peters > Cc: nsis@ietf.org > Subject: Re: [NSIS] NATFW and the GIST API >=20 >=20 > Hi, >=20 > On Monday, 2006-06-26, Henning Peters wrote: > > your observation is correct. I remember that we discovered=20 > this issue=20 > > last fall similarly while implementing NAT/Firewall NSLP and raised=20 > > discussion for an API change. >=20 > Ah, very well, thank you. >=20 > > While I forgot the final outcome of the API discussion (I hope GIST=20 > > folks have not?!), I know that our workaround is based on=20 > configuration.=20 > > We simply maintain a mapping between IP addresses and=20 > private/public=20 > > interface (see example conf attached, look for=20 > natfw.isPrivateNet option) >=20 > > Extending the API with the network interface (how do you=20 > define this?)=20 > > might not be expressive enough, adding the receiving IP=20 > address is not=20 > > necessary and creates ambiguity. A boolean variable=20 > (private/public)=20 > > would suffice for protocol operation. >=20 > The first thing I had in mind was to extend the API to give me the > network device identifiers (eth0 is public, eth1 is private,=20 > etc.), but > they are highly unportable. The IP address of the network=20 > interface that > received a message is easily accessible using the socket API. >=20 > A private/public boolean variable would hand the problem off=20 > to GIST and > would require configuration on GIST level because you can't always be > sure that only RFC1918 addresses are used on the private side. Because > of this, I like your configuration based address matching better. >=20 > At the moment, I'm not sure which approach to use, but I don't have to > decide it immediately. >=20 > Regards, > Matthias >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 07:38:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxjEn-0002Q6-Ln; Tue, 04 Jul 2006 07:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxjEm-0002M8-9l for nsis@ietf.org; Tue, 04 Jul 2006 07:38:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxjEm-0000B6-5c for nsis@ietf.org; Tue, 04 Jul 2006 07:38:40 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FxjBQ-0004W7-K5 for nsis@ietf.org; Tue, 04 Jul 2006 07:35:14 -0400 Received: from [192.168.178.200] (p5484B402.dip0.t-ipconnect.de [84.132.180.2]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k64BYeCR009300; Tue, 4 Jul 2006 13:34:41 +0200 (MEST) Message-ID: <44AA51AF.2090303@cs.uni-goettingen.de> Date: Tue, 04 Jul 2006 13:31:59 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <05F34B6959F19F43BBD78FFCD4C15D055DFE60@esealmw116.eemea.ericsson.se> <44A996C2.7010602@cs.uni-goettingen.de> <44AA4247.9010605@gmx.net> In-Reply-To: <44AA4247.9010605@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Scan-Signature: d17d07dd202acd5ddc1032aa43098523 Cc: "Ash, Gerald R \(Jerry\), ALABS" , Georgios Karagiannis , Kappler Cornelia , nsis@ietf.org, =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, please see inline. Benrnd Hannes Tschofenig wrote: > Hi Bernd, >=20 >=20 > Bernd Schloer wrote: >=20 >> Hi all, >> >> just an idea: >> >> Token Bucket is the only mandatory parameter. >=20 >=20 > There are several mandatory parameters defined in the QSPEC, namely: >=20 > * NON QOSM Hop > * Excess Treatment > * Bandwidth > * Token Bucket the above should be mandatory. > * PHB Class > * Y.1541 QoS Class > * DSTE Class Type > * & > * Admission Priority > * RPH Priority this should be optional. as suggested a bit earlier the ping tool could u= pdate=20 the path latency. >=20 > Are you suggesting to reduce the list to a single mandatory parameter? >=20 > It is interpreted by CLS >=20 >> and Y.1541. RMD can map it to Bandwidth. >=20 >=20 > CLS and Y.1541 use the token bucket parameter. >=20 > RMD says that it can be mapped to bandwidth if the e2e message contains= =20 > the token bucket parameter in a QOSM that is not understood. >=20 >> >> Other Parameters, like Path Latency,etc. are optional. If a QOSM=20 >> doesn't support it, it can be skipped. >=20 >=20 > Correct. >=20 >=20 >> >> Mainly two types of parameters are left: Delay, Priority. If supported= =20 >> by two different QOSMs, the following mapping could be tried: >> >> Delay: can be mapped to , > Jitter>, >> >> Priority: , , > Priority>, >> Here should rather be derived from = =20 >> than vice versa, as is more complex. Or in general the = >> simple parameters should be derived from the more complex one. >=20 >=20 > I do not quite follow this idea. >=20 >> >> The only problem I see: Do I know the QOSM of my neighbor domain? Do I= =20 >> have to consider this when sending the initiator QSPEC? >=20 >=20 > Note that you do not necessarily only need to know your neighoring=20 > domain. Consider the migration scenario where many networks don't=20 > understand the QoS signaling message at all. For example, you might=20 > consider the case where only the access networks inspect the NSIS=20 > signaling messages. >=20 >=20 > Ciao > Hannes >=20 >> >> Bernd >> >> >> >> >> Attila B=E1der (IJ/ETH) wrote: >> >>> Hi All, >>> >>> If "ignore" is not a type interpretation, I also think that it should= =20 >>> be reformulated. >>> >>> In general, to understend mandatory parameters that is not used in a = >>> local QoSM, I see less problem. If a QOSM has to fill in mandatory=20 >>> parameters that is not used in this QOSM, seems to be more difficult.= >>> >>> Best regards, Attila >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, July 03, 2006 4:37 PM >>>> To: Georgios Karagiannis >>>> Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila B=E1der (IJ/ETH); >>>> nsis@ietf.org; 'Kappler Cornelia' >>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>> >>>> >>>> Hi Georgios, >>>> >>>> please find my comment below: >>>> >>>> Georgios Karagiannis wrote: >>>> >>>>> Hi Jerry >>>>> Regarding your last point: >>>>> >>>>> >>>>>>> Hannes: >>>>>>> Do you think it is awfully realistic for all QNEs to=20 >>>> >>>> >>>> >>>> understand all >>>> >>>>>>> mandatory parameters? I could imagine that Attila and Georgios=20 >>>>>>> are not going to implement stateless interior QNEs in such a way = >>>>>>> that they understand all the mandatory QSPEC parameters. In fact = >>>>>>> they don't have todo it since only edge routers are likely to=20 >>>>>>> ever see QoS NSLP messages that contain QOSM IDs that they do not= =20 >>>>>>> understand (otherwise something go terribly wrong). >>>>> >>>>> >>>>> >>>>> >>>>>> Jerry: It is up the RMD authors to specify how they want RMD >>>>>> >>>>>>> to behave wrt mandatory parameters (and obtain rough consensus,=20 >>>>>>> of course). That is, if a mandatory parameter is remapped and=20 >>>>>>> not strictly interpreted, the remapping must be specified in the = >>>>>>> QOSM specification document. Otherwise, the QOSM must strictly=20 >>>>>>> interpret the mandatory parameters that are not remapped, if they= =20 >>>>>>> are populated by the QNI. >>>>>>> There are no restrictions on how the remapping must be done, it=20 >>>>>>> can be as simple as necessary (but no simpler). >>>>> >>>>> >>>>> >>>>> >>>>> Georgios: >>>>> Jerry, I think that the point raised by Hannes is related to >>>>> how the QNE's interior to the RMD domain will have to comply to the= >>>>> mandatory descriptions specified in the QSPEC template. An=20 >>>>> interior QNE (in RMD-QOSM) will not process the end to end QSpec.=20 >>>>> The only QSpec that will be processed by the interior QNE is the=20 >>>>> RMD Qsepc that is initiated by the ingress node (i.e., QNI for the = >>>>> RMD local session). Note that the above observation is valid for=20 >>>>> all local QOSMs. >>>>> However, the above is not allowed due to the following text that is= =20 >>>>> included in the QSpec template draft: >>>>> >>>>> "A QNE MUST interpret all mandatory parameters from this=20 >>>> >>>> >>>> >>>> document even >>>> >>>>> if it does not support the received QoS NSLP message with the=20 >>>>> indicated QOSM." >>>>> >>>>> Therefore, in my opinion it is required to modify the above=20 >>>> >>>> >>>> >>>> sentence in >>>> >>>>> something like: >>>>> >>>>> "A QNE SHOULD interpret all mandatory parameters from this=20 >>>> >>>> >>>> >>>> document even >>>> >>>>> if it does not support the received QoS NSLP message with the=20 >>>>> indicated QOSM. A QNE that supports a local QOSM, does not=20 >>>> >>>> >>>> >>>> have to interpret >>>> >>>>> all mandatory parameters carried by a QSpec that was=20 >>>> >>>> >>>> >>>> generated by a QNI >>>> >>>>> located outside the domain that supports the given local QOSM."=20 >>>> >>>> >>>> >>>> Something along these lines would probably be more realistic, I gues= s. >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>>> Best regards, >>>>> Georgios >>>>> >>>>> -----Original Message----- >>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] Sent:=20 >>>>> maandag 3 juli 2006 2:03 >>>>> To: Hannes Tschofenig >>>>> Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH);=20 >>>> >>>> >>>> >>>> nsis@ietf.org; >>>> >>>>> Kappler Cornelia >>>>> Subject: RE: [NSIS] draft-qosmodel-controlledload-04 >>>>> >>>>> Hi Hannes, >>>>> >>>>> See below. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Saturday, July 01, 2006 4:26 PM >>>>>> To: Ash, Gerald R (Jerry), ALABS >>>>>> Cc: nsis@ietf.org >>>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>> >>>>>> Hi Jerry, >>>>>> >>>>>> it is true that I haven't read the most recent QSPEC draft=20 >>>> >>>> >>>> >>>> when I sent >>>> >>>>>> this mail. In the meanwhile I did. Please find a few comments belo= w: >>>>>> >>>>>> Ash, Gerald R (Jerry), ALABS wrote: >>>>>> >>>>>> >>>>>>> Hi Hannes, >>>>>>> >>>>>>> See below. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>> Sent: Friday, June 30, 2006 8:43 AM >>>>>>>> To: Bernd Schloer >>>>>>>> Cc: nsis@ietf.org >>>>>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>>>> >>>>>>>> Hi Bernd, >>>>>>>> >>>>>>>> Bernd Schloer wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> the first open issue in the appendix B is about what to do with= =20 >>>>>>>>> mandatory QSPEC parameters which are not needed for CLS. >>>>>>>>> >>>>>>>>> Does a QOSM have to understand (and provide information=20 >>>> >>>> >>>> >>>> about) all >>>> >>>>>>>>> mandatory parameters, even if they are not used? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think the question is wrong. What about the following question= : >>>>>>>> " >>>>>>>> Does a node that implements a particular QOSM has to=20 >>>> >>>> >>>> >>>> understand all >>>> >>>>>>>> mandatory parameters listed in the QSPEC template draft >>>>>> >>>>>> >>>>>> >>>>>> (even if the >>>>>> >>>>>> >>>>>>>> QOSM does not make use of them)? >>>>>>>> " >>>>>>>> The answer would be "YES" since the QSPEC template draft=20 >>>> >>>> >>>> >>>> says that >>>> >>>>>>>> mandatory parameters have to be understood by every NSIS QoS nod= e. >>>>>>>> >>>>>>>> There is only the question what "understands" means. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> IMO you need to more carefully read the QSPEC I-D document. All = >>>>>>> mandatory QSPEC parameters that are populated in the QSPEC must=20 >>>>>>> be interpreted by every QNE, which is explained in the QSPEC I-D:= >>>>>>> >>>>>>> It says in Section 4.4.1 (Mandatory and Optional QSPEC >>>>>> >>>>>> >>>>>> >>>>>> . Parameters) of >>>>>> >>>>>> >>>>>>> the QSPEC I-D >>>>>>> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: >>>>>>> >>>>>>> " Mandatory QSPEC parameters are treated as follows: >>>>>>> >>>>>>> o A QNI SHOULD populate mandatory QSPEC parameters if >>>>>> >>>>>> >>>>>> >>>>>> . applicable to >>>>>> >>>>>> >>>>>>> the underlying QOSM. >>>>>> >>>>>> >>>>>> >>>>>> I don't understand this sentence. What does it mean that a QNI=20 >>>>>> "SHOULD" >>>>>> populate parameters if applicable? >>>>> >>>>> >>>>> >>>>> >>>>> It means that a QNI is not required to populate all=20 >>>> >>>> >>>> >>>> mandatory parameters. A >>>> >>>>> QNI would only populated a mandatory parameter if is used=20 >>>> >>>> >>>> >>>> by the QOSM >>>> >>>>> supported by the QNI. >>>>> >>>>> >>>>> >>>>>>> o QNEs MUST interpret mandatory QSPEC parameters, if signaled." >>>>>>> >>>>>>> Furthermore, it says in Section 4.2 (QSPEC Processing): >>>>>>> >>>>>>> " a QNE >>>>>>> MUST at least interpret all the mandatory parameters in a QSPEC= =20 >>>>>>> even >>>>>>> if it does not support the corresponding QOSM. >>>>>>> >>>>>>> Mandatory parameters provide a minimal subset of parameters. A >>>>>>> QNE MUST either a) strictly interpret a mandatory parameter, or >>>>>>> b) remap the parameter and raise the flag =20 >>>>>>> defined in >>>>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>>>> specification. Here the terminology 'strictly interpret' means= =20 >>>>>>> that >>>>>> >>>>>> >>>>>> >>>>>> What is the difference between 'strictly interpret' and=20 >>>> >>>> >>>> >>>> 'interpret'? >>>> >>>>>> In the rest of the document you use 'interpret'. >>>>> >>>>> >>>>> >>>>> >>>>> 'Strictly interpret' is defined in the text I quoted from=20 >>>> >>>> >>>> >>>> Section 4.2 (QSPEC >>>> >>>>> Processing), which is given again in the very next=20 >>>> >>>> >>>> >>>> sentences I quoted just >>>> >>>>> below (after you posed your above question :-) >>>>> >>>>> " Mandatory parameters provide a minimal subset of parameters. A >>>>> QNE MUST either a) strictly interpret a mandatory parameter, or >>>>> b) remap the parameter and raise the flag=20 >>>> >>>> >>>> >>>> defined in >>>> >>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>> specification. Here the terminology 'strictly=20 >>>> >>>> >>>> >>>> interpret' means that >>>> >>>>> the parameter is implemented according to the commonly accepted >>>>> definition and/or as specified by references given for each QSPEC= >>>>> parameter. This means that in case a), a =20 >>>> >>>> >>>> >>>> parameter >>>> >>>>> must be strictly interpreted as a token bucket. =20 >>>> >>>> >>>> >>>> However, in case b), >>>> >>>>> a parameter may be remapped, perhaps to a=20 >>>> >>>> >>>> >>>> >>>> >>>>> parameter." >>>>> >>>>> In the document, the term 'interpret' a mandatory parameter=20 >>>> >>>> >>>> >>>> means either a) >>>> >>>>> strictly interpret (as defined above), or b) remap (as=20 >>>> >>>> >>>> >>>> defined above). >>>> >>>>> Perhaps this can be made clearer in the text. >>>>> >>>>> >>>>> >>>>>>> the parameter is implemented according to the commonly accepted >>>>>>> definition and/or as specified by references given for=20 >>>> >>>> >>>> >>>> each QSPEC >>>> >>>>>>> parameter. This means that in case a), a parame= ter >>>>>>> must be strictly interpreted as a token bucket. However, in=20 >>>>>>> case b), >>>>>>> a parameter may be remapped, perhaps to a=20 >>>>>>> >>>>>>> parameter. >>>>>> >>>>>> >>>>>> >>>>>> I noticed this text improvement and I am happy to see more=20 >>>> >>>> >>>> >>>> text about >>>> >>>>>> it. >>>>>> >>>>>> Still, I have some issues with the section: >>>>>> >>>>>> I had a problem with this paragraph following the previous=20 >>>> >>>> >>>> >>>> one in the >>>> >>>>>> section. The previous paragraph said " >>>>>> However, if a QSPEC arrives at a QNE that does >>>>>> not support the QOSM being signaled, it can still understand the= >>>>>> QSPEC content, at least to a basic degree. >>>>>> " >>>>>> >>>>>> When I read through the text I got the impression that the two=20 >>>>>> sections relate to each other and in fact they do not. Hence, I=20 >>>>>> suggest to delete the previous paragraph since this one=20 >>>> >>>> >>>> >>>> contains the >>>> >>>>>> info already. >>>>> >>>>> >>>>> >>>>> >>>>> I'm unclear as to which paragraph/text you are proposing to delete.= >>>>> >>>>> >>>>> >>>>>> You >>>>>> might also want to delete the second paragraph as well=20 >>>> >>>> >>>> >>>> since it is far >>>> >>>>>> too obvious to use RFC2119 language: If you don't support even a=20 >>>>>> single QOSM then why are you a QOS NSLP node in the first place. >>>>> >>>>> >>>>> >>>>> >>>>> I think it important to state that a QNE MUST support at=20 >>>> >>>> >>>> >>>> least one QOSM, >>>> >>>>> even if this is clearly necessary to effectively support=20 >>>> >>>> >>>> >>>> QoS-NSLP/QSPEC. >>>> >>>>> >>>>>> You might want to highlight the following sentence, though: >>>>>> >>>>>> " >>>>>> A QNE MUST interpret all mandatory parameters from this=20 >>>> >>>> >>>> >>>> document even >>>> >>>>>> if it does not support the received QoS NSLP message with the=20 >>>>>> indicated QOSM. >>>>>> " >>>>>> >>>>>> Here is my proposal for the section: >>>>>> >>>>>> " >>>>>> 4.2 QSPEC Processing >>>>>> >>>>>> The QSPEC is opaque to the QoS NSLP processing. The=20 >>>> >>>> >>>> >>>> QSPEC control >>>> >>>>>> information and the QoS description are interpreted and MAY be >>>>>> modified by the RMF in a QNE (see description in [QoS-SIG]). >>>>>> >>>>>> The QSPEC contains a QOSM ID, i.e. information on what QOSM is= =20 >>>>>> being >>>>>> signaled by the QNI. However, if a QSPEC arrives at a QNE=20 >>>>>> that does >>>>>> not support the QOSM being signaled, it can still understand the= >>>>>> QSPEC content, at least to a basic degree. This is because=20 >>>>>> mandatory >>>>>> parameters have been defined as a common language. Therefore,= =20 >>>>>> a QNE >>>>>> MUST at least interpret all the mandatory parameters in a =20 >>>>>> QSPEC even >>>>>> if it does not support the corresponding QOSM. >>>>>> >>>>>> A QNE MUST either >>>>>> >>>>>> a) interpret a mandatory parameter carried in the QSPEC=20 >>>> >>>> >>>> >>>> object, or >>>> >>>>>> b) remap the parameter and raise the flag =20 >>>>>> defined in >>>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>>> specification. >>>>>> >>>>>> Here the terminology 'interpret' means that >>>>>> the parameter is implemented according to the references given= =20 >>>>>> for each QSPEC parameter. >>>>>> >>>>>> If a QSPEC arrives at a QNE that does not support the QOSM being= >>>>>> signaled, it can still understand the QSPEC content, at=20 >>>> >>>> >>>> >>>> least to a >>>> >>>>>> basic degree. Hence, with case (a), a parameter >>>>>> must be strictly interpreted as a token bucket. >>>>>> >>>>>> In case b), a parameter may be remapped, =20 >>>>>> perhaps to a >>>>>> parameter. >>>>>> " >>>>> >>>>> >>>>> >>>>> >>>>> I don't see any benefit in redefining what 'interpret' means in the= >>>>> document. As I mentioned above, the document uses the term=20 >>>> >>>> >>>> >>>> 'interpret' to >>>> >>>>> mean that a mandatory parameter is 'interpreted' if is=20 >>>> >>>> >>>> >>>> either 'strictly >>>> >>>>> interpreted' or it is 'remapped' (where the remapping must=20 >>>> >>>> >>>> >>>> be defined in the >>>> >>>>> QOSM specification document). OTOH, it might be useful to define a= >>>>> 'remapping' flag to indicated if a mandatory or optional=20 >>>> >>>> >>>> >>>> parameter has been >>>> >>>>> remapped by a QNE in the path. >>>>> >>>>> >>>>> >>>>>> Btw, have you noticed that the draft has >>>>>> * a flag (Section 5.1) >>>>>> * a parameter (Section 7.2.1) >>>>>> >>>>>> I think they refer to the same concept... >>>>> >>>>> >>>>> >>>>> >>>>> Yes, good catch. is indeed intended to be a=20 >>>> >>>> >>>> >>>> flag, and >>>> >>>>> perhaps one of the QSPEC object flags defined in Section=20 >>>> >>>> >>>> >>>> 7.1 could be used >>>> >>>>> for this purpose, rather than use a full 32-bit parameter=20 >>>> >>>> >>>> >>>> for this purpose, >>>> >>>>> as currently specified in Section 7.2.1. >>>>> >>>>> >>>>> >>>>>>> In the latter case, the remapping of the to >>>>>>> must be specified in the QOSM specification=20 >>>> >>>> >>>> >>>> document. >>>> >>>>>>> For example, QOSM X exclusively uses the parameter =20 >>>>>>> . It >>>>>>> must define a mapping of the mandatory parameter .= >>>>>>> The mapping consists of interpreting the Token Bucket Rate as >>>>>>> the parameter and disregarding the other=20 >>>> >>>> >>>> >>>> Token Bucket >>>> >>>>>>> parameters. Clearly, some information contained in the >>>>>> Bucket> parameter is lost by this mapping, and the resulting=20 >>>>>>> QoS may >>>>>>> not be quite what was intended by the QNI. Therefore, QOSM X a= lso >>>>>>> specifies that the flag be raised. Thus, a QNE = >>>>>>> using >>>>>>> QOSM X is able to make an informed decision whether to admit a >>>>>>> reservation described in terms of , and=20 >>>> >>>> >>>> >>>> at the same >>>> >>>>>>> time (by means of ) signals to the=20 >>>> >>>> >>>> >>>> QNI/QNR that the >>>> >>>>>>> exact intention of the QNI may not be met." >>>>>>> >>>>>>> I think this text is pretty clear as to what is required=20 >>>>>>> regarding interpreting mandatory parameters. If not, please=20 >>>>>>> suggest clarifications. >>>>>> >>>>>> >>>>>> >>>>>> The text in the new draft has improved a lot. >>>>>> Thanks for the update. >>>>>> >>>>>> >>>>>> >>>>>>>> Another possible question would be: >>>>>>>> " >>>>>>>> Does a node that implements a particular QOSM has to=20 >>>> >>>> >>>> >>>> define mappings >>>> >>>>>>>> from all mandatory parameters listed in the QSPEC=20 >>>> >>>> >>>> >>>> template draft to >>>> >>>>>>>> the QOSM draft (even if the QOSM does not make use >>>>>> >>>>>> >>>>>> >>>>>> of them)? >>>>>> >>>>>> >>>>>>>> " >>>>>>>> >>>>>>>> The answer is "I don't know". >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> A QNE must interpret all mandatory parameters, if populated, as >>>>>>> explained in the above text I quoted. If a QOSM re-maps a=20 >>>> >>>> >>>> >>>> mandatory >>>> >>>>>>> QSPEC parameter, that re-mapping must be defined in the QOSM >>>>>>> specification. As stated in Section 4.7 (QOSM Specification >>>>>>> Requirements): >>>>>>> >>>>>>> " A QOSM specification MUST define QSPEC parameter behavior=20 >>>>>>> for these >>>>>>> cases: a) new optional QSPEC parameters the QOSM specification >>>>>>> defines, and b) remapping of existing mandatory or=20 >>>> >>>> >>>> >>>> optional QSPEC >>>> >>>>>>> parameters, as described in Section 4.2. Unless otherwise=20 >>>>>>> specified >>>>>>> in the QOSM specification document, the behaviors to strictly >>>>>>> interpret the mandatory and optional QSPEC parameters are=20 >>>>>>> defined in >>>>>>> this document through the references to RFCs that precisely def= ine >>>>>>> the QSPEC parameter behaviors. A QOSM specification MUST define= =20 >>>>>>> how the mandatory parameters are to >>>>>>> be mapped onto the QSPEC parameters used by the QOSM,=20 >>>> >>>> >>>> >>>> however the >>>> >>>>>>> mapping MAY result in slight modification to the intended >>>>>>> specification when an exact mapping is not possible. This=20 >>>>>>> definition >>>>>>> MUST allow a QNE implementing this QOSM to make a decision as to= >>>>>>> whether a reservation described in terms of mandatory =20 >>>>>>> parameters can >>>>>>> be admitted. If for a particular mandatory parameter no =20 >>>>>>> mapping can >>>>>>> be found that guarantees the desired QoS, the QNE is advised to= =20 >>>>>>> raise >>>>>>> the flag. In other words, for all mandatory >>>>>>> parameters a mapping must be defined, but it is=20 >>>> >>>> >>>> >>>> acknowledged that >>>> >>>>>>> this mapping may result in slightly bending the original=20 >>>>>>> intention of >>>>>>> the QNI." >>>>>>> >>>>>>> I think this text is pretty clear as to what is required. If not= , >>>>>>> please suggest clarifications. >>>>>> >>>>>> >>>>>> >>>>>> I understood the token bucket to bandwidth example. >>>>>> >>>>>> Would the RMD draft, for example, list all mandatory parameters=20 >>>>>> and indicate whether it can map them (and how) to parameters used = >>>>>> in the RMD specification? >>>>> >>>>> >>>>> >>>>> >>>>> As stated in the QOSM specification requirements in Section=20 >>>> >>>> >>>> >>>> 4.7, if a QOSM >>>> >>>>> remaps a mandatory parameter, the remapping must be defined=20 >>>> >>>> >>>> >>>> in the QOSM >>>> >>>>> specification document. If no such remapping is defined,=20 >>>> >>>> >>>> >>>> the default >>>> >>>>> behavior is that the QOSM must strictly interpret the=20 >>>> >>>> >>>> >>>> mandatory parameter, >>>> >>>>> as defined above. >>>>> >>>>> >>>>> >>>>>> Do you think it is awfully realistic for all QNEs to understand=20 >>>>>> all mandatory parameters? I could imagine that Attila and Georgios= =20 >>>>>> are not going to implement stateless interior QNEs in such a way=20 >>>>>> that they understand all the mandatory QSPEC parameters. In fact=20 >>>>>> they don't have todo it since only edge routers are likely to ever= =20 >>>>>> see QoS NSLP messages that contain QOSM IDs that they do not=20 >>>>>> understand (otherwise something go terribly wrong). >>>>> >>>>> >>>>> >>>>> >>>>> It is up the RMD authors to specify how they want RMD to behave wrt= >>>>> mandatory parameters (and obtain rough consensus, of=20 >>>> >>>> >>>> >>>> course). That is, if a >>>> >>>>> mandatory parameter is remapped and not strictly=20 >>>> >>>> >>>> >>>> interpreted, the remapping >>>> >>>>> must be specified in the QOSM specification document. =20 >>>> >>>> >>>> >>>> Otherwise, the QOSM >>>> >>>>> must strictly interpret the mandatory parameters that are=20 >>>> >>>> >>>> >>>> not remapped, if >>>> >>>>> they are populated by the QNI. >>>>> >>>>> There are no restrictions on how the remapping must be=20 >>>> >>>> >>>> >>>> done, it can be as >>>> >>>>> simple as necessary (but no simpler). >>>>> >>>>> Thanks, >>>>> Jerry >>>>> >>>>> >>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Jerry >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Ciao >>>>>>>> Hannes >>>>>>>> >>>>>>>> The QSPEC-draft says in section 5 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> that >>>>>>>>> all parameters listed in the next sections are mandatory. The=20 >>>>>>>>> QSPEC-draft also >>>>>>>>> says in section 4.1 that "a given QOSM defines which of the=20 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> mandatory and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> optional parameters it uses, ..." >>>>>>>>> >>>>>>>>> Are there any specific parameters which makes the open=20 >>>>>> >>>>>> >>>>>> >>>>>> issue B.1.1. >>>>>> >>>>>>>>> clearer? Following the QSPEC-draft there doesn't seem to be=20 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> a conflict, >>>>>>>> >>>>>>>> >>>>>>>>> if nothing is >>>>>>>>> done with the unneeded parameters. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bernd >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> nsis mailing list >>>>> nsis@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>>> >>>>> >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> >> >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 08:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxjcI-0001Nj-In; Tue, 04 Jul 2006 08:02:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxjcH-0001Ne-9N for nsis@ietf.org; Tue, 04 Jul 2006 08:02:57 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxjcG-0002hk-0v for nsis@ietf.org; Tue, 04 Jul 2006 08:02:57 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k64C2acD023021; Tue, 4 Jul 2006 14:02:37 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k64C2aCY032549; Tue, 4 Jul 2006 14:02:36 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 14:01:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] draft-qosmodel-controlledload-04 Date: Tue, 4 Jul 2006 14:00:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] draft-qosmodel-controlledload-04 thread-index: AcafXqNNp68p2eQQQQCxpGDSkQNhUAAAqS3A From: "Tschofenig, Hannes" To: "Bernd Schloer" , "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jul 2006 12:01:39.0726 (UTC) FILETIME=[9B911AE0:01C69F61] X-Spam-Score: 1.1 (+) X-Scan-Signature: 22ee92479d98f6ee260f4d663978f084 Cc: "Ash, Gerald R \(Jerry\), ALABS" , Georgios Karagiannis , =?iso-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= , nsis@ietf.org, "Kappler, Cornelia" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd,=20 I got your idea. To be honest I am the wrong person to judge which = parameter should be mandatory or optional.=20 Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 > Gesendet: Dienstag, 4. Juli 2006 13:32 > An: Hannes Tschofenig > Cc: Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis;=20 > Kappler, Cornelia; nsis@ietf.org; "Attila B=E1der (IJ/ETH)" > Betreff: Re: [NSIS] draft-qosmodel-controlledload-04 >=20 > Hi Hannes, please see inline. >=20 > Benrnd >=20 >=20 > Hannes Tschofenig wrote: > > Hi Bernd, > >=20 > >=20 > > Bernd Schloer wrote: > >=20 > >> Hi all, > >> > >> just an idea: > >> > >> Token Bucket is the only mandatory parameter. > >=20 > >=20 > > There are several mandatory parameters defined in the QSPEC, namely: > >=20 > > * NON QOSM Hop > > * Excess Treatment > > * Bandwidth > > * Token Bucket > the above should be mandatory. >=20 > > * PHB Class > > * Y.1541 QoS Class > > * DSTE Class Type > > * & > > * Admission Priority > > * RPH Priority > this should be optional. as suggested a bit earlier the ping=20 > tool could update=20 > the path latency. > >=20 > > Are you suggesting to reduce the list to a single mandatory=20 > parameter? > >=20 > > It is interpreted by CLS > >=20 > >> and Y.1541. RMD can map it to Bandwidth. > >=20 > >=20 > > CLS and Y.1541 use the token bucket parameter. > >=20 > > RMD says that it can be mapped to bandwidth if the e2e=20 > message contains=20 > > the token bucket parameter in a QOSM that is not understood. > >=20 > >> > >> Other Parameters, like Path Latency,etc. are optional. If a QOSM=20 > >> doesn't support it, it can be skipped. > >=20 > >=20 > > Correct. > >=20 > >=20 > >> > >> Mainly two types of parameters are left: Delay, Priority.=20 > If supported=20 > >> by two different QOSMs, the following mapping could be tried: > >> > >> Delay: can be mapped to , >> Jitter>, > >> > >> Priority: , , >> Priority>, > >> Here should rather be derived from=20 > =20 > >> than vice versa, as is more complex. Or in=20 > general the=20 > >> simple parameters should be derived from the more complex one. > >=20 > >=20 > > I do not quite follow this idea. > >=20 > >> > >> The only problem I see: Do I know the QOSM of my neighbor=20 > domain? Do I=20 > >> have to consider this when sending the initiator QSPEC? > >=20 > >=20 > > Note that you do not necessarily only need to know your neighoring=20 > > domain. Consider the migration scenario where many networks don't=20 > > understand the QoS signaling message at all. For example, you might=20 > > consider the case where only the access networks inspect the NSIS=20 > > signaling messages. > >=20 > >=20 > > Ciao > > Hannes > >=20 > >> > >> Bernd > >> > >> > >> > >> > >> Attila B=E1der (IJ/ETH) wrote: > >> > >>> Hi All, > >>> > >>> If "ignore" is not a type interpretation, I also think=20 > that it should=20 > >>> be reformulated. > >>> > >>> In general, to understend mandatory parameters that is=20 > not used in a=20 > >>> local QoSM, I see less problem. If a QOSM has to fill in=20 > mandatory=20 > >>> parameters that is not used in this QOSM, seems to be=20 > more difficult. > >>> > >>> Best regards, Attila > >>> > >>> > >>>> -----Original Message----- > >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>> Sent: Monday, July 03, 2006 4:37 PM > >>>> To: Georgios Karagiannis > >>>> Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila B=E1der (IJ/ETH); > >>>> nsis@ietf.org; 'Kappler Cornelia' > >>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 > >>>> > >>>> > >>>> Hi Georgios, > >>>> > >>>> please find my comment below: > >>>> > >>>> Georgios Karagiannis wrote: > >>>> > >>>>> Hi Jerry > >>>>> Regarding your last point: > >>>>> > >>>>> > >>>>>>> Hannes: > >>>>>>> Do you think it is awfully realistic for all QNEs to=20 > >>>> > >>>> > >>>> > >>>> understand all > >>>> > >>>>>>> mandatory parameters? I could imagine that Attila and=20 > Georgios=20 > >>>>>>> are not going to implement stateless interior QNEs in=20 > such a way=20 > >>>>>>> that they understand all the mandatory QSPEC=20 > parameters. In fact=20 > >>>>>>> they don't have todo it since only edge routers are likely to=20 > >>>>>>> ever see QoS NSLP messages that contain QOSM IDs that=20 > they do not=20 > >>>>>>> understand (otherwise something go terribly wrong). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Jerry: It is up the RMD authors to specify how they want RMD > >>>>>> > >>>>>>> to behave wrt mandatory parameters (and obtain rough=20 > consensus,=20 > >>>>>>> of course). That is, if a mandatory parameter is=20 > remapped and=20 > >>>>>>> not strictly interpreted, the remapping must be=20 > specified in the=20 > >>>>>>> QOSM specification document. Otherwise, the QOSM=20 > must strictly=20 > >>>>>>> interpret the mandatory parameters that are not=20 > remapped, if they=20 > >>>>>>> are populated by the QNI. > >>>>>>> There are no restrictions on how the remapping must=20 > be done, it=20 > >>>>>>> can be as simple as necessary (but no simpler). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Georgios: > >>>>> Jerry, I think that the point raised by Hannes is related to > >>>>> how the QNE's interior to the RMD domain will have to=20 > comply to the > >>>>> mandatory descriptions specified in the QSPEC template. An=20 > >>>>> interior QNE (in RMD-QOSM) will not process the end to=20 > end QSpec.=20 > >>>>> The only QSpec that will be processed by the interior=20 > QNE is the=20 > >>>>> RMD Qsepc that is initiated by the ingress node (i.e.,=20 > QNI for the=20 > >>>>> RMD local session). Note that the above observation is=20 > valid for=20 > >>>>> all local QOSMs. > >>>>> However, the above is not allowed due to the following=20 > text that is=20 > >>>>> included in the QSpec template draft: > >>>>> > >>>>> "A QNE MUST interpret all mandatory parameters from this=20 > >>>> > >>>> > >>>> > >>>> document even > >>>> > >>>>> if it does not support the received QoS NSLP message with the=20 > >>>>> indicated QOSM." > >>>>> > >>>>> Therefore, in my opinion it is required to modify the above=20 > >>>> > >>>> > >>>> > >>>> sentence in > >>>> > >>>>> something like: > >>>>> > >>>>> "A QNE SHOULD interpret all mandatory parameters from this=20 > >>>> > >>>> > >>>> > >>>> document even > >>>> > >>>>> if it does not support the received QoS NSLP message with the=20 > >>>>> indicated QOSM. A QNE that supports a local QOSM, does not=20 > >>>> > >>>> > >>>> > >>>> have to interpret > >>>> > >>>>> all mandatory parameters carried by a QSpec that was=20 > >>>> > >>>> > >>>> > >>>> generated by a QNI > >>>> > >>>>> located outside the domain that supports the given local QOSM."=20 > >>>> > >>>> > >>>> > >>>> Something along these lines would probably be more=20 > realistic, I guess. > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> > >>>>> Best regards, > >>>>> Georgios > >>>>> > >>>>> -----Original Message----- > >>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] Sent:=20 > >>>>> maandag 3 juli 2006 2:03 > >>>>> To: Hannes Tschofenig > >>>>> Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH);=20 > >>>> > >>>> > >>>> > >>>> nsis@ietf.org; > >>>> > >>>>> Kappler Cornelia > >>>>> Subject: RE: [NSIS] draft-qosmodel-controlledload-04 > >>>>> > >>>>> Hi Hannes, > >>>>> > >>>>> See below. > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>> Sent: Saturday, July 01, 2006 4:26 PM > >>>>>> To: Ash, Gerald R (Jerry), ALABS > >>>>>> Cc: nsis@ietf.org > >>>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 > >>>>>> > >>>>>> Hi Jerry, > >>>>>> > >>>>>> it is true that I haven't read the most recent QSPEC draft=20 > >>>> > >>>> > >>>> > >>>> when I sent > >>>> > >>>>>> this mail. In the meanwhile I did. Please find a few=20 > comments below: > >>>>>> > >>>>>> Ash, Gerald R (Jerry), ALABS wrote: > >>>>>> > >>>>>> > >>>>>>> Hi Hannes, > >>>>>>> > >>>>>>> See below. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>> Sent: Friday, June 30, 2006 8:43 AM > >>>>>>>> To: Bernd Schloer > >>>>>>>> Cc: nsis@ietf.org > >>>>>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 > >>>>>>>> > >>>>>>>> Hi Bernd, > >>>>>>>> > >>>>>>>> Bernd Schloer wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> the first open issue in the appendix B is about=20 > what to do with=20 > >>>>>>>>> mandatory QSPEC parameters which are not needed for CLS. > >>>>>>>>> > >>>>>>>>> Does a QOSM have to understand (and provide information=20 > >>>> > >>>> > >>>> > >>>> about) all > >>>> > >>>>>>>>> mandatory parameters, even if they are not used? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I think the question is wrong. What about the=20 > following question: > >>>>>>>> " > >>>>>>>> Does a node that implements a particular QOSM has to=20 > >>>> > >>>> > >>>> > >>>> understand all > >>>> > >>>>>>>> mandatory parameters listed in the QSPEC template draft > >>>>>> > >>>>>> > >>>>>> > >>>>>> (even if the > >>>>>> > >>>>>> > >>>>>>>> QOSM does not make use of them)? > >>>>>>>> " > >>>>>>>> The answer would be "YES" since the QSPEC template draft=20 > >>>> > >>>> > >>>> > >>>> says that > >>>> > >>>>>>>> mandatory parameters have to be understood by every=20 > NSIS QoS node. > >>>>>>>> > >>>>>>>> There is only the question what "understands" means. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> IMO you need to more carefully read the QSPEC I-D=20 > document. All=20 > >>>>>>> mandatory QSPEC parameters that are populated in the=20 > QSPEC must=20 > >>>>>>> be interpreted by every QNE, which is explained in=20 > the QSPEC I-D: > >>>>>>> > >>>>>>> It says in Section 4.4.1 (Mandatory and Optional QSPEC > >>>>>> > >>>>>> > >>>>>> > >>>>>> . Parameters) of > >>>>>> > >>>>>> > >>>>>>> the QSPEC I-D > >>>>>>> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: > >>>>>>> > >>>>>>> " Mandatory QSPEC parameters are treated as follows: > >>>>>>> > >>>>>>> o A QNI SHOULD populate mandatory QSPEC parameters if > >>>>>> > >>>>>> > >>>>>> > >>>>>> . applicable to > >>>>>> > >>>>>> > >>>>>>> the underlying QOSM. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I don't understand this sentence. What does it mean that a QNI=20 > >>>>>> "SHOULD" > >>>>>> populate parameters if applicable? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> It means that a QNI is not required to populate all=20 > >>>> > >>>> > >>>> > >>>> mandatory parameters. A > >>>> > >>>>> QNI would only populated a mandatory parameter if is used=20 > >>>> > >>>> > >>>> > >>>> by the QOSM > >>>> > >>>>> supported by the QNI. > >>>>> > >>>>> > >>>>> > >>>>>>> o QNEs MUST interpret mandatory QSPEC parameters, if=20 > signaled." > >>>>>>> > >>>>>>> Furthermore, it says in Section 4.2 (QSPEC Processing): > >>>>>>> > >>>>>>> " a QNE > >>>>>>> MUST at least interpret all the mandatory parameters=20 > in a QSPEC=20 > >>>>>>> even > >>>>>>> if it does not support the corresponding QOSM. > >>>>>>> > >>>>>>> Mandatory parameters provide a minimal subset of=20 > parameters. A > >>>>>>> QNE MUST either a) strictly interpret a mandatory=20 > parameter, or > >>>>>>> b) remap the parameter and raise the flag =20 > >>>>>>> defined in > >>>>>>> Section 5.1, where the remapping MUST be specified=20 > in the QOSM > >>>>>>> specification. Here the terminology 'strictly =20 > interpret' means=20 > >>>>>>> that > >>>>>> > >>>>>> > >>>>>> > >>>>>> What is the difference between 'strictly interpret' and=20 > >>>> > >>>> > >>>> > >>>> 'interpret'? > >>>> > >>>>>> In the rest of the document you use 'interpret'. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> 'Strictly interpret' is defined in the text I quoted from=20 > >>>> > >>>> > >>>> > >>>> Section 4.2 (QSPEC > >>>> > >>>>> Processing), which is given again in the very next=20 > >>>> > >>>> > >>>> > >>>> sentences I quoted just > >>>> > >>>>> below (after you posed your above question :-) > >>>>> > >>>>> " Mandatory parameters provide a minimal subset of=20 > parameters. A > >>>>> QNE MUST either a) strictly interpret a mandatory=20 > parameter, or > >>>>> b) remap the parameter and raise the flag=20 > >>>> > >>>> > >>>> > >>>> defined in > >>>> > >>>>> Section 5.1, where the remapping MUST be specified in the QOSM > >>>>> specification. Here the terminology 'strictly=20 > >>>> > >>>> > >>>> > >>>> interpret' means that > >>>> > >>>>> the parameter is implemented according to the=20 > commonly accepted > >>>>> definition and/or as specified by references given=20 > for each QSPEC > >>>>> parameter. This means that in case a), a =20 > >>>> > >>>> > >>>> > >>>> parameter > >>>> > >>>>> must be strictly interpreted as a token bucket. =20 > >>>> > >>>> > >>>> > >>>> However, in case b), > >>>> > >>>>> a parameter may be remapped, perhaps to a=20 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> parameter." > >>>>> > >>>>> In the document, the term 'interpret' a mandatory parameter=20 > >>>> > >>>> > >>>> > >>>> means either a) > >>>> > >>>>> strictly interpret (as defined above), or b) remap (as=20 > >>>> > >>>> > >>>> > >>>> defined above). > >>>> > >>>>> Perhaps this can be made clearer in the text. > >>>>> > >>>>> > >>>>> > >>>>>>> the parameter is implemented according to the=20 > commonly accepted > >>>>>>> definition and/or as specified by references given for=20 > >>>> > >>>> > >>>> > >>>> each QSPEC > >>>> > >>>>>>> parameter. This means that in case a), a Bucket> parameter > >>>>>>> must be strictly interpreted as a token bucket. =20 > However, in=20 > >>>>>>> case b), > >>>>>>> a parameter may be remapped, perhaps to a=20 > >>>>>>> > >>>>>>> parameter. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I noticed this text improvement and I am happy to see more=20 > >>>> > >>>> > >>>> > >>>> text about > >>>> > >>>>>> it. > >>>>>> > >>>>>> Still, I have some issues with the section: > >>>>>> > >>>>>> I had a problem with this paragraph following the previous=20 > >>>> > >>>> > >>>> > >>>> one in the > >>>> > >>>>>> section. The previous paragraph said " > >>>>>> However, if a QSPEC arrives at a QNE that does > >>>>>> not support the QOSM being signaled, it can still=20 > understand the > >>>>>> QSPEC content, at least to a basic degree. > >>>>>> " > >>>>>> > >>>>>> When I read through the text I got the impression that the two=20 > >>>>>> sections relate to each other and in fact they do not.=20 > Hence, I=20 > >>>>>> suggest to delete the previous paragraph since this one=20 > >>>> > >>>> > >>>> > >>>> contains the > >>>> > >>>>>> info already. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> I'm unclear as to which paragraph/text you are=20 > proposing to delete. > >>>>> > >>>>> >=20 > >>>>> > >>>>>> You > >>>>>> might also want to delete the second paragraph as well=20 > >>>> > >>>> > >>>> > >>>> since it is far > >>>> > >>>>>> too obvious to use RFC2119 language: If you don't=20 > support even a=20 > >>>>>> single QOSM then why are you a QOS NSLP node in the=20 > first place. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> I think it important to state that a QNE MUST support at=20 > >>>> > >>>> > >>>> > >>>> least one QOSM, > >>>> > >>>>> even if this is clearly necessary to effectively support=20 > >>>> > >>>> > >>>> > >>>> QoS-NSLP/QSPEC. > >>>> > >>>>> > >>>>>> You might want to highlight the following sentence, though: > >>>>>> > >>>>>> " > >>>>>> A QNE MUST interpret all mandatory parameters from this=20 > >>>> > >>>> > >>>> > >>>> document even > >>>> > >>>>>> if it does not support the received QoS NSLP message with the=20 > >>>>>> indicated QOSM. > >>>>>> " > >>>>>> > >>>>>> Here is my proposal for the section: > >>>>>> > >>>>>> " > >>>>>> 4.2 QSPEC Processing > >>>>>> > >>>>>> The QSPEC is opaque to the QoS NSLP processing. The=20 > >>>> > >>>> > >>>> > >>>> QSPEC control > >>>> > >>>>>> information and the QoS description are interpreted=20 > and MAY be > >>>>>> modified by the RMF in a QNE (see description in [QoS-SIG]). > >>>>>> > >>>>>> The QSPEC contains a QOSM ID, i.e. information on=20 > what QOSM is=20 > >>>>>> being > >>>>>> signaled by the QNI. However, if a QSPEC arrives at a QNE=20 > >>>>>> that does > >>>>>> not support the QOSM being signaled, it can still=20 > understand the > >>>>>> QSPEC content, at least to a basic degree. This is =20 > because=20 > >>>>>> mandatory > >>>>>> parameters have been defined as a common language. =20 > Therefore,=20 > >>>>>> a QNE > >>>>>> MUST at least interpret all the mandatory parameters in a =20 > >>>>>> QSPEC even > >>>>>> if it does not support the corresponding QOSM. > >>>>>> > >>>>>> A QNE MUST either > >>>>>> > >>>>>> a) interpret a mandatory parameter carried in the QSPEC=20 > >>>> > >>>> > >>>> > >>>> object, or > >>>> > >>>>>> b) remap the parameter and raise the flag =20 > >>>>>> defined in > >>>>>> Section 5.1, where the remapping MUST be specified=20 > in the QOSM > >>>>>> specification. > >>>>>> > >>>>>> Here the terminology 'interpret' means that > >>>>>> the parameter is implemented according to the=20 > references given=20 > >>>>>> for each QSPEC parameter. > >>>>>> > >>>>>> If a QSPEC arrives at a QNE that does not support=20 > the QOSM being > >>>>>> signaled, it can still understand the QSPEC content, at=20 > >>>> > >>>> > >>>> > >>>> least to a > >>>> > >>>>>> basic degree. Hence, with case (a), a =20 > parameter > >>>>>> must be strictly interpreted as a token bucket. > >>>>>> > >>>>>> In case b), a parameter may be remapped, =20 > >>>>>> perhaps to a > >>>>>> parameter. > >>>>>> " > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> I don't see any benefit in redefining what 'interpret'=20 > means in the > >>>>> document. As I mentioned above, the document uses the term=20 > >>>> > >>>> > >>>> > >>>> 'interpret' to > >>>> > >>>>> mean that a mandatory parameter is 'interpreted' if is=20 > >>>> > >>>> > >>>> > >>>> either 'strictly > >>>> > >>>>> interpreted' or it is 'remapped' (where the remapping must=20 > >>>> > >>>> > >>>> > >>>> be defined in the > >>>> > >>>>> QOSM specification document). OTOH, it might be useful=20 > to define a > >>>>> 'remapping' flag to indicated if a mandatory or optional=20 > >>>> > >>>> > >>>> > >>>> parameter has been > >>>> > >>>>> remapped by a QNE in the path. > >>>>> > >>>>> > >>>>> > >>>>>> Btw, have you noticed that the draft has > >>>>>> * a flag (Section 5.1) > >>>>>> * a parameter (Section 7.2.1) > >>>>>> > >>>>>> I think they refer to the same concept... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Yes, good catch. is indeed intended to be a=20 > >>>> > >>>> > >>>> > >>>> flag, and > >>>> > >>>>> perhaps one of the QSPEC object flags defined in Section=20 > >>>> > >>>> > >>>> > >>>> 7.1 could be used > >>>> > >>>>> for this purpose, rather than use a full 32-bit parameter=20 > >>>> > >>>> > >>>> > >>>> for this purpose, > >>>> > >>>>> as currently specified in Section 7.2.1. > >>>>> > >>>>> > >>>>> > >>>>>>> In the latter case, the remapping of the to > >>>>>>> must be specified in the QOSM specification=20 > >>>> > >>>> > >>>> > >>>> document. > >>>> > >>>>>>> For example, QOSM X exclusively uses the parameter =20 > >>>>>>> . It > >>>>>>> must define a mapping of the mandatory parameter=20 > . > >>>>>>> The mapping consists of interpreting the Token Bucket Rate as > >>>>>>> the parameter and disregarding the other=20 > >>>> > >>>> > >>>> > >>>> Token Bucket > >>>> > >>>>>>> parameters. Clearly, some information contained in=20 > the >>>>>>> Bucket> parameter is lost by this mapping, and the =20 > resulting=20 > >>>>>>> QoS may > >>>>>>> not be quite what was intended by the QNI. =20 > Therefore, QOSM X also > >>>>>>> specifies that the flag be raised. =20 > Thus, a QNE=20 > >>>>>>> using > >>>>>>> QOSM X is able to make an informed decision whether=20 > to admit a > >>>>>>> reservation described in terms of , and=20 > >>>> > >>>> > >>>> > >>>> at the same > >>>> > >>>>>>> time (by means of ) signals to the=20 > >>>> > >>>> > >>>> > >>>> QNI/QNR that the > >>>> > >>>>>>> exact intention of the QNI may not be met." > >>>>>>> > >>>>>>> I think this text is pretty clear as to what is required=20 > >>>>>>> regarding interpreting mandatory parameters. If not, please=20 > >>>>>>> suggest clarifications. > >>>>>> > >>>>>> > >>>>>> > >>>>>> The text in the new draft has improved a lot. > >>>>>> Thanks for the update. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> Another possible question would be: > >>>>>>>> " > >>>>>>>> Does a node that implements a particular QOSM has to=20 > >>>> > >>>> > >>>> > >>>> define mappings > >>>> > >>>>>>>> from all mandatory parameters listed in the QSPEC=20 > >>>> > >>>> > >>>> > >>>> template draft to > >>>> > >>>>>>>> the QOSM draft (even if the QOSM does not make use > >>>>>> > >>>>>> > >>>>>> > >>>>>> of them)? > >>>>>> > >>>>>> > >>>>>>>> " > >>>>>>>> > >>>>>>>> The answer is "I don't know". > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> A QNE must interpret all mandatory parameters, if=20 > populated, as > >>>>>>> explained in the above text I quoted. If a QOSM re-maps a=20 > >>>> > >>>> > >>>> > >>>> mandatory > >>>> > >>>>>>> QSPEC parameter, that re-mapping must be defined in the QOSM > >>>>>>> specification. As stated in Section 4.7 (QOSM Specification > >>>>>>> Requirements): > >>>>>>> > >>>>>>> " A QOSM specification MUST define QSPEC parameter =20 > behavior=20 > >>>>>>> for these > >>>>>>> cases: a) new optional QSPEC parameters the QOSM=20 > specification > >>>>>>> defines, and b) remapping of existing mandatory or=20 > >>>> > >>>> > >>>> > >>>> optional QSPEC > >>>> > >>>>>>> parameters, as described in Section 4.2. Unless otherwise=20 > >>>>>>> specified > >>>>>>> in the QOSM specification document, the behaviors to strictly > >>>>>>> interpret the mandatory and optional QSPEC parameters are=20 > >>>>>>> defined in > >>>>>>> this document through the references to RFCs that =20 > precisely define > >>>>>>> the QSPEC parameter behaviors. A QOSM specification=20 > MUST define=20 > >>>>>>> how the mandatory parameters are to > >>>>>>> be mapped onto the QSPEC parameters used by the QOSM,=20 > >>>> > >>>> > >>>> > >>>> however the > >>>> > >>>>>>> mapping MAY result in slight modification to the intended > >>>>>>> specification when an exact mapping is not possible. This=20 > >>>>>>> definition > >>>>>>> MUST allow a QNE implementing this QOSM to make a=20 > decision as to > >>>>>>> whether a reservation described in terms of mandatory =20 > >>>>>>> parameters can > >>>>>>> be admitted. If for a particular mandatory parameter no =20 > >>>>>>> mapping can > >>>>>>> be found that guarantees the desired QoS, the QNE is=20 > advised to=20 > >>>>>>> raise > >>>>>>> the flag. In other words, for all mandatory > >>>>>>> parameters a mapping must be defined, but it is=20 > >>>> > >>>> > >>>> > >>>> acknowledged that > >>>> > >>>>>>> this mapping may result in slightly bending the original=20 > >>>>>>> intention of > >>>>>>> the QNI." > >>>>>>> > >>>>>>> I think this text is pretty clear as to what is=20 > required. If not, > >>>>>>> please suggest clarifications. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I understood the token bucket to bandwidth example. > >>>>>> > >>>>>> Would the RMD draft, for example, list all mandatory=20 > parameters=20 > >>>>>> and indicate whether it can map them (and how) to=20 > parameters used=20 > >>>>>> in the RMD specification? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> As stated in the QOSM specification requirements in Section=20 > >>>> > >>>> > >>>> > >>>> 4.7, if a QOSM > >>>> > >>>>> remaps a mandatory parameter, the remapping must be defined=20 > >>>> > >>>> > >>>> > >>>> in the QOSM > >>>> > >>>>> specification document. If no such remapping is defined,=20 > >>>> > >>>> > >>>> > >>>> the default > >>>> > >>>>> behavior is that the QOSM must strictly interpret the=20 > >>>> > >>>> > >>>> > >>>> mandatory parameter, > >>>> > >>>>> as defined above. > >>>>> > >>>>> > >>>>> > >>>>>> Do you think it is awfully realistic for all QNEs to=20 > understand=20 > >>>>>> all mandatory parameters? I could imagine that Attila=20 > and Georgios=20 > >>>>>> are not going to implement stateless interior QNEs in=20 > such a way=20 > >>>>>> that they understand all the mandatory QSPEC=20 > parameters. In fact=20 > >>>>>> they don't have todo it since only edge routers are=20 > likely to ever=20 > >>>>>> see QoS NSLP messages that contain QOSM IDs that they do not=20 > >>>>>> understand (otherwise something go terribly wrong). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> It is up the RMD authors to specify how they want RMD=20 > to behave wrt > >>>>> mandatory parameters (and obtain rough consensus, of=20 > >>>> > >>>> > >>>> > >>>> course). That is, if a > >>>> > >>>>> mandatory parameter is remapped and not strictly=20 > >>>> > >>>> > >>>> > >>>> interpreted, the remapping > >>>> > >>>>> must be specified in the QOSM specification document. =20 > >>>> > >>>> > >>>> > >>>> Otherwise, the QOSM > >>>> > >>>>> must strictly interpret the mandatory parameters that are=20 > >>>> > >>>> > >>>> > >>>> not remapped, if > >>>> > >>>>> they are populated by the QNI. > >>>>> > >>>>> There are no restrictions on how the remapping must be=20 > >>>> > >>>> > >>>> > >>>> done, it can be as > >>>> > >>>>> simple as necessary (but no simpler). > >>>>> > >>>>> Thanks, > >>>>> Jerry > >>>>> > >>>>> > >>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Thanks, > >>>>>>> Jerry > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Ciao > >>>>>>>> Hannes > >>>>>>>> > >>>>>>>> The QSPEC-draft says in section 5 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> that > >>>>>>>>> all parameters listed in the next sections are=20 > mandatory. The=20 > >>>>>>>>> QSPEC-draft also > >>>>>>>>> says in section 4.1 that "a given QOSM defines which of the=20 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> mandatory and > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> optional parameters it uses, ..." > >>>>>>>>> > >>>>>>>>> Are there any specific parameters which makes the open=20 > >>>>>> > >>>>>> > >>>>>> > >>>>>> issue B.1.1. > >>>>>> > >>>>>>>>> clearer? Following the QSPEC-draft there doesn't seem to be=20 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> a conflict, > >>>>>>>> > >>>>>>>> > >>>>>>>>> if nothing is > >>>>>>>>> done with the unneeded parameters. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Bernd > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> nsis mailing list > >>>>> nsis@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/nsis > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> nsis mailing list > >>> nsis@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/nsis > >>> > >> > >> >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 08:07:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxjgw-0005DF-1k; Tue, 04 Jul 2006 08:07:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxjgv-0005DA-HH for nsis@ietf.org; Tue, 04 Jul 2006 08:07:45 -0400 Received: from natreg.rzone.de ([81.169.145.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxjgu-00038W-ES for nsis@ietf.org; Tue, 04 Jul 2006 08:07:45 -0400 Received: from [192.168.178.200] (p5484B402.dip0.t-ipconnect.de [84.132.180.2]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k64C7SKc014185; Tue, 4 Jul 2006 14:07:29 +0200 (MEST) Message-ID: <44AA595F.6010902@cs.uni-goettingen.de> Date: Tue, 04 Jul 2006 14:04:47 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: AW: [NSIS] draft-qosmodel-controlledload-04 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: e2979bf969b930cb324a529c01a4e0b4 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org, Georgios Karagiannis , =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= , "Kappler, Cornelia" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, that would make the QOSM CLS implemantable. I'm not sure about other QOSM= s. Bernd Tschofenig, Hannes wrote: > Hi Bernd,=20 >=20 > I got your idea. To be honest I am the wrong person to judge which para= meter should be mandatory or optional.=20 >=20 > Ciao > Hannes > =20 >=20 >=20 >>-----Urspr=FCngliche Nachricht----- >>Von: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 >>Gesendet: Dienstag, 4. Juli 2006 13:32 >>An: Hannes Tschofenig >>Cc: Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis;=20 >>Kappler, Cornelia; nsis@ietf.org; "Attila B=E1der (IJ/ETH)" >>Betreff: Re: [NSIS] draft-qosmodel-controlledload-04 >> >>Hi Hannes, please see inline. >> >>Benrnd >> >> >>Hannes Tschofenig wrote: >> >>>Hi Bernd, >>> >>> >>>Bernd Schloer wrote: >>> >>> >>>>Hi all, >>>> >>>>just an idea: >>>> >>>>Token Bucket is the only mandatory parameter. >>> >>> >>>There are several mandatory parameters defined in the QSPEC, namely: >>> >>>* NON QOSM Hop >>>* Excess Treatment >>>* Bandwidth >>>* Token Bucket >> >>the above should be mandatory. >> >> >>>* PHB Class >>>* Y.1541 QoS Class >>>* DSTE Class Type >>>* & >>>* Admission Priority >>>* RPH Priority >> >>this should be optional. as suggested a bit earlier the ping=20 >>tool could update=20 >>the path latency. >> >>>Are you suggesting to reduce the list to a single mandatory=20 >> >>parameter? >> >>> It is interpreted by CLS >>> >>> >>>>and Y.1541. RMD can map it to Bandwidth. >>> >>> >>>CLS and Y.1541 use the token bucket parameter. >>> >>>RMD says that it can be mapped to bandwidth if the e2e=20 >> >>message contains=20 >> >>>the token bucket parameter in a QOSM that is not understood. >>> >>> >>>>Other Parameters, like Path Latency,etc. are optional. If a QOSM=20 >>>>doesn't support it, it can be skipped. >>> >>> >>>Correct. >>> >>> >>> >>>>Mainly two types of parameters are left: Delay, Priority.=20 >> >>If supported=20 >> >>>>by two different QOSMs, the following mapping could be tried: >>>> >>>>Delay: can be mapped to , >>>Jitter>, >>>> >>>>Priority: , , >>>Priority>, >>>>Here should rather be derived from=20 >> >>=20 >> >>>>than vice versa, as is more complex. Or in=20 >> >>general the=20 >> >>>>simple parameters should be derived from the more complex one. >>> >>> >>>I do not quite follow this idea. >>> >>> >>>>The only problem I see: Do I know the QOSM of my neighbor=20 >> >>domain? Do I=20 >> >>>>have to consider this when sending the initiator QSPEC? >>> >>> >>>Note that you do not necessarily only need to know your neighoring=20 >>>domain. Consider the migration scenario where many networks don't=20 >>>understand the QoS signaling message at all. For example, you might=20 >>>consider the case where only the access networks inspect the NSIS=20 >>>signaling messages. >>> >>> >>>Ciao >>>Hannes >>> >>> >>>>Bernd >>>> >>>> >>>> >>>> >>>>Attila B=E1der (IJ/ETH) wrote: >>>> >>>> >>>>>Hi All, >>>>> >>>>>If "ignore" is not a type interpretation, I also think=20 >> >>that it should=20 >> >>>>>be reformulated. >>>>> >>>>>In general, to understend mandatory parameters that is=20 >> >>not used in a=20 >> >>>>>local QoSM, I see less problem. If a QOSM has to fill in=20 >> >>mandatory=20 >> >>>>>parameters that is not used in this QOSM, seems to be=20 >> >>more difficult. >> >>>>>Best regards, Attila >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>Sent: Monday, July 03, 2006 4:37 PM >>>>>>To: Georgios Karagiannis >>>>>>Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila B=E1der (IJ/ETH); >>>>>>nsis@ietf.org; 'Kappler Cornelia' >>>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>> >>>>>> >>>>>>Hi Georgios, >>>>>> >>>>>>please find my comment below: >>>>>> >>>>>>Georgios Karagiannis wrote: >>>>>> >>>>>> >>>>>>>Hi Jerry >>>>>>>Regarding your last point: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>Hannes: >>>>>>>>>Do you think it is awfully realistic for all QNEs to=20 >>>>>> >>>>>> >>>>>> >>>>>>understand all >>>>>> >>>>>> >>>>>>>>>mandatory parameters? I could imagine that Attila and=20 >> >>Georgios=20 >> >>>>>>>>>are not going to implement stateless interior QNEs in=20 >> >>such a way=20 >> >>>>>>>>>that they understand all the mandatory QSPEC=20 >> >>parameters. In fact=20 >> >>>>>>>>>they don't have todo it since only edge routers are likely to=20 >>>>>>>>>ever see QoS NSLP messages that contain QOSM IDs that=20 >> >>they do not=20 >> >>>>>>>>>understand (otherwise something go terribly wrong). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Jerry: It is up the RMD authors to specify how they want RMD >>>>>>>> >>>>>>>> >>>>>>>>>to behave wrt mandatory parameters (and obtain rough=20 >> >>consensus,=20 >> >>>>>>>>>of course). That is, if a mandatory parameter is=20 >> >>remapped and=20 >> >>>>>>>>>not strictly interpreted, the remapping must be=20 >> >>specified in the=20 >> >>>>>>>>>QOSM specification document. Otherwise, the QOSM=20 >> >>must strictly=20 >> >>>>>>>>>interpret the mandatory parameters that are not=20 >> >>remapped, if they=20 >> >>>>>>>>>are populated by the QNI. >>>>>>>>>There are no restrictions on how the remapping must=20 >> >>be done, it=20 >> >>>>>>>>>can be as simple as necessary (but no simpler). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>Georgios: >>>>>>>Jerry, I think that the point raised by Hannes is related to >>>>>>>how the QNE's interior to the RMD domain will have to=20 >> >>comply to the >> >>>>>>>mandatory descriptions specified in the QSPEC template. An=20 >>>>>>>interior QNE (in RMD-QOSM) will not process the end to=20 >> >>end QSpec.=20 >> >>>>>>>The only QSpec that will be processed by the interior=20 >> >>QNE is the=20 >> >>>>>>>RMD Qsepc that is initiated by the ingress node (i.e.,=20 >> >>QNI for the=20 >> >>>>>>>RMD local session). Note that the above observation is=20 >> >>valid for=20 >> >>>>>>>all local QOSMs. >>>>>>>However, the above is not allowed due to the following=20 >> >>text that is=20 >> >>>>>>>included in the QSpec template draft: >>>>>>> >>>>>>>"A QNE MUST interpret all mandatory parameters from this=20 >>>>>> >>>>>> >>>>>> >>>>>>document even >>>>>> >>>>>> >>>>>>>if it does not support the received QoS NSLP message with the=20 >>>>>>>indicated QOSM." >>>>>>> >>>>>>>Therefore, in my opinion it is required to modify the above=20 >>>>>> >>>>>> >>>>>> >>>>>>sentence in >>>>>> >>>>>> >>>>>>>something like: >>>>>>> >>>>>>>"A QNE SHOULD interpret all mandatory parameters from this=20 >>>>>> >>>>>> >>>>>> >>>>>>document even >>>>>> >>>>>> >>>>>>>if it does not support the received QoS NSLP message with the=20 >>>>>>>indicated QOSM. A QNE that supports a local QOSM, does not=20 >>>>>> >>>>>> >>>>>> >>>>>>have to interpret >>>>>> >>>>>> >>>>>>>all mandatory parameters carried by a QSpec that was=20 >>>>>> >>>>>> >>>>>> >>>>>>generated by a QNI >>>>>> >>>>>> >>>>>>>located outside the domain that supports the given local QOSM."=20 >>>>>> >>>>>> >>>>>> >>>>>>Something along these lines would probably be more=20 >> >>realistic, I guess. >> >>>>>>Ciao >>>>>>Hannes >>>>>> >>>>>> >>>>>> >>>>>>>Best regards, >>>>>>>Georgios >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] Sent:=20 >>>>>>>maandag 3 juli 2006 2:03 >>>>>>>To: Hannes Tschofenig >>>>>>>Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH);=20 >>>>>> >>>>>> >>>>>> >>>>>>nsis@ietf.org; >>>>>> >>>>>> >>>>>>>Kappler Cornelia >>>>>>>Subject: RE: [NSIS] draft-qosmodel-controlledload-04 >>>>>>> >>>>>>>Hi Hannes, >>>>>>> >>>>>>>See below. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>Sent: Saturday, July 01, 2006 4:26 PM >>>>>>>>To: Ash, Gerald R (Jerry), ALABS >>>>>>>>Cc: nsis@ietf.org >>>>>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>>>> >>>>>>>>Hi Jerry, >>>>>>>> >>>>>>>>it is true that I haven't read the most recent QSPEC draft=20 >>>>>> >>>>>> >>>>>> >>>>>>when I sent >>>>>> >>>>>> >>>>>>>>this mail. In the meanwhile I did. Please find a few=20 >> >>comments below: >> >>>>>>>>Ash, Gerald R (Jerry), ALABS wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Hi Hannes, >>>>>>>>> >>>>>>>>>See below. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>-----Original Message----- >>>>>>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>>Sent: Friday, June 30, 2006 8:43 AM >>>>>>>>>>To: Bernd Schloer >>>>>>>>>>Cc: nsis@ietf.org >>>>>>>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>>>>>> >>>>>>>>>>Hi Bernd, >>>>>>>>>> >>>>>>>>>>Bernd Schloer wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Hi, >>>>>>>>>>> >>>>>>>>>>>the first open issue in the appendix B is about=20 >> >>what to do with=20 >> >>>>>>>>>>>mandatory QSPEC parameters which are not needed for CLS. >>>>>>>>>>> >>>>>>>>>>>Does a QOSM have to understand (and provide information=20 >>>>>> >>>>>> >>>>>> >>>>>>about) all >>>>>> >>>>>> >>>>>>>>>>>mandatory parameters, even if they are not used? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>I think the question is wrong. What about the=20 >> >>following question: >> >>>>>>>>>>" >>>>>>>>>>Does a node that implements a particular QOSM has to=20 >>>>>> >>>>>> >>>>>> >>>>>>understand all >>>>>> >>>>>> >>>>>>>>>>mandatory parameters listed in the QSPEC template draft >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>(even if the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>QOSM does not make use of them)? >>>>>>>>>>" >>>>>>>>>>The answer would be "YES" since the QSPEC template draft=20 >>>>>> >>>>>> >>>>>> >>>>>>says that >>>>>> >>>>>> >>>>>>>>>>mandatory parameters have to be understood by every=20 >> >>NSIS QoS node. >> >>>>>>>>>>There is only the question what "understands" means. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>IMO you need to more carefully read the QSPEC I-D=20 >> >>document. All=20 >> >>>>>>>>>mandatory QSPEC parameters that are populated in the=20 >> >>QSPEC must=20 >> >>>>>>>>>be interpreted by every QNE, which is explained in=20 >> >>the QSPEC I-D: >> >>>>>>>>>It says in Section 4.4.1 (Mandatory and Optional QSPEC >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>. Parameters) of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>the QSPEC I-D >>>>>>>>>http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: >>>>>>>>> >>>>>>>>>" Mandatory QSPEC parameters are treated as follows: >>>>>>>>> >>>>>>>>> o A QNI SHOULD populate mandatory QSPEC parameters if >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>. applicable to >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> the underlying QOSM. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>I don't understand this sentence. What does it mean that a QNI=20 >>>>>>>>"SHOULD" >>>>>>>>populate parameters if applicable? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>It means that a QNI is not required to populate all=20 >>>>>> >>>>>> >>>>>> >>>>>>mandatory parameters. A >>>>>> >>>>>> >>>>>>>QNI would only populated a mandatory parameter if is used=20 >>>>>> >>>>>> >>>>>> >>>>>>by the QOSM >>>>>> >>>>>> >>>>>>>supported by the QNI. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> o QNEs MUST interpret mandatory QSPEC parameters, if=20 >> >>signaled." >> >>>>>>>>>Furthermore, it says in Section 4.2 (QSPEC Processing): >>>>>>>>> >>>>>>>>>" a QNE >>>>>>>>> MUST at least interpret all the mandatory parameters=20 >> >>in a QSPEC=20 >> >>>>>>>>>even >>>>>>>>> if it does not support the corresponding QOSM. >>>>>>>>> >>>>>>>>> Mandatory parameters provide a minimal subset of=20 >> >>parameters. A >> >>>>>>>>> QNE MUST either a) strictly interpret a mandatory=20 >> >>parameter, or >> >>>>>>>>> b) remap the parameter and raise the flag =20 >>>>>>>>>defined in >>>>>>>>> Section 5.1, where the remapping MUST be specified=20 >> >>in the QOSM >> >>>>>>>>> specification. Here the terminology 'strictly =20 >> >>interpret' means=20 >> >>>>>>>>>that >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>What is the difference between 'strictly interpret' and=20 >>>>>> >>>>>> >>>>>> >>>>>>'interpret'? >>>>>> >>>>>> >>>>>>>>In the rest of the document you use 'interpret'. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>'Strictly interpret' is defined in the text I quoted from=20 >>>>>> >>>>>> >>>>>> >>>>>>Section 4.2 (QSPEC >>>>>> >>>>>> >>>>>>>Processing), which is given again in the very next=20 >>>>>> >>>>>> >>>>>> >>>>>>sentences I quoted just >>>>>> >>>>>> >>>>>>>below (after you posed your above question :-) >>>>>>> >>>>>>>" Mandatory parameters provide a minimal subset of=20 >> >>parameters. A >> >>>>>>> QNE MUST either a) strictly interpret a mandatory=20 >> >>parameter, or >> >>>>>>> b) remap the parameter and raise the flag=20 >>>>>> >>>>>> >>>>>> >>>>>>defined in >>>>>> >>>>>> >>>>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>>>> specification. Here the terminology 'strictly=20 >>>>>> >>>>>> >>>>>> >>>>>>interpret' means that >>>>>> >>>>>> >>>>>>> the parameter is implemented according to the=20 >> >>commonly accepted >> >>>>>>> definition and/or as specified by references given=20 >> >>for each QSPEC >> >>>>>>> parameter. This means that in case a), a =20 >>>>>> >>>>>> >>>>>> >>>>>>parameter >>>>>> >>>>>> >>>>>>> must be strictly interpreted as a token bucket. =20 >>>>>> >>>>>> >>>>>> >>>>>>However, in case b), >>>>>> >>>>>> >>>>>>> a parameter may be remapped, perhaps to a=20 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> parameter." >>>>>>> >>>>>>>In the document, the term 'interpret' a mandatory parameter=20 >>>>>> >>>>>> >>>>>> >>>>>>means either a) >>>>>> >>>>>> >>>>>>>strictly interpret (as defined above), or b) remap (as=20 >>>>>> >>>>>> >>>>>> >>>>>>defined above). >>>>>> >>>>>> >>>>>>>Perhaps this can be made clearer in the text. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> the parameter is implemented according to the=20 >> >>commonly accepted >> >>>>>>>>> definition and/or as specified by references given for=20 >>>>>> >>>>>> >>>>>> >>>>>>each QSPEC >>>>>> >>>>>> >>>>>>>>> parameter. This means that in case a), a > >>Bucket> parameter >> >>>>>>>>> must be strictly interpreted as a token bucket. =20 >> >>However, in=20 >> >>>>>>>>>case b), >>>>>>>>> a parameter may be remapped, perhaps to a=20 >>>>>>>>> >>>>>>>>> parameter. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>I noticed this text improvement and I am happy to see more=20 >>>>>> >>>>>> >>>>>> >>>>>>text about >>>>>> >>>>>> >>>>>>>>it. >>>>>>>> >>>>>>>>Still, I have some issues with the section: >>>>>>>> >>>>>>>>I had a problem with this paragraph following the previous=20 >>>>>> >>>>>> >>>>>> >>>>>>one in the >>>>>> >>>>>> >>>>>>>>section. The previous paragraph said " >>>>>>>>However, if a QSPEC arrives at a QNE that does >>>>>>>> not support the QOSM being signaled, it can still=20 >> >>understand the >> >>>>>>>> QSPEC content, at least to a basic degree. >>>>>>>>" >>>>>>>> >>>>>>>>When I read through the text I got the impression that the two=20 >>>>>>>>sections relate to each other and in fact they do not.=20 >> >>Hence, I=20 >> >>>>>>>>suggest to delete the previous paragraph since this one=20 >>>>>> >>>>>> >>>>>> >>>>>>contains the >>>>>> >>>>>> >>>>>>>>info already. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>I'm unclear as to which paragraph/text you are=20 >> >>proposing to delete. >> >>>>>>> >>>>>>>>You >>>>>>>>might also want to delete the second paragraph as well=20 >>>>>> >>>>>> >>>>>> >>>>>>since it is far >>>>>> >>>>>> >>>>>>>>too obvious to use RFC2119 language: If you don't=20 >> >>support even a=20 >> >>>>>>>>single QOSM then why are you a QOS NSLP node in the=20 >> >>first place. >> >>>>>>> >>>>>>> >>>>>>> >>>>>>>I think it important to state that a QNE MUST support at=20 >>>>>> >>>>>> >>>>>> >>>>>>least one QOSM, >>>>>> >>>>>> >>>>>>>even if this is clearly necessary to effectively support=20 >>>>>> >>>>>> >>>>>> >>>>>>QoS-NSLP/QSPEC. >>>>>> >>>>>> >>>>>>>>You might want to highlight the following sentence, though: >>>>>>>> >>>>>>>>" >>>>>>>>A QNE MUST interpret all mandatory parameters from this=20 >>>>>> >>>>>> >>>>>> >>>>>>document even >>>>>> >>>>>> >>>>>>>>if it does not support the received QoS NSLP message with the=20 >>>>>>>>indicated QOSM. >>>>>>>>" >>>>>>>> >>>>>>>>Here is my proposal for the section: >>>>>>>> >>>>>>>>" >>>>>>>>4.2 QSPEC Processing >>>>>>>> >>>>>>>> The QSPEC is opaque to the QoS NSLP processing. The=20 >>>>>> >>>>>> >>>>>> >>>>>>QSPEC control >>>>>> >>>>>> >>>>>>>> information and the QoS description are interpreted=20 >> >>and MAY be >> >>>>>>>> modified by the RMF in a QNE (see description in [QoS-SIG]). >>>>>>>> >>>>>>>> The QSPEC contains a QOSM ID, i.e. information on=20 >> >>what QOSM is=20 >> >>>>>>>>being >>>>>>>> signaled by the QNI. However, if a QSPEC arrives at a QNE=20 >>>>>>>>that does >>>>>>>> not support the QOSM being signaled, it can still=20 >> >>understand the >> >>>>>>>> QSPEC content, at least to a basic degree. This is =20 >> >> because=20 >> >>>>>>>>mandatory >>>>>>>> parameters have been defined as a common language. =20 >> >> Therefore,=20 >> >>>>>>>>a QNE >>>>>>>> MUST at least interpret all the mandatory parameters in a =20 >>>>>>>>QSPEC even >>>>>>>> if it does not support the corresponding QOSM. >>>>>>>> >>>>>>>> A QNE MUST either >>>>>>>> >>>>>>>> a) interpret a mandatory parameter carried in the QSPEC=20 >>>>>> >>>>>> >>>>>> >>>>>>object, or >>>>>> >>>>>> >>>>>>>> b) remap the parameter and raise the flag =20 >>>>>>>>defined in >>>>>>>> Section 5.1, where the remapping MUST be specified=20 >> >>in the QOSM >> >>>>>>>> specification. >>>>>>>> >>>>>>>> Here the terminology 'interpret' means that >>>>>>>> the parameter is implemented according to the=20 >> >>references given=20 >> >>>>>>>>for each QSPEC parameter. >>>>>>>> >>>>>>>> If a QSPEC arrives at a QNE that does not support=20 >> >>the QOSM being >> >>>>>>>> signaled, it can still understand the QSPEC content, at=20 >>>>>> >>>>>> >>>>>> >>>>>>least to a >>>>>> >>>>>> >>>>>>>> basic degree. Hence, with case (a), a =20 >> >>parameter >> >>>>>>>> must be strictly interpreted as a token bucket. >>>>>>>> >>>>>>>> In case b), a parameter may be remapped, =20 >>>>>>>>perhaps to a >>>>>>>> parameter. >>>>>>>>" >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>I don't see any benefit in redefining what 'interpret'=20 >> >>means in the >> >>>>>>>document. As I mentioned above, the document uses the term=20 >>>>>> >>>>>> >>>>>> >>>>>>'interpret' to >>>>>> >>>>>> >>>>>>>mean that a mandatory parameter is 'interpreted' if is=20 >>>>>> >>>>>> >>>>>> >>>>>>either 'strictly >>>>>> >>>>>> >>>>>>>interpreted' or it is 'remapped' (where the remapping must=20 >>>>>> >>>>>> >>>>>> >>>>>>be defined in the >>>>>> >>>>>> >>>>>>>QOSM specification document). OTOH, it might be useful=20 >> >>to define a >> >>>>>>>'remapping' flag to indicated if a mandatory or optional=20 >>>>>> >>>>>> >>>>>> >>>>>>parameter has been >>>>>> >>>>>> >>>>>>>remapped by a QNE in the path. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Btw, have you noticed that the draft has >>>>>>>>* a flag (Section 5.1) >>>>>>>>* a parameter (Section 7.2.1) >>>>>>>> >>>>>>>>I think they refer to the same concept... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>Yes, good catch. is indeed intended to be a=20 >>>>>> >>>>>> >>>>>> >>>>>>flag, and >>>>>> >>>>>> >>>>>>>perhaps one of the QSPEC object flags defined in Section=20 >>>>>> >>>>>> >>>>>> >>>>>>7.1 could be used >>>>>> >>>>>> >>>>>>>for this purpose, rather than use a full 32-bit parameter=20 >>>>>> >>>>>> >>>>>> >>>>>>for this purpose, >>>>>> >>>>>> >>>>>>>as currently specified in Section 7.2.1. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> In the latter case, the remapping of the to >>>>>>>>> must be specified in the QOSM specification=20 >>>>>> >>>>>> >>>>>> >>>>>>document. >>>>>> >>>>>> >>>>>>>>> For example, QOSM X exclusively uses the parameter =20 >>>>>>>>>. It >>>>>>>>> must define a mapping of the mandatory parameter=20 >> >>. >> >>>>>>>>> The mapping consists of interpreting the Token Bucket Rate as >>>>>>>>> the parameter and disregarding the other=20 >>>>>> >>>>>> >>>>>> >>>>>>Token Bucket >>>>>> >>>>>> >>>>>>>>> parameters. Clearly, some information contained in=20 >> >>the > >>>>>>>>> Bucket> parameter is lost by this mapping, and the =20 >> >>resulting=20 >> >>>>>>>>>QoS may >>>>>>>>> not be quite what was intended by the QNI. =20 >> >>Therefore, QOSM X also >> >>>>>>>>> specifies that the flag be raised. =20 >> >>Thus, a QNE=20 >> >>>>>>>>>using >>>>>>>>> QOSM X is able to make an informed decision whether=20 >> >>to admit a >> >>>>>>>>> reservation described in terms of , and=20 >>>>>> >>>>>> >>>>>> >>>>>>at the same >>>>>> >>>>>> >>>>>>>>> time (by means of ) signals to the=20 >>>>>> >>>>>> >>>>>> >>>>>>QNI/QNR that the >>>>>> >>>>>> >>>>>>>>> exact intention of the QNI may not be met." >>>>>>>>> >>>>>>>>>I think this text is pretty clear as to what is required=20 >>>>>>>>>regarding interpreting mandatory parameters. If not, please=20 >>>>>>>>>suggest clarifications. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>The text in the new draft has improved a lot. >>>>>>>>Thanks for the update. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>Another possible question would be: >>>>>>>>>>" >>>>>>>>>>Does a node that implements a particular QOSM has to=20 >>>>>> >>>>>> >>>>>> >>>>>>define mappings >>>>>> >>>>>> >>>>>>>>>>from all mandatory parameters listed in the QSPEC=20 >>>>>> >>>>>> >>>>>> >>>>>>template draft to >>>>>> >>>>>> >>>>>>>>>>the QOSM draft (even if the QOSM does not make use >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>of them)? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>" >>>>>>>>>> >>>>>>>>>>The answer is "I don't know". >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>A QNE must interpret all mandatory parameters, if=20 >> >>populated, as >> >>>>>>>>>explained in the above text I quoted. If a QOSM re-maps a=20 >>>>>> >>>>>> >>>>>> >>>>>>mandatory >>>>>> >>>>>> >>>>>>>>>QSPEC parameter, that re-mapping must be defined in the QOSM >>>>>>>>>specification. As stated in Section 4.7 (QOSM Specification >>>>>>>>>Requirements): >>>>>>>>> >>>>>>>>>" A QOSM specification MUST define QSPEC parameter =20 >> >>behavior=20 >> >>>>>>>>>for these >>>>>>>>> cases: a) new optional QSPEC parameters the QOSM=20 >> >>specification >> >>>>>>>>> defines, and b) remapping of existing mandatory or=20 >>>>>> >>>>>> >>>>>> >>>>>>optional QSPEC >>>>>> >>>>>> >>>>>>>>> parameters, as described in Section 4.2. Unless otherwise=20 >>>>>>>>>specified >>>>>>>>> in the QOSM specification document, the behaviors to strictly >>>>>>>>> interpret the mandatory and optional QSPEC parameters are=20 >>>>>>>>>defined in >>>>>>>>> this document through the references to RFCs that =20 >> >>precisely define >> >>>>>>>>> the QSPEC parameter behaviors. A QOSM specification=20 >> >>MUST define=20 >> >>>>>>>>>how the mandatory parameters are to >>>>>>>>> be mapped onto the QSPEC parameters used by the QOSM,=20 >>>>>> >>>>>> >>>>>> >>>>>>however the >>>>>> >>>>>> >>>>>>>>> mapping MAY result in slight modification to the intended >>>>>>>>> specification when an exact mapping is not possible. This=20 >>>>>>>>>definition >>>>>>>>> MUST allow a QNE implementing this QOSM to make a=20 >> >>decision as to >> >>>>>>>>> whether a reservation described in terms of mandatory =20 >>>>>>>>>parameters can >>>>>>>>> be admitted. If for a particular mandatory parameter no =20 >>>>>>>>>mapping can >>>>>>>>> be found that guarantees the desired QoS, the QNE is=20 >> >> advised to=20 >> >>>>>>>>>raise >>>>>>>>> the flag. In other words, for all mandatory >>>>>>>>> parameters a mapping must be defined, but it is=20 >>>>>> >>>>>> >>>>>> >>>>>>acknowledged that >>>>>> >>>>>> >>>>>>>>> this mapping may result in slightly bending the original=20 >>>>>>>>> intention of >>>>>>>>> the QNI." >>>>>>>>> >>>>>>>>>I think this text is pretty clear as to what is=20 >> >>required. If not, >> >>>>>>>>>please suggest clarifications. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>I understood the token bucket to bandwidth example. >>>>>>>> >>>>>>>>Would the RMD draft, for example, list all mandatory=20 >> >>parameters=20 >> >>>>>>>>and indicate whether it can map them (and how) to=20 >> >>parameters used=20 >> >>>>>>>>in the RMD specification? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>As stated in the QOSM specification requirements in Section=20 >>>>>> >>>>>> >>>>>> >>>>>>4.7, if a QOSM >>>>>> >>>>>> >>>>>>>remaps a mandatory parameter, the remapping must be defined=20 >>>>>> >>>>>> >>>>>> >>>>>>in the QOSM >>>>>> >>>>>> >>>>>>>specification document. If no such remapping is defined,=20 >>>>>> >>>>>> >>>>>> >>>>>>the default >>>>>> >>>>>> >>>>>>>behavior is that the QOSM must strictly interpret the=20 >>>>>> >>>>>> >>>>>> >>>>>>mandatory parameter, >>>>>> >>>>>> >>>>>>>as defined above. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Do you think it is awfully realistic for all QNEs to=20 >> >>understand=20 >> >>>>>>>>all mandatory parameters? I could imagine that Attila=20 >> >>and Georgios=20 >> >>>>>>>>are not going to implement stateless interior QNEs in=20 >> >>such a way=20 >> >>>>>>>>that they understand all the mandatory QSPEC=20 >> >>parameters. In fact=20 >> >>>>>>>>they don't have todo it since only edge routers are=20 >> >>likely to ever=20 >> >>>>>>>>see QoS NSLP messages that contain QOSM IDs that they do not=20 >>>>>>>>understand (otherwise something go terribly wrong). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>It is up the RMD authors to specify how they want RMD=20 >> >>to behave wrt >> >>>>>>>mandatory parameters (and obtain rough consensus, of=20 >>>>>> >>>>>> >>>>>> >>>>>>course). That is, if a >>>>>> >>>>>> >>>>>>>mandatory parameter is remapped and not strictly=20 >>>>>> >>>>>> >>>>>> >>>>>>interpreted, the remapping >>>>>> >>>>>> >>>>>>>must be specified in the QOSM specification document. =20 >>>>>> >>>>>> >>>>>> >>>>>>Otherwise, the QOSM >>>>>> >>>>>> >>>>>>>must strictly interpret the mandatory parameters that are=20 >>>>>> >>>>>> >>>>>> >>>>>>not remapped, if >>>>>> >>>>>> >>>>>>>they are populated by the QNI. >>>>>>> >>>>>>>There are no restrictions on how the remapping must be=20 >>>>>> >>>>>> >>>>>> >>>>>>done, it can be as >>>>>> >>>>>> >>>>>>>simple as necessary (but no simpler). >>>>>>> >>>>>>>Thanks, >>>>>>>Jerry >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Ciao >>>>>>>>Hannes >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Thanks, >>>>>>>>>Jerry >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>Ciao >>>>>>>>>>Hannes >>>>>>>>>> >>>>>>>>>>The QSPEC-draft says in section 5 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>that >>>>>>>>>>>all parameters listed in the next sections are=20 >> >>mandatory. The=20 >> >>>>>>>>>>>QSPEC-draft also >>>>>>>>>>>says in section 4.1 that "a given QOSM defines which of the=20 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>mandatory and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>optional parameters it uses, ..." >>>>>>>>>>> >>>>>>>>>>>Are there any specific parameters which makes the open=20 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>issue B.1.1. >>>>>>>> >>>>>>>> >>>>>>>>>>>clearer? Following the QSPEC-draft there doesn't seem to be=20 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>a conflict, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>if nothing is >>>>>>>>>>>done with the unneeded parameters. >>>>>>>>>>> >>>>>>>>>>>Thanks, >>>>>>>>>>>Bernd >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>nsis mailing list >>>>>>>nsis@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>nsis mailing list >>>>>nsis@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>> >>>> >>>> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 08:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxk15-0000AE-Sf; Tue, 04 Jul 2006 08:28:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxk14-0000A9-Jw for nsis@ietf.org; Tue, 04 Jul 2006 08:28:34 -0400 Received: from natreg.rzone.de ([81.169.145.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxk13-00048e-JP for nsis@ietf.org; Tue, 04 Jul 2006 08:28:34 -0400 Received: from [192.168.178.200] (p5484B402.dip0.t-ipconnect.de [84.132.180.2]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k64CS9Lu010291; Tue, 4 Jul 2006 14:28:10 +0200 (MEST) Message-ID: <44AA5E38.90302@cs.uni-goettingen.de> Date: Tue, 04 Jul 2006 14:25:28 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <002501c69f52$f2090590$4c0d5982@dynamic.ewi.utwente.nl> <44AA4ED7.3030007@schloer.net> In-Reply-To: <44AA4ED7.3030007@schloer.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: e954f05237973402164cd206a863a135 Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , 'Kappler Cornelia' , nsis@ietf.org, =?ISO-8859-1?Q?=22=27Attila_B=E1der_=28IJ/ETH=29=27=22?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, the ping tool should be extended by these features: - delay variation (is this the same as jitter?) - loss ratio Every QNE could then support , , ,=20 , , , Bernd Bernd Schloer wrote: > Hi Georgios, >=20 > maybe two parameters. We could also integrate the ping tool so that=20 > every QNE can provide information about the Path Latency. But how does = > fit in there? CLS is not using it, e.g. >=20 > Bernd >=20 >=20 > Georgios Karagiannis wrote: >=20 >> Hi Bernd >> >> Are you proposing that the only mandory parameter should be: >> =3D >> Best Regards, >> Georgios >> >> -----Original Message----- >> From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] Sent:=20 >> dinsdag 4 juli 2006 0:14 >> To: "Attila B=E1der (IJ/ETH)" >> Cc: Hannes Tschofenig; Georgios Karagiannis; Ash, Gerald R (Jerry),=20 >> ALABS; >> nsis@ietf.org; Kappler Cornelia >> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >> >> Hi all, >> >> just an idea: >> >> Token Bucket is the only mandatory parameter. It is interpreted by CLS= =20 >> and >> Y.1541. RMD can map it to Bandwidth. >> >> Other Parameters, like Path Latency,etc. are optional. If a QOSM doesn= 't >> support it, it can be skipped. >> >> Mainly two types of parameters are left: Delay, Priority. If supported= by >> two different QOSMs, the following mapping could be tried: >> >> Delay: can be mapped to , , >> >> >> Priority: , , > Priority>, >> >> Here should rather be derived from = =20 >> than >> vice versa, as is more complex. Or in general the simpl= e >> parameters should be derived from the more complex one. >> >> The only problem I see: Do I know the QOSM of my neighbor domain? Do I= =20 >> have >> to consider this when sending the initiator QSPEC? >> >> Bernd >> >> >> >> >> Attila B=E1der (IJ/ETH) wrote: >> >>> Hi All, >>> >>> If "ignore" is not a type interpretation, I also think that it should= be >> >> >> reformulated. >> >>> In general, to understend mandatory parameters that is not used in a = >>> local >> >> >> QoSM, I see less problem. If a QOSM has to fill in mandatory=20 >> parameters that >> is not used in this QOSM, seems to be more difficult. >> >>> Best regards, Attila >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, July 03, 2006 4:37 PM >>>> To: Georgios Karagiannis >>>> Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila B=E1der (IJ/ETH);=20 >>>> nsis@ietf.org; 'Kappler Cornelia' >>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>> >>>> >>>> Hi Georgios, >>>> >>>> please find my comment below: >>>> >>>> Georgios Karagiannis wrote: >>>> >>>> >>>>> Hi Jerry >>>>> >>>>> Regarding your last point: >>>>> >>>>> >>>>> >>>>>>> Hannes: >>>>>>> Do you think it is awfully realistic for all QNEs to >>>> >>>> >>>> understand all >>>> >>>> >>>>>>> mandatory parameters? I could imagine that Attila and Georgios=20 >>>>>>> are not going to implement stateless interior QNEs in such a way = >>>>>>> that they understand all the mandatory QSPEC parameters. In fact = >>>>>>> they don't have todo it since only edge routers are likely to=20 >>>>>>> ever see QoS NSLP messages that contain QOSM IDs that they do not= =20 >>>>>>> understand (otherwise something go terribly wrong). >>>>> >>>>> >>>>> >>>>>> Jerry: It is up the RMD authors to specify how they want RMD >>>>>> >>>>>> >>>>>> >>>>>>> to behave wrt mandatory parameters (and obtain rough consensus,=20 >>>>>>> of course). That is, if a mandatory parameter is remapped and=20 >>>>>>> not strictly interpreted, the remapping must be specified in the = >>>>>>> QOSM specification document. >>>>>>> Otherwise, the QOSM must strictly interpret the mandatory=20 >>>>>>> parameters that are not remapped, if they are populated by the QN= I. >>>>>>> There are no restrictions on how the remapping must be done, it=20 >>>>>>> can be as simple as necessary (but no simpler). >>>>> >>>>> >>>>> >>>>> Georgios: >>>>> Jerry, I think that the point raised by Hannes is related to how=20 >>>>> the QNE's interior to the RMD domain will have to comply to the=20 >>>>> mandatory descriptions specified in the QSPEC template. >>>>> An interior QNE (in RMD-QOSM) will not process the end to end=20 >>>>> QSpec. The only QSpec that will be processed by the interior QNE is= =20 >>>>> the RMD Qsepc that is initiated by the ingress node (i.e., QNI for = >>>>> the RMD local session). >>>>> Note that the above observation is valid for all local QOSMs. >>>>> However, the above is not allowed due to the following text that is= =20 >>>>> included in the QSpec template draft: >>>>> >>>>> "A QNE MUST interpret all mandatory parameters from this >>>> >>>> >>>> document even >>>> >>>> >>>>> if it does not support the received QoS NSLP message with the=20 >>>>> indicated QOSM." >>>>> >>>>> Therefore, in my opinion it is required to modify the above >>>> >>>> >>>> sentence in >>>> >>>> >>>>> something like: >>>>> >>>>> "A QNE SHOULD interpret all mandatory parameters from this >>>> >>>> >>>> document even >>>> >>>> >>>>> if it does not support the received QoS NSLP message with the=20 >>>>> indicated QOSM. A QNE that supports a local QOSM, does not >>>> >>>> >>>> have to interpret >>>> >>>> >>>>> all mandatory parameters carried by a QSpec that was >>>> >>>> >>>> generated by a QNI >>>> >>>> >>>>> located outside the domain that supports the given local QOSM."=20 >>>> >>>> >>>> Something along these lines would probably be more realistic, I gues= s. >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>>> Best regards, >>>>> Georgios >>>>> >>>>> -----Original Message----- >>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>>>> Sent: maandag 3 juli 2006 2:03 >>>>> To: Hannes Tschofenig >>>>> Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH); >>>> >>>> >>>> nsis@ietf.org; >>>> >>>> >>>>> Kappler Cornelia >>>>> Subject: RE: [NSIS] draft-qosmodel-controlledload-04 >>>>> >>>>> Hi Hannes, >>>>> >>>>> See below. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Saturday, July 01, 2006 4:26 PM >>>>>> To: Ash, Gerald R (Jerry), ALABS >>>>>> Cc: nsis@ietf.org >>>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>> >>>>>> Hi Jerry, >>>>>> >>>>>> it is true that I haven't read the most recent QSPEC draft >>>> >>>> >>>> when I sent >>>> >>>> >>>>>> this mail. In the meanwhile I did. Please find a few comments belo= w: >>>>>> >>>>>> Ash, Gerald R (Jerry), ALABS wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi Hannes, >>>>>>> >>>>>>> See below. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>> Sent: Friday, June 30, 2006 8:43 AM >>>>>>>> To: Bernd Schloer >>>>>>>> Cc: nsis@ietf.org >>>>>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>>>> >>>>>>>> Hi Bernd, >>>>>>>> >>>>>>>> Bernd Schloer wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> the first open issue in the appendix B is about what to do with= =20 >>>>>>>>> mandatory QSPEC parameters which are not needed for CLS. >>>>>>>>> >>>>>>>>> Does a QOSM have to understand (and provide information >>>> >>>> >>>> about) all >>>> >>>> >>>>>>>>> mandatory parameters, even if they are not used? >>>>>>>> >>>>>>>> >>>>>>>> I think the question is wrong. What about the following question= : >>>>>>>> " >>>>>>>> Does a node that implements a particular QOSM has to >>>> >>>> >>>> understand all >>>> >>>> >>>>>>>> mandatory parameters listed in the QSPEC template draft >>>>>> >>>>>> >>>>>> (even if the >>>>>> >>>>>> >>>>>> >>>>>>>> QOSM does not make use of them)? >>>>>>>> " >>>>>>>> The answer would be "YES" since the QSPEC template draft >>>> >>>> >>>> says that >>>> >>>> >>>>>>>> mandatory parameters have to be understood by every NSIS QoS nod= e. >>>>>>>> >>>>>>>> There is only the question what "understands" means. >>>>>>> >>>>>>> >>>>>>> >>>>>>> IMO you need to more carefully read the QSPEC I-D document. All = >>>>>>> mandatory QSPEC parameters that are populated in the QSPEC must=20 >>>>>>> be interpreted by every QNE, which is explained in the QSPEC I-D:= >>>>>>> >>>>>>> It says in Section 4.4.1 (Mandatory and Optional QSPEC >>>>>> >>>>>> >>>>>> . Parameters) of >>>>>> >>>>>> >>>>>> >>>>>>> the QSPEC I-D >>>>>>> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: >>>>>>> >>>>>>> " Mandatory QSPEC parameters are treated as follows: >>>>>>> >>>>>>> o A QNI SHOULD populate mandatory QSPEC parameters if >>>>>> >>>>>> >>>>>> . applicable to >>>>>> >>>>>> >>>>>> >>>>>>> the underlying QOSM. >>>>>> >>>>>> >>>>>> I don't understand this sentence. What does it mean that a QNI=20 >>>>>> "SHOULD" >>>>>> populate parameters if applicable? >>>>> >>>>> >>>>> >>>>> It means that a QNI is not required to populate all >>>> >>>> >>>> mandatory parameters. A >>>> >>>> >>>>> QNI would only populated a mandatory parameter if is used >>>> >>>> >>>> by the QOSM >>>> >>>> >>>>> supported by the QNI. >>>>> >>>>> >>>>> >>>>> >>>>>>> o QNEs MUST interpret mandatory QSPEC parameters, if signaled." >>>>>>> >>>>>>> Furthermore, it says in Section 4.2 (QSPEC Processing): >>>>>>> >>>>>>> " a QNE >>>>>>> MUST at least interpret all the mandatory parameters in >>>>>>> a QSPEC even >>>>>>> if it does not support the corresponding QOSM. >>>>>>> >>>>>>> Mandatory parameters provide a minimal subset of parameters. A =20 >>>>>>> QNE MUST either a) strictly interpret a mandatory parameter, or >>>>>>> b) remap the parameter and raise the flag defined= =20 >>>>>>> in Section 5.1, where the remapping MUST be specified in the=20 >>>>>>> QOSM specification. Here the terminology 'strictly interpret' = >>>>>>> means that >>>>>> >>>>>> >>>>>> What is the difference between 'strictly interpret' and >>>> >>>> >>>> 'interpret'? >>>> >>>>>> In the rest of the document you use 'interpret'. >>>>> >>>>> >>>>> >>>>> 'Strictly interpret' is defined in the text I quoted from >>>> >>>> >>>> Section 4.2 (QSPEC >>>> >>>> >>>>> Processing), which is given again in the very next >>>> >>>> >>>> sentences I quoted just >>>> >>>> >>>>> below (after you posed your above question :-) >>>>> >>>>> " Mandatory parameters provide a minimal subset of parameters. A >>>>> QNE MUST either a) strictly interpret a mandatory parameter, or >>>>> b) remap the parameter and raise the flag >>>> >>>> >>>> defined in >>>> >>>> >>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>> specification. Here the terminology 'strictly >>>> >>>> >>>> interpret' means that >>>> >>>> >>>>> the parameter is implemented according to the commonly accepted >>>>> definition and/or as specified by references given for each QSPEC >>>>> parameter. This means that in case a), a >>>> >>>> >>>> parameter >>>> >>>> >>>>> must be strictly interpreted as a token bucket. =20 >>>> >>>> >>>> However, in case b), >>>> >>>> >>>>> a parameter may be remapped, perhaps to a >>>> >>>> >>>> >>>> >>>>> parameter." >>>>> >>>>> In the document, the term 'interpret' a mandatory parameter >>>> >>>> >>>> means either a) >>>> >>>> >>>>> strictly interpret (as defined above), or b) remap (as >>>> >>>> >>>> defined above). >>>> >>>> >>>>> Perhaps this can be made clearer in the text. >>>>> >>>>> >>>>> >>>>> >>>>>>> the parameter is implemented according to the commonly accepted = >>>>>>> definition and/or as specified by references given for >>>> >>>> >>>> each QSPEC >>>> >>>> >>>>>>> parameter. This means that in case a), a =20 >>>>>>> parameter must be strictly interpreted as a token bucket. >>>>>>> However, in case b), >>>>>>> a parameter may be remapped, perhaps to a =20 >>>>>>> parameter. >>>>>> >>>>>> >>>>>> I noticed this text improvement and I am happy to see more >>>> >>>> >>>> text about >>>> >>>> >>>>>> it. >>>>>> >>>>>> Still, I have some issues with the section: >>>>>> >>>>>> I had a problem with this paragraph following the previous >>>> >>>> >>>> one in the >>>> >>>> >>>>>> section. The previous paragraph said " >>>>>> However, if a QSPEC arrives at a QNE that does >>>>>> not support the QOSM being signaled, it can still understand the >>>>>> QSPEC content, at least to a basic degree. >>>>>> " >>>>>> >>>>>> When I read through the text I got the impression that the two=20 >>>>>> sections relate to each other and in fact they do not. Hence, I=20 >>>>>> suggest to delete the previous paragraph since this one >>>> >>>> >>>> contains the >>>> >>>> >>>>>> info already. >>>>> >>>>> >>>>> >>>>> I'm unclear as to which paragraph/text you are proposing to delete.= >>>>> >>>>> >>>>> >>>>> >>>>>> You >>>>>> might also want to delete the second paragraph as well >>>> >>>> >>>> since it is far >>>> >>>> >>>>>> too obvious to use RFC2119 language: If you don't support even a=20 >>>>>> single QOSM then why are you a QOS NSLP node in the first place. >>>>> >>>>> >>>>> >>>>> I think it important to state that a QNE MUST support at >>>> >>>> >>>> least one QOSM, >>>> >>>> >>>>> even if this is clearly necessary to effectively support >>>> >>>> >>>> QoS-NSLP/QSPEC. >>>> >>>> >>>>>> You might want to highlight the following sentence, though: >>>>>> >>>>>> " >>>>>> A QNE MUST interpret all mandatory parameters from this >>>> >>>> >>>> document even >>>> >>>> >>>>>> if it does not support the received QoS NSLP message with the=20 >>>>>> indicated QOSM. >>>>>> " >>>>>> >>>>>> Here is my proposal for the section: >>>>>> >>>>>> " >>>>>> 4.2 QSPEC Processing >>>>>> >>>>>> The QSPEC is opaque to the QoS NSLP processing. The >>>> >>>> >>>> QSPEC control >>>> >>>> >>>>>> information and the QoS description are interpreted and MAY be >>>>>> modified by the RMF in a QNE (see description in [QoS-SIG]). >>>>>> >>>>>> The QSPEC contains a QOSM ID, i.e. information on what QOSM is=20 >>>>>> being >>>>>> signaled by the QNI. However, if a QSPEC arrives at a QNE that = >>>>>> does >>>>>> not support the QOSM being signaled, it can still understand the >>>>>> QSPEC content, at least to a basic degree. This is because=20 >>>>>> mandatory >>>>>> parameters have been defined as a common language. Therefore, a= =20 >>>>>> QNE >>>>>> MUST at least interpret all the mandatory parameters in a QSPEC = >>>>>> even >>>>>> if it does not support the corresponding QOSM. >>>>>> >>>>>> A QNE MUST either >>>>>> >>>>>> a) interpret a mandatory parameter carried in the QSPEC >>>> >>>> >>>> object, or >>>> >>>> >>>>>> b) remap the parameter and raise the flag defined= in >>>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>>> specification. >>>>>> >>>>>> Here the terminology 'interpret' means that >>>>>> the parameter is implemented according to the references given=20 >>>>>> for each QSPEC parameter. >>>>>> >>>>>> If a QSPEC arrives at a QNE that does not support the QOSM being >>>>>> signaled, it can still understand the QSPEC content, at >>>> >>>> >>>> least to a >>>> >>>> >>>>>> basic degree. Hence, with case (a), a parameter >>>>>> must be strictly interpreted as a token bucket. >>>>>> >>>>>> In case b), a parameter may be remapped, perhaps = >>>>>> to a >>>>>> parameter. >>>>>> " >>>>> >>>>> >>>>> >>>>> I don't see any benefit in redefining what 'interpret' means in the= =20 >>>>> document. As I mentioned above, the document uses the term >>>> >>>> >>>> 'interpret' to >>>> >>>> >>>>> mean that a mandatory parameter is 'interpreted' if is >>>> >>>> >>>> either 'strictly >>>> >>>> >>>>> interpreted' or it is 'remapped' (where the remapping must >>>> >>>> >>>> be defined in the >>>> >>>> >>>>> QOSM specification document). OTOH, it might be useful to define a= =20 >>>>> 'remapping' flag to indicated if a mandatory or optional >>>> >>>> >>>> parameter has been >>>> >>>> >>>>> remapped by a QNE in the path. >>>>> >>>>> >>>>> >>>>> >>>>>> Btw, have you noticed that the draft has >>>>>> * a flag (Section 5.1) >>>>>> * a parameter (Section 7.2.1) >>>>>> >>>>>> I think they refer to the same concept... >>>>> >>>>> >>>>> >>>>> Yes, good catch. is indeed intended to be a >>>> >>>> >>>> flag, and >>>> >>>> >>>>> perhaps one of the QSPEC object flags defined in Section >>>> >>>> >>>> 7.1 could be used >>>> >>>> >>>>> for this purpose, rather than use a full 32-bit parameter >>>> >>>> >>>> for this purpose, >>>> >>>> >>>>> as currently specified in Section 7.2.1. >>>>> >>>>> >>>>> >>>>> >>>>>>> In the latter case, the remapping of the to =20 >>>>>>> must be specified in the QOSM specification >>>> >>>> >>>> document. >>>> >>>> >>>>>>> For example, QOSM X exclusively uses the parameter . = =20 >>>>>>> It must define a mapping of the mandatory parameter . >>>>>>> The mapping consists of interpreting the Token Bucket Rate as =20 >>>>>>> the parameter and disregarding the other >>>> >>>> >>>> Token Bucket >>>> >>>> >>>>>>> parameters. Clearly, some information contained in the >>>>>> Bucket> parameter is lost by this mapping, and the resulting QoS= =20 >>>>>>> may not be quite what was intended by the QNI. Therefore, QOSM= =20 >>>>>>> X also specifies that the flag be raised. Thus, = =20 >>>>>>> a QNE using QOSM X is able to make an informed decision whether = >>>>>>> to admit a reservation described in terms of , and= >>>> >>>> >>>> at the same >>>> >>>> >>>>>>> time (by means of ) signals to the >>>> >>>> >>>> QNI/QNR that the >>>> >>>> >>>>>>> exact intention of the QNI may not be met." >>>>>>> >>>>>>> I think this text is pretty clear as to what is required=20 >>>>>>> regarding interpreting mandatory parameters. If not, please=20 >>>>>>> suggest clarifications. >>>>>> >>>>>> >>>>>> The text in the new draft has improved a lot. >>>>>> Thanks for the update. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> Another possible question would be: >>>>>>>> " >>>>>>>> Does a node that implements a particular QOSM has to >>>> >>>> >>>> define mappings >>>> >>>> >>>>>>>> from all mandatory parameters listed in the QSPEC >>>> >>>> >>>> template draft to >>>> >>>> >>>>>>>> the QOSM draft (even if the QOSM does not make use >>>>>> >>>>>> >>>>>> of them)? >>>>>> >>>>>> >>>>>> >>>>>>>> " >>>>>>>> >>>>>>>> The answer is "I don't know". >>>>>>> >>>>>>> >>>>>>> >>>>>>> A QNE must interpret all mandatory parameters, if populated, as=20 >>>>>>> explained in the above text I quoted. If a QOSM re-maps a >>>> >>>> >>>> mandatory >>>> >>>> >>>>>>> QSPEC parameter, that re-mapping must be defined in the QOSM=20 >>>>>>> specification. As stated in Section 4.7 (QOSM Specification >>>>>>> Requirements): >>>>>>> >>>>>>> " A QOSM specification MUST define QSPEC parameter behavior for= =20 >>>>>>> these >>>>>>> cases: a) new optional QSPEC parameters the QOSM specification >>>>>>> defines, and b) remapping of existing mandatory or >>>> >>>> >>>> optional QSPEC >>>> >>>> >>>>>>> parameters, as described in Section 4.2. Unless otherwise=20 >>>>>>> specified in the QOSM specification document, the behaviors to=20 >>>>>>> strictly interpret the mandatory and optional QSPEC parameters = >>>>>>> are defined in this document through the references to RFCs=20 >>>>>>> that precisely define the QSPEC parameter behaviors. >>>>>>> >>>>>>> A QOSM specification MUST define how the mandatory parameters=20 >>>>>>> are to be mapped onto the QSPEC parameters used by the QOSM, >>>> >>>> >>>> however the >>>> >>>> >>>>>>> mapping MAY result in slight modification to the intended =20 >>>>>>> specification when an exact mapping is not possible. >>>>>>> This definition >>>>>>> MUST allow a QNE implementing this QOSM to make a decision as to = =20 >>>>>>> whether a reservation described in terms of mandatory parameters= =20 >>>>>>> can be admitted. If for a particular mandatory parameter no =20 >>>>>>> mapping can be found that guarantees the desired QoS, the QNE=20 >>>>>>> is advised to raise the flag. In other words,=20 >>>>>>> for all mandatory parameters a mapping must be defined, but it i= s >>>> >>>> >>>> acknowledged that >>>> >>>> >>>>>>> this mapping may result in slightly bending the original =20 >>>>>>> intention of the QNI." >>>>>>> >>>>>>> I think this text is pretty clear as to what is required. If=20 >>>>>>> not, please suggest clarifications. >>>>>> >>>>>> >>>>>> I understood the token bucket to bandwidth example. >>>>>> >>>>>> Would the RMD draft, for example, list all mandatory parameters=20 >>>>>> and indicate whether it can map them (and how) to parameters used = >>>>>> in the RMD specification? >>>>> >>>>> >>>>> >>>>> As stated in the QOSM specification requirements in Section >>>> >>>> >>>> 4.7, if a QOSM >>>> >>>> >>>>> remaps a mandatory parameter, the remapping must be defined >>>> >>>> >>>> in the QOSM >>>> >>>> >>>>> specification document. If no such remapping is defined, >>>> >>>> >>>> the default >>>> >>>> >>>>> behavior is that the QOSM must strictly interpret the >>>> >>>> >>>> mandatory parameter, >>>> >>>> >>>>> as defined above. >>>>> >>>>> >>>>> >>>>> >>>>>> Do you think it is awfully realistic for all QNEs to understand=20 >>>>>> all mandatory parameters? I could imagine that Attila and Georgios= =20 >>>>>> are not going to implement stateless interior QNEs in such a way=20 >>>>>> that they understand all the mandatory QSPEC parameters. In fact=20 >>>>>> they don't have todo it since only edge routers are likely to ever= =20 >>>>>> see QoS NSLP messages that contain QOSM IDs that they do not=20 >>>>>> understand (otherwise something go terribly wrong). >>>>> >>>>> >>>>> >>>>> It is up the RMD authors to specify how they want RMD to behave wrt= =20 >>>>> mandatory parameters (and obtain rough consensus, of >>>> >>>> >>>> course). That is, if a >>>> >>>> >>>>> mandatory parameter is remapped and not strictly >>>> >>>> >>>> interpreted, the remapping >>>> >>>> >>>>> must be specified in the QOSM specification document. =20 >>>> >>>> >>>> Otherwise, the QOSM >>>> >>>> >>>>> must strictly interpret the mandatory parameters that are >>>> >>>> >>>> not remapped, if >>>> >>>> >>>>> they are populated by the QNI. >>>>> >>>>> There are no restrictions on how the remapping must be >>>> >>>> >>>> done, it can be as >>>> >>>> >>>>> simple as necessary (but no simpler). >>>>> >>>>> Thanks, >>>>> Jerry >>>>> >>>>> >>>>> >>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Jerry >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Ciao >>>>>>>> Hannes >>>>>>>> >>>>>>>> The QSPEC-draft says in section 5 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> that >>>>>>>>> all parameters listed in the next sections are mandatory. The=20 >>>>>>>>> QSPEC-draft also says in section 4.1 that "a given QOSM defines= =20 >>>>>>>>> which of the >>>>>>>> >>>>>>>> >>>>>>>> mandatory and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> optional parameters it uses, ..." >>>>>>>>> >>>>>>>>> Are there any specific parameters which makes the open >>>>>> >>>>>> >>>>>> issue B.1.1. >>>>>> >>>>>> >>>>>>>>> clearer? Following the QSPEC-draft there doesn't seem to be >>>>>>>> >>>>>>>> >>>>>>>> a conflict, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> if nothing is >>>>>>>>> done with the unneeded parameters. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bernd >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> nsis mailing list >>>>> nsis@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>>> >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> >> >> >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 09:18:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxknk-0008Ak-Mv; Tue, 04 Jul 2006 09:18:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxkni-0008Ac-U3 for nsis@ietf.org; Tue, 04 Jul 2006 09:18:50 -0400 Received: from natreg.rzone.de ([81.169.145.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxkne-0001dF-SF for nsis@ietf.org; Tue, 04 Jul 2006 09:18:50 -0400 Received: from [192.168.178.200] (p5484B402.dip0.t-ipconnect.de [84.132.180.2]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k64DIVBf017487; Tue, 4 Jul 2006 15:18:32 +0200 (MEST) Message-ID: <44AA6A06.8090304@cs.uni-goettingen.de> Date: Tue, 04 Jul 2006 15:15:50 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <002501c69f52$f2090590$4c0d5982@dynamic.ewi.utwente.nl> <44AA4ED7.3030007@schloer.net> <44AA5E38.90302@cs.uni-goettingen.de> In-Reply-To: <44AA5E38.90302@cs.uni-goettingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: e5f266f4274da5f9c358642fb34e0d4b Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , =?ISO-8859-1?Q?=22=27Attila_B=E1der_=28IJ/ETH=29=27=22?= , nsis@ietf.org, 'Kappler Cornelia' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, a QOSM GS might also be supported then. Bernd Bernd Schloer wrote: > Hi all, >=20 > the ping tool should be extended by these features: >=20 > - delay variation (is this the same as jitter?) > - loss ratio >=20 > Every QNE could then support , , Jitter>, , , , >=20 > Bernd >=20 >=20 > Bernd Schloer wrote: >=20 >> Hi Georgios, >> >> maybe two parameters. We could also integrate the ping tool so that=20 >> every QNE can provide information about the Path Latency. But how does= =20 >> fit in there? CLS is not using it, e.g. >> >> Bernd >> >> >> Georgios Karagiannis wrote: >> >>> Hi Bernd >>> >>> Are you proposing that the only mandory parameter should be: >>> =3D >>> Best Regards, >>> Georgios >>> >>> -----Original Message----- >>> From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] Sent:=20 >>> dinsdag 4 juli 2006 0:14 >>> To: "Attila B=E1der (IJ/ETH)" >>> Cc: Hannes Tschofenig; Georgios Karagiannis; Ash, Gerald R (Jerry),=20 >>> ALABS; >>> nsis@ietf.org; Kappler Cornelia >>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>> >>> Hi all, >>> >>> just an idea: >>> >>> Token Bucket is the only mandatory parameter. It is interpreted by=20 >>> CLS and >>> Y.1541. RMD can map it to Bandwidth. >>> >>> Other Parameters, like Path Latency,etc. are optional. If a QOSM does= n't >>> support it, it can be skipped. >>> >>> Mainly two types of parameters are left: Delay, Priority. If=20 >>> supported by >>> two different QOSMs, the following mapping could be tried: >>> >>> Delay: can be mapped to , >> Jitter>, >>> >>> >>> Priority: , , >> Priority>, >>> >>> Here should rather be derived from >> Priority> than >>> vice versa, as is more complex. Or in general the simp= le >>> parameters should be derived from the more complex one. >>> >>> The only problem I see: Do I know the QOSM of my neighbor domain? Do = >>> I have >>> to consider this when sending the initiator QSPEC? >>> >>> Bernd >>> >>> >>> >>> >>> Attila B=E1der (IJ/ETH) wrote: >>> >>>> Hi All, >>>> >>>> If "ignore" is not a type interpretation, I also think that it=20 >>>> should be >>> >>> >>> >>> reformulated. >>> >>>> In general, to understend mandatory parameters that is not used in a= =20 >>>> local >>> >>> >>> >>> QoSM, I see less problem. If a QOSM has to fill in mandatory=20 >>> parameters that >>> is not used in this QOSM, seems to be more difficult. >>> >>>> Best regards, Attila >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Monday, July 03, 2006 4:37 PM >>>>> To: Georgios Karagiannis >>>>> Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila B=E1der (IJ/ETH);=20 >>>>> nsis@ietf.org; 'Kappler Cornelia' >>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>> >>>>> >>>>> Hi Georgios, >>>>> >>>>> please find my comment below: >>>>> >>>>> Georgios Karagiannis wrote: >>>>> >>>>> >>>>>> Hi Jerry >>>>>> >>>>>> Regarding your last point: >>>>>> >>>>>> >>>>>> >>>>>>>> Hannes: >>>>>>>> Do you think it is awfully realistic for all QNEs to >>>>> >>>>> >>>>> >>>>> understand all >>>>> >>>>> >>>>>>>> mandatory parameters? I could imagine that Attila and Georgios=20 >>>>>>>> are not going to implement stateless interior QNEs in such a way= =20 >>>>>>>> that they understand all the mandatory QSPEC parameters. In fact= =20 >>>>>>>> they don't have todo it since only edge routers are likely to=20 >>>>>>>> ever see QoS NSLP messages that contain QOSM IDs that they do=20 >>>>>>>> not understand (otherwise something go terribly wrong). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Jerry: It is up the RMD authors to specify how they want RMD >>>>>>> >>>>>>> >>>>>>> >>>>>>>> to behave wrt mandatory parameters (and obtain rough consensus, = >>>>>>>> of course). That is, if a mandatory parameter is remapped and=20 >>>>>>>> not strictly interpreted, the remapping must be specified in the= =20 >>>>>>>> QOSM specification document. >>>>>>>> Otherwise, the QOSM must strictly interpret the mandatory=20 >>>>>>>> parameters that are not remapped, if they are populated by the Q= NI. >>>>>>>> There are no restrictions on how the remapping must be done, it = >>>>>>>> can be as simple as necessary (but no simpler). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Georgios: >>>>>> Jerry, I think that the point raised by Hannes is related to how=20 >>>>>> the QNE's interior to the RMD domain will have to comply to the=20 >>>>>> mandatory descriptions specified in the QSPEC template. >>>>>> An interior QNE (in RMD-QOSM) will not process the end to end=20 >>>>>> QSpec. The only QSpec that will be processed by the interior QNE=20 >>>>>> is the RMD Qsepc that is initiated by the ingress node (i.e., QNI = >>>>>> for the RMD local session). >>>>>> Note that the above observation is valid for all local QOSMs. >>>>>> However, the above is not allowed due to the following text that=20 >>>>>> is included in the QSpec template draft: >>>>>> >>>>>> "A QNE MUST interpret all mandatory parameters from this >>>>> >>>>> >>>>> >>>>> document even >>>>> >>>>> >>>>>> if it does not support the received QoS NSLP message with the=20 >>>>>> indicated QOSM." >>>>>> >>>>>> Therefore, in my opinion it is required to modify the above >>>>> >>>>> >>>>> >>>>> sentence in >>>>> >>>>> >>>>>> something like: >>>>>> >>>>>> "A QNE SHOULD interpret all mandatory parameters from this >>>>> >>>>> >>>>> >>>>> document even >>>>> >>>>> >>>>>> if it does not support the received QoS NSLP message with the=20 >>>>>> indicated QOSM. A QNE that supports a local QOSM, does not >>>>> >>>>> >>>>> >>>>> have to interpret >>>>> >>>>> >>>>>> all mandatory parameters carried by a QSpec that was >>>>> >>>>> >>>>> >>>>> generated by a QNI >>>>> >>>>> >>>>>> located outside the domain that supports the given local QOSM."=20 >>>>> >>>>> >>>>> >>>>> Something along these lines would probably be more realistic, I gue= ss. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> >>>>>> Best regards, >>>>>> Georgios >>>>>> >>>>>> -----Original Message----- >>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>>>>> Sent: maandag 3 juli 2006 2:03 >>>>>> To: Hannes Tschofenig >>>>>> Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH); >>>>> >>>>> >>>>> >>>>> nsis@ietf.org; >>>>> >>>>> >>>>>> Kappler Cornelia >>>>>> Subject: RE: [NSIS] draft-qosmodel-controlledload-04 >>>>>> >>>>>> Hi Hannes, >>>>>> >>>>>> See below. >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Saturday, July 01, 2006 4:26 PM >>>>>>> To: Ash, Gerald R (Jerry), ALABS >>>>>>> Cc: nsis@ietf.org >>>>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>>> >>>>>>> Hi Jerry, >>>>>>> >>>>>>> it is true that I haven't read the most recent QSPEC draft >>>>> >>>>> >>>>> >>>>> when I sent >>>>> >>>>> >>>>>>> this mail. In the meanwhile I did. Please find a few comments bel= ow: >>>>>>> >>>>>>> Ash, Gerald R (Jerry), ALABS wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi Hannes, >>>>>>>> >>>>>>>> See below. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>> Sent: Friday, June 30, 2006 8:43 AM >>>>>>>>> To: Bernd Schloer >>>>>>>>> Cc: nsis@ietf.org >>>>>>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >>>>>>>>> >>>>>>>>> Hi Bernd, >>>>>>>>> >>>>>>>>> Bernd Schloer wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> the first open issue in the appendix B is about what to do=20 >>>>>>>>>> with mandatory QSPEC parameters which are not needed for CLS. >>>>>>>>>> >>>>>>>>>> Does a QOSM have to understand (and provide information >>>>> >>>>> >>>>> >>>>> about) all >>>>> >>>>> >>>>>>>>>> mandatory parameters, even if they are not used? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I think the question is wrong. What about the following questio= n: >>>>>>>>> " >>>>>>>>> Does a node that implements a particular QOSM has to >>>>> >>>>> >>>>> >>>>> understand all >>>>> >>>>> >>>>>>>>> mandatory parameters listed in the QSPEC template draft >>>>>>> >>>>>>> >>>>>>> >>>>>>> (even if the >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> QOSM does not make use of them)? >>>>>>>>> " >>>>>>>>> The answer would be "YES" since the QSPEC template draft >>>>> >>>>> >>>>> >>>>> says that >>>>> >>>>> >>>>>>>>> mandatory parameters have to be understood by every NSIS QoS no= de. >>>>>>>>> >>>>>>>>> There is only the question what "understands" means. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> IMO you need to more carefully read the QSPEC I-D document. All= =20 >>>>>>>> mandatory QSPEC parameters that are populated in the QSPEC must = >>>>>>>> be interpreted by every QNE, which is explained in the QSPEC I-D= : >>>>>>>> >>>>>>>> It says in Section 4.4.1 (Mandatory and Optional QSPEC >>>>>>> >>>>>>> >>>>>>> >>>>>>> . Parameters) of >>>>>>> >>>>>>> >>>>>>> >>>>>>>> the QSPEC I-D >>>>>>>> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: >>>>>>>> >>>>>>>> " Mandatory QSPEC parameters are treated as follows: >>>>>>>> >>>>>>>> o A QNI SHOULD populate mandatory QSPEC parameters if >>>>>>> >>>>>>> >>>>>>> >>>>>>> . applicable to >>>>>>> >>>>>>> >>>>>>> >>>>>>>> the underlying QOSM. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I don't understand this sentence. What does it mean that a QNI=20 >>>>>>> "SHOULD" >>>>>>> populate parameters if applicable? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It means that a QNI is not required to populate all >>>>> >>>>> >>>>> >>>>> mandatory parameters. A >>>>> >>>>> >>>>>> QNI would only populated a mandatory parameter if is used >>>>> >>>>> >>>>> >>>>> by the QOSM >>>>> >>>>> >>>>>> supported by the QNI. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> o QNEs MUST interpret mandatory QSPEC parameters, if signaled." >>>>>>>> >>>>>>>> Furthermore, it says in Section 4.2 (QSPEC Processing): >>>>>>>> >>>>>>>> " a QNE >>>>>>>> MUST at least interpret all the mandatory parameters in >>>>>>>> a QSPEC even >>>>>>>> if it does not support the corresponding QOSM. >>>>>>>> >>>>>>>> Mandatory parameters provide a minimal subset of parameters. A = >>>>>>>> QNE MUST either a) strictly interpret a mandatory parameter, or >>>>>>>> b) remap the parameter and raise the flag =20 >>>>>>>> defined in Section 5.1, where the remapping MUST be specified=20 >>>>>>>> in the QOSM specification. Here the terminology 'strictly =20 >>>>>>>> interpret' means that >>>>>>> >>>>>>> >>>>>>> >>>>>>> What is the difference between 'strictly interpret' and >>>>> >>>>> >>>>> >>>>> 'interpret'? >>>>> >>>>>>> In the rest of the document you use 'interpret'. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 'Strictly interpret' is defined in the text I quoted from >>>>> >>>>> >>>>> >>>>> Section 4.2 (QSPEC >>>>> >>>>> >>>>>> Processing), which is given again in the very next >>>>> >>>>> >>>>> >>>>> sentences I quoted just >>>>> >>>>> >>>>>> below (after you posed your above question :-) >>>>>> >>>>>> " Mandatory parameters provide a minimal subset of parameters. A= >>>>>> QNE MUST either a) strictly interpret a mandatory parameter, or >>>>>> b) remap the parameter and raise the flag >>>>> >>>>> >>>>> >>>>> defined in >>>>> >>>>> >>>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>>> specification. Here the terminology 'strictly >>>>> >>>>> >>>>> >>>>> interpret' means that >>>>> >>>>> >>>>>> the parameter is implemented according to the commonly accepted >>>>>> definition and/or as specified by references given for each QSPEC= >>>>>> parameter. This means that in case a), a >>>>> >>>>> >>>>> >>>>> parameter >>>>> >>>>> >>>>>> must be strictly interpreted as a token bucket. =20 >>>>> >>>>> >>>>> >>>>> However, in case b), >>>>> >>>>> >>>>>> a parameter may be remapped, perhaps to a >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> parameter." >>>>>> >>>>>> In the document, the term 'interpret' a mandatory parameter >>>>> >>>>> >>>>> >>>>> means either a) >>>>> >>>>> >>>>>> strictly interpret (as defined above), or b) remap (as >>>>> >>>>> >>>>> >>>>> defined above). >>>>> >>>>> >>>>>> Perhaps this can be made clearer in the text. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> the parameter is implemented according to the commonly accepted = =20 >>>>>>>> definition and/or as specified by references given for >>>>> >>>>> >>>>> >>>>> each QSPEC >>>>> >>>>> >>>>>>>> parameter. This means that in case a), a =20 >>>>>>>> parameter must be strictly interpreted as a token bucket. >>>>>>>> However, in case b), >>>>>>>> a parameter may be remapped, perhaps to a =20 >>>>>>>> parameter. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I noticed this text improvement and I am happy to see more >>>>> >>>>> >>>>> >>>>> text about >>>>> >>>>> >>>>>>> it. >>>>>>> >>>>>>> Still, I have some issues with the section: >>>>>>> >>>>>>> I had a problem with this paragraph following the previous >>>>> >>>>> >>>>> >>>>> one in the >>>>> >>>>> >>>>>>> section. The previous paragraph said " >>>>>>> However, if a QSPEC arrives at a QNE that does >>>>>>> not support the QOSM being signaled, it can still understand the= >>>>>>> QSPEC content, at least to a basic degree. >>>>>>> " >>>>>>> >>>>>>> When I read through the text I got the impression that the two=20 >>>>>>> sections relate to each other and in fact they do not. Hence, I=20 >>>>>>> suggest to delete the previous paragraph since this one >>>>> >>>>> >>>>> >>>>> contains the >>>>> >>>>> >>>>>>> info already. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I'm unclear as to which paragraph/text you are proposing to delete= =2E >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> You >>>>>>> might also want to delete the second paragraph as well >>>>> >>>>> >>>>> >>>>> since it is far >>>>> >>>>> >>>>>>> too obvious to use RFC2119 language: If you don't support even a = >>>>>>> single QOSM then why are you a QOS NSLP node in the first place. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I think it important to state that a QNE MUST support at >>>>> >>>>> >>>>> >>>>> least one QOSM, >>>>> >>>>> >>>>>> even if this is clearly necessary to effectively support >>>>> >>>>> >>>>> >>>>> QoS-NSLP/QSPEC. >>>>> >>>>> >>>>>>> You might want to highlight the following sentence, though: >>>>>>> >>>>>>> " >>>>>>> A QNE MUST interpret all mandatory parameters from this >>>>> >>>>> >>>>> >>>>> document even >>>>> >>>>> >>>>>>> if it does not support the received QoS NSLP message with the=20 >>>>>>> indicated QOSM. >>>>>>> " >>>>>>> >>>>>>> Here is my proposal for the section: >>>>>>> >>>>>>> " >>>>>>> 4.2 QSPEC Processing >>>>>>> >>>>>>> The QSPEC is opaque to the QoS NSLP processing. The >>>>> >>>>> >>>>> >>>>> QSPEC control >>>>> >>>>> >>>>>>> information and the QoS description are interpreted and MAY be >>>>>>> modified by the RMF in a QNE (see description in [QoS-SIG]). >>>>>>> >>>>>>> The QSPEC contains a QOSM ID, i.e. information on what QOSM is = >>>>>>> being >>>>>>> signaled by the QNI. However, if a QSPEC arrives at a QNE that= =20 >>>>>>> does >>>>>>> not support the QOSM being signaled, it can still understand the= >>>>>>> QSPEC content, at least to a basic degree. This is because=20 >>>>>>> mandatory >>>>>>> parameters have been defined as a common language. Therefore, = >>>>>>> a QNE >>>>>>> MUST at least interpret all the mandatory parameters in a QSPEC= =20 >>>>>>> even >>>>>>> if it does not support the corresponding QOSM. >>>>>>> >>>>>>> A QNE MUST either >>>>>>> >>>>>>> a) interpret a mandatory parameter carried in the QSPEC >>>>> >>>>> >>>>> >>>>> object, or >>>>> >>>>> >>>>>>> b) remap the parameter and raise the flag =20 >>>>>>> defined in >>>>>>> Section 5.1, where the remapping MUST be specified in the QOSM >>>>>>> specification. >>>>>>> >>>>>>> Here the terminology 'interpret' means that >>>>>>> the parameter is implemented according to the references given = >>>>>>> for each QSPEC parameter. >>>>>>> >>>>>>> If a QSPEC arrives at a QNE that does not support the QOSM being= >>>>>>> signaled, it can still understand the QSPEC content, at >>>>> >>>>> >>>>> >>>>> least to a >>>>> >>>>> >>>>>>> basic degree. Hence, with case (a), a parameter >>>>>>> must be strictly interpreted as a token bucket. >>>>>>> >>>>>>> In case b), a parameter may be remapped, perhaps= =20 >>>>>>> to a >>>>>>> parameter. >>>>>>> " >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I don't see any benefit in redefining what 'interpret' means in=20 >>>>>> the document. As I mentioned above, the document uses the term >>>>> >>>>> >>>>> >>>>> 'interpret' to >>>>> >>>>> >>>>>> mean that a mandatory parameter is 'interpreted' if is >>>>> >>>>> >>>>> >>>>> either 'strictly >>>>> >>>>> >>>>>> interpreted' or it is 'remapped' (where the remapping must >>>>> >>>>> >>>>> >>>>> be defined in the >>>>> >>>>> >>>>>> QOSM specification document). OTOH, it might be useful to define = >>>>>> a 'remapping' flag to indicated if a mandatory or optional >>>>> >>>>> >>>>> >>>>> parameter has been >>>>> >>>>> >>>>>> remapped by a QNE in the path. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Btw, have you noticed that the draft has >>>>>>> * a flag (Section 5.1) >>>>>>> * a parameter (Section 7.2.1) >=20 >=20 >>>>>>> >>>>>>> I think they refer to the same concept... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Yes, good catch. is indeed intended to be a >>>>> >>>>> >>>>> >>>>> flag, and >>>>> >>>>> >>>>>> perhaps one of the QSPEC object flags defined in Section >>>>> >>>>> >>>>> >>>>> 7.1 could be used >>>>> >>>>> >>>>>> for this purpose, rather than use a full 32-bit parameter >>>>> >>>>> >>>>> >>>>> for this purpose, >>>>> >>>>> >>>>>> as currently specified in Section 7.2.1. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> In the latter case, the remapping of the to =20 >>>>>>>> must be specified in the QOSM specification >>>>> >>>>> >>>>> >>>>> document. >>>>> >>>>> >>>>>>>> For example, QOSM X exclusively uses the parameter =20 >>>>>>>> . It must define a mapping of the mandatory=20 >>>>>>>> parameter . >>>>>>>> The mapping consists of interpreting the Token Bucket Rate as =20 >>>>>>>> the parameter and disregarding the other >>>>> >>>>> >>>>> >>>>> Token Bucket >>>>> >>>>> >>>>>>>> parameters. Clearly, some information contained in the >>>>>>> Bucket> parameter is lost by this mapping, and the resulting=20 >>>>>>>> QoS may not be quite what was intended by the QNI. Therefore, = =20 >>>>>>>> QOSM X also specifies that the flag be raised. = >>>>>>>> Thus, a QNE using QOSM X is able to make an informed decision = >>>>>>>> whether to admit a reservation described in terms of >>>>>>> Bucket>, and >>>>> >>>>> >>>>> >>>>> at the same >>>>> >>>>> >>>>>>>> time (by means of ) signals to the >>>>> >>>>> >>>>> >>>>> QNI/QNR that the >>>>> >>>>> >>>>>>>> exact intention of the QNI may not be met." >>>>>>>> >>>>>>>> I think this text is pretty clear as to what is required=20 >>>>>>>> regarding interpreting mandatory parameters. If not, please=20 >>>>>>>> suggest clarifications. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The text in the new draft has improved a lot. >>>>>>> Thanks for the update. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Another possible question would be: >>>>>>>>> " >>>>>>>>> Does a node that implements a particular QOSM has to >>>>> >>>>> >>>>> >>>>> define mappings >>>>> >>>>> >>>>>>>>> from all mandatory parameters listed in the QSPEC >>>>> >>>>> >>>>> >>>>> template draft to >>>>> >>>>> >>>>>>>>> the QOSM draft (even if the QOSM does not make use >>>>>>> >>>>>>> >>>>>>> >>>>>>> of them)? >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> " >>>>>>>>> >>>>>>>>> The answer is "I don't know". >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A QNE must interpret all mandatory parameters, if populated, as = >>>>>>>> explained in the above text I quoted. If a QOSM re-maps a >>>>> >>>>> >>>>> >>>>> mandatory >>>>> >>>>> >>>>>>>> QSPEC parameter, that re-mapping must be defined in the QOSM=20 >>>>>>>> specification. As stated in Section 4.7 (QOSM Specification >>>>>>>> Requirements): >>>>>>>> >>>>>>>> " A QOSM specification MUST define QSPEC parameter behavior=20 >>>>>>>> for these >>>>>>>> cases: a) new optional QSPEC parameters the QOSM specification >>>>>>>> defines, and b) remapping of existing mandatory or >>>>> >>>>> >>>>> >>>>> optional QSPEC >>>>> >>>>> >>>>>>>> parameters, as described in Section 4.2. Unless otherwise=20 >>>>>>>> specified in the QOSM specification document, the behaviors to = >>>>>>>> strictly interpret the mandatory and optional QSPEC parameters = =20 >>>>>>>> are defined in this document through the references to RFCs=20 >>>>>>>> that precisely define the QSPEC parameter behaviors. >>>>>>>> >>>>>>>> A QOSM specification MUST define how the mandatory parameters=20 >>>>>>>> are to be mapped onto the QSPEC parameters used by the QOSM, >>>>> >>>>> >>>>> >>>>> however the >>>>> >>>>> >>>>>>>> mapping MAY result in slight modification to the intended =20 >>>>>>>> specification when an exact mapping is not possible. >>>>>>>> This definition >>>>>>>> MUST allow a QNE implementing this QOSM to make a decision as=20 >>>>>>>> to whether a reservation described in terms of mandatory =20 >>>>>>>> parameters can be admitted. If for a particular mandatory=20 >>>>>>>> parameter no mapping can be found that guarantees the desired = >>>>>>>> QoS, the QNE is advised to raise the flag. In = >>>>>>>> other words, for all mandatory parameters a mapping must be=20 >>>>>>>> defined, but it is >>>>> >>>>> >>>>> >>>>> acknowledged that >>>>> >>>>> >>>>>>>> this mapping may result in slightly bending the original =20 >>>>>>>> intention of the QNI." >>>>>>>> >>>>>>>> I think this text is pretty clear as to what is required. If=20 >>>>>>>> not, please suggest clarifications. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I understood the token bucket to bandwidth example. >>>>>>> >>>>>>> Would the RMD draft, for example, list all mandatory parameters=20 >>>>>>> and indicate whether it can map them (and how) to parameters used= =20 >>>>>>> in the RMD specification? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> As stated in the QOSM specification requirements in Section >>>>> >>>>> >>>>> >>>>> 4.7, if a QOSM >>>>> >>>>> >>>>>> remaps a mandatory parameter, the remapping must be defined >>>>> >>>>> >>>>> >>>>> in the QOSM >>>>> >>>>> >>>>>> specification document. If no such remapping is defined, >>>>> >>>>> >>>>> >>>>> the default >>>>> >>>>> >>>>>> behavior is that the QOSM must strictly interpret the >>>>> >>>>> >>>>> >>>>> mandatory parameter, >>>>> >>>>> >>>>>> as defined above. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Do you think it is awfully realistic for all QNEs to understand=20 >>>>>>> all mandatory parameters? I could imagine that Attila and=20 >>>>>>> Georgios are not going to implement stateless interior QNEs in=20 >>>>>>> such a way that they understand all the mandatory QSPEC=20 >>>>>>> parameters. In fact they don't have todo it since only edge=20 >>>>>>> routers are likely to ever see QoS NSLP messages that contain=20 >>>>>>> QOSM IDs that they do not understand (otherwise something go=20 >>>>>>> terribly wrong). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It is up the RMD authors to specify how they want RMD to behave=20 >>>>>> wrt mandatory parameters (and obtain rough consensus, of >>>>> >>>>> >>>>> >>>>> course). That is, if a >>>>> >>>>> >>>>>> mandatory parameter is remapped and not strictly >>>>> >>>>> >>>>> >>>>> interpreted, the remapping >>>>> >>>>> >>>>>> must be specified in the QOSM specification document. =20 >>>>> >>>>> >>>>> >>>>> Otherwise, the QOSM >>>>> >>>>> >>>>>> must strictly interpret the mandatory parameters that are >>>>> >>>>> >>>>> >>>>> not remapped, if >>>>> >>>>> >>>>>> they are populated by the QNI. >>>>>> >>>>>> There are no restrictions on how the remapping must be >>>>> >>>>> >>>>> >>>>> done, it can be as >>>>> >>>>> >>>>>> simple as necessary (but no simpler). >>>>>> >>>>>> Thanks, >>>>>> Jerry >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Jerry >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Ciao >>>>>>>>> Hannes >>>>>>>>> >>>>>>>>> The QSPEC-draft says in section 5 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> that >>>>>>>>>> all parameters listed in the next sections are mandatory. The = >>>>>>>>>> QSPEC-draft also says in section 4.1 that "a given QOSM=20 >>>>>>>>>> defines which of the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> mandatory and >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> optional parameters it uses, ..." >>>>>>>>>> >>>>>>>>>> Are there any specific parameters which makes the open >>>>>>> >>>>>>> >>>>>>> >>>>>>> issue B.1.1. >>>>>>> >>>>>>> >>>>>>>>>> clearer? Following the QSPEC-draft there doesn't seem to be >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> a conflict, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> if nothing is >>>>>>>>>> done with the unneeded parameters. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Bernd >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> nsis mailing list >>>>>> nsis@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/nsis >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> >> >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsi > s _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 04 11:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxmod-0004xt-Qf; Tue, 04 Jul 2006 11:27:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxmoc-0004ph-7U; Tue, 04 Jul 2006 11:27:54 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxmoa-0003p7-PX; Tue, 04 Jul 2006 11:27:54 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k64FRcAD001170; Tue, 4 Jul 2006 16:27:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSIS Controlled load & Pre-Congestion Notification (P CN) Date: Tue, 4 Jul 2006 16:27:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS Controlled load & Pre-Congestion Notification (P CN) Thread-Index: AcaZ88Lt7DYHSgDDQ5ezq3cAZeuhJwFhNpHQ From: "Hancock, Robert" To: "Geib, Ruediger" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tsvwg@ietf.org, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, i think it would be a good thing to have the controlled load QOSM made official, and at the same time work out how to support the PCN architecture and algorithms with NSIS signalling. in the past i've been in favour of covering both in a single specification, although i think i'm swimming against the tide on that. however, in any case, i think it would be good to work on the related specifications (including the PCN/RSVP ones) at=20 the same time and so far as possible in the same place, because then they'll fit together better and also get better reviews. i'm not clear in my own head how much of a delta CL-4-PCN/NSIS=20 would be compared to 'classical CL'. at least it would be interesting to decide if it is a new QOSM or an extension to an existing one (which might also help to clarify some of the=20 current extensibility discussions). other interesting points would be how to handle AdSpec-equivalent processing (which=20 has been an interesting point for the CL-QOSM and AFAIK is currently undefined for PCN/RSVP), and whether the QoS-NSLP/ QSPEC flexibility provides any neater solution to the 'on-hold' problem (where a reservation request arrives at the egress=20 before it has a congestion estimate). cheers, robert h. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 > Sent: 27 June 2006 15:12 > To: john.loughney@nokia.com > Cc: tsvwg@ietf.org; nsis@ietf.org > Subject: RE: [NSIS] NSIS Controlled load & Pre-Congestion=20 > Notification (P CN) >=20 >=20 > Hi John, >=20 > as I'm interested in PCN and also following NSIS, I would appreciate=20 > some activity to signal CLS/PCN with NSIS. If there's more interest,=20 > I'd also help on a draft. >=20 > PCN doesn't yet have WG status. Would it be a good idea to wait until=20 > IETF accepts PCN as a work item before NSIS starts to work on this?=20 > Should we discuss this in Montreal (maybe also with Bob Briscoe=20 > and Francois Lefaucheur)? >=20 > Regards, >=20 > Rudiger >=20 > |The current situation is that we (in NSIS) are starting to clear our > |charter, and there has been interest in making the=20 > Controlled Load QoS=20 > |Model a WG draft. > |I would imagine that also working on the PCN at the same=20 > time might be > |desirable. > | > |let me know, > |thanks, > |John > | > |_______________________________________________ > |nsis mailing list > |nsis@ietf.org > |https://www1.ietf.org/mailman/listinfo/nsis > | >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 05 06:23:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy4Xr-0000D0-Ow; Wed, 05 Jul 2006 06:23:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy4Xp-0000Cv-QH for nsis@ietf.org; Wed, 05 Jul 2006 06:23:45 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy4Xn-0005CK-Aj for nsis@ietf.org; Wed, 05 Jul 2006 06:23:45 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k65ANXE4028864; Wed, 5 Jul 2006 11:23:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSLP authorization work Date: Wed, 5 Jul 2006 11:23:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSLP authorization work Thread-Index: AcaY8Ug4fCIVt3RmT+qtRrAQmfNZygHKBTpw From: "Hancock, Robert" To: "Jukka MJ Manner" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, i think this is an interesting document. i have some comments on it: *) section 3.1: this assumes that GIST defines the NLSP object space and AB flag settings. however, this hasn't been true=20 since version -06 (over a year ago!); at the moment, AFAIK no document creates or describes the NSLP object registry. (Incidentally, this can be taken as a WGLC comment on all the current NSLP specs.) *) section 3.2.1: i think it could be made clearer that the addresses which can be used as identifiers here are orthogonal=20 to addressing associated with the signalling nodes or the resources being requested.=20 *) section 3.2.3/3.2.4: carrying address/port information here raises a number of concerns with me. - there is no discussion of NAT traversal issues. - it isn't clear whether the addresses should relate to e2e=20 flows or GIST/NSLP peers - are the addresses always meaningful - e.g. what is the correct 'called party' address for a NATFW REA message? [the last point is a reflection of the issue that basing the authorisation model too closely on rfc3520 may not be ideal, since the session concepts themselves are not that directly related.] *) section 3.2.7: likewise, the 'resources' attribute seems to=20 run the risk of partial duplication of information which is=20 already being carried in another form in the main body of the NSLP. my main concerns are the last two. it seems that related information is going to be carried in the 'main' NSLP objects and also in=20 the AUTH_SESSION object, and it is up to the NSLP implementation at either end to compare and match the two. However, it's quite unclear how much freedom there should be in doing this. For example, what does one do about MRI wildcarding, or if a flow label is specified, or if the token bucket is given in a Qspec but not a bandwidth, and so on. I suspect the underlying problem here is that different authorisation infrastructures use different formats to represent the resources that are authorised, so some unpleasant interworking is going to be required somewhere. But doing that in a partial way in the NSLP=20 seems very awkward. r. > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: 26 June 2006 08:22 > To: nsis@ietf.org > Subject: [NSIS] NSLP authorization work >=20 >=20 >=20 > Hi all, >=20 > Hannes, Martin and myself have pretty much finalized our=20 > proposal to add > an authorization object to the NSLP layer. We'd like to hear=20 > comments on > whether this would be as usefull to have as we see it. The=20 > draft includes > e.g., the structure and use of the authorization object and message > processing rules for the QoS and NAT/FW NSLPs. >=20 > http://www.ietf.org/internet-drafts/draft-manner-nsis-nslp-auth-01.txt >=20 > Regards, > Jukka >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 05 07:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5jd-0007UK-OM; Wed, 05 Jul 2006 07:40:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5jc-0007U2-Ny for nsis@ietf.org; Wed, 05 Jul 2006 07:40:00 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy5jb-0003l8-Qd for nsis@ietf.org; Wed, 05 Jul 2006 07:40:00 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k65Bdm8P008908; Wed, 5 Jul 2006 12:39:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] NSIS next steps Date: Wed, 5 Jul 2006 12:39:48 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS next steps Thread-Index: AcacB63nPd9yC1TPTd6lLx4oCyhV0AEHeSjg From: "Hancock, Robert" To: , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0911877832==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0911877832== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A027.B82DCDEE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A027.B82DCDEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable john, =20 as well as the 3 topics you list (which are certainly at/near the top of my list of priorities), there are a couple of other areas I would highlight: =20 firstly, there is stuff that the WG needs to do support the current set of specs. this would include: - the extensibility document - NAT traversal specification - hannes'/pasi's GIST security document all these topics came up to a greater or lesser extent in Magnus' GIST review. =20 secondly, i'd like to register interest for the 'MRM patterns' document, although this is clearly a longer term activity. =20 finally, people might also like to be aware of http://tools.ietf.org/wg/mipshop/draft-hancock-mipshop-gist-for-mih-00.t xt, which is a proposal to use GIST as a basis for the common protocol functions needed for 802.21 support. it's on the mipshop agenda for Montreal. =20 cheers, =20 robert h. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: 30 June 2006 06:40 To: nsis@ietf.org Subject: [NSIS] NSIS next steps =09 =09 Hi all, Below is a cut & paste (with slight editing) from http://tools.ietf.org/wg/nsis/ showing the individual drafts that are active for NSIS. I believe that we have had interest in at least the Partly De-coupled Signaling, Controlled Load QoS Model & the Meeting NSLP work. These are (at least) the intial set of drafts that we would be considering to add to the charter after we complete our milestones. Some of these may require us to modify our current charter. I'd like the working group to comment on the drafts, indicating what is your priority for completing. If there are items that you feel are not a priority, please let me know. We will talk more about this in Montreal. thanks, John =20 draft-cordeiro-nsis-hypath-00.txt -00 2006-03-01 14:53 =20 draft-dressler-nsis-metering-nslp-04.txt -04 new 2006-06-28 21:21 =20 draft-fessi-nsis-m-nslp-framework-03.txt -03 new 2006-06-28 21:19 =20 draft-fu-nsis-diagnostics-nslp-01.txt -01 2006-03-16 02:07 =20 draft-fu-nsis-qos-nslp-statemachine-04.txt -04 new 2006-06-28 21:00 =20 draft-hancock-nsis-pds-problem-03.txt -03 2006-03-09 02:07 =20 draft-kappler-nsis-qosmodel-controlledload-04.txt -04 new 2006-06-26 20:25 =20 draft-loughney-nsis-ext-02.txt -02 2006-03-16 02:07 =20 draft-manner-nsis-nslp-auth-01.txt -01 2006-06-22 19:55 =20 draft-pashalidis-nsis-gimps-nattraversal-03.txt -03 new 2006-06-26 18:41 =20 draft-stiemerling-nsis-mrm-patterns-00.txt -00 2006-06-20 20:22 =20 draft-thiruvengadam-nsis-mip6-fw-04.txt -04 new 2006-06-29 17:47 =20 draft-tommasi-nsis-semipro-00.txt -00 2006-02-22 17:15 =20 draft-tschofenig-nsis-gist-security-01.txt -01 new 2006-06-28 20:58 =20 draft-werner-nsis-natfw-nslp-statemachine-03.txt -03 new 2006-06-28 19:41 =20 draft-zhang-nsis-interdomain-qosm-02.txt -02 new 2006-06-26 13:56 =20 ------_=_NextPart_001_01C6A027.B82DCDEE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
john,
 
as=20 well as the 3 topics you list (which are certainly at/near the top of my = list of=20 priorities), there are a couple of other areas I would=20 highlight:
 
firstly, there is stuff that the WG needs to do support the = current set=20 of specs. this would include:
- the=20 extensibility document
- NAT=20 traversal specification
-=20 hannes'/pasi's GIST security document
all=20 these topics came up to a greater or lesser extent in Magnus' GIST=20 review.
 
secondly, i'd like to register interest for the 'MRM patterns' = document,=20 although this is clearly a longer term activity.
 
finally, people might also like to be aware of = http://tools.ietf.org/wg/mipshop/draft-hancock-mipshop-gist-fo= r-mih-00.txt,=20 which is a proposal to use GIST as a basis for the common protocol = functions=20 needed for 802.21 support. it's on the mipshop agenda for=20 Montreal.
 
cheers,
 
robert=20 h.
-----Original Message-----
From:=20 john.loughney@nokia.com [mailto:john.loughney@nokia.com] =
Sent: 30=20 June 2006 06:40
To: nsis@ietf.org
Subject: [NSIS] = NSIS=20 next steps

Hi all,

Below is a cut & paste (with slight = editing)=20 from http://tools.ietf.org/wg/nsis/ showing=20 the individual drafts that are active for NSIS.

I believe that we have had interest in = at least the=20 Partly De-coupled Signaling, Controlled Load QoS Model & the = Meeting NSLP=20 work.  These are (at least) the intial set of drafts that we = would be=20 considering to add to the charter after we complete our = milestones.  Some=20 of these may require us to modify our current charter.

I'd like the working group to = comment on the=20 drafts, indicating what is your priority for completing.  If = there are=20 items that you feel are not a priority, please let me know.

We will talk more about this in=20 Montreal.

thanks,

John

 

= draft-cordeiro-nsis-hypath-00.txt -00=20 2006-03-01 14:53 

draft-dressler-nsis-metering-nslp-04.txt = -04 new=20 2006-06-28 21:21 

draft-fessi-nsis-m-nslp-framework-03.txt = -03 new=20 2006-06-28 21:19 

draft-fu-nsis-diagnostics-nslp-01.txt = -01=20 2006-03-16 02:07 

draft-fu-nsis-qos-nslp-statemachine-04.txt= -04=20 new 2006-06-28 21:00 

draft-hancock-nsis-pds-problem-03.txt = -03=20 2006-03-09 02:07 

draft-kappler-nsis-qosmodel-controlledload-04.txt=20 -04 new 2006-06-26 20:25 

= draft-loughney-nsis-ext-02.txt -02=20 2006-03-16 02:07 

draft-manner-nsis-nslp-auth-01.txt -01=20 2006-06-22 19:55 

draft-pashalidis-nsis-gimps-nattraversal-03.txt=20 -03 new 2006-06-26 18:41 

draft-stiemerling-nsis-mrm-patterns-00.txt= -00=20 2006-06-20 20:22 

draft-thiruvengadam-nsis-mip6-fw-04.txt = -04 new=20 2006-06-29 17:47 

= draft-tommasi-nsis-semipro-00.txt -00=20 2006-02-22 17:15 

draft-tschofenig-nsis-gist-security-01.txt= -01=20 new 2006-06-28 20:58 

draft-werner-nsis-natfw-nslp-statemachine-03.txt=20 -03 new 2006-06-28 19:41 

draft-zhang-nsis-interdomain-qosm-02.txt = -02 new=20 2006-06-26 13:56 

------_=_NextPart_001_01C6A027.B82DCDEE-- --===============0911877832== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0911877832==-- From nsis-bounces@ietf.org Wed Jul 05 10:29:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8O2-00075e-G5; Wed, 05 Jul 2006 10:29:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8O1-00075Z-HY for nsis@ietf.org; Wed, 05 Jul 2006 10:29:53 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8Nz-0005fa-Hj for nsis@ietf.org; Wed, 05 Jul 2006 10:29:53 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k65ETn4O004692; Wed, 5 Jul 2006 16:29:49 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k65ETnLh001352; Wed, 5 Jul 2006 16:29:49 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 16:29:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Legacy NAT traversal for NSIS Date: Wed, 5 Jul 2006 16:29:30 +0200 Message-ID: <69D2C30BFA177E4DB3E6C93A94C87F1F8EAD65@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Legacy NAT traversal for NSIS thread-index: AcadRTG2CJAETM0lT4iiyEbOcHvg6QBYpi1AAGMmbtA= From: "Pashalidis, Andreas" To: "Hancock, Robert" , "Hannes Tschofenig" , X-OriginalArrivalTime: 05 Jul 2006 14:29:31.0716 (UTC) FILETIME=[6E191840:01C6A03F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hello all, Many thanks to those who provided feedback on our "legacy NAT traversal for GIST" document. I take it that sufficient interest exists for the document to be submitted to the WG. Some answers to Robert's comments: > my biggest question about the approach is that the discussion > is mostly about a flow which goes through the legacy NAT in the=20 > internal->external direction (same as the initial Query for the > signalling). how does one handle a flow in the other direction?=20 > it's a different flow, so either one needs a technique to get the > Query through the NAT the other way, or to rely on the upstream=20 > encapsulation. Each has its tricky side. This has struck me in=20 > the past as the hardest part of the problem. Surely the problem you mention is the trickiest one. Consider this:=20 For the (internal->external) direction the solution works as follows. Signalling causes a UDP NAT binding to be installed, which is then used to tunnel data traffic over. If the same "technique" was to be applied in the (external->internal) direction, then we would require that *first* there is a data flow, which (by some out-of-scope means) has caused a NAT binding to be installed at the NAT.=20 Subsequently (and only subsequently) we could use that very NAT binding for the tunnelling of signalling traffic. In other words, the "solution" would only work if signalling is initiated *after* the data is already flowing. Of course there may be other ways to solve the (external->internal) direction problem, but these may result in GIST to rely on some external services (while it could very well do without them). I am not sure whether=20 or not the WG desires reliance on external services in certain hard-to-solve NAT traversal instances. Having said that, this may very well acceptable if made optional. Moreover, I am not sure whether or not it is worth the effort to enable (external->internal) direction legacy NAT traversal within GIST (given that legacy NAT traversal is, by its nature, a "best=20 effort" service, and a mid-term "solution" anyway). It would be nice to know what people think regarding the above questions.=20 > some more detailed comments: > section 2: you refer to the GIST spec for NI/NR/DS/DR but > actually that document doesn't define or use the terms. in particular, > I think of NI/NR as NSLP layer terminology which might not be > appropriate here. Thanks for pointing this out.=20 > section 4 bullet 2: i don't see the need for precise matching > of packets to interfaces. wouldn't arriving on the correct > 'side' of the NAT be enough? A multi-homed NAT may have multiple interfaces and "sides". A given interface may have one or more IP addresses. A GIST peer=20 should send a message B to the NAT's address (as opposed to directly to the GIST peer that is behind the NAT). It is therefore expected that the GIST peer uses the NATs IP address that it saw in a previous message A - in fact, the document mandates this behaviour. If the message B arrives on an interface that is different from the interface where A was sent from, this would probably mean that the peer used the wrong IP address. This should not happen, right?=20 > section 4 bullet 3: strictly, GIST can indicate a possible=20 > routing change in some of these circumstances (e.g. if inbound/ > outbound interfaces change, or a TTL changes). i don't think this > changes the argument however. Absolutely; thanks for pointing this out. I changed "Thus, under "normal" path coupled signalling, it is not an error condition [...]" to "Thus, under "normal" path coupled signalling, it is not always an error condition [...]". I hope this removes the error. > page 7 last bullet: the phrasing of this condition might need > to be refined if you consider the upstream query as well. Absolutely. > general question: how should the upstream node handle refreshing > Queries? i guess it should generate 'normal' queries (with the=20 > RAO included and not tunnelled), but then there would be > a question of whether it should use the existing UDP source > port or a new one (thus creating a new binding at the NAT). This is a good question. I would say that the same NAT binding should be used for the whole duration of the signalling session and - for that matter - the existence of the data flow. Switching the signalling to a new NAT binding would also require switching the data flow to that binding (which could break the application). (Having said that, the session ID could be used to map refreshing queries to existing UDP tunnels.) Another argument is that it may be undesirable that many NAT bindings exist for a single data flow / signalling session pair. Should the refreshing query should also be tunnelled over UDP or not? Maybe a refreshing query should be sent exactly as the "first" query, i.e normally. In other words, the NAT would have to be re-discovered. However, the downstream peer could shortcut the process by sending a RESPONSE over=20 the existent messaging association, right? Re-discovering the NAT=20 seems to be necessary in case a previously unknown (or rebooted) peer identifies itself as a new downstream peer... > page 8: i'm not sure about extending the stack proposal this > way, but it's not a critical issue for the basic form of the > solution. I am not sure either. This was done in order to avoid changes to GIST message formats. The semantics of such a message seem unambiguous to me... > page 9 first para: the packet analysis rules are not quite > perfect. for example, a Query would be identified as a data > packet, as would any GIST message if the GIST node in question > was also the flow endpoint. however, the standard GIST rules > should be able to cover these cases. Right. Thanks for pointing this out, too.=20 > page 9, penultimate paragraph: i think full NAT processing=20 > (whatever that means) is required here, including e.g. source > port remapping, checksum fixups and so on, not just source > address rewriting. (consider the case of two nodes behind the > same NAT.) Will do. Thanks again. Best Regards, Andreas > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 01 July 2006 20:32 > To: john.loughney@nokia.com > Cc: Andreas.Pashalidis@siemens.com; nsis@ietf.org > Subject: Re: [NSIS] Legacy NAT traversal for NSIS >=20 >=20 > Hi John, > Hi Saikat, >=20 > thanks for the feedback. I definitely think that we should=20 > explore the=20 > usage of these protocols in context with GIST for legacy NAT=20 > traversal. >=20 > Ciao > Hannes >=20 > john.loughney@nokia.com wrote: > > Hi Saikat, > >=20 > > You're observations are right - if we want, we can run GIST over > > any 'standard' NAT traveral mechanisms (TERADO, STUN, TURN).=20 > >=20 > > I think working through this would be a useful exercise. > >=20 > > John > >=20 > >=20 > >>On Mon, 2006-06-19 at 15:22 +0200, Pashalidis, Andreas wrote: > >> > >>>Is anyone interested to make NSIS work through legacy NATs ?? (i.e. > >>>NSIS-unaware NATs) > >>> > >>>Under the following link a preliminary document (in I-D format) can > >=20 > > be=20 > >=20 > >>>found that describes a solution approach. > >>> > >> > >>http://www.tschofenig.priv.at/TEMP/draft-pashalidis-nsis-gist-legac > >>ynats-00. > >> > >>>txt > >>> > >>>In an exremely small nutshell: the idea is to tunnel both=20 > signalling=20 > >>>and data traffic over a single UDP NAT binding. > >> > >>I haven't gone through the document throughly, but the=20 > >>underlying transport you propose reminds me of TEREDO (which=20 > >>is over IPv6 over UDP over IPv4, where the UDP=20 > >>over IPv4 is punched through legacy NATs with the help of=20 > >>STUN/TURN/ICE etc.) One could potentially run GIST over TEREDO=20 > >>and keep the signaling and data channel separate in > >>IPv6 land even though they use the same NAT binding in IPv4 land. > >> > >>Alternatively, TURN (public-data-relay protocol for traversing=20 > >>the worst of NATs) now has some lightweight framing=20 > >>capability; the framing in TURN could potentially be extended=20 > >>to carry any in-band signals including GIST.=20 > >> > >>-- > >>Saikat > >> > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 05 11:46:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9aS-0006I1-A2; Wed, 05 Jul 2006 11:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9aQ-0006Hw-AJ for nsis@ietf.org; Wed, 05 Jul 2006 11:46:46 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy9aM-000661-UY for nsis@ietf.org; Wed, 05 Jul 2006 11:46:46 -0400 Received: from elena1 (unknown [10.0.12.115]) by mailing.unile.it (Postfix) with SMTP id C554E104B44; Wed, 5 Jul 2006 17:46:38 +0200 (CEST) Message-ID: <016f01c6a04a$36286980$730c000a@elena1> From: "Elena Scialpi" To: "Bernd Schloer" References: <44A99A80.2060904@cs.uni-goettingen.de> Subject: Re: [NSIS] Receiver Initiated Reservation - Teardown Date: Wed, 5 Jul 2006 17:46:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Antivirus: avast! (VPS 0627-1, 05/07/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd, I would want to know if you have received a private answer to this mail. Please see below for my opinion. > Hi Jukka, > > RSVP has two types of teardown-messages: PathTear and ResvTear. The QoS > NSLP is only allowed to send a RESERVE towards the QNR. How can a receiver > initiated reservation be torn down? The QNR is not allowed. I think that a reservation can be torn down by a RESERVE message ( with TEAR flag set) from both, QNI and QNR, entity. Only RESERVE for resource reservation MUST travel from QNI to QNR and not in the opposite direction. > > Section 5.4.2, p. 61: > > 3576 Note that QUERY messages with the RESERVE-INIT flag set MUST be > 3577 answered by the QNR. > > Isn't this the QNI who should answer the QUERY, since the QNR is the > sender? Section 5.1.2.2. RESERVE-INIT (R) - when this is set, the QUERY is meant as a trigger for the recipient to make a resource reservation by sending a RESERVE. Then, when a QNI receive QUERY with a RESERVE-INIT set it responds with a RESERVE message. Note that QUERY messages with the RESERVE-INIT flag set MUST be answered by the QNR. This feature may be used, e.g., following handovers, to set up new path state in GIST, and request the other party to send a RESERVE back on this new GIST path. It could be an exceptional case? > > Thanks, > Bernd > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------------ LIIS Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi http://liis.unile.it http://www.campusdelsalento.it Office: (+39) 0832-297310 c/o Palazzo di Ingegneria Via per Monteroni I-73100 Lecce LE, Italy _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 05 12:59:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAj4-0004UF-8B; Wed, 05 Jul 2006 12:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAj3-0004U4-7o for nsis@ietf.org; Wed, 05 Jul 2006 12:59:45 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyAj1-0001lP-OJ for nsis@ietf.org; Wed, 05 Jul 2006 12:59:45 -0400 Received: from [192.168.178.200] (p5484B43C.dip0.t-ipconnect.de [84.132.180.60]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k65GxauP016942; Wed, 5 Jul 2006 18:59:37 +0200 (MEST) Message-ID: <44ABEF57.2030002@schloer.net> Date: Wed, 05 Jul 2006 18:56:55 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elena Scialpi Subject: Re: [NSIS] Receiver Initiated Reservation - Teardown References: <44A99A80.2060904@cs.uni-goettingen.de> <016f01c6a04a$36286980$730c000a@elena1> In-Reply-To: <016f01c6a04a$36286980$730c000a@elena1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Elena, please see inline. Bernd Elena Scialpi wrote: > > Hi Bernd, > > I would want to know if you have received a private answer to this mail. > Please see below for my opinion. > No, I haven't. Yours is the first reply. > >> Hi Jukka, >> >> RSVP has two types of teardown-messages: PathTear and ResvTear. The >> QoS NSLP is only allowed to send a RESERVE towards the QNR. How can a >> receiver initiated reservation be torn down? The QNR is not allowed. > > > > I think that a reservation can be torn down by a RESERVE message ( with > TEAR flag set) from both, QNI and QNR, entity. > Only RESERVE for resource reservation MUST travel from QNI to QNR and > not in the opposite direction. > That would make sense. But section 5.4.1 says: RESERVE messages MUST only be sent towards the QNR. In my opinion this includes also RESERVE messages with set T-Flag. >> >> Section 5.4.2, p. 61: >> >> 3576 Note that QUERY messages with the RESERVE-INIT flag set MUST be >> 3577 answered by the QNR. >> >> Isn't this the QNI who should answer the QUERY, since the QNR is the >> sender? > > > > Section 5.1.2.2. > > RESERVE-INIT (R) - when this is set, the QUERY is meant as a trigger > for the recipient to make a resource reservation by sending a > RESERVE. > > Then, when a QNI receive QUERY with a RESERVE-INIT set it responds with > a RESERVE message. > > > Note that QUERY messages with the RESERVE-INIT flag set MUST be > answered by the QNR. This feature may be used, e.g., following > handovers, to set up new path state in GIST, and request the other > party to send a RESERVE back on this new GIST path. > > It could be an exceptional case? > 1537 QNR QNE QNE QNI 1538 sender receiver 1539 | | | | 1540 | QUERY | | | 1541 +--------->| | | 1542 | | QUERY | | 1543 | +--------->| | 1544 | | | QUERY | 1545 | | +--------->| 1546 | | | | 1547 | | | RESERVE | 1548 | | |<---------+ 1549 | | RESERVE | | 1550 | |<---------+ | 1551 | RESERVE | | | 1552 |<---------+ | | 1553 | | | | 1554 | RESPONSE | | | 1555 +--------->| | | 1556 | | RESPONSE | | 1557 | +--------->| | 1558 | | | RESPONSE | 1559 | | +--------->| 1560 | | | | 1561 1562 Figure 8: Basic Receiver Initiated Reservation 1563 I have this figure from section 4.3 in mind. The QNR is the sender of the QUERY. And section 5.4.2. says that the QNR must answer the QUERY with set RESERVE-INIT flag. You mean the exception could be the handover? Are the roles of QNR and QNI changed after a handover? > >> >> Thanks, >> Bernd >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > ------------ LIIS > Laboratorio per l'Internetworking > e l'Interoperabilita' tra i Sistemi > http://liis.unile.it > http://www.campusdelsalento.it > Office: (+39) 0832-297310 > c/o Palazzo di Ingegneria > Via per Monteroni > I-73100 Lecce LE, Italy > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 05 13:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBOD-0000a9-Us; Wed, 05 Jul 2006 13:42:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBOC-0000a1-SD for nsis@ietf.org; Wed, 05 Jul 2006 13:42:16 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyBOB-0005xe-JI for nsis@ietf.org; Wed, 05 Jul 2006 13:42:16 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 05 Jul 2006 20:42:12 +0300 id 00087E0F.44ABF9F4.00000D5D Date: Wed, 5 Jul 2006 20:42:12 +0300 (EEST) From: Jukka MJ Manner To: Bernd Schloer In-Reply-To: <44A99A80.2060904@cs.uni-goettingen.de> Message-ID: References: <44A99A80.2060904@cs.uni-goettingen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: nsis@ietf.org Subject: [NSIS] Re: Receiver Initiated Reservation - Teardown X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, you may be right. I'll need to re-check the text and our terminology. ;) Jukka On Tue, 4 Jul 2006, Bernd Schloer wrote: > Hi Jukka, > > RSVP has two types of teardown-messages: PathTear and ResvTear. The QoS NSLP > is only allowed to send a RESERVE towards the QNR. How can a receiver > initiated reservation be torn down? The QNR is not allowed. > > Section 5.4.2, p. 61: > > 3576 Note that QUERY messages with the RESERVE-INIT flag set MUST be > 3577 answered by the QNR. > > Isn't this the QNI who should answer the QUERY, since the QNR is the sender? > > Thanks, > Bernd > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 05 15:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDQP-0008R9-OX; Wed, 05 Jul 2006 15:52:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDQP-0008R4-A9 for nsis@ietf.org; Wed, 05 Jul 2006 15:52:41 -0400 Received: from ionians.ncr.disa.mil ([164.117.82.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyDQO-0007hB-26 for nsis@ietf.org; Wed, 05 Jul 2006 15:52:41 -0400 Received: from vanualevu.disanet.disa-u.mil ([164.117.144.226]) by ionians.ncr.disa.mil with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 15:52:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) Date: Wed, 5 Jul 2006 15:52:39 -0400 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A59A9728E@vanualevu.disanet.disa-u.mil> in-reply-to: <9473683187ADC049A855ED2DA739ABCA0DDC7A76@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List Thread-Index: Acae/dFNHJGpI3/FTHqQU3uZOOhMtQBaKNPg From: "Nguyen, An P CIV NCS NC2" To: "Ash, Gerald R \(Jerry\), ALABS" , "Janet P Gunn" X-OriginalArrivalTime: 05 Jul 2006 19:52:39.0841 (UTC) FILETIME=[92523110:01C6A06C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: John Rosenberg , "Attila Bader \(IJ/ETH\)" , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Classification: UNCLASSIFIED=20 Caveats: NONE Janet, Just a question: Is the DISA specification publicly available?=20 An -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] Sent: Monday, July 03, 2006 8:07 PM To: Janet P Gunn Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader (IJ/ETH); NSIS; John Rosenberg Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List Hi Janet, See below.=20 > -----Original Message----- > From: Janet P Gunn [mailto:jgunn6@csc.com]=20 > Sent: Monday, July 03, 2006 10:14 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH) > Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List >=20 > Nits with regard to RPH. >=20 > References should be updated to include RFC4412 (instead of=20 > just the ID) >=20 > In section 7.2.7.3 you show a mapping between the text values=20 > and numeric > values for RPH priority. (The mappings for ets and wps are fine) >=20 > For dsn and drsn you show >=20 > 4 - dsn.routine > 3 - dsn.priority > 2 - dsn.immediate > 1 - dsn.flash > 0 - dsn.flash-override >=20 > 5 - drsn.routine > 4 - drsn.priority > 3 - drsn.immediate > 2 - drsn.flash > 1 - drsn.flash-override > 0 - drsn.flash-override-override >=20 > You might want to check with the intended users of those=20 > namesapces, as I > understand (see recent email on the IEPREP mailing list) that=20 > DISA intends > to use a quite different numerical mapping, with "0" for=20 > routine in all > cases. >=20 > "The current DISA specification for MLPP on VoIP networks=20 > specifies RPH > r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of=20 > priority (e.g. > 0 =3D Routine and 9 =3D F-O-O)." >=20 > It will be very confusing if one numeric mapping is used in SIP and a > different, opposing, mapping is used in QSPEC. Agreed. We'll check the referenced specification and align the mapping = in the QSPEC. =20 Thanks a lot for pointing this out. Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis Classification: UNCLASSIFIED=20 Caveats: NONE _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 05 16:27:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDy0-0005oI-GO; Wed, 05 Jul 2006 16:27:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDxy-0005o2-Rc for nsis@ietf.org; Wed, 05 Jul 2006 16:27:22 -0400 Received: from pfwhqs1.ncr.disa.mil ([209.22.99.17] helo=pfwhqs100.ncr.disa.mil) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyDxy-0001kV-1n for nsis@ietf.org; Wed, 05 Jul 2006 16:27:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) Date: Wed, 5 Jul 2006 16:27:21 -0400 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A59A97291@vanualevu.disanet.disa-u.mil> in-reply-to: <6.2.1.2.0.20060705150330.033b03b0@ihmail.ih.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) Thread-Index: AcagbiHS9m0Vji/qQHGyPsXSxEyCrAAAoEyA From: "Nguyen, An P CIV NCS NC2" To: "John Rosenberg" , "Ash, Gerald R \(Jerry\), ALABS" , "Janet P Gunn" X-OriginalArrivalTime: 05 Jul 2006 20:27:21.0659 (UTC) FILETIME=[6B2E68B0:01C6A071] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: "Attila Bader \(IJ/ETH\)" , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Classification: UNCLASSIFIED=20 Caveats: NONE My next question is: how can you reference it in the ID if it is not = publicly available? This leads to my next question: for security, is = DISA comfortable with having its MLPP spec being discussed here? An -----Original Message----- From: John Rosenberg [mailto:jrrosenberg@lucent.com] Sent: Wednesday, July 05, 2006 4:04 PM To: Nguyen, An P CIV NCS NC2; Ash, Gerald R (Jerry), ALABS; Janet P Gunn Cc: Kappler Cornelia; Attila Bader (IJ/ETH); NSIS Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) No, not yet. At 02:52 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >Janet, > >Just a question: Is the DISA specification publicly available? > >An > >-----Original Message----- >From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >Sent: Monday, July 03, 2006 8:07 PM >To: Janet P Gunn >Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader >(IJ/ETH); NSIS; John Rosenberg >Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute = List > > >Hi Janet, > >See below. > >> -----Original Message----- >> From: Janet P Gunn [mailto:jgunn6@csc.com] >> Sent: Monday, July 03, 2006 10:14 AM >> To: Ash, Gerald R (Jerry), ALABS >> Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH) >> Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List >> >> Nits with regard to RPH. >> >> References should be updated to include RFC4412 (instead of >> just the ID) >> >> In section 7.2.7.3 you show a mapping between the text values >> and numeric >> values for RPH priority. (The mappings for ets and wps are fine) >> >> For dsn and drsn you show >> >> 4 - dsn.routine >> 3 - dsn.priority >> 2 - dsn.immediate >> 1 - dsn.flash >> 0 - dsn.flash-override >> >> 5 - drsn.routine >> 4 - drsn.priority >> 3 - drsn.immediate >> 2 - drsn.flash >> 1 - drsn.flash-override >> 0 - drsn.flash-override-override >> >> You might want to check with the intended users of those >> namesapces, as I >> understand (see recent email on the IEPREP mailing list) that >> DISA intends >> to use a quite different numerical mapping, with "0" for >> routine in all >> cases. >> >> "The current DISA specification for MLPP on VoIP networks >> specifies RPH >> r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of >> priority (e.g. >> 0 =3D Routine and 9 =3D F-O-O)." >> >> It will be very confusing if one numeric mapping is used in SIP and = a >> different, opposing, mapping is used in QSPEC. > >Agreed. We'll check the referenced specification and align the = mapping in >the QSPEC. > >Thanks a lot for pointing this out. > >Jerry > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis >Classification: UNCLASSIFIED >Caveats: NONE Classification: UNCLASSIFIED=20 Caveats: NONE _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 05 17:00:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyEUD-0003dw-Pn; Wed, 05 Jul 2006 17:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyEUC-0003dr-Vn for nsis@ietf.org; Wed, 05 Jul 2006 17:00:40 -0400 Received: from athena.hosts.co.uk ([212.84.175.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyEUA-0005Ja-H1 for nsis@ietf.org; Wed, 05 Jul 2006 17:00:40 -0400 Received: from [69.138.71.89] (helo=[192.168.1.2]) by athena.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.62) (envelope-from ) id 1FyETz-0006iD-Pn; Wed, 05 Jul 2006 22:00:28 +0100 In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59A97291@vanualevu.disanet.disa-u.mil> References: <9B4320CC9BC1D847AFFA97F25A422A59A97291@vanualevu.disanet.disa-u.mil> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <62D84945-0258-4C16-8314-24190BF0EE3E@g11.org.uk> Content-Transfer-Encoding: quoted-printable From: ken carlberg Subject: Re: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) Date: Wed, 5 Jul 2006 17:00:16 -0400 To: "Nguyen, An P CIV NCS NC2" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: John Rosenberg , NSIS , "Ash, Gerald R \(Jerry\), ALABS" , "Attila Bader \(IJ/ETH\)" , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Another thought is to just remove the example DISA-related values =20 from the QSPEC and simply have them registered later through IANA by =20 the interested party. The critical thing for the QSPEC is to have =20 the structure/container that can hold the values and not the values =20 themselves. -ken On Jul 5, 2006, at 4:27 PM, Nguyen, An P CIV NCS NC2 wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > My next question is: how can you reference it in the ID if it is =20 > not publicly available? This leads to my next question: for =20 > security, is DISA comfortable with having its MLPP spec being =20 > discussed here? > > An > > -----Original Message----- > From: John Rosenberg [mailto:jrrosenberg@lucent.com] > Sent: Wednesday, July 05, 2006 4:04 PM > To: Nguyen, An P CIV NCS NC2; Ash, Gerald R (Jerry), ALABS; Janet P =20= > Gunn > Cc: Kappler Cornelia; Attila Bader (IJ/ETH); NSIS > Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute =20= > List > (UNCLASSIFIED) > > > No, not yet. > > At 02:52 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: >> Classification: UNCLASSIFIED >> Caveats: NONE >> >> Janet, >> >> Just a question: Is the DISA specification publicly available? >> >> An >> >> -----Original Message----- >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >> Sent: Monday, July 03, 2006 8:07 PM >> To: Janet P Gunn >> Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader >> (IJ/ETH); NSIS; John Rosenberg >> Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory =20 >> Attribute List >> >> >> Hi Janet, >> >> See below. >> >>> -----Original Message----- >>> From: Janet P Gunn [mailto:jgunn6@csc.com] >>> Sent: Monday, July 03, 2006 10:14 AM >>> To: Ash, Gerald R (Jerry), ALABS >>> Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH) >>> Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List >>> >>> Nits with regard to RPH. >>> >>> References should be updated to include RFC4412 (instead of >>> just the ID) >>> >>> In section 7.2.7.3 you show a mapping between the text values >>> and numeric >>> values for RPH priority. (The mappings for ets and wps are fine) >>> >>> For dsn and drsn you show >>> >>> 4 - dsn.routine >>> 3 - dsn.priority >>> 2 - dsn.immediate >>> 1 - dsn.flash >>> 0 - dsn.flash-override >>> >>> 5 - drsn.routine >>> 4 - drsn.priority >>> 3 - drsn.immediate >>> 2 - drsn.flash >>> 1 - drsn.flash-override >>> 0 - drsn.flash-override-override >>> >>> You might want to check with the intended users of those >>> namesapces, as I >>> understand (see recent email on the IEPREP mailing list) that >>> DISA intends >>> to use a quite different numerical mapping, with "0" for >>> routine in all >>> cases. >>> >>> "The current DISA specification for MLPP on VoIP networks >>> specifies RPH >>> r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of >>> priority (e.g. >>> 0 =3D Routine and 9 =3D F-O-O)." >>> >>> It will be very confusing if one numeric mapping is used in SIP =20 >>> and a >>> different, opposing, mapping is used in QSPEC. >> >> Agreed. We'll check the referenced specification and align the =20 >> mapping in >> the QSPEC. >> >> Thanks a lot for pointing this out. >> >> Jerry >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> Classification: UNCLASSIFIED >> Caveats: NONE > Classification: UNCLASSIFIED > Caveats: NONE > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 05 17:42:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyF8k-0001Y5-Kc; Wed, 05 Jul 2006 17:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyF8k-0001Xl-91 for nsis@ietf.org; Wed, 05 Jul 2006 17:42:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyF8i-0000gY-O1 for nsis@ietf.org; Wed, 05 Jul 2006 17:42:34 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2006 14:42:32 -0700 X-IronPort-AV: i="4.06,210,1149490800"; d="scan'208"; a="432850036:sNHT35997076" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k65LgVgh002108; Wed, 5 Jul 2006 14:42:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k65LgVCU012707; Wed, 5 Jul 2006 14:42:31 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jul 2006 14:42:31 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.104]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jul 2006 14:42:30 -0700 Message-Id: <4.3.2.7.2.20060705164104.032a9ca0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Jul 2006 16:42:29 -0500 To: ken carlberg , "Nguyen, An P CIV NCS NC2" From: "James M. Polk" Subject: Re: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) In-Reply-To: <62D84945-0258-4C16-8314-24190BF0EE3E@g11.org.uk> References: <9B4320CC9BC1D847AFFA97F25A422A59A97291@vanualevu.disanet.disa-u.mil> <9B4320CC9BC1D847AFFA97F25A422A59A97291@vanualevu.disanet.disa-u.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 05 Jul 2006 21:42:30.0810 (UTC) FILETIME=[EAD83FA0:01C6A07B] DKIM-Signature: a=rsa-sha1; q=dns; l=4096; t=1152135751; x=1152999751; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20RPH=20nits=20Re=3A=20[NSIS]=20QSPEC=20Comment=3A=20Mandatory=20A ttribute=0A=20=20List=20(UNCLASSIFIED); X=v=3Dcisco.com=3B=20h=3D649EGsQ+l3RvrQIC7nXxb6ZeD5U=3D; b=DSB0/FjAxcgZByJvfh4zcVjZ0Ow6G/R7AxkxdSgU2KkTYXuV9N+roHERrOn1hjYuufAYePke xpagTFDgs9o88R8WKhRalLw0t5LeyNruBpVl375Tfw9rwPR7dV3O60BW; Authentication-Results: sj-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: John Rosenberg , "Attila Bader \(IJ/ETH\)" , Kappler Cornelia , NSIS , "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org At 05:00 PM 7/5/2006 -0400, ken carlberg wrote: >Another thought is to just remove the example DISA-related values >from the QSPEC and simply have them registered later through IANA by >the interested party. >The critical thing for the QSPEC is to have >the structure/container that can hold the values and not the values >themselves. This is an interesting idea. Design the container and the semantics, but=20 leave the values for later assignment. I like it. >-ken > > >On Jul 5, 2006, at 4:27 PM, Nguyen, An P CIV NCS NC2 wrote: > >>Classification: UNCLASSIFIED >>Caveats: NONE >> >>My next question is: how can you reference it in the ID if it is >>not publicly available? This leads to my next question: for >>security, is DISA comfortable with having its MLPP spec being >>discussed here? >> >>An >> >>-----Original Message----- >>From: John Rosenberg [mailto:jrrosenberg@lucent.com] >>Sent: Wednesday, July 05, 2006 4:04 PM >>To: Nguyen, An P CIV NCS NC2; Ash, Gerald R (Jerry), ALABS; Janet P >>Gunn >>Cc: Kappler Cornelia; Attila Bader (IJ/ETH); NSIS >>Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute >>List >>(UNCLASSIFIED) >> >> >>No, not yet. >> >>At 02:52 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: >>>Classification: UNCLASSIFIED >>>Caveats: NONE >>> >>>Janet, >>> >>>Just a question: Is the DISA specification publicly available? >>> >>>An >>> >>>-----Original Message----- >>>From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>>Sent: Monday, July 03, 2006 8:07 PM >>>To: Janet P Gunn >>>Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader >>>(IJ/ETH); NSIS; John Rosenberg >>>Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory >>>Attribute List >>> >>> >>>Hi Janet, >>> >>>See below. >>> >>>>-----Original Message----- >>>>From: Janet P Gunn [mailto:jgunn6@csc.com] >>>>Sent: Monday, July 03, 2006 10:14 AM >>>>To: Ash, Gerald R (Jerry), ALABS >>>>Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH) >>>>Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List >>>> >>>>Nits with regard to RPH. >>>> >>>>References should be updated to include RFC4412 (instead of >>>>just the ID) >>>> >>>>In section 7.2.7.3 you show a mapping between the text values >>>>and numeric >>>>values for RPH priority. (The mappings for ets and wps are fine) >>>> >>>>For dsn and drsn you show >>>> >>>> 4 - dsn.routine >>>> 3 - dsn.priority >>>> 2 - dsn.immediate >>>> 1 - dsn.flash >>>> 0 - dsn.flash-override >>>> >>>> 5 - drsn.routine >>>> 4 - drsn.priority >>>> 3 - drsn.immediate >>>> 2 - drsn.flash >>>> 1 - drsn.flash-override >>>> 0 - drsn.flash-override-override >>>> >>>>You might want to check with the intended users of those >>>>namesapces, as I >>>>understand (see recent email on the IEPREP mailing list) that >>>>DISA intends >>>>to use a quite different numerical mapping, with "0" for >>>>routine in all >>>>cases. >>>> >>>>"The current DISA specification for MLPP on VoIP networks >>>>specifies RPH >>>>r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of >>>>priority (e.g. >>>>0 =3D Routine and 9 =3D F-O-O)." >>>> >>>>It will be very confusing if one numeric mapping is used in SIP >>>>and a >>>>different, opposing, mapping is used in QSPEC. >>> >>>Agreed. We'll check the referenced specification and align the >>>mapping in >>>the QSPEC. >>> >>>Thanks a lot for pointing this out. >>> >>>Jerry >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>>Classification: UNCLASSIFIED >>>Caveats: NONE >>Classification: UNCLASSIFIED >>Caveats: NONE >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 05 21:27:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyIeJ-0005c8-VY; Wed, 05 Jul 2006 21:27:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyIeJ-0005c3-Bh for nsis@ietf.org; Wed, 05 Jul 2006 21:27:23 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyIeI-0005ol-2U for nsis@ietf.org; Wed, 05 Jul 2006 21:27:23 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k661RLdw005867; Wed, 5 Jul 2006 21:27:21 -0400 (EDT) In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59A9728E@vanualevu.disanet.disa-u.mil> Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) To: "Nguyen, An P CIV NCS NC2" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Wed, 5 Jul 2006 21:27:17 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/05/2006 09:26:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: "Ash, Gerald R \(Jerry\), ALABS" , Kappler Cornelia , John Rosenberg , NSIS , "Attila Bader \(IJ/ETH\)" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org An, I don't know if it is publicly available or not, which is why I was car= eful to quote from what had been posted on the IEPREP mailing list, instead = of from the spec itself. Janet -----------------------------------------------------------------------= -----------------------------------------------------------------------= ---------------------------------- This is a PRIVATE message. If you are not the intended recipient, pleas= e 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 wri= tten agreement or government initiative expressly permitting the use of e-ma= il for such purpose. -----------------------------------------------------------------------= -----------------------------------------------------------------------= ---------------------------------- "Nguyen, An P CIV NCS NC2" wrote on 07/05/2006 03:52:39 PM: > Classification: UNCLASSIFIED > Caveats: NONE > > Janet, > > Just a question: Is the DISA specification publicly available? > > An > > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: Monday, July 03, 2006 8:07 PM > To: Janet P Gunn > Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader > (IJ/ETH); NSIS; John Rosenberg > Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute L= ist > > > Hi Janet, > > See below. > > > -----Original Message----- > > From: Janet P Gunn [mailto:jgunn6@csc.com] > > Sent: Monday, July 03, 2006 10:14 AM > > To: Ash, Gerald R (Jerry), ALABS > > Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH)= > > Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute Lis= t > > > > Nits with regard to RPH. > > > > References should be updated to include RFC4412 (instead of > > just the ID) > > > > In section 7.2.7.3 you show a mapping between the text values > > and numeric > > values for RPH priority. (The mappings for ets and wps are fine) > > > > For dsn and drsn you show > > > > 4 - dsn.routine > > 3 - dsn.priority > > 2 - dsn.immediate > > 1 - dsn.flash > > 0 - dsn.flash-override > > > > 5 - drsn.routine > > 4 - drsn.priority > > 3 - drsn.immediate > > 2 - drsn.flash > > 1 - drsn.flash-override > > 0 - drsn.flash-override-override > > > > You might want to check with the intended users of those > > namesapces, as I > > understand (see recent email on the IEPREP mailing list) that > > DISA intends > > to use a quite different numerical mapping, with "0" for > > routine in all > > cases. > > > > "The current DISA specification for MLPP on VoIP networks > > specifies RPH > > r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of > > priority (e.g. > > 0 =3D Routine and 9 =3D F-O-O)." > > > > It will be very confusing if one numeric mapping is used in SIP an= d a > > different, opposing, mapping is used in QSPEC. > > Agreed. We'll check the referenced specification and align the > mapping in the QSPEC. > > Thanks a lot for pointing this out. > > Jerry > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > Classification: UNCLASSIFIED > Caveats: NONE >= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 07:04:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyReK-0002Q2-3x; Thu, 06 Jul 2006 07:04:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyReJ-0002Pu-CA for nsis@ietf.org; Thu, 06 Jul 2006 07:03:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyR4o-0005NQ-VF for nsis@ietf.org; Thu, 06 Jul 2006 06:27:18 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyQpB-0001ne-Oo for nsis@ietf.org; Thu, 06 Jul 2006 06:11:12 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k66AAnCv019469; Thu, 6 Jul 2006 11:10:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: IANA Consideration Section Date: Thu, 6 Jul 2006 11:10:49 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: IANA Consideration Section Thread-Index: Acaednw2toZKuFqyS7CfNcE9Qm/SxQCZswCg From: "Hancock, Robert" To: "Hannes Tschofenig" , "Ash, Gerald R \(Jerry\), ALABS" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Kappler Cornelia , NSIS , =?iso-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, some comments on the 'reserved' bits (no pun intended): > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 03 July 2006 08:57 > To: Ash, Gerald R (Jerry), ALABS > Cc: "Attila B=E1der (IJ/ETH)"; NSIS; Kappler Cornelia > Subject: Re: [NSIS] QSPEC Comment: IANA Consideration Section >=20 >=20 > Hi Jerry, >=20 > thanks for your quick feedback. > Please find my comment below: >=20 > Ash, Gerald R (Jerry), ALABS wrote: > > Hi Hannes, > >=20 > > See below. > >=20 > >=20 > >> -----Original Message----- From: Hannes Tschofenig > >> [mailto:Hannes.Tschofenig@gmx.net] Sent: Sunday, July 02, 2006 6:01 > >> AM To: NSIS Subject: [NSIS] QSPEC Comment: IANA Consideration > >> Section > >>=20 > >> Hi QSPEC authors, > >>=20 > >> let me comment on the IANA consideration section. [snip] > >> [hannes] What does 'reserved' mean? The Object Type has 12 bits and > >> according to Section 7 all of them are used. > >=20 > >=20 > > I'm not sure of your question, Section 9 says: > >=20 > > Object Types (12 bits): The following values are allocated by this > > specification: 0-4: assigned as specified in Section 7. The > > allocation policies for further values are as follows: 5-63: > > Standards Action 64-127: Private/Experimental Use 128-4095: Reserved > >=20 > > This is how the 12 bits are used in the registry. Perhaps your > > question pertains to the "Reserved" above? >=20 > The packet format looks as follows: >=20 >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R|E|r|r| Object Type |r|r|r|r| Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The Object Type has 12 bytes but in the IANA consideration=20 > section you=20 > define more bytes as reserved. This means: A few bytes are=20 > reserved in=20 > the Object Type and then followed by a few bytes that are reserved. >=20 > The meaning of the two reserved is different: The 'r's from the above=20 > figure indicate padding and the other reserved mean for=20 > undefined future=20 > use. Then, there are the 'r's at the beginning of the object=20 > that mean=20 > 'will be specified if you add something to the registry'. >=20 > Sounds confusing to me. i think it is true that there are two sorts of 'reserved' here: 1) there are the bits marked 'r' in the object header 2) there are the values for Object Type listed as 'Reserved' in the IANA section. the first type could conceptually be used in a future spec revision to define additional flags which apply to the processing of existing and new objects. conceptually i suppose you could discuss these flag bits in the IANA section (as Diameter does, section 11.2.2 of 3588), but since in each case new flag bits can only be defined by a standards action I don't really see the point. In other words, the existence of these flag bits should not be relevant to the IANA section. >=20 >=20 >=20 > Here the specified range > > designated as 'reserved' is a normal use of allocated space in a > > registry that is reserved for future definition by a specification. > > Future specifications can redefine the registry allocations, and > > allocate more space to various designations, as necessary=20 > (e.g., more > > space allocated to "Standards Action" or to "Private/Experimental > > Use", etc.). >=20 > I am not so sure that this is common and useful practice. > The IANA consideration section already indicates that a=20 > fraction of the=20 > namespace requires standards track actions. this is similar to what is in the GIST spec, and to me it just seems like common sense. basically, you could parcel up the whole registry (4096 values) for different allocation policies, but what happens if you get the division wrong and run out of (for example) expert review space in 3 years? you would have to start stealing codes from other parts of the registry. leaving a Reserved chunk allows a second chance at getting the division right in the light of some deployment = experience. (see also = http://www1.ietf.org/mail-archive/web/nsis/current/msg06337.html for this discussion of this topic in the GIST context). r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 07:09:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRj9-00030V-UZ; Thu, 06 Jul 2006 07:08:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRj9-00030Q-51 for nsis@ietf.org; Thu, 06 Jul 2006 07:08:59 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FyRj6-0004or-Mx for nsis@ietf.org; Thu, 06 Jul 2006 07:08:59 -0400 Received: (qmail invoked by alias); 06 Jul 2006 11:08:54 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp037) with SMTP; 06 Jul 2006 13:08:54 +0200 X-Authenticated: #29516787 Message-ID: <44ACEF46.2040700@gmx.net> Date: Thu, 06 Jul 2006 13:08:54 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] QSPEC Comment: IANA Consideration Section References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?ISO-8859-1?Q?tila_B=E1der_=28IJ/ETH=29=22?= , Kappler Cornelia , NSIS , =?ISO-8859-1?Q?=22At?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, > > i think it is true that there are two sorts of 'reserved' here: > 1) there are the bits marked 'r' in the object header > 2) there are the values for Object Type listed as 'Reserved' in the > IANA section. > > the first type could conceptually be used in a future spec revision > to define additional flags which apply to the processing of existing > and new objects. conceptually i suppose you could discuss these flag > bits in the IANA section (as Diameter does, section 11.2.2 of 3588), > but since in each case new flag bits can only be defined by a standards > action I don't really see the point. In other words, the existence > of these flag bits should not be relevant to the IANA section. > I think that there are better ways to provide the ability to extend functionality in the future. The current approach is confusing. The easiest way is to register a namespace with IANA and provide guidelines for allocation of new values. > >> >> >> Here the specified range >> >>>designated as 'reserved' is a normal use of allocated space in a >>>registry that is reserved for future definition by a specification. >>>Future specifications can redefine the registry allocations, and >>>allocate more space to various designations, as necessary >> >>(e.g., more >> >>>space allocated to "Standards Action" or to "Private/Experimental >>>Use", etc.). >> >>I am not so sure that this is common and useful practice. >>The IANA consideration section already indicates that a >>fraction of the >>namespace requires standards track actions. > > > this is similar to what is in the GIST spec, and to me it just seems > like common sense. basically, you could parcel up the whole registry > (4096 values) for different allocation policies, but what happens if > you get the division wrong and run out of (for example) expert review > space in 3 years? you would have to start stealing codes from other > parts of the registry. leaving a Reserved chunk allows a second chance > at getting the division right in the light of some deployment experience. > (see also http://www1.ietf.org/mail-archive/web/nsis/current/msg06337.html > for this discussion of this topic in the GIST context). If this is the intention of this approach then maybe it would be worth adding a few lines somewhere. The link to the previous discussions seems to support my comment that the intention of the reserved space is misleading. I wonder whether IANA knows what todo when it sees the stuff. Ciao Hannes > > r. > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 07:49:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySMW-0001P6-CY; Thu, 06 Jul 2006 07:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySMV-0001P1-4I for nsis@ietf.org; Thu, 06 Jul 2006 07:49:39 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FySMU-00081L-L0 for nsis@ietf.org; Thu, 06 Jul 2006 07:49:39 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k66Bn7Dq003671; Thu, 6 Jul 2006 12:49:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: IANA Consideration Section Date: Thu, 6 Jul 2006 12:49:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: IANA Consideration Section Thread-Index: Acag7KL3IkDasQe2R+CBZZ46lG9v4wABQ7KA From: "Hancock, Robert" To: "Hannes Tschofenig" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: "Ash, Gerald R \(Jerry\), ALABS" , Kappler Cornelia , NSIS , =?iso-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 06 July 2006 12:09 > To: Hancock, Robert > Cc: Ash, Gerald R (Jerry), ALABS; "Attila B=E1der (IJ/ETH)";=20 > NSIS; Kappler Cornelia > Subject: Re: [NSIS] QSPEC Comment: IANA Consideration Section >=20 >=20 > Hi Robert, >=20 > >=20 > > i think it is true that there are two sorts of 'reserved' here: > > 1) there are the bits marked 'r' in the object header > > 2) there are the values for Object Type listed as 'Reserved' in the > > IANA section. > >=20 > > the first type could conceptually be used in a future spec revision > > to define additional flags which apply to the processing of existing > > and new objects. conceptually i suppose you could discuss these flag > > bits in the IANA section (as Diameter does, section 11.2.2 of 3588), > > but since in each case new flag bits can only be defined by a = standards > > action I don't really see the point. In other words, the existence > > of these flag bits should not be relevant to the IANA section. > >=20 >=20 > I think that there are better ways to provide the ability to extend=20 > functionality in the future. The current approach is confusing. >=20 > The easiest way is to register a namespace with IANA and provide=20 > guidelines for allocation of new values. i'm not sure what you are recommending here. that the 'r' bits are hard coded as 0? or something else? sometimes new functionality doesn't require a whole new namespace. >=20 > >=20 > >> > >> > >> Here the specified range > >> > >>>designated as 'reserved' is a normal use of allocated space in a > >>>registry that is reserved for future definition by a specification. > >>>Future specifications can redefine the registry allocations, and > >>>allocate more space to various designations, as necessary=20 > >> > >>(e.g., more > >> > >>>space allocated to "Standards Action" or to "Private/Experimental > >>>Use", etc.). > >> > >>I am not so sure that this is common and useful practice. > >>The IANA consideration section already indicates that a=20 > >>fraction of the=20 > >>namespace requires standards track actions. > >=20 > >=20 > > this is similar to what is in the GIST spec, and to me it just seems > > like common sense. basically, you could parcel up the whole registry > > (4096 values) for different allocation policies, but what happens if > > you get the division wrong and run out of (for example)=20 > expert review > > space in 3 years? you would have to start stealing codes from other > > parts of the registry. leaving a Reserved chunk allows a=20 > second chance > > at getting the division right in the light of some=20 > deployment experience. > > (see also=20 > http://www1.ietf.org/mail-archive/web/nsis/current/msg06337.html > > for this discussion of this topic in the GIST context). > If this is the intention of this approach then maybe it would=20 > be worth=20 > adding a few lines somewhere. The link to the previous=20 > discussions seems=20 > to support my comment that the intention of the reserved space is=20 > misleading. I wonder whether IANA knows what todo when it=20 > sees the stuff. i agree that more explanation never hurts, up to a point.=20 however, i went through the GIST IANA considerations with IANA people in Vancouver and they seemed happy with them. the problem isn't with the instruction itself ('Reserved' just means 'don't=20 give these out' which is pretty easy to follow), but with the motivation for the instruction. r. >=20 > Ciao > Hannes >=20 >=20 > >=20 > > r. > >=20 > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 07:54:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySQf-0001hi-CZ; Thu, 06 Jul 2006 07:53:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySQd-0001hd-Rz for nsis@ietf.org; Thu, 06 Jul 2006 07:53:55 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FySQc-0008Kj-D8 for nsis@ietf.org; Thu, 06 Jul 2006 07:53:55 -0400 Received: (qmail invoked by alias); 06 Jul 2006 11:53:50 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp039) with SMTP; 06 Jul 2006 13:53:50 +0200 X-Authenticated: #29516787 Message-ID: <44ACF9CD.2040602@gmx.net> Date: Thu, 06 Jul 2006 13:53:49 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] QSPEC Comment: IANA Consideration Section References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?ISO-8859-1?Q?tila_B=E1der_=28IJ/ETH=29=22?= , Kappler Cornelia , NSIS , =?ISO-8859-1?Q?=22At?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Hancock, Robert wrote: > hi, > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: 06 July 2006 12:09 >>To: Hancock, Robert >>Cc: Ash, Gerald R (Jerry), ALABS; "Attila Báder (IJ/ETH)"; >>NSIS; Kappler Cornelia >>Subject: Re: [NSIS] QSPEC Comment: IANA Consideration Section >> >> >>Hi Robert, >> >> >>>i think it is true that there are two sorts of 'reserved' here: >>>1) there are the bits marked 'r' in the object header >>>2) there are the values for Object Type listed as 'Reserved' in the >>> IANA section. >>> >>>the first type could conceptually be used in a future spec revision >>>to define additional flags which apply to the processing of existing >>>and new objects. conceptually i suppose you could discuss these flag >>>bits in the IANA section (as Diameter does, section 11.2.2 of 3588), >>>but since in each case new flag bits can only be defined by a standards >>>action I don't really see the point. In other words, the existence >>>of these flag bits should not be relevant to the IANA section. >>> >> >>I think that there are better ways to provide the ability to extend >>functionality in the future. The current approach is confusing. >> >>The easiest way is to register a namespace with IANA and provide >>guidelines for allocation of new values. > > > i'm not sure what you are recommending here. that the 'r' bits are > hard coded as 0? or something else? The 'r' bit in the object header unless it has the meaning of (2). > > sometimes new functionality doesn't require a whole new namespace. > > >>>> >>>> Here the specified range >>>> >>>> >>>>>designated as 'reserved' is a normal use of allocated space in a >>>>>registry that is reserved for future definition by a specification. >>>>>Future specifications can redefine the registry allocations, and >>>>>allocate more space to various designations, as necessary >>>> >>>>(e.g., more >>>> >>>> >>>>>space allocated to "Standards Action" or to "Private/Experimental >>>>>Use", etc.). >>>> >>>>I am not so sure that this is common and useful practice. >>>>The IANA consideration section already indicates that a >>>>fraction of the >>>>namespace requires standards track actions. >>> >>> >>>this is similar to what is in the GIST spec, and to me it just seems >>>like common sense. basically, you could parcel up the whole registry >>>(4096 values) for different allocation policies, but what happens if >>>you get the division wrong and run out of (for example) >> >>expert review >> >>>space in 3 years? you would have to start stealing codes from other >>>parts of the registry. leaving a Reserved chunk allows a >> >>second chance >> >>>at getting the division right in the light of some >> >>deployment experience. >> >>>(see also >> >>http://www1.ietf.org/mail-archive/web/nsis/current/msg06337.html >> >>>for this discussion of this topic in the GIST context). >> >>If this is the intention of this approach then maybe it would >>be worth >>adding a few lines somewhere. The link to the previous >>discussions seems >> to support my comment that the intention of the reserved space is >>misleading. I wonder whether IANA knows what todo when it >>sees the stuff. > > > i agree that more explanation never hurts, up to a point. > > however, i went through the GIST IANA considerations with IANA > people in Vancouver and they seemed happy with them. the problem > isn't with the instruction itself ('Reserved' just means 'don't > give these out' which is pretty easy to follow), but with the > motivation for the instruction. Why not to just add one line saying this? It would someone like me help to understand the document. Ciao Hannes > > r. > > >>Ciao >>Hannes >> >> >> >>>r. >>> >>> >> >> > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 08:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTDf-0004F1-D1; Thu, 06 Jul 2006 08:44:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyE2Y-000222-K0 for nsis@ietf.org; Wed, 05 Jul 2006 16:32:06 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyE2W-000221-7r for nsis@ietf.org; Wed, 05 Jul 2006 16:32:06 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k65KVsZq027410; Wed, 5 Jul 2006 15:31:54 -0500 (CDT) Received: from jrrosenberg-04.lucent.com ([135.185.233.167]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k65KVru07282; Wed, 5 Jul 2006 15:31:53 -0500 (CDT) Message-Id: <6.2.1.2.0.20060705152836.0315d0d8@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 05 Jul 2006 15:31:52 -0500 To: "Nguyen, An P CIV NCS NC2" , "Ash, Gerald R \(Jerry\), ALABS" , "Janet P Gunn" From: John Rosenberg Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59A97291@vanualevu.disanet.d isa-u.mil> References: <6.2.1.2.0.20060705150330.033b03b0@ihmail.ih.lucent.com> <9B4320CC9BC1D847AFFA97F25A422A59A97291@vanualevu.disanet.disa-u.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-Mailman-Approved-At: Thu, 06 Jul 2006 08:44:34 -0400 Cc: "Attila Bader \(IJ/ETH\)" , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org DISA's current (mostly TDM) MLPP spec is publicly available, and I believe= =20 that their SIP-based spec will be too, whenever they get done with it. Having said that, I don't know what the best way, or even a good way, is to= =20 reference their current rather closely-held draft. John At 03:27 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >My next question is: how can you reference it in the ID if it is not >publicly available? This leads to my next question: for security, is DISA >comfortable with having its MLPP spec being discussed here? > >An > >-----Original Message----- >From: John Rosenberg [mailto:jrrosenberg@lucent.com] >Sent: Wednesday, July 05, 2006 4:04 PM >To: Nguyen, An P CIV NCS NC2; Ash, Gerald R (Jerry), ALABS; Janet P Gunn >Cc: Kappler Cornelia; Attila Bader (IJ/ETH); NSIS >Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List >(UNCLASSIFIED) > > >No, not yet. > >At 02:52 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: > >Classification: UNCLASSIFIED > >Caveats: NONE > > > >Janet, > > > >Just a question: Is the DISA specification publicly available? > > > >An > > > >-----Original Message----- > >From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > >Sent: Monday, July 03, 2006 8:07 PM > >To: Janet P Gunn > >Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader > >(IJ/ETH); NSIS; John Rosenberg > >Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List > > > > > >Hi Janet, > > > >See below. > > > >> -----Original Message----- > >> From: Janet P Gunn [mailto:jgunn6@csc.com] > >> Sent: Monday, July 03, 2006 10:14 AM > >> To: Ash, Gerald R (Jerry), ALABS > >> Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH) > >> Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List > >> > >> Nits with regard to RPH. > >> > >> References should be updated to include RFC4412 (instead of > >> just the ID) > >> > >> In section 7.2.7.3 you show a mapping between the text values > >> and numeric > >> values for RPH priority. (The mappings for ets and wps are fine) > >> > >> For dsn and drsn you show > >> > >> 4 - dsn.routine > >> 3 - dsn.priority > >> 2 - dsn.immediate > >> 1 - dsn.flash > >> 0 - dsn.flash-override > >> > >> 5 - drsn.routine > >> 4 - drsn.priority > >> 3 - drsn.immediate > >> 2 - drsn.flash > >> 1 - drsn.flash-override > >> 0 - drsn.flash-override-override > >> > >> You might want to check with the intended users of those > >> namesapces, as I > >> understand (see recent email on the IEPREP mailing list) that > >> DISA intends > >> to use a quite different numerical mapping, with "0" for > >> routine in all > >> cases. > >> > >> "The current DISA specification for MLPP on VoIP networks > >> specifies RPH > >> r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of > >> priority (e.g. > >> 0 =3D Routine and 9 =3D F-O-O)." > >> > >> It will be very confusing if one numeric mapping is used in SIP and a > >> different, opposing, mapping is used in QSPEC. > > > >Agreed. We'll check the referenced specification and align the mapping= in > >the QSPEC. > > > >Thanks a lot for pointing this out. > > > >Jerry > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > >Classification: UNCLASSIFIED > >Caveats: NONE >Classification: UNCLASSIFIED >Caveats: NONE _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 08:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTDf-0004Eg-4n; Thu, 06 Jul 2006 08:44:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDbC-0002EC-PD for nsis@ietf.org; Wed, 05 Jul 2006 16:03:50 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyDbA-0008Gw-Dy for nsis@ietf.org; Wed, 05 Jul 2006 16:03:50 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k65K3hmI006880; Wed, 5 Jul 2006 15:03:44 -0500 (CDT) Received: from jrrosenberg-04.lucent.com ([135.185.233.167]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k65K3hu15219; Wed, 5 Jul 2006 15:03:43 -0500 (CDT) Message-Id: <6.2.1.2.0.20060705150330.033b03b0@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 05 Jul 2006 15:03:42 -0500 To: "Nguyen, An P CIV NCS NC2" , "Ash, Gerald R \(Jerry\), ALABS" , "Janet P Gunn" From: John Rosenberg Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59A9728E@vanualevu.disanet.d isa-u.mil> References: <9473683187ADC049A855ED2DA739ABCA0DDC7A76@KCCLUST06EVS1.ugd.att.com> <9B4320CC9BC1D847AFFA97F25A422A59A9728E@vanualevu.disanet.disa-u.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Thu, 06 Jul 2006 08:44:34 -0400 Cc: "Attila Bader \(IJ/ETH\)" , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org No, not yet. At 02:52 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >Janet, > >Just a question: Is the DISA specification publicly available? > >An > >-----Original Message----- >From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >Sent: Monday, July 03, 2006 8:07 PM >To: Janet P Gunn >Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader >(IJ/ETH); NSIS; John Rosenberg >Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List > > >Hi Janet, > >See below. > >> -----Original Message----- >> From: Janet P Gunn [mailto:jgunn6@csc.com] >> Sent: Monday, July 03, 2006 10:14 AM >> To: Ash, Gerald R (Jerry), ALABS >> Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH) >> Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List >> >> Nits with regard to RPH. >> >> References should be updated to include RFC4412 (instead of >> just the ID) >> >> In section 7.2.7.3 you show a mapping between the text values >> and numeric >> values for RPH priority. (The mappings for ets and wps are fine) >> >> For dsn and drsn you show >> >> 4 - dsn.routine >> 3 - dsn.priority >> 2 - dsn.immediate >> 1 - dsn.flash >> 0 - dsn.flash-override >> >> 5 - drsn.routine >> 4 - drsn.priority >> 3 - drsn.immediate >> 2 - drsn.flash >> 1 - drsn.flash-override >> 0 - drsn.flash-override-override >> >> You might want to check with the intended users of those >> namesapces, as I >> understand (see recent email on the IEPREP mailing list) that >> DISA intends >> to use a quite different numerical mapping, with "0" for >> routine in all >> cases. >> >> "The current DISA specification for MLPP on VoIP networks >> specifies RPH >> r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of >> priority (e.g. >> 0 =3D Routine and 9 =3D F-O-O)." >> >> It will be very confusing if one numeric mapping is used in SIP and a >> different, opposing, mapping is used in QSPEC. > >Agreed. We'll check the referenced specification and align the mapping in >the QSPEC. > >Thanks a lot for pointing this out. > >Jerry > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis >Classification: UNCLASSIFIED >Caveats: NONE _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 08:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTDf-0004F1-D1; Thu, 06 Jul 2006 08:44:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyE2Y-000222-K0 for nsis@ietf.org; Wed, 05 Jul 2006 16:32:06 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyE2W-000221-7r for nsis@ietf.org; Wed, 05 Jul 2006 16:32:06 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k65KVsZq027410; Wed, 5 Jul 2006 15:31:54 -0500 (CDT) Received: from jrrosenberg-04.lucent.com ([135.185.233.167]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k65KVru07282; Wed, 5 Jul 2006 15:31:53 -0500 (CDT) Message-Id: <6.2.1.2.0.20060705152836.0315d0d8@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 05 Jul 2006 15:31:52 -0500 To: "Nguyen, An P CIV NCS NC2" , "Ash, Gerald R \(Jerry\), ALABS" , "Janet P Gunn" From: John Rosenberg Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59A97291@vanualevu.disanet.d isa-u.mil> References: <6.2.1.2.0.20060705150330.033b03b0@ihmail.ih.lucent.com> <9B4320CC9BC1D847AFFA97F25A422A59A97291@vanualevu.disanet.disa-u.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-Mailman-Approved-At: Thu, 06 Jul 2006 08:44:34 -0400 Cc: "Attila Bader \(IJ/ETH\)" , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org DISA's current (mostly TDM) MLPP spec is publicly available, and I believe= =20 that their SIP-based spec will be too, whenever they get done with it. Having said that, I don't know what the best way, or even a good way, is to= =20 reference their current rather closely-held draft. John At 03:27 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >My next question is: how can you reference it in the ID if it is not >publicly available? This leads to my next question: for security, is DISA >comfortable with having its MLPP spec being discussed here? > >An > >-----Original Message----- >From: John Rosenberg [mailto:jrrosenberg@lucent.com] >Sent: Wednesday, July 05, 2006 4:04 PM >To: Nguyen, An P CIV NCS NC2; Ash, Gerald R (Jerry), ALABS; Janet P Gunn >Cc: Kappler Cornelia; Attila Bader (IJ/ETH); NSIS >Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List >(UNCLASSIFIED) > > >No, not yet. > >At 02:52 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: > >Classification: UNCLASSIFIED > >Caveats: NONE > > > >Janet, > > > >Just a question: Is the DISA specification publicly available? > > > >An > > > >-----Original Message----- > >From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > >Sent: Monday, July 03, 2006 8:07 PM > >To: Janet P Gunn > >Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader > >(IJ/ETH); NSIS; John Rosenberg > >Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List > > > > > >Hi Janet, > > > >See below. > > > >> -----Original Message----- > >> From: Janet P Gunn [mailto:jgunn6@csc.com] > >> Sent: Monday, July 03, 2006 10:14 AM > >> To: Ash, Gerald R (Jerry), ALABS > >> Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH) > >> Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List > >> > >> Nits with regard to RPH. > >> > >> References should be updated to include RFC4412 (instead of > >> just the ID) > >> > >> In section 7.2.7.3 you show a mapping between the text values > >> and numeric > >> values for RPH priority. (The mappings for ets and wps are fine) > >> > >> For dsn and drsn you show > >> > >> 4 - dsn.routine > >> 3 - dsn.priority > >> 2 - dsn.immediate > >> 1 - dsn.flash > >> 0 - dsn.flash-override > >> > >> 5 - drsn.routine > >> 4 - drsn.priority > >> 3 - drsn.immediate > >> 2 - drsn.flash > >> 1 - drsn.flash-override > >> 0 - drsn.flash-override-override > >> > >> You might want to check with the intended users of those > >> namesapces, as I > >> understand (see recent email on the IEPREP mailing list) that > >> DISA intends > >> to use a quite different numerical mapping, with "0" for > >> routine in all > >> cases. > >> > >> "The current DISA specification for MLPP on VoIP networks > >> specifies RPH > >> r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of > >> priority (e.g. > >> 0 =3D Routine and 9 =3D F-O-O)." > >> > >> It will be very confusing if one numeric mapping is used in SIP and a > >> different, opposing, mapping is used in QSPEC. > > > >Agreed. We'll check the referenced specification and align the mapping= in > >the QSPEC. > > > >Thanks a lot for pointing this out. > > > >Jerry > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > >Classification: UNCLASSIFIED > >Caveats: NONE >Classification: UNCLASSIFIED >Caveats: NONE _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 08:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTDf-0004Eg-4n; Thu, 06 Jul 2006 08:44:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDbC-0002EC-PD for nsis@ietf.org; Wed, 05 Jul 2006 16:03:50 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyDbA-0008Gw-Dy for nsis@ietf.org; Wed, 05 Jul 2006 16:03:50 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k65K3hmI006880; Wed, 5 Jul 2006 15:03:44 -0500 (CDT) Received: from jrrosenberg-04.lucent.com ([135.185.233.167]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k65K3hu15219; Wed, 5 Jul 2006 15:03:43 -0500 (CDT) Message-Id: <6.2.1.2.0.20060705150330.033b03b0@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 05 Jul 2006 15:03:42 -0500 To: "Nguyen, An P CIV NCS NC2" , "Ash, Gerald R \(Jerry\), ALABS" , "Janet P Gunn" From: John Rosenberg Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59A9728E@vanualevu.disanet.d isa-u.mil> References: <9473683187ADC049A855ED2DA739ABCA0DDC7A76@KCCLUST06EVS1.ugd.att.com> <9B4320CC9BC1D847AFFA97F25A422A59A9728E@vanualevu.disanet.disa-u.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Thu, 06 Jul 2006 08:44:34 -0400 Cc: "Attila Bader \(IJ/ETH\)" , NSIS , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org No, not yet. At 02:52 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >Janet, > >Just a question: Is the DISA specification publicly available? > >An > >-----Original Message----- >From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >Sent: Monday, July 03, 2006 8:07 PM >To: Janet P Gunn >Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader >(IJ/ETH); NSIS; John Rosenberg >Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List > > >Hi Janet, > >See below. > >> -----Original Message----- >> From: Janet P Gunn [mailto:jgunn6@csc.com] >> Sent: Monday, July 03, 2006 10:14 AM >> To: Ash, Gerald R (Jerry), ALABS >> Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH) >> Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List >> >> Nits with regard to RPH. >> >> References should be updated to include RFC4412 (instead of >> just the ID) >> >> In section 7.2.7.3 you show a mapping between the text values >> and numeric >> values for RPH priority. (The mappings for ets and wps are fine) >> >> For dsn and drsn you show >> >> 4 - dsn.routine >> 3 - dsn.priority >> 2 - dsn.immediate >> 1 - dsn.flash >> 0 - dsn.flash-override >> >> 5 - drsn.routine >> 4 - drsn.priority >> 3 - drsn.immediate >> 2 - drsn.flash >> 1 - drsn.flash-override >> 0 - drsn.flash-override-override >> >> You might want to check with the intended users of those >> namesapces, as I >> understand (see recent email on the IEPREP mailing list) that >> DISA intends >> to use a quite different numerical mapping, with "0" for >> routine in all >> cases. >> >> "The current DISA specification for MLPP on VoIP networks >> specifies RPH >> r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of >> priority (e.g. >> 0 =3D Routine and 9 =3D F-O-O)." >> >> It will be very confusing if one numeric mapping is used in SIP and a >> different, opposing, mapping is used in QSPEC. > >Agreed. We'll check the referenced specification and align the mapping in >the QSPEC. > >Thanks a lot for pointing this out. > >Jerry > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis >Classification: UNCLASSIFIED >Caveats: NONE _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 08:59:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTSL-0006wu-Kk; Thu, 06 Jul 2006 08:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTSJ-0006wA-TB for nsis@ietf.org; Thu, 06 Jul 2006 08:59:43 -0400 Received: from ionians.ncr.disa.mil ([164.117.82.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTSJ-0001q4-Jb for nsis@ietf.org; Thu, 06 Jul 2006 08:59:43 -0400 Received: from vanualevu.disanet.disa-u.mil ([164.117.144.226]) by ionians.ncr.disa.mil with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 08:59:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) Date: Thu, 6 Jul 2006 08:59:39 -0400 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A59A97292@vanualevu.disanet.disa-u.mil> in-reply-to: <62D84945-0258-4C16-8314-24190BF0EE3E@g11.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) Thread-Index: AcagdhJfi6cXBRNKSWGK1N/f3lC6mwAha45Q From: "Nguyen, An P CIV NCS NC2" To: "ken carlberg" X-OriginalArrivalTime: 06 Jul 2006 12:59:41.0111 (UTC) FILETIME=[0B75CC70:01C6A0FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: John Rosenberg , NSIS , "Ash, Gerald R \(Jerry\), ALABS" , "Attila Bader \(IJ/ETH\)" , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Classification: UNCLASSIFIED=20 Caveats: NONE Ken, I like your suggestion. An -----Original Message----- From: ken carlberg [mailto:carlberg@g11.org.uk]=20 Sent: Wednesday, July 05, 2006 5:00 PM To: Nguyen, An P CIV NCS NC2 Cc: John Rosenberg; Ash, Gerald R (Jerry), ALABS; Janet P Gunn; Attila = Bader (IJ/ETH); NSIS; Kappler Cornelia Subject: Re: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List = (UNCLASSIFIED) Another thought is to just remove the example DISA-related values =20 from the QSPEC and simply have them registered later through IANA by =20 the interested party. The critical thing for the QSPEC is to have =20 the structure/container that can hold the values and not the values =20 themselves. -ken On Jul 5, 2006, at 4:27 PM, Nguyen, An P CIV NCS NC2 wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > My next question is: how can you reference it in the ID if it is =20 > not publicly available? This leads to my next question: for =20 > security, is DISA comfortable with having its MLPP spec being =20 > discussed here? > > An > > -----Original Message----- > From: John Rosenberg [mailto:jrrosenberg@lucent.com] > Sent: Wednesday, July 05, 2006 4:04 PM > To: Nguyen, An P CIV NCS NC2; Ash, Gerald R (Jerry), ALABS; Janet P =20 > Gunn > Cc: Kappler Cornelia; Attila Bader (IJ/ETH); NSIS > Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute =20 > List > (UNCLASSIFIED) > > > No, not yet. > > At 02:52 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: >> Classification: UNCLASSIFIED >> Caveats: NONE >> >> Janet, >> >> Just a question: Is the DISA specification publicly available? >> >> An >> >> -----Original Message----- >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >> Sent: Monday, July 03, 2006 8:07 PM >> To: Janet P Gunn >> Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader >> (IJ/ETH); NSIS; John Rosenberg >> Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory =20 >> Attribute List >> >> >> Hi Janet, >> >> See below. >> >>> -----Original Message----- >>> From: Janet P Gunn [mailto:jgunn6@csc.com] >>> Sent: Monday, July 03, 2006 10:14 AM >>> To: Ash, Gerald R (Jerry), ALABS >>> Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH) >>> Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List >>> >>> Nits with regard to RPH. >>> >>> References should be updated to include RFC4412 (instead of >>> just the ID) >>> >>> In section 7.2.7.3 you show a mapping between the text values >>> and numeric >>> values for RPH priority. (The mappings for ets and wps are fine) >>> >>> For dsn and drsn you show >>> >>> 4 - dsn.routine >>> 3 - dsn.priority >>> 2 - dsn.immediate >>> 1 - dsn.flash >>> 0 - dsn.flash-override >>> >>> 5 - drsn.routine >>> 4 - drsn.priority >>> 3 - drsn.immediate >>> 2 - drsn.flash >>> 1 - drsn.flash-override >>> 0 - drsn.flash-override-override >>> >>> You might want to check with the intended users of those >>> namesapces, as I >>> understand (see recent email on the IEPREP mailing list) that >>> DISA intends >>> to use a quite different numerical mapping, with "0" for >>> routine in all >>> cases. >>> >>> "The current DISA specification for MLPP on VoIP networks >>> specifies RPH >>> r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of >>> priority (e.g. >>> 0 =3D Routine and 9 =3D F-O-O)." >>> >>> It will be very confusing if one numeric mapping is used in SIP =20 >>> and a >>> different, opposing, mapping is used in QSPEC. >> >> Agreed. We'll check the referenced specification and align the =20 >> mapping in >> the QSPEC. >> >> Thanks a lot for pointing this out. >> >> Jerry >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> Classification: UNCLASSIFIED >> Caveats: NONE > Classification: UNCLASSIFIED > Caveats: NONE > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis Classification: UNCLASSIFIED=20 Caveats: NONE _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 09:44:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyU9E-0006Q3-54; Thu, 06 Jul 2006 09:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyU9C-0006Py-Hp for nsis@ietf.org; Thu, 06 Jul 2006 09:44:02 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyU9C-0005IL-7O for nsis@ietf.org; Thu, 06 Jul 2006 09:44:02 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k66DhvPY008300; Thu, 6 Jul 2006 09:43:57 -0400 (EDT) In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59A97292@vanualevu.disanet.disa-u.mil> Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List (UNCLASSIFIED) To: "Nguyen, An P CIV NCS NC2" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Thu, 6 Jul 2006 09:43:54 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/06/2006 09:42:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 1.2 (+) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: "Ash, Gerald R \(Jerry\), ALABS" , NSIS , John Rosenberg , "Attila Bader \(IJ/ETH\)" , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I do to, Janet -----------------------------------------------------------------------= -----------------------------------------------------------------------= ---------------------------------- This is a PRIVATE message. If you are not the intended recipient, pleas= e 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 wri= tten agreement or government initiative expressly permitting the use of e-ma= il for such purpose. -----------------------------------------------------------------------= -----------------------------------------------------------------------= ---------------------------------- "Nguyen, An P CIV NCS NC2" wrote on 07/06/2006 08:59:39 AM: > Classification: UNCLASSIFIED > Caveats: NONE > > Ken, > > I like your suggestion. > > An > > -----Original Message----- > From: ken carlberg [mailto:carlberg@g11.org.uk] > Sent: Wednesday, July 05, 2006 5:00 PM > To: Nguyen, An P CIV NCS NC2 > Cc: John Rosenberg; Ash, Gerald R (Jerry), ALABS; Janet P Gunn; > Attila Bader (IJ/ETH); NSIS; Kappler Cornelia > Subject: Re: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute > List (UNCLASSIFIED) > > Another thought is to just remove the example DISA-related values > from the QSPEC and simply have them registered later through IANA by > the interested party. The critical thing for the QSPEC is to have > the structure/container that can hold the values and not the values > themselves. > > -ken > > > On Jul 5, 2006, at 4:27 PM, Nguyen, An P CIV NCS NC2 wrote: > > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > My next question is: how can you reference it in the ID if it is > > not publicly available? This leads to my next question: for > > security, is DISA comfortable with having its MLPP spec being > > discussed here? > > > > An > > > > -----Original Message----- > > From: John Rosenberg [mailto:jrrosenberg@lucent.com] > > Sent: Wednesday, July 05, 2006 4:04 PM > > To: Nguyen, An P CIV NCS NC2; Ash, Gerald R (Jerry), ALABS; Janet P= > > Gunn > > Cc: Kappler Cornelia; Attila Bader (IJ/ETH); NSIS > > Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute= > > List > > (UNCLASSIFIED) > > > > > > No, not yet. > > > > At 02:52 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: > >> Classification: UNCLASSIFIED > >> Caveats: NONE > >> > >> Janet, > >> > >> Just a question: Is the DISA specification publicly available? > >> > >> An > >> > >> -----Original Message----- > >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > >> Sent: Monday, July 03, 2006 8:07 PM > >> To: Janet P Gunn > >> Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader > >> (IJ/ETH); NSIS; John Rosenberg > >> Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory > >> Attribute List > >> > >> > >> Hi Janet, > >> > >> See below. > >> > >>> -----Original Message----- > >>> From: Janet P Gunn [mailto:jgunn6@csc.com] > >>> Sent: Monday, July 03, 2006 10:14 AM > >>> To: Ash, Gerald R (Jerry), ALABS > >>> Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ET= H) > >>> Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute L= ist > >>> > >>> Nits with regard to RPH. > >>> > >>> References should be updated to include RFC4412 (instead of > >>> just the ID) > >>> > >>> In section 7.2.7.3 you show a mapping between the text values > >>> and numeric > >>> values for RPH priority. (The mappings for ets and wps are fine) > >>> > >>> For dsn and drsn you show > >>> > >>> 4 - dsn.routine > >>> 3 - dsn.priority > >>> 2 - dsn.immediate > >>> 1 - dsn.flash > >>> 0 - dsn.flash-override > >>> > >>> 5 - drsn.routine > >>> 4 - drsn.priority > >>> 3 - drsn.immediate > >>> 2 - drsn.flash > >>> 1 - drsn.flash-override > >>> 0 - drsn.flash-override-override > >>> > >>> You might want to check with the intended users of those > >>> namesapces, as I > >>> understand (see recent email on the IEPREP mailing list) that > >>> DISA intends > >>> to use a quite different numerical mapping, with "0" for > >>> routine in all > >>> cases. > >>> > >>> "The current DISA specification for MLPP on VoIP networks > >>> specifies RPH > >>> r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of > >>> priority (e.g. > >>> 0 =3D Routine and 9 =3D F-O-O)." > >>> > >>> It will be very confusing if one numeric mapping is used in SIP > >>> and a > >>> different, opposing, mapping is used in QSPEC. > >> > >> Agreed. We'll check the referenced specification and align the > >> mapping in > >> the QSPEC. > >> > >> Thanks a lot for pointing this out. > >> > >> Jerry > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> Classification: UNCLASSIFIED > >> Caveats: NONE > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > Classification: UNCLASSIFIED > Caveats: NONE >= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 10:18:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUgi-0005nu-Av; Thu, 06 Jul 2006 10:18:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUgh-0005k6-5f for nsis@ietf.org; Thu, 06 Jul 2006 10:18:39 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FyUgf-0006xW-NA for nsis@ietf.org; Thu, 06 Jul 2006 10:18:39 -0400 Received: (qmail invoked by alias); 06 Jul 2006 14:18:35 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp032) with SMTP; 06 Jul 2006 16:18:35 +0200 X-Authenticated: #29516787 Message-ID: <44AD1BB9.7030500@gmx.net> Date: Thu, 06 Jul 2006 16:18:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] QSPEC Comment: IANA Consideration Section References: <9473683187ADC049A855ED2DA739ABCA0DDC7A90@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7A90@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: =?ISO-8859-1?Q?=22Atti?=, =?ISO-8859-1?Q?la_B=E1der_=28IJ/ETH=29=22?= , Kappler Cornelia , NSIS , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, I will take the time to talk to the IANA folks by myself about this issue. I am interested to hear what they think about the concept and whether they have experience with it. Ciao Hannes Ash, Gerald R (Jerry), ALABS wrote: > Hi Hannes, > > See below. > > Jerry> Here the specified range > Jerry> designated as 'reserved' is a normal use of allocated space in a > Jerry> registry that is reserved for future definition by a > Jerry> specification. > Jerry> Future specifications can redefine the registry allocations, and > Jerry> allocate more space to various designations, as necessary > Jerry> (e.g., more > Jerry> space allocated to "Standards Action" or to "Private/Experimental > Jerry> Use", etc.). > > Hannes> I am not so sure that this is common and useful practice. > Hannes> The IANA consideration section already indicates that a > Hannes> fraction of the > Hannes> namespace requires standards track actions. > > Robert> this is similar to what is in the GIST spec, and to me it > Robert> just seems > Robert> like common sense. basically, you could parcel up the > Robert> whole registry > Robert> (4096 values) for different allocation policies, but what > Robert> happens if > Robert> you get the division wrong and run out of (for example) > Robert> expert review > Robert> space in 3 years? you would have to start stealing codes from other > Robert> parts of the registry. leaving a Reserved chunk allows a > Robert> second chance > Robert> at getting the division right in the light of some > Robert> deployment experience. > Robert> (see also > Robert> http://www1.ietf.org/mail-archive/web/nsis/current/msg06337.html > Robert> for this discussion of this topic in the GIST context). > > Hannes> If this is the intention of this approach then maybe it would > Hannes> be worth > Hannes> adding a few lines somewhere. The link to the previous > Hannes> discussions seems > Hannes> to support my comment that the intention of the reserved space is > Hannes> misleading. I wonder whether IANA knows what todo when it > Hannes> sees the stuff. > > Robert> i agree that more explanation never hurts, up to a point. > Robert> however, i went through the GIST IANA considerations with IANA > Robert> people in Vancouver and they seemed happy with them. the problem > Robert> isn't with the instruction itself ('Reserved' just means 'don't > Robert> give these out' which is pretty easy to follow), but with the > Robert> motivation for the instruction. > > Hannes> Why not to just add one line saying this? It would someone > Hannes> like me help > Hannes> to understand the document. > > We can add a line of explanation. However, Robert has confirmed that this practice is already understood by IANA, and I believe is common practice for the reasons given by Robert. You have commented also to remove several "explanatory" notes and/or "examples" from the IANA section because they were not needed by IANA. > > Thanks, > Jerry > > >>Ciao >>Hannes > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 10:20:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUic-0000D1-GA; Thu, 06 Jul 2006 10:20:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUib-0000BC-1t for nsis@ietf.org; Thu, 06 Jul 2006 10:20:37 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FyUiY-000760-L3 for nsis@ietf.org; Thu, 06 Jul 2006 10:20:37 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-15.tower-126.messagelabs.com!1152195205!12871806!11 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14793 invoked from network); 6 Jul 2006 14:13:54 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-15.tower-126.messagelabs.com with SMTP; 6 Jul 2006 14:13:54 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452001362EB; Thu, 6 Jul 2006 10:13:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: IANA Consideration Section Date: Thu, 6 Jul 2006 09:13:52 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A90@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44ACF9CD.2040602@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: IANA Consideration Section Thread-Index: Acag8t41X8wUISJrSimVpLm5wpN5zQAEZ7zg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" , "Hancock, Robert" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "Ash, Gerald R \(Jerry\), ALABS" , Kappler Cornelia , NSIS , =?iso-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, See below. Jerry> Here the specified range Jerry> designated as 'reserved' is a normal use of allocated space in a Jerry> registry that is reserved for future definition by a=20 Jerry> specification. Jerry> Future specifications can redefine the registry allocations, and Jerry> allocate more space to various designations, as necessary=20 Jerry> (e.g., more Jerry> space allocated to "Standards Action" or to "Private/Experimental Jerry> Use", etc.). Hannes> I am not so sure that this is common and useful practice. Hannes> The IANA consideration section already indicates that a=20 Hannes> fraction of the=20 Hannes> namespace requires standards track actions. Robert> this is similar to what is in the GIST spec, and to me it=20 Robert> just seems Robert> like common sense. basically, you could parcel up the=20 Robert> whole registry Robert> (4096 values) for different allocation policies, but what=20 Robert> happens if Robert> you get the division wrong and run out of (for example)=20 Robert> expert review Robert> space in 3 years? you would have to start stealing codes from = other Robert> parts of the registry. leaving a Reserved chunk allows a=20 Robert> second chance Robert> at getting the division right in the light of some=20 Robert> deployment experience. Robert> (see also=20 Robert> http://www1.ietf.org/mail-archive/web/nsis/current/msg06337.html Robert> for this discussion of this topic in the GIST context). Hannes> If this is the intention of this approach then maybe it would=20 Hannes> be worth=20 Hannes> adding a few lines somewhere. The link to the previous=20 Hannes> discussions seems=20 Hannes> to support my comment that the intention of the reserved space = is=20 Hannes> misleading. I wonder whether IANA knows what todo when it=20 Hannes> sees the stuff. Robert> i agree that more explanation never hurts, up to a point.=20 Robert> however, i went through the GIST IANA considerations with IANA Robert> people in Vancouver and they seemed happy with them. the problem Robert> isn't with the instruction itself ('Reserved' just means 'don't=20 Robert> give these out' which is pretty easy to follow), but with the Robert> motivation for the instruction. Hannes> Why not to just add one line saying this? It would someone=20 Hannes> like me help=20 Hannes> to understand the document. We can add a line of explanation. However, Robert has confirmed that = this practice is already understood by IANA, and I believe is common = practice for the reasons given by Robert. You have commented also to = remove several "explanatory" notes and/or "examples" from the IANA = section because they were not needed by IANA. Thanks, Jerry =20 > Ciao > Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 10:27:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUor-0000sA-5q; Thu, 06 Jul 2006 10:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUoq-0000s5-FM for nsis@ietf.org; Thu, 06 Jul 2006 10:27:04 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyUop-0007Gv-6r for nsis@ietf.org; Thu, 06 Jul 2006 10:27:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9F70E2009092; Thu, 6 Jul 2006 16:27:24 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24660-09; Thu, 6 Jul 2006 16:27:24 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8C08A20031E6; Thu, 6 Jul 2006 16:27:24 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSIS next steps Date: Thu, 6 Jul 2006 16:27:02 +0200 Message-ID: <6D28EBC684A4D94096217AD2FE40087389BA30@venus.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS next steps Thread-Index: AcacB63nPd9yC1TPTd6lLx4oCyhV0AEHeSjgADg4H2A= From: "Marcus Brunner" To: "Hancock, Robert" , X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Robert, all, =20 > secondly, i'd like to register interest for the 'MRM patterns' document, although this is clearly a longer term activity.=20 =20 Glad to hear your interrest. You might be right with that it is longer term, however, I think depending on how serious you are about GIST being generalized you have to down that path. AS we have seen that two NSLPs defined used a slightly different way, other signalling applications might have some different requirements as well. Mrcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 10:39:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyV0S-0001U1-DE; Thu, 06 Jul 2006 10:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyV0Q-0001Tu-Lq for nsis@ietf.org; Thu, 06 Jul 2006 10:39:02 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyV0P-0007dC-6X for nsis@ietf.org; Thu, 06 Jul 2006 10:39:02 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k66EcxYK015856; Thu, 6 Jul 2006 16:38:59 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k66Ecvnq007051; Thu, 6 Jul 2006 16:38:59 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 16:38:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] NSIS next steps Date: Thu, 6 Jul 2006 16:38:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS next steps thread-index: AcacB63nPd9yC1TPTd6lLx4oCyhV0AEHeSjgADg4H2AAAMtgQA== From: "Tschofenig, Hannes" To: "Marcus Brunner" , "Hancock, Robert" , X-OriginalArrivalTime: 06 Jul 2006 14:38:52.0423 (UTC) FILETIME=[E6B7F170:01C6A109] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Marcus,=20 I was also impressed when I saw the MRM pattern presentation given by = Martin. This is certainly something interesting to take a closer look = at.=20 I wonder whether you have some applications that make use of these = patterns in mind as well. Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Marcus Brunner [mailto:Brunner@netlab.nec.de]=20 > Gesendet: Donnerstag, 6. Juli 2006 16:27 > An: Hancock, Robert; nsis@ietf.org > Betreff: RE: [NSIS] NSIS next steps >=20 > Robert, all, > =20 > > secondly, i'd like to register interest for the 'MRM patterns' > document, although this is clearly a longer term activity.=20 > =20 > Glad to hear your interrest. You might be right with that it is longer > term, however, I think depending on how serious you are about=20 > GIST being > generalized you have to down that path. AS we have seen that two NSLPs > defined used a slightly different way, other signalling applications > might have some different requirements as well. >=20 > Mrcus >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 10:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyV9r-0004a6-9x; Thu, 06 Jul 2006 10:48:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyV9q-0004a1-8m for nsis@ietf.org; Thu, 06 Jul 2006 10:48:46 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyV9o-0008EV-JC for nsis@ietf.org; Thu, 06 Jul 2006 10:48:46 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k66EkC1s001731; Thu, 6 Jul 2006 15:46:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt Date: Thu, 6 Jul 2006 15:43:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt Thread-Index: AcaW/kaTNRc1lr6NTHO3fZd0EYaG7gAAYfvgAILnqHAB/nYSYA== From: "Hancock, Robert" To: , , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, some wglc comments. most are minor/editorial-ish. in general, i thought i could understand the document and follow what it was defining. however, that might be because i am too close to the subject matter to see the ambiguities. i wonder whether there might be value in having space in an appendix for more examples (not that I have anything specific to contribute here). 1) section 4.2 p9 para 3 ("When reserving..."): maybe worth clarifying here that the terms ingress/egress apply to the direction of the RESERVE rather than the direction of the flow. (possibly applies elsewhere.) 2) para 4 but also elsewhere: i found the formatting confusing in=20 several places where lists get run together like this. for example, i can't immediately tell whether the last sentence in the paragraph applies to (c) or to (a) and (b) as well. 3) page 11 last para: this seems to assume that there is an INTSERV-QOSM whereas in fact none is being defined. but it raises a more general point: where in the document to look for a summary of the QOSM concept. To me, it would be good to have a (small) dedicated section somewhere near the start. 4) page 12 para 3 ("Case 1"): I would prefer to replace phrasing like 'the QNx notifies the QNI' with something like 'the QNx generates a RESPONSE'. partly this is because in the past there have been genuine proposals that a QNx could send a message directly to the QNI, and partly because notify may get confused with NOTIFY. people who are fully familiar with the QoS-NSLP spec may be ok with this, but the casual reader may not. (also applies elsewhere.) 5) section 4.4.1: what treatment is required at the QNR?=20 6) section 4.5 page 15 2nd last para, also 4.5.3: I found the tunneling=20 description here rather confusing at first, and eventually came to the conclusion that I don't like the T flag in the first place. my=20 reasoning is as follows: - there are several cases where a QNE has to make a judgement call about whether it has strictly interpreted a parameter or not; in the latter case it can set the flag to say so. - i see the tunnel case as just one more example of this, which is not really special in its own right. - for example, suppose a reservation goes across an MPLS cloud rather than an RSVP aggregation cloud. no T flag would be set in the MPLS case since it's just 1 hop across (a.k.a. the tunnelling is not visible at the IP level). however, do we really believe that the interpretation=20 is any more accurate because of that? 7) section 4.6 last para: i remember this point came up at the last IETF and I still hold the view that it would be more sensible for this information about Qspec-related codepoints to be in the Qspec document. (this information isn't in any case in the extensibility document at the moment.) 8) section 5.2.1: i think the grammar of this section could be more clear about whether the sets of objects on the right hand side of '=3D' are alternatives, things you can have >1 of, options, etc. 9) section 5.2.2, all references to 'queuing delay bound': the discussion seems to imply that this parameter can be carried in the Qspec independently of PL, but I don't see how. (two occurrences in this section.) 10) section 5.2.2: there is no discussion of 11) section 5.2.2: there are multiple references to the QNR having to do something for the egress link for the cumulative parameters. I don't see what this could mean. 12) section 7.1: box diagram says 'Parameter ID' but text says 'Parameter Type' 13) section 7.2.7: i don't see how to relate the multiple priority=20 parameters. What if someone provides both the rfc3181 parameters and the admission/RPH parameters? 14) section 7.2.8/9/10/11: if N is set in these parameters when=20 a QNE receives the message, does it still have to process the parameter value? 15) section 7.2.9: if Y.1541 is needed to define the composition function, it should be a normative reference, and should be referred to from=20 7.2.8 and 7.2.10 as well. OTOH since it is not freely available, would it be possible to include the corresponding formulae here? 16) section 7.2.10/11: i assume the comments about microsecond time resolution are cut&paste artifacts. cheers, robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: 26 June 2006 11:31 > To: gash@att.com; nsis@ietf.org > Subject: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt >=20 >=20 > Hi all, >=20 > Jerry has submitted the QoS NSLP QSPEC Template. You can find the > announcement & Jerry's comments below. >=20 > The WGLC will run until July 7th. After that, Jerry can summarize all > issues and we will discuss them at the next IETF meeting in Montreal. >=20 > thanks, > John=20 >=20 > >-----Original Message----- > >From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > >Sent: 23 June, 2006 23:16 > >To: nsis@ietf.org > >Cc: Ash, Gerald R (Jerry), ALABS > >Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt=20 > > > >Hi All, > > > >The updated 'QoS-NSLP QSPEC Template' I-D is available at=20 > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt. > > > >The updates are in response to comments and discussion since IETF-65: > > > >1. rewrote Section 2 (Introduction) for clarity 2. added=20 > >clarifications on mandatory parameters in Section 4.2; added=20 > >discussion of forwarding options when a domain supports a=20 > >different QOSM than the QNI 3. expanded Section 4.5 on error=20 > >code handling, including redefined E-Flag and editorial=20 > >changes to the N-Flag and T-Flag discussions 4. made some=20 > >editorial clarifications in Section 4.6 on defining new=20 > >mandatory parameters 5. Section 4.7 added to identify what a=20 > >QOSM specification document must include 6. clarified the=20 > >requirements in Section 5 for defining a new QSPEC Version 7.=20 > >made editorial changes to Section 6 (Procedures), and added=20 > >procedures for handling preemption 8. removed QOSM ID=20 > >assignments in Section 9 (IANA Considerations); clarified=20 > >procedures for defining new mandatory parameters; added=20 > >registry for QOSM error codes > > > >There are no further outstanding changes/comments pending and=20 > >no open issues currently identified. > > > >Thanks, > >Regards, > >Jerry=20 > > > >-----Original Message----- > >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >Sent: Friday, June 23, 2006 3:50 PM > >To: i-d-announce@ietf.org > >Cc: nsis@ietf.org > >Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt=20 > > > >A New Internet-Draft is available from the on-line=20 > >Internet-Drafts directories. > >This draft is a work item of the Next Steps in Signaling=20 > >Working Group of the IETF. > > > > Title : QoS NSLP QSPEC Template > > Author(s) : J. Ash, et al. > > Filename : draft-ietf-nsis-qspec-10.txt > > Pages : 53 > > Date : 2006-6-23 > >=09 > >The QoS NSLP protocol is used to signal QoS reservations and=20 > >is independent of a specific QoS model (QOSM) such as IntServ=20 > >or DiffServ. Rather, all information specific to a QOSM is=20 > >encapsulated in a separate object, the QSPEC. This document=20 > >defines a template for the QSPEC, which contains both the QoS=20 > >description and QSPEC control information. The QSPEC format is=20 > >defined, as are a number of QSPEC parameters. The QSPEC=20 > >parameters provide a common language to be re-used in several=20 > >QOSMs. To a certain extent QSPEC parameters ensure=20 > >interoperability of QOSMs. Optional QSPEC parameters aim to=20 > >ensure the extensibility of QoS NSLP to other QOSMs in the future. > >The node initiating the NSIS signaling adds an Initiator QSPEC=20 > >that must not be removed, thereby ensuring the intention of=20 > >the NSIS initiator is preserved along the signaling path. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 06 15:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZGv-000213-8A; Thu, 06 Jul 2006 15:12:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZGt-00020R-SH for nsis@ietf.org; Thu, 06 Jul 2006 15:12:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWmH-0003gK-OY for nsis@ietf.org; Thu, 06 Jul 2006 12:32:33 -0400 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FyWaB-0008Dv-PC for nsis@ietf.org; Thu, 06 Jul 2006 12:20:05 -0400 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Thu, 06 Jul 2006 18:19:29 +0200 Received: from [172.27.99.67] ([172.27.99.67]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 6 Jul 2006 18:19:27 +0200 Message-ID: <44AD380F.1060902@docomolab-euro.com> Date: Thu, 06 Jul 2006 18:19:27 +0200 From: mendes User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: AW: [NSIS] NSIS next steps References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Jul 2006 16:19:27.0414 (UTC) FILETIME=[F3DA7D60:01C6A117] X-Spam-Score: -2.6 (--) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Marcus and all, I would like to express interest on the MRM pattern (I had already done it in Dallas after Martin's presentation). As for Hannes question about applications that may make use of this MRM, I can mention one: a different type of interDomain-QoSM as the one that will be presented in Montreal (draft-zhang-nsis-interdomain-qosm-02): - the draft to be presented in Montreal makes use of the new off-path MRM to break the end-to-end QoS signaling into inter-domain and intra-domain. - with the MRM pattern the inter-domain signaling may be done in a different way, starting by the QoS-controller that triggers the navigation pattern. For instance: - one QoS-controller may explore/monitor the capacity of neighbour networks (QoS-controllers) with a TTL defined in the query message and use the returned information to dimension its network. - one QoS-controller may announce its own capability to its neighbours with a TTL defined in the query, and to collect the interest of other networks to make use of that capability. Another application may be to configuration over dispersed nodes, such as sensors, and to collect sensing information. Cheers Paulo Tschofenig, Hannes wrote: > Hi Marcus, > > I was also impressed when I saw the MRM pattern presentation given by Martin. This is certainly something interesting to take a closer look at. > > I wonder whether you have some applications that make use of these patterns in mind as well. > > Ciao > Hannes > > > >> -----Ursprüngliche Nachricht----- >> Von: Marcus Brunner [mailto:Brunner@netlab.nec.de] >> Gesendet: Donnerstag, 6. Juli 2006 16:27 >> An: Hancock, Robert; nsis@ietf.org >> Betreff: RE: [NSIS] NSIS next steps >> >> Robert, all, >> >> >>> secondly, i'd like to register interest for the 'MRM patterns' >>> >> document, although this is clearly a longer term activity. >> >> Glad to hear your interrest. You might be right with that it is longer >> term, however, I think depending on how serious you are about >> GIST being >> generalized you have to down that path. AS we have seen that two NSLPs >> defined used a slightly different way, other signalling applications >> might have some different requirements as well. >> >> Mrcus >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 07 05:03:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FymFe-0006Ry-NI; Fri, 07 Jul 2006 05:03:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FymFc-0006Rt-UU for nsis@ietf.org; Fri, 07 Jul 2006 05:03:52 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FymFb-0004wv-G7 for nsis@ietf.org; Fri, 07 Jul 2006 05:03:52 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6793dIr027133; Fri, 7 Jul 2006 10:03:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSIS next steps Date: Fri, 7 Jul 2006 09:48:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS next steps Thread-Index: AcacB63nPd9yC1TPTd6lLx4oCyhV0AEHeSjgADg4H2AAJsUi0A== From: "Hancock, Robert" To: "Marcus Brunner" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, > -----Original Message----- > From: Marcus Brunner [mailto:Brunner@netlab.nec.de]=20 > Sent: 06 July 2006 15:27 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] NSIS next steps >=20 >=20 > Robert, all, > =20 > > secondly, i'd like to register interest for the 'MRM patterns' > document, although this is clearly a longer term activity.=20 > =20 > Glad to hear your interrest. You might be right with that it is longer > term, however, I think depending on how serious you are about=20 > GIST being > generalized you have to down that path. no doubting that this work is important. the point i was more trying to raise was for the other items i mentioned, i think the problem and the deliverable that would address it are pretty well understood, whereas in this case the scope itself needs a bit of discussion. are we looking at PS extensions to GIST? or the signalling applications that need them as well? or experimentals? or a frameworky discussion? i guess these are appropriate topics for a rechartering discussion. r. > AS we have seen that two NSLPs > defined used a slightly different way, other signalling applications > might have some different requirements as well. >=20 > Mrcus >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 07 05:18:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FymTm-0007Jk-AB; Fri, 07 Jul 2006 05:18:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FymTl-0007JS-HX for nsis@ietf.org; Fri, 07 Jul 2006 05:18:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FylRP-0007uR-C5 for nsis@ietf.org; Fri, 07 Jul 2006 04:11:59 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FylIJ-0005x9-BL for nsis@ietf.org; Fri, 07 Jul 2006 04:02:36 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Fri, 7 Jul 2006 10:02:27 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id <3GKS87N3>; Fri, 7 Jul 2006 10:02:27 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E6413@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: Brunner@netlab.nec.de Subject: RE: [NSIS] NSIS next steps Date: Fri, 7 Jul 2006 10:02:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hallo Marcus, I also like the basic idea of the MRM draft. It seems to be worth a closer look. Regards, Rudiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 07 06:34:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fynex-0001JL-UL; Fri, 07 Jul 2006 06:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fynew-0001J1-KJ for nsis@ietf.org; Fri, 07 Jul 2006 06:34:06 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fynet-0005Un-Ov for nsis@ietf.org; Fri, 07 Jul 2006 06:34:06 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k67AXcsD008646; Fri, 7 Jul 2006 11:33:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Legacy NAT traversal for NSIS Date: Fri, 7 Jul 2006 11:32:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Legacy NAT traversal for NSIS Thread-Index: AcadRTG2CJAETM0lT4iiyEbOcHvg6QBYpi1AAGMmbtAAORDzUA== From: "Hancock, Robert" To: "Pashalidis, Andreas" , "Hannes Tschofenig" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, below. r. > -----Original Message----- > From: Pashalidis, Andreas [mailto:Andreas.Pashalidis@siemens.com]=20 > Sent: 05 July 2006 15:30 > To: Hancock, Robert; Hannes Tschofenig; john.loughney@nokia.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] Legacy NAT traversal for NSIS >=20 >=20 > Hello all, >=20 > Many thanks to those who provided feedback on our "legacy NAT=20 > traversal > for GIST" document. > I take it that sufficient interest exists for the document to be > submitted to the WG. >=20 > Some answers to Robert's comments: >=20 >=20 > > my biggest question about the approach is that the discussion > > is mostly about a flow which goes through the legacy NAT in the=20 > > internal->external direction (same as the initial Query for the > > signalling). how does one handle a flow in the other direction?=20 > > it's a different flow, so either one needs a technique to get the > > Query through the NAT the other way, or to rely on the upstream=20 > > encapsulation. Each has its tricky side. This has struck me in=20 > > the past as the hardest part of the problem. >=20 > Surely the problem you mention is the trickiest one. Consider this:=20 > For the (internal->external) direction the solution works as follows. > Signalling causes a UDP NAT binding to be installed, which is then > used to tunnel data traffic over. If the same "technique" was to > be applied in the (external->internal) direction, then we would > require that *first* there is a data flow, which (by some out-of-scope > means) has caused a NAT binding to be installed at the NAT.=20 > Subsequently (and only subsequently) we could use that very NAT > binding for the tunnelling of signalling traffic. In other words, the > "solution" > would only work if signalling is initiated *after* the data is already > flowing. i'll try a rephrasing of my question, since i can't tell whether this is an answer or not ;-) consider the following case: Source <--> GN1 <--> NAT <--> GN2 <--> Dest we have an application session (e.g. the VoIP call) initiated by=20 Source. In your solution, you assuming GIST signalling initiated also by Source, with the Query causing state installation at the NAT. The tunnel then handles data (in fact, voice) packets heading from Source to Dest. so far, so good. but what about the packets from the same call going from Dest to Source? (assuming that Dest is talking back to Source, of course). there is no reason to believe that they will be routed back=20 through GN2 (routing asymmetry), so some other node will be the GIST initiator sending a Query towards the NAT. and for the data traffic hitting the NAT, there is no reason to believer (if it goes through the NAT at all) that it will go through GN1. >=20 > Of course there may be other ways to solve the (external->internal) > direction problem, but these may result in GIST to rely on=20 > some external > services (while it could very well do without them). I am not sure > whether=20 > or not the WG desires reliance on external services in certain > hard-to-solve > NAT traversal instances. Having said that, this may very well=20 > acceptable > if made optional. > Moreover, I am not sure whether or not it is > worth the effort to enable (external->internal) direction legacy NAT > traversal > within GIST (given that legacy NAT traversal is, by its=20 > nature, a "best=20 > effort" service, and a mid-term "solution" anyway). it is a good question. one can imagine defining an approach looking like a classical virtual server for GIST behind the firewall, but it rapidly starts to look like full-blown off-path signalling which will be very hard unless strict topological assumptions are made. >=20 > It would be nice to know what people think regarding the above > questions.=20 >=20 >=20 > > some more detailed comments: >=20 > > section 2: you refer to the GIST spec for NI/NR/DS/DR but > > actually that document doesn't define or use the terms. in=20 > particular, > > I think of NI/NR as NSLP layer terminology which might not be > > appropriate here. >=20 > Thanks for pointing this out.=20 >=20 > > section 4 bullet 2: i don't see the need for precise matching > > of packets to interfaces. wouldn't arriving on the correct > > 'side' of the NAT be enough? >=20 > A multi-homed NAT may have multiple interfaces and "sides". A given > interface may have one or more IP addresses. A GIST peer=20 > should send a message B to the NAT's address (as opposed to=20 > directly to > the GIST peer > that is behind the NAT). It is therefore expected that the GIST peer > uses > the NATs IP address that it saw in a previous message A - in fact, the > document > mandates this behaviour. If the message B arrives on an interface that > is different > from the interface where A was sent from, this would probably=20 > mean that > the peer > used the wrong IP address. This should not happen, right?=20 sending a packet to an IP address does not guarantee that it arrives on the interface that this IP address is bound to. that is a question of local topology and routing protocol operation. (routers usually advertise all their reachable prefixes which effectively includes all their interface addresses out of all of their interfaces.=20 obviously this rule is modified for NATs, but it is still quite possible for an interface IP#1 which is bound to one interface to be advertised as reachable via another interface.) >=20 > > section 4 bullet 3: strictly, GIST can indicate a possible=20 > > routing change in some of these circumstances (e.g. if inbound/ > > outbound interfaces change, or a TTL changes). i don't think this > > changes the argument however. >=20 > Absolutely; thanks for pointing this out. I changed "Thus, under > "normal" path coupled signalling, it is not > an error condition [...]" to "Thus, under "normal" path coupled > signalling, it is not > always an error condition [...]". I hope this removes the error. >=20 > > page 7 last bullet: the phrasing of this condition might need > > to be refined if you consider the upstream query as well. >=20 > Absolutely. >=20 > > general question: how should the upstream node handle refreshing > > Queries? i guess it should generate 'normal' queries (with the=20 > > RAO included and not tunnelled), but then there would be > > a question of whether it should use the existing UDP source > > port or a new one (thus creating a new binding at the NAT). >=20 > This is a good question. I would say that the same NAT=20 > binding should be > used for the whole > duration of the signalling session and - for that matter -=20 > the existence >=20 > of the data flow. Switching the signalling to a new NAT binding would > also require switching the data flow to that binding (which could > break the application). (Having said that, the session ID=20 > could be used > to map refreshing queries to existing UDP tunnels.) Another > argument is that it may be undesirable that many NAT bindings exist > for a single data flow / signalling session pair. >=20 > Should the refreshing query should also be tunnelled over UDP or not? > Maybe a refreshing query should be sent exactly as the "first" query, > i.e normally. > In other words, the NAT would have to be re-discovered. However, the > downstream peer could shortcut the process by sending a RESPONSE over=20 > the existent messaging association, right? Re-discovering the NAT=20 > seems to be necessary in case a previously unknown (or rebooted) peer > identifies itself as a new downstream peer... if you send a normal query then you still have to be careful to re-use the existing source port (that the first query was sent from). this just needs a bit of clarification. normally, tunnelling queries is a really bad idea: the point of a Query is to discover the network topology (including changes in it), and by=20 tunnelling it you insulate the Query from the topology. in this case you have basically created a static overlay, and you probably don't care=20 about topology changes in the first place. so routing state refresh times could be long ... >=20 > > page 8: i'm not sure about extending the stack proposal this > > way, but it's not a critical issue for the basic form of the > > solution. >=20 > I am not sure either. This was done in order to avoid changes to GIST > message formats. > The semantics of such a message seem unambiguous to me... what if someone later defines "rate-limited UDP" as a possible MA protocol for signalling but not data traffic? >=20 > > page 9 first para: the packet analysis rules are not quite > > perfect. for example, a Query would be identified as a data > > packet, as would any GIST message if the GIST node in question > > was also the flow endpoint. however, the standard GIST rules > > should be able to cover these cases. >=20 > Right. Thanks for pointing this out, too.=20 >=20 >=20 > > page 9, penultimate paragraph: i think full NAT processing=20 > > (whatever that means) is required here, including e.g. source > > port remapping, checksum fixups and so on, not just source > > address rewriting. (consider the case of two nodes behind the > > same NAT.) >=20 > Will do. Thanks again. >=20 > Best Regards, > Andreas >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > Sent: 01 July 2006 20:32 > > To: john.loughney@nokia.com > > Cc: Andreas.Pashalidis@siemens.com; nsis@ietf.org > > Subject: Re: [NSIS] Legacy NAT traversal for NSIS > >=20 > >=20 > > Hi John, > > Hi Saikat, > >=20 > > thanks for the feedback. I definitely think that we should=20 > > explore the=20 > > usage of these protocols in context with GIST for legacy NAT=20 > > traversal. > >=20 > > Ciao > > Hannes > >=20 > > john.loughney@nokia.com wrote: > > > Hi Saikat, > > >=20 > > > You're observations are right - if we want, we can run GIST over > > > any 'standard' NAT traveral mechanisms (TERADO, STUN, TURN).=20 > > >=20 > > > I think working through this would be a useful exercise. > > >=20 > > > John > > >=20 > > >=20 > > >>On Mon, 2006-06-19 at 15:22 +0200, Pashalidis, Andreas wrote: > > >> > > >>>Is anyone interested to make NSIS work through legacy=20 > NATs ?? (i.e. > > >>>NSIS-unaware NATs) > > >>> > > >>>Under the following link a preliminary document (in I-D=20 > format) can > > >=20 > > > be=20 > > >=20 > > >>>found that describes a solution approach. > > >>> > > >> > > >>http://www.tschofenig.priv.at/TEMP/draft-pashalidis-nsis-gist-legac > > >>ynats-00. > > >> > > >>>txt > > >>> > > >>>In an exremely small nutshell: the idea is to tunnel both=20 > > signalling=20 > > >>>and data traffic over a single UDP NAT binding. > > >> > > >>I haven't gone through the document throughly, but the=20 > > >>underlying transport you propose reminds me of TEREDO (which=20 > > >>is over IPv6 over UDP over IPv4, where the UDP=20 > > >>over IPv4 is punched through legacy NATs with the help of=20 > > >>STUN/TURN/ICE etc.) One could potentially run GIST over TEREDO=20 > > >>and keep the signaling and data channel separate in > > >>IPv6 land even though they use the same NAT binding in IPv4 land. > > >> > > >>Alternatively, TURN (public-data-relay protocol for traversing=20 > > >>the worst of NATs) now has some lightweight framing=20 > > >>capability; the framing in TURN could potentially be extended=20 > > >>to carry any in-band signals including GIST.=20 > > >> > > >>-- > > >>Saikat > > >> > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 07 06:54:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FynyZ-0006pe-1X; Fri, 07 Jul 2006 06:54:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FynyX-0006pW-M5 for nsis@ietf.org; Fri, 07 Jul 2006 06:54:21 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FynyX-00007U-5S for nsis@ietf.org; Fri, 07 Jul 2006 06:54:21 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 07 Jul 2006 13:54:18 +0300 id 00087E4A.44AE3D5A.00005A85 Date: Fri, 7 Jul 2006 13:54:18 +0300 (EEST) From: Jukka MJ Manner To: "Hancock, Robert" Subject: RE: [NSIS] NSIS next steps In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: John Loughney , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, All work on securing the NSIS architecture are on the top of my list. In addition, the PDS, MRM patterns, Controlled Load QOSM, metering work, NAT traversal and mobility related items are things I'd like to be further developed and where I could give a helping hand. Jukka On Wed, 5 Jul 2006, Hancock, Robert wrote: > john, > > as well as the 3 topics you list (which are certainly at/near the top of > my list of priorities), there are a couple of other areas I would > highlight: > > firstly, there is stuff that the WG needs to do support the current set > of specs. this would include: > - the extensibility document > - NAT traversal specification > - hannes'/pasi's GIST security document > all these topics came up to a greater or lesser extent in Magnus' GIST > review. > > secondly, i'd like to register interest for the 'MRM patterns' document, > although this is clearly a longer term activity. > > finally, people might also like to be aware of > http://tools.ietf.org/wg/mipshop/draft-hancock-mipshop-gist-for-mih-00.t > xt, which is a proposal to use GIST as a basis for the common protocol > functions needed for 802.21 support. it's on the mipshop agenda for > Montreal. > > cheers, > > robert h. > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 30 June 2006 06:40 > To: nsis@ietf.org > Subject: [NSIS] NSIS next steps > > > > Hi all, > > Below is a cut & paste (with slight editing) from > http://tools.ietf.org/wg/nsis/ showing the individual drafts that are > active for NSIS. > > I believe that we have had interest in at least the Partly > De-coupled Signaling, Controlled Load QoS Model & the Meeting NSLP work. > These are (at least) the intial set of drafts that we would be > considering to add to the charter after we complete our milestones. > Some of these may require us to modify our current charter. > > I'd like the working group to comment on the drafts, indicating > what is your priority for completing. If there are items that you feel > are not a priority, please let me know. > > We will talk more about this in Montreal. > > thanks, > > John > > > > draft-cordeiro-nsis-hypath-00.txt > -00 > 2006-03-01 14:53 > > draft-dressler-nsis-metering-nslp-04.txt > > -04 new 2006-06-28 21:21 > > draft-fessi-nsis-m-nslp-framework-03.txt > > -03 new 2006-06-28 21:19 > > draft-fu-nsis-diagnostics-nslp-01.txt > > -01 2006-03-16 02:07 > > draft-fu-nsis-qos-nslp-statemachine-04.txt > t> -04 new 2006-06-28 21:00 > > draft-hancock-nsis-pds-problem-03.txt > > -03 2006-03-09 02:07 > > draft-kappler-nsis-qosmodel-controlledload-04.txt > d-04.txt> -04 new 2006-06-26 20:25 > > draft-loughney-nsis-ext-02.txt > -02 > 2006-03-16 02:07 > > draft-manner-nsis-nslp-auth-01.txt > -01 > 2006-06-22 19:55 > > draft-pashalidis-nsis-gimps-nattraversal-03.txt > 03.txt> -03 new 2006-06-26 18:41 > > draft-stiemerling-nsis-mrm-patterns-00.txt > t> -00 2006-06-20 20:22 > > draft-thiruvengadam-nsis-mip6-fw-04.txt > > -04 new 2006-06-29 17:47 > > draft-tommasi-nsis-semipro-00.txt > -00 > 2006-02-22 17:15 > > draft-tschofenig-nsis-gist-security-01.txt > t> -01 new 2006-06-28 20:58 > > draft-werner-nsis-natfw-nslp-statemachine-03.txt > -03.txt> -03 new 2006-06-28 19:41 > > draft-zhang-nsis-interdomain-qosm-02.txt > > -02 new 2006-06-26 13:56 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 07 08:08:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyp8Y-0003JC-Tz; Fri, 07 Jul 2006 08:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyp8Y-0003IE-3z for nsis@ietf.org; Fri, 07 Jul 2006 08:08:46 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyp8V-0007LL-K7 for nsis@ietf.org; Fri, 07 Jul 2006 08:08:46 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 07 Jul 2006 15:08:42 +0300 id 00087DB6.44AE4ECA.00001938 Date: Fri, 7 Jul 2006 15:08:42 +0300 (EEST) From: Jukka MJ Manner To: "Hancock, Robert" Subject: RE: [NSIS] NSLP authorization work In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, thanks for the comments. Some words below (mainly "acks). Jukka On Wed, 5 Jul 2006, Hancock, Robert wrote: > hi, > > i think this is an interesting document. i have some comments > on it: > > *) section 3.1: this assumes that GIST defines the NLSP object > space and AB flag settings. however, this hasn't been true > since version -06 (over a year ago!); at the moment, AFAIK > no document creates or describes the NSLP object registry. > (Incidentally, this can be taken as a WGLC comment on all the > current NSLP specs.) Thanks. :) > > *) section 3.2.1: i think it could be made clearer that the > addresses which can be used as identifiers here are orthogonal > to addressing associated with the signalling nodes or the > resources being requested. Right. > > *) section 3.2.3/3.2.4: carrying address/port information here > raises a number of concerns with me. > - there is no discussion of NAT traversal issues. > - it isn't clear whether the addresses should relate to e2e > flows or GIST/NSLP peers > - are the addresses always meaningful - e.g. what is the correct > 'called party' address for a NATFW REA message? > [the last point is a reflection of the issue that basing the > authorisation model too closely on rfc3520 may not be ideal, since > the session concepts themselves are not that directly related.] Good points. We need to be more specific and think about the NAT-cases. The NAT/FW message processing and use need still more work. > > *) section 3.2.7: likewise, the 'resources' attribute seems to > run the risk of partial duplication of information which is > already being carried in another form in the main body of the > NSLP. Good point. We need to think more about how we could re-use the QSPEC in this, e.g., through similar flags that the QoS NSLP uses for the packet classifier (pointing to GIST information). > > my main concerns are the last two. it seems that related information > is going to be carried in the 'main' NSLP objects and also in > the AUTH_SESSION object, and it is up to the NSLP implementation > at either end to compare and match the two. However, it's quite > unclear how much freedom there should be in doing this. For > example, what does one do about MRI wildcarding, or if a flow > label is specified, or if the token bucket is given in a Qspec > but not a bandwidth, and so on. > > I suspect the underlying problem here is that different authorisation > infrastructures use different formats to represent the resources > that are authorised, so some unpleasant interworking is going to > be required somewhere. But doing that in a partial way in the NSLP > seems very awkward. Those are good points. We took RFC3520 as the baseline, but we clearly need to work more on the draft to integrate it better with the NSIS way of signaling, and GIST and the NSLPs. > > r. > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: 26 June 2006 08:22 > > To: nsis@ietf.org > > Subject: [NSIS] NSLP authorization work > > > > > > > > Hi all, > > > > Hannes, Martin and myself have pretty much finalized our > > proposal to add > > an authorization object to the NSLP layer. We'd like to hear > > comments on > > whether this would be as usefull to have as we see it. The > > draft includes > > e.g., the structure and use of the authorization object and message > > processing rules for the QoS and NAT/FW NSLPs. > > > > http://www.ietf.org/internet-drafts/draft-manner-nsis-nslp-auth-01.txt > > > > Regards, > > Jukka > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 07 16:07:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fywbs-000290-JF; Fri, 07 Jul 2006 16:07:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fywbs-00028v-2V for nsis@ietf.org; Fri, 07 Jul 2006 16:07:32 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fywbr-0000S7-Az for nsis@ietf.org; Fri, 07 Jul 2006 16:07:32 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1152302737!13510781!22 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 11592 invoked from network); 7 Jul 2006 20:07:27 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-120.messagelabs.com with SMTP; 7 Jul 2006 20:07:27 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB45200170A53; Fri, 7 Jul 2006 16:07:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt Date: Fri, 7 Jul 2006 15:07:26 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7AA5@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7A91@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt Thread-Index: AcaW/kaTNRc1lr6NTHO3fZd0EYaG7gAAYfvgAILnqHAB/nYSYAAF6ZJwADYhf2A= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hancock, Robert" , "NSIS" X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Many thanks for your detailed and constructive review of the QSPEC document http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt. Please see some initial responses below (will provide further responses later). Thanks, Regards, Jerry=20 > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > Sent: Thursday, July 06, 2006 10:44 AM > To: john.loughney@nokia.com; Ash, Gerald R (Jerry), ALABS;=20 > nsis@ietf.org > Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt >=20 > hi all, >=20 > some wglc comments. most are minor/editorial-ish. >=20 > in general, i thought i could understand the document and follow what > it was defining. however, that might be because i am too close to the > subject matter to see the ambiguities. i wonder whether there might be > value in having space in an appendix for more examples (not=20 > that I have > anything specific to contribute here). >=20 > 1) section 4.2 p9 para 3 ("When reserving..."): maybe worth clarifying > here that the terms ingress/egress apply to the direction of=20 > the RESERVE > rather than the direction of the flow. (possibly applies elsewhere.) OK, good point, will clarify. =20 > 2) para 4 but also elsewhere: i found the formatting confusing in=20 > several places where lists get run together like this. for example, > i can't immediately tell whether the last sentence in the paragraph > applies to (c) or to (a) and (b) as well. Good point, will reformat lists to make it clear. =20 > 3) page 11 last para: this seems to assume that there is an=20 > INTSERV-QOSM > whereas in fact none is being defined.=20 This is the reference: [INTSERV-QOSM] Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS," work in progress. This QOSM is being defined, but is not yet a WG draft. > but it raises a more general > point: > where in the document to look for a summary of the QOSM=20 > concept. To me, > it would be good to have a (small) dedicated section=20 > somewhere near the > start. Agreed, the QOSM discussion is spread around the document right now. We'll provide a summary of the QOSM concept in a separate section, as you suggest. =20 > 4) page 12 para 3 ("Case 1"): I would prefer to replace phrasing like > 'the QNx notifies the QNI' with something like 'the QNx generates a > RESPONSE'. partly this is because in the past there have been genuine > proposals that a QNx could send a message directly to the QNI, and > partly > because notify may get confused with NOTIFY. people who are fully > familiar > with the QoS-NSLP spec may be ok with this, but the casual reader may > not. > (also applies elsewhere.) Good point, will rephrase as suggested (where appropriate) to make it clear. =20 > 5) section 4.4.1: what treatment is required at the QNR?=20 The QNR treatment is the same as the behaviors required of the QNEs; will make that clear. =20 > 6) section 4.5 page 15 2nd last para, also 4.5.3: I found the=20 > tunneling=20 > description here rather confusing at first, and eventually came to the > conclusion that I don't like the T flag in the first place. my=20 > reasoning is as follows: >=20 > - there are several cases where a QNE has to make a judgment=20 > call about > whether it has strictly interpreted a parameter or not; in the latter > case it can set the flag to say so. >=20 > - i see the tunnel case as just one more example of this, which is not > really special in its own right. >=20 > - for example, suppose a reservation goes across an MPLS cloud rather > than an RSVP aggregation cloud. no T flag would be set in the=20 > MPLS case > since it's just 1 hop across (a.k.a. the tunnelling is not visible at > the IP level). however, do we really believe that the interpretation=20 > is any more accurate because of that? Interesting point that the T-flag has a similar effect as the flag. However, the latter is not set per-QSPEC-parameter (although I've proposed a flag that would be set per-QSPEC-parameter that is remapped). Hannes also suggested that the T-flag wasn't useful in his review of the document. =20 In another discussion of the T-flag, I pointed out that the T-flag could be used by a QNE to avoid strictly-interpreting or remapping a mandatory QSPEC parameter. That is, it could be used to in-effect 'ignore' a mandatory QSPEC parameter. However, this would be an abuse of the mandatory parameter requirement and our thought is to disallow this in the document ("MUST NOT"). It would be good to have other views on the T-flag parameter (see Section 4.5.3). =20 > 7) section 4.6 last para: i remember this point came up at the last > IETF and I still hold the view that it would be more sensible for this > information about Qspec-related codepoints to be in the Qspec=20 > document. > (this information isn't in any case in the extensibility document at > the moment.) Can you point us to what "QSPEC-related codepoints" you're referring to here? =20 > 8) section 5.2.1: i think the grammar of this section could be more > clear about whether the sets of objects on the right hand side of = '=3D' > are alternatives, things you can have >1 of, options, etc. Agreed, will clarify. =20 > 9) section 5.2.2, all references to 'queuing delay bound': the > discussion > seems to imply that this parameter can be carried in the Qspec > independently > of PL, but I don't see how. (two occurrences in this section.) I think the 'queuing delay bound' language crept in from a cut&paste artifact. IMO these references can be removed. =20 > 10) section 5.2.2: there is no discussion of OK, will add discussion on . =20 > 11) section 5.2.2: there are multiple references to the QNR=20 > having to do > something for the egress link for the cumulative parameters. I don't > see what this could mean. I'm not sure what is unclear in the references to QNR actions. E.g., for jitter is says: " Each QNE MUST add the jitter of its outgoing link, which includes the QNR adding the associated jitter for the egress link. Furthermore, the QNI MUST add the jitter of the ingress link." Any suggestions on how to make this clearer? =20 > 12) section 7.1: box diagram says 'Parameter ID' but text says > 'Parameter Type' >=20 > 13) section 7.2.7: i don't see how to relate the multiple priority=20 > parameters. What if someone provides both the rfc3181 parameters > and the admission/RPH parameters? This is an interesting comment. IMO a QNI/QOSM would specify either to populate in the Initiator QSPEC: A) & =20 Or B) & But not both. Normally both A) and B) would *not* be specified together, and I agree that it would be unclear how they would get treated together. IMO the document should say that A) and B) above MUST NOT be specified together. =20 > 14) section 7.2.8/9/10/11: if N is set in these parameters when=20 > a QNE receives the message, does it still have to process the > parameter value? Interesting question. The 'N flag' means that a QSPEC parameter is not supported. If a QNE in the path doesn't support and sets the N flag, then perhaps downstream QNEs should then ignore the parameter. Alternatively, all QNEs that support the parameter should update it, even if the N flag is set. However, the presence of the N flag will make the cumulative value unreliable, and the QNI/QNR decides whether or not to accept the reservation with the N-flag set. I would support the latter alternative. It would be good to hear other opinions on this point. =20 > 15) section 7.2.9: if Y.1541 is needed to define the composition > function, > it should be a normative reference, and should be referred to from=20 > 7.2.8 and 7.2.10 as well. OTOH since it is not freely available, would > it be possible to include the corresponding formulae here? Y.1541 should be normative (this comment has been made before, and applies to all RFCs/standards that are normative to supporting the QSPEC parameters). IMO Y.1541 is 'freely available', since anyone can download is for free from the ITU-T web-site. I would not like to be putting in a lot formulae here if it can be avoided by making the right normative references. =20 > 16) section 7.2.10/11: i assume the comments about microsecond time > resolution are cut&paste artifacts. You're right that these are cut&paste artifacts. IMO it is OK to delete these references. Thanks again, Jerry >=20 > cheers, >=20 > robert h. >=20 > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > > Sent: 26 June 2006 11:31 > > To: gash@att.com; nsis@ietf.org > > Subject: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt > >=20 > >=20 > > Hi all, > >=20 > > Jerry has submitted the QoS NSLP QSPEC Template. You can find the > > announcement & Jerry's comments below. > >=20 > > The WGLC will run until July 7th. After that, Jerry can=20 > summarize all > > issues and we will discuss them at the next IETF meeting in=20 > Montreal. > >=20 > > thanks, > > John=20 > >=20 > > >-----Original Message----- > > >From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > > >Sent: 23 June, 2006 23:16 > > >To: nsis@ietf.org > > >Cc: Ash, Gerald R (Jerry), ALABS > > >Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt=20 > > > > > >Hi All, > > > > > >The updated 'QoS-NSLP QSPEC Template' I-D is available at=20 > > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt. > > > > > >The updates are in response to comments and discussion=20 > since IETF-65: > > > > > >1. rewrote Section 2 (Introduction) for clarity 2. added=20 > > >clarifications on mandatory parameters in Section 4.2; added=20 > > >discussion of forwarding options when a domain supports a=20 > > >different QOSM than the QNI 3. expanded Section 4.5 on error=20 > > >code handling, including redefined E-Flag and editorial=20 > > >changes to the N-Flag and T-Flag discussions 4. made some=20 > > >editorial clarifications in Section 4.6 on defining new=20 > > >mandatory parameters 5. Section 4.7 added to identify what a=20 > > >QOSM specification document must include 6. clarified the=20 > > >requirements in Section 5 for defining a new QSPEC Version 7.=20 > > >made editorial changes to Section 6 (Procedures), and added=20 > > >procedures for handling preemption 8. removed QOSM ID=20 > > >assignments in Section 9 (IANA Considerations); clarified=20 > > >procedures for defining new mandatory parameters; added=20 > > >registry for QOSM error codes > > > > > >There are no further outstanding changes/comments pending and=20 > > >no open issues currently identified. > > > > > >Thanks, > > >Regards, > > >Jerry=20 > > > > > >-----Original Message----- > > >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > >Sent: Friday, June 23, 2006 3:50 PM > > >To: i-d-announce@ietf.org > > >Cc: nsis@ietf.org > > >Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt=20 > > > > > >A New Internet-Draft is available from the on-line=20 > > >Internet-Drafts directories. > > >This draft is a work item of the Next Steps in Signaling=20 > > >Working Group of the IETF. > > > > > > Title : QoS NSLP QSPEC Template > > > Author(s) : J. Ash, et al. > > > Filename : draft-ietf-nsis-qspec-10.txt > > > Pages : 53 > > > Date : 2006-6-23 > > >=09 > > >The QoS NSLP protocol is used to signal QoS reservations and=20 > > >is independent of a specific QoS model (QOSM) such as IntServ=20 > > >or DiffServ. Rather, all information specific to a QOSM is=20 > > >encapsulated in a separate object, the QSPEC. This document=20 > > >defines a template for the QSPEC, which contains both the QoS=20 > > >description and QSPEC control information. The QSPEC format is=20 > > >defined, as are a number of QSPEC parameters. The QSPEC=20 > > >parameters provide a common language to be re-used in several=20 > > >QOSMs. To a certain extent QSPEC parameters ensure=20 > > >interoperability of QOSMs. Optional QSPEC parameters aim to=20 > > >ensure the extensibility of QoS NSLP to other QOSMs in the future. > > >The node initiating the NSIS signaling adds an Initiator QSPEC=20 > > >that must not be removed, thereby ensuring the intention of=20 > > >the NSIS initiator is preserved along the signaling path. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 08 00:19:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz4Hr-00019r-OC; Sat, 08 Jul 2006 00:19:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz4Hq-00019m-GY for nsis@ietf.org; Sat, 08 Jul 2006 00:19:22 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz4Hp-0007T3-0h for nsis@ietf.org; Sat, 08 Jul 2006 00:19:22 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k684JIhY005818 for ; Sat, 8 Jul 2006 06:19:18 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k684JGvb006544; Sat, 8 Jul 2006 06:19:16 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k684JGq21366; Sat, 8 Jul 2006 06:19:16 +0200 (MEST) Date: Sat, 8 Jul 2006 06:19:16 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nsis@ietf.org Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 08 Jul 2006 04:19:15 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <9mshAIWY.1152332355.2827720.karagian@ewi.utwente.nl> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7AA5@KCCLUST06EVS1.ugd.att.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.54 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Sat, 08 Jul 2006 06:19:19 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: karagian@cs.utwente.nl Subject: [NSIS] comment on on draft-ietf-nsis-qspec-10.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Cornelia and Attila I have a comment on Section 6.1 of the QSpec template draft that may also apply to Section 6.2. In the last paragraph of the section you say: "Regarding Control Information, the rule is that all parameters that have been included in the RESERVE message by the QNI MUST also be included in the RESPONSE message by the QNR with the value they had when arriving at the QNR." Note that for the Control Information defined by a QOSM this rule may be overruled, since the QOSM defines how the control information should be used by the domain that supports this QOSM. Therefore, I would very much appreciate if you could modify the paragraph to allow this possibility. A possible modifiation could be: "Regarding Control Information, the default rule is that all parameters that have been included in the RESERVE message by the QNI are also included in the RESPONSE message by the QNR with the value they had when arriving at the QNR. However, regarding the QOSM specific Control Information, a QOSM may specify its own processing rules." Please note that the same comment applies to Section 6.2. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 09 14:18:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdrB-0003Y5-8i; Sun, 09 Jul 2006 14:18:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzdr9-0003R3-My for nsis@ietf.org; Sun, 09 Jul 2006 14:18:11 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fzdr8-0004u4-7s for nsis@ietf.org; Sun, 09 Jul 2006 14:18:11 -0400 Received: (qmail invoked by alias); 09 Jul 2006 18:18:08 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp002) with SMTP; 09 Jul 2006 20:18:08 +0200 X-Authenticated: #29516787 Message-ID: <44B14850.5030507@gmx.net> Date: Sun, 09 Jul 2006 20:17:52 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS , dime@ietf.org, radiusext@ops.ietf.org, tsvwg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [NSIS] [Fwd: [Dime] Diameter QoS Dinner] X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, please do not forget the QoS dinner Sunday evening, 19:30 at the registration desk. Ciao Hannes -------- Original Message -------- Subject: [Dime] Diameter QoS Dinner Date: Mon, 19 Jun 2006 14:14:39 +0200 From: Tschofenig, Hannes To: Hi all, it would be good to meet Diameter QoS interested folks at the next IETF for a discussion about possible next steps before the DIME session. The DIME WG session will be on***** MONDAY, July 10, 2006** * *1740-1840 Afternoon Session III* Room 519B APP _widex_ Widget Description Exchange Service WG Room 520ABC INT _softwire_ Softwires WG Room 519A IRTF NMRG Network Management Research Group Charter *Room 513C-F OPS **_dime_* * Diameter Maintenance and Extensions WG *Room 520DEF RAI rtpsec Securing the Real-time Transport Protocol BOF Room 513B SEC _sasl_ Simple Authentication and Security Layer WG Room 518AB TSV _tsvwg_ Transport Area Working Group WG _https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=66_ Hence, there is only time after the Welcome Reception on Sunday. My proposal would be to meet at the registration desk at 19:30. Please send me a mail if you are interested. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 08:22:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzum6-0003jk-6S; Mon, 10 Jul 2006 08:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzum4-0003jf-MV for nsis@ietf.org; Mon, 10 Jul 2006 08:22:04 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzum4-0001hA-6G for nsis@ietf.org; Mon, 10 Jul 2006 08:22:04 -0400 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by mailer.gwdg.de with esmtp (Exim 4.60) (envelope-from ) id 1Fzulz-00008Y-Eo for nsis@ietf.org; Mon, 10 Jul 2006 14:22:03 +0200 Received: from [66.103.220.155] (unknown [66.103.220.155]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP for ; Mon, 10 Jul 2006 14:21:58 +0200 (CEST) Message-ID: <44B24661.90709@cs.uni-goettingen.de> Date: Mon, 10 Jul 2006 08:21:53 -0400 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required _SUMMARY_ X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, all, Is it possible for NAT/FW NSIS NSLP to support detection of middlebox presence? We find out this feature will be useful in MIP6 FW traversal scenarios, as depicted in http://www.ietf.org/internet-drafts/draft-thiruvengadam-nsis-mip6-fw-04.txt This could save additional signaling message flows, especially if one expects to install multiple rules in a firewall -- if exists -- in a particular IP path, e.g., rules for allowing both BU and HoTI messages to traverse between the MN and the HA. Cheers, Xiaoming Internet-Drafts@ietf.org wrote: > 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 : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) > Author(s) : M. Stiemerling, et al. > Filename : draft-ietf-nsis-nslp-natfw-12.txt > Pages : 101 > Date : 2006-6-29 > > This memo defines the NSIS Signaling Layer Protocol (NSLP) for > Network Address Translators (NATs) and firewalls. This NSLP allows > hosts to signal on the data path for NATs and firewalls to be > configured according to the needs of the application data flows. It > enables hosts behind NATs to obtain a public reachable address and > hosts behind firewalls to receive data traffic. The overall > architecture is given by the framework and requirements defined by > the Next Steps in Signaling (NSIS) working group. The network > scenarios, the protocol itself, and examples for path-coupled > signaling are given in this memo. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nsis-nslp-natfw-12.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 09:20:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzvgn-0008Jz-J3; Mon, 10 Jul 2006 09:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzvgm-0008Jt-QK for nsis@ietf.org; Mon, 10 Jul 2006 09:20:40 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzvgl-0003tG-AL for nsis@ietf.org; Mon, 10 Jul 2006 09:20:40 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ACKW6I012617; Mon, 10 Jul 2006 15:20:33 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:20:05 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:20:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: IANA Consideration Section Date: Mon, 10 Jul 2006 16:20:04 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: IANA Consideration Section Thread-Index: Acaednw2toZKuFqyS7CfNcE9Qm/SxQCZswCgANGKUJA= From: To: , , X-OriginalArrivalTime: 10 Jul 2006 13:20:05.0079 (UTC) FILETIME=[8EA77E70:01C6A423] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: attila.bader@ericsson.com, nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Small comment: >i think it is true that there are two sorts of 'reserved' here: >1) there are the bits marked 'r' in the object header >2) there are the values for Object Type listed as 'Reserved' in the > IANA section. > >the first type could conceptually be used in a future spec=20 >revision to define additional flags which apply to the=20 >processing of existing and new objects. conceptually i suppose=20 >you could discuss these flag bits in the IANA section (as=20 >Diameter does, section 11.2.2 of 3588), but since in each case=20 >new flag bits can only be defined by a standards action I=20 >don't really see the point. In other words, the existence of=20 >these flag bits should not be relevant to the IANA section. Agree with Robert. >> Here the specified range >> > designated as 'reserved' is a normal use of allocated space in a=20 >> > registry that is reserved for future definition by a specification. >> > Future specifications can redefine the registry allocations, and=20 >> > allocate more space to various designations, as necessary >> (e.g., more >> > space allocated to "Standards Action" or to "Private/Experimental=20 >> > Use", etc.). >>=20 >> I am not so sure that this is common and useful practice. >> The IANA consideration section already indicates that a fraction of=20 >> the namespace requires standards track actions. > >this is similar to what is in the GIST spec, and to me it just=20 >seems like common sense. basically, you could parcel up the=20 >whole registry >(4096 values) for different allocation policies, but what=20 >happens if you get the division wrong and run out of (for=20 >example) expert review space in 3 years? you would have to=20 >start stealing codes from other parts of the registry. leaving=20 >a Reserved chunk allows a second chance at getting the=20 >division right in the light of some deployment experience. >(see also=20 >http://www1.ietf.org/mail-archive/web/nsis/current/msg06337.html >for this discussion of this topic in the GIST context). > If we get it wrong, we write a -bis draft, updating the IANA registry info. No big deal. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 09:23:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzvjO-0001Lz-9a; Mon, 10 Jul 2006 09:23:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzvjN-0001Lu-2W for nsis@ietf.org; Mon, 10 Jul 2006 09:23:21 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzvjL-0003zi-Jg for nsis@ietf.org; Mon, 10 Jul 2006 09:23:21 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ADNAhH006788; Mon, 10 Jul 2006 16:23:14 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:22:24 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:22:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comment: IANA Consideration Section Date: Mon, 10 Jul 2006 16:22:23 +0300 Message-ID: In-Reply-To: <44ACF9CD.2040602@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comment: IANA Consideration Section Thread-Index: Acag8y2u1tjKOO8WScKChJSVc9l2ZADMITfQ From: To: , X-OriginalArrivalTime: 10 Jul 2006 13:22:23.0826 (UTC) FILETIME=[E15A9B20:01C6A423] X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: gash@att.com, cornelia.kappler@siemens.com, =?ISO-8859-1?Q?=22At?=@mgw-ext01.nokia.com, nsis@ietf.org, attila.bader@ericsson.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hannes, >>>The easiest way is to register a namespace with IANA and provide=20 >>>guidelines for allocation of new values. >>=20 >> i'm not sure what you are recommending here. that the 'r' bits are=20 >> hard coded as 0? or something else? > >The 'r' bit in the object header unless it has the meaning of (2). So, are you saying that the reserved bits should have a value, and the value should be fixed?=20 >>=20 >> i agree that more explanation never hurts, up to a point.=20 >>=20 >> however, i went through the GIST IANA considerations with IANA people = >> in Vancouver and they seemed happy with them. the problem isn't with=20 >> the instruction itself ('Reserved' just means 'don't give these out'=20 >> which is pretty easy to follow), but with the motivation for the=20 >> instruction. >=20 > Why not to just add one line saying this? It would someone=20 > like me help to understand the document. that would work for me. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 09:29:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzvom-0003Os-3k; Mon, 10 Jul 2006 09:28:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzvok-0003On-Ii for nsis@ietf.org; Mon, 10 Jul 2006 09:28:54 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzvoj-0004EN-5X for nsis@ietf.org; Mon, 10 Jul 2006 09:28:54 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ADSbX0010287; Mon, 10 Jul 2006 16:28:37 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:28:36 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:28:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory AttributeList (UNCLASSIFIED) Date: Mon, 10 Jul 2006 16:28:36 +0300 Message-ID: In-Reply-To: <4.3.2.7.2.20060705164104.032a9ca0@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPH nits Re: [NSIS] QSPEC Comment: Mandatory AttributeList (UNCLASSIFIED) Thread-Index: AcagfATBflyR/ogzTH6IUU7aaCkrHQDqJZUg From: To: , , X-OriginalArrivalTime: 10 Jul 2006 13:28:36.0817 (UTC) FILETIME=[BFAC8410:01C6A424] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: jrrosenberg@lucent.com, gash@att.com, cornelia.kappler@siemens.com, nsis@ietf.org, attila.bader@ericsson.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org James, >>The critical thing for the QSPEC is to have the structure/container=20 >>that can hold the values and not the values themselves. > >This is an interesting idea. Design the container and the=20 >semantics, but leave the values for later assignment. This is the general idea for the QoS NSLP - we can define the=20 semantics, the QSPEC template defines the container and QoS models define specific QoS deployments. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 09:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzvp3-0003Uc-Dl; Mon, 10 Jul 2006 09:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzvp2-0003UX-OY for nsis@ietf.org; Mon, 10 Jul 2006 09:29:12 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzvp2-0004FB-8O for nsis@ietf.org; Mon, 10 Jul 2006 09:29:12 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ACSxDd018775; Mon, 10 Jul 2006 15:29:00 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:29:00 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:28:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List(UNCLASSIFIED) Date: Mon, 10 Jul 2006 16:28:58 +0300 Message-ID: In-Reply-To: <62D84945-0258-4C16-8314-24190BF0EE3E@g11.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute List(UNCLASSIFIED) Thread-Index: AcagdkBKewcNuJsCT8SMW4Hgg2e2CwDroKIw From: To: , X-OriginalArrivalTime: 10 Jul 2006 13:28:59.0457 (UTC) FILETIME=[CD2B1B10:01C6A424] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: jrrosenberg@lucent.com, attila.bader@ericsson.com, cornelia.kappler@siemens.com, nsis@ietf.org, gash@att.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Ken, >Another thought is to just remove the example DISA-related=20 >values from the QSPEC and simply have them registered later=20 >through IANA by the interested party. The critical thing for=20 >the QSPEC is to have the structure/container that can hold the=20 >values and not the values themselves. I think that is a good suggestion. John >-ken > > >On Jul 5, 2006, at 4:27 PM, Nguyen, An P CIV NCS NC2 wrote: > >> Classification: UNCLASSIFIED >> Caveats: NONE >> >> My next question is: how can you reference it in the ID if it is not=20 >> publicly available? This leads to my next question: for security, is=20 >> DISA comfortable with having its MLPP spec being discussed here? >> >> An >> >> -----Original Message----- >> From: John Rosenberg [mailto:jrrosenberg@lucent.com] >> Sent: Wednesday, July 05, 2006 4:04 PM >> To: Nguyen, An P CIV NCS NC2; Ash, Gerald R (Jerry), ALABS; Janet P=20 >> Gunn >> Cc: Kappler Cornelia; Attila Bader (IJ/ETH); NSIS >> Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory Attribute=20 >> List >> (UNCLASSIFIED) >> >> >> No, not yet. >> >> At 02:52 PM 7/5/2006, Nguyen, An P CIV NCS NC2 wrote: >>> Classification: UNCLASSIFIED >>> Caveats: NONE >>> >>> Janet, >>> >>> Just a question: Is the DISA specification publicly available? >>> >>> An >>> >>> -----Original Message----- >>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>> Sent: Monday, July 03, 2006 8:07 PM >>> To: Janet P Gunn >>> Cc: Ash, Gerald R (Jerry), ALABS; Kappler Cornelia; Attila Bader >>> (IJ/ETH); NSIS; John Rosenberg >>> Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory =20 >>> Attribute List >>> >>> >>> Hi Janet, >>> >>> See below. >>> >>>> -----Original Message----- >>>> From: Janet P Gunn [mailto:jgunn6@csc.com] >>>> Sent: Monday, July 03, 2006 10:14 AM >>>> To: Ash, Gerald R (Jerry), ALABS >>>> Cc: John Rosenberg; Kappler Cornelia; NSIS; Attila B=E1der (IJ/ETH) >>>> Subject: RPH nits Re: [NSIS] QSPEC Comment: Mandatory=20 >Attribute List >>>> >>>> Nits with regard to RPH. >>>> >>>> References should be updated to include RFC4412 (instead of >>>> just the ID) >>>> >>>> In section 7.2.7.3 you show a mapping between the text values >>>> and numeric >>>> values for RPH priority. (The mappings for ets and wps are fine) >>>> >>>> For dsn and drsn you show >>>> >>>> 4 - dsn.routine >>>> 3 - dsn.priority >>>> 2 - dsn.immediate >>>> 1 - dsn.flash >>>> 0 - dsn.flash-override >>>> >>>> 5 - drsn.routine >>>> 4 - drsn.priority >>>> 3 - drsn.immediate >>>> 2 - drsn.flash >>>> 1 - drsn.flash-override >>>> 0 - drsn.flash-override-override >>>> >>>> You might want to check with the intended users of those >>>> namesapces, as I >>>> understand (see recent email on the IEPREP mailing list) that >>>> DISA intends >>>> to use a quite different numerical mapping, with "0" for >>>> routine in all >>>> cases. >>>> >>>> "The current DISA specification for MLPP on VoIP networks >>>> specifies RPH >>>> r-priority values of 0, 2, 4, 6, 8, 9 in ascending order of >>>> priority (e.g. >>>> 0 =3D Routine and 9 =3D F-O-O)." >>>> >>>> It will be very confusing if one numeric mapping is used in SIP =20 >>>> and a >>>> different, opposing, mapping is used in QSPEC. >>> >>> Agreed. We'll check the referenced specification and align the =20 >>> mapping in >>> the QSPEC. >>> >>> Thanks a lot for pointing this out. >>> >>> Jerry >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> Classification: UNCLASSIFIED >>> Caveats: NONE >> Classification: UNCLASSIFIED >> Caveats: NONE >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 09:56:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwFq-0000Da-JU; Mon, 10 Jul 2006 09:56:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwFo-0000B2-Rr for nsis@ietf.org; Mon, 10 Jul 2006 09:56:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzs08-0004R8-EE for nsis@ietf.org; Mon, 10 Jul 2006 05:24:24 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FzrRw-0003qZ-NO for nsis@ietf.org; Mon, 10 Jul 2006 04:49:08 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k6A8mCfs006706; Mon, 10 Jul 2006 17:48:12 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k6A8mEj19108; Mon, 10 Jul 2006 17:48:14 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with SMTP id k6A8mEP13914; Mon, 10 Jul 2006 17:48:14 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] WGLC on QoS NSLP Date: Mon, 10 Jul 2006 16:45:46 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDFF4288@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC on QoS NSLP Thread-Index: AcaZD0zKpjBvaPUpR1eYvJ98FN20AwK7HlwQ From: "Cheng Hong" To: "Jukka MJ Manner" , X-Spam-Score: -2.6 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: john.loughney@nokia.com, andrew.mcdonald@roke.co.uk, Georgios Karagiannis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, Sorry for a late comment on the draft. I have gone through it, and quite like the way it is. However, I got a question regarding one of the message format definition. For the Reserve (also the QUERY) message, it is defined in section 5.1.2.1 as: RESERVE =3D COMMON_HEADER RSN [ RII ] [ REFRESH_PERIOD ] [ *BOUND_SESSION_ID ] [ [ PACKET_CLASSIFIER ] [ QSPEC ] [ QSPEC ] ] As I read it, there could be multiple QSPEC stacked in the message, however there is only one PACKET_ClASSIFIER object allowed. Shouldn't this be [ [ PACKET_CLASSIFIER ] [ QSPEC ] [PACKET_CLASSIFIER] [ QSPEC ] ] instead? (because the PACKET_CLASSIFIER would depend on the QoS Model used)=20 I remember there were some discussion regarding the issue around the Nov meeting time last year. But, I could not remember how this is resolved. Could you provide a pointer to the resolution? cheers Cheng Hong > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: Monday, June 26, 2006 6:59 PM > To: nsis@ietf.org > Subject: Re: [NSIS] WGLC on QoS NSLP >=20 >=20 > Hi all, >=20 > The wdiff tool does not like changes in section headings, so=20 > below is a page-by-page diff. It's not as nice as what wdiff=20 > produces, but shows the main things.=20 >=20 > There were a lot of editorial fixes and some text was=20 > re-arranged, many clarifications, but not that many technical=20 > changes. Some of the main technical things were removal of=20 > the peer ack-feature, fixes in the error codes, added error=20 > source identifier coding, add a new flag to RESERVE, etc. >=20 > http://www.cs.helsinki.fi/u/jmanner/draft-ietf-nsis-qos-nslp-1 > 1-from-0.diff.html >=20 >=20 > Jukka >=20 >=20 > On Mon, 26 Jun 2006 john.loughney@nokia.com wrote: >=20 > > Hi all, > >=20 > > Jukka has submitted the QoS NSLP draft. It should be=20 > released today. > > Until it is announced, you can find a copy of it here: > >=20 > http://www.cs.helsinki.fi/u/jmanner/papers/draft-ietf-nsis-qos-nslp-11 > > .t > > xt > >=20 > > The WGLC will run until July 7th. After that, Jukka can=20 > summarize all=20 > > issues and we will discuss them at the next IETF meeting in=20 > Montreal. > >=20 > > Jukka, do you have a diff file or a summary of the changes made? > >=20 > > thanks, > > John > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 10:12:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwVJ-0006OV-VV; Mon, 10 Jul 2006 10:12:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwVI-0006OP-IG for nsis@ietf.org; Mon, 10 Jul 2006 10:12:52 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzwVH-00017I-9n for nsis@ietf.org; Mon, 10 Jul 2006 10:12:52 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 10 Jul 2006 10:12:34 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006071010123129216 ; Mon, 10 Jul 2006 10:12:32 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Jul 2006 10:12:31 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230E3A@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: john.loughney@nokia.com, jmpolk@cisco.com, carlberg@g11.org.uk, an.p.nguyen@dhs.gov Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory AttributeList(UN CLASSIFIED) Date: Mon, 10 Jul 2006 10:12:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: jrrosenberg@lucent.com, cornelia.kappler@siemens.com, attila.bader@ericsson.com, nsis@ietf.org, gash@att.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org John and James: Please see comments inline [RRR]. As John pointed out that QSPEC is a generic one that defines the generic structure/container, and QoS models (e.g., Y.1541, DSTE, RSVP, DiffServ) define specific QoS deployments. Now the questions in front of the NSIS WG are as follows: 1. If this is the case why are there "some" QoS model-specific extensions like Y.1541 and DSTE (Sections 7.2.6.2 and 7.2.6.3) included in this QSPEC draft in the first place? 2. Why is there another draft - Y.1541 QoS model-specific extensions for QSPEC that deals with how all Y.1541 parameters can be used in extending QSPEC? Is it not more rational to make this Y.1451 draft as a SINGLE "stand-alone" draft that deals with ONLY Y.1541 QoS-model specific extensions of QSPEC? 3. Why can the present QPSEC draft be generic enough NOT to deal with only QoS-model specific extensions? What is the rational that the NSIS WG wants to deal with two drafts (a. one for QSPEC draft and b. another one Y.1541 draft) to deal with Y.541 QoS-model specific extensions of the "same" QSPEC parameters? 4. Why will the Chair (/members) not the appoint the EDITOR if the present authors are NOT willing to do so as suggested above because the WG Chair (/members) can "appoint" EDITOR to do so per charter of the IETF? Best regards, Radhika R. Roy -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of john.loughney@nokia.com Sent: Monday, July 10, 2006 9:29 AM To: jmpolk@cisco.com; carlberg@g11.org.uk; an.p.nguyen@dhs.gov Cc: jrrosenberg@lucent.com; gash@att.com; cornelia.kappler@siemens.com; nsis@ietf.org; attila.bader@ericsson.com Subject: RE: RPH nits Re: [NSIS] QSPEC Comment: Mandatory AttributeList(UNCLASSIFIED) James, >>The critical thing for the QSPEC is to have the structure/container >>that can hold the values and not the values themselves. > >This is an interesting idea. Design the container and the >semantics, but leave the values for later assignment. This is the general idea for the QoS NSLP - we can define the semantics, the QSPEC template defines the container and QoS models define specific QoS deployments. [RRR] Please the notes provided above what needs to be done with respect to the present QSPEC draft and Y.1541 draft that are in the WGLC. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 10:22:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwer-0001bO-5C; Mon, 10 Jul 2006 10:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwep-0001UX-Ky for nsis@ietf.org; Mon, 10 Jul 2006 10:22:43 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzweo-0001hB-5P for nsis@ietf.org; Mon, 10 Jul 2006 10:22:43 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ADMdsg029531; Mon, 10 Jul 2006 16:22:40 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:22:39 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:22:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Revised WGLC on RMD & new WGLC on Y1541 Date: Mon, 10 Jul 2006 17:22:39 +0300 Message-ID: In-Reply-To: <003101c69f58$36c20060$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Revised WGLC on RMD & new WGLC on Y1541 Thread-Index: AcacQt/F6eJBvNXpSt+MxfHV+3J+JwDFLK8AATUj2lA= From: To: , X-OriginalArrivalTime: 10 Jul 2006 14:22:39.0602 (UTC) FILETIME=[4C863D20:01C6A42C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org The QSPEC template has enough open issues, that I think that it is important to give time to ensure everything is OK. I'd like to see some comments on the draft - has anyone read the update? Are people's open issues from the previous wglc addressed? thanks, John >-----Original Message----- >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >Sent: 04 July, 2006 06:54 >To: Loughney John (Nokia-NRC/Helsinki); nsis@ietf.org >Subject: RE: [NSIS] Revised WGLC on RMD & new WGLC on Y1541 > >Hi John > >Maybe one week after the WGLC is expired it will be enough! >Could you please set the WGLC deadline for RMD-QOSM and=20 >Y1541-QOSM on July 14th, instead of 20th? >Note that many of us will start their holidays after the IETF meeting! > >Best regards, >Georgios > > > >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: vrijdag 30 juni 2006 14:44 >To: nsis@ietf.org >Subject: [NSIS] Revised WGLC on RMD & new WGLC on Y1541 > >Hi all, > >RMD is currently in WGLC, but as it is dependent on the QoS=20 >NSLP & QoS Template document, I will need to push back the=20 >WGLC on it. The WGLC will runn until July 20th, just in case=20 >there are any issues on either the QoS NSLP or QoS Template document. > >Feel free to review it now, though. > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-07.txt > >This draft is also ready for WGLC: >http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-02.txt > >and I will also start WGLC, going until July 20th. Again,=20 >send comments early. > >thanks, >John > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 10:31:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwmt-0003bp-WB; Mon, 10 Jul 2006 10:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwms-0003bk-Ni for nsis@ietf.org; Mon, 10 Jul 2006 10:31:02 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzwmq-00020H-Cg for nsis@ietf.org; Mon, 10 Jul 2006 10:31:02 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 10 Jul 2006 17:30:57 +0300 id 00087FF1.44B264A1.000059AD Date: Mon, 10 Jul 2006 17:30:57 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [NSIS] QoS NSLP WGLC ended X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, The WGLC on the QoS NSLP ended July 7th, and there was only one comment, a typo with QNI and QNR being mixed. Thus, the WG seems happy with the spec as it is. Yet, I'd would suggest one functionality to be added, the Proxy Mode. There were emails exchanged on the list end of April - beginning of May, and there seemed to be support for it. I didn't take it into the draft then, but it seems I perhaps should have. The reasons are: 1) Support in the WG 2) NAT/FW NSLP also has the same functionality 3) TSVWG is considering this issues for RSVP currently Proxy Mode would allow a QNE to operate on-behalf of an end-host to reply to QoS NSLP signaling messages. This would allow to set up reservations for outgoing and incoming flows. Not any QNE may operate as proxy, it must be a previously configured node. The changes required would be 1) One Generic Flag bit to indicate a message is part of a Proxy Mode session. 2) One Message Flag bit to indiate a QUERY is meant to trigger a RESERVE for an incoming flow. 3) Updates here and there to add discussion and message processing rules for the Proxy Mode. The Proxy Mode will probably be my main (only?) issue for the time slot at the meeting. We basically have two options: a) Take the Proxy Mode into the NSLP spec now, or b) Wait a bit and see how we finalize the parallel work in TSVWG goes, and then write a separate spec that adds the Proxy Mode for the QoS NSLP. You can comment now on the mailing list, or at the meeting (or catch me in the hallways). Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 10:34:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwq0-0004jh-Jw; Mon, 10 Jul 2006 10:34:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwpy-0004jc-Ro for nsis@ietf.org; Mon, 10 Jul 2006 10:34:14 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzwpx-00028a-8l for nsis@ietf.org; Mon, 10 Jul 2006 10:34:14 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ADYAAQ009868; Mon, 10 Jul 2006 16:34:12 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:34:11 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:34:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QoS NSLP WGLC ended Date: Mon, 10 Jul 2006 17:34:11 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QoS NSLP WGLC ended Thread-Index: AcakLYwRYmzNkBnjTkOmpaKzOGWLVAAADnkw From: To: , X-OriginalArrivalTime: 10 Jul 2006 14:34:11.0587 (UTC) FILETIME=[E8FAC530:01C6A42D] X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Additionally, I'd appreciate people speaking up that they have read the draft & that their open issues have been resolved. You have until Wednesday AM! John=20 >-----Original Message----- >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 >Sent: 10 July, 2006 10:31 >To: nsis@ietf.org >Subject: [NSIS] QoS NSLP WGLC ended > > >Dear all, > >The WGLC on the QoS NSLP ended July 7th, and there was only=20 >one comment, a typo with QNI and QNR being mixed. Thus, the WG=20 >seems happy with the spec as it is. > >Yet, I'd would suggest one functionality to be added, the Proxy Mode. =20 >There were emails exchanged on the list end of April -=20 >beginning of May, and there seemed to be support for it. I=20 >didn't take it into the draft then, but it seems I perhaps=20 >should have. The reasons are: > >1) Support in the WG >2) NAT/FW NSLP also has the same functionality >3) TSVWG is considering this issues for RSVP currently > >Proxy Mode would allow a QNE to operate on-behalf of an=20 >end-host to reply to QoS NSLP signaling messages. This would=20 >allow to set up reservations for outgoing and incoming flows.=20 >Not any QNE may operate as proxy, it must be a previously=20 >configured node. > >The changes required would be > >1) One Generic Flag bit to indicate a message is part of a Proxy Mode=20 > session. >2) One Message Flag bit to indiate a QUERY is meant to trigger=20 >a RESERVE=20 > for an incoming flow. >3) Updates here and there to add discussion and message=20 >processing rules=20 > for the Proxy Mode. > >The Proxy Mode will probably be my main (only?) issue for the=20 >time slot at the meeting. We basically have two options: > >a) Take the Proxy Mode into the NSLP spec now, or > >b) Wait a bit and see how we finalize the parallel work in=20 >TSVWG goes, and > then write a separate spec that adds the Proxy Mode for the=20 >QoS NSLP. > > >You can comment now on the mailing list, or at the meeting (or=20 >catch me in the hallways). > >Jukka > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 10:35:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwqv-0005OF-79; Mon, 10 Jul 2006 10:35:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwqu-0005O6-MJ for nsis@ietf.org; Mon, 10 Jul 2006 10:35:12 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fzwqt-0002B7-8h for nsis@ietf.org; Mon, 10 Jul 2006 10:35:12 -0400 Received: (qmail invoked by alias); 10 Jul 2006 14:35:10 -0000 Received: from h01fd-net84db.lab.risq.net (EHLO [132.219.1.253]) [132.219.1.253] by mail.gmx.net (mp038) with SMTP; 10 Jul 2006 16:35:10 +0200 X-Authenticated: #29516787 Message-ID: <44B265A2.3090308@gmx.net> Date: Mon, 10 Jul 2006 16:35:14 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP WGLC ended References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I supported the idea of adding proxy support already during the discussion in April. Ciao Hannes Jukka MJ Manner wrote: > Dear all, > > The WGLC on the QoS NSLP ended July 7th, and there was only one comment, a > typo with QNI and QNR being mixed. Thus, the WG seems happy with the spec > as it is. > > Yet, I'd would suggest one functionality to be added, the Proxy Mode. > There were emails exchanged on the list end of April - beginning of May, > and there seemed to be support for it. I didn't take it into the draft > then, but it seems I perhaps should have. The reasons are: > > 1) Support in the WG > 2) NAT/FW NSLP also has the same functionality > 3) TSVWG is considering this issues for RSVP currently > > Proxy Mode would allow a QNE to operate on-behalf of an end-host to reply > to QoS NSLP signaling messages. This would allow to set up reservations > for outgoing and incoming flows. Not any QNE may operate as proxy, it must > be a previously configured node. > > The changes required would be > > 1) One Generic Flag bit to indicate a message is part of a Proxy Mode > session. > 2) One Message Flag bit to indiate a QUERY is meant to trigger a RESERVE > for an incoming flow. > 3) Updates here and there to add discussion and message processing rules > for the Proxy Mode. > > The Proxy Mode will probably be my main (only?) issue for the time slot at > the meeting. We basically have two options: > > a) Take the Proxy Mode into the NSLP spec now, or > > b) Wait a bit and see how we finalize the parallel work in TSVWG goes, and > then write a separate spec that adds the Proxy Mode for the QoS NSLP. > > > You can comment now on the mailing list, or at the meeting (or catch me in > the hallways). > > Jukka > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 10:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwvz-0007n7-S1; Mon, 10 Jul 2006 10:40:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwvy-0007i2-3a for nsis@ietf.org; Mon, 10 Jul 2006 10:40:26 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fzwvw-0002My-Le for nsis@ietf.org; Mon, 10 Jul 2006 10:40:26 -0400 Received: (qmail invoked by alias); 10 Jul 2006 14:40:23 -0000 Received: from h01fd-net84db.lab.risq.net (EHLO [132.219.1.253]) [132.219.1.253] by mail.gmx.net (mp007) with SMTP; 10 Jul 2006 16:40:23 +0200 X-Authenticated: #29516787 Message-ID: <44B266DC.6070503@gmx.net> Date: Mon, 10 Jul 2006 16:40:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] QoS NSLP WGLC ended References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: jmanner@cs.Helsinki.FI, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, you raised a good point. I have read draft-ietf-nsis-qos-nslp-10.txt and faxed my comments to the authors. I haven't read draft-ietf-nsis-qos-nslp-11.txt because of the submission deadlines. I therefore haven't had the possibility to verify whether my comments actually got addressed. I plan read the -11 version and to post comments. Ciao Hannes john.loughney@nokia.com wrote: > Additionally, I'd appreciate people speaking up that they have read > the draft & that their open issues have been resolved. You have until > Wednesday AM! > > John > > >>-----Original Message----- >>From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >>Sent: 10 July, 2006 10:31 >>To: nsis@ietf.org >>Subject: [NSIS] QoS NSLP WGLC ended >> >> >>Dear all, >> >>The WGLC on the QoS NSLP ended July 7th, and there was only >>one comment, a typo with QNI and QNR being mixed. Thus, the WG >>seems happy with the spec as it is. >> >>Yet, I'd would suggest one functionality to be added, the Proxy Mode. >>There were emails exchanged on the list end of April - >>beginning of May, and there seemed to be support for it. I >>didn't take it into the draft then, but it seems I perhaps >>should have. The reasons are: >> >>1) Support in the WG >>2) NAT/FW NSLP also has the same functionality >>3) TSVWG is considering this issues for RSVP currently >> >>Proxy Mode would allow a QNE to operate on-behalf of an >>end-host to reply to QoS NSLP signaling messages. This would >>allow to set up reservations for outgoing and incoming flows. >>Not any QNE may operate as proxy, it must be a previously >>configured node. >> >>The changes required would be >> >>1) One Generic Flag bit to indicate a message is part of a Proxy Mode >> session. >>2) One Message Flag bit to indiate a QUERY is meant to trigger >>a RESERVE >> for an incoming flow. >>3) Updates here and there to add discussion and message >>processing rules >> for the Proxy Mode. >> >>The Proxy Mode will probably be my main (only?) issue for the >>time slot at the meeting. We basically have two options: >> >>a) Take the Proxy Mode into the NSLP spec now, or >> >>b) Wait a bit and see how we finalize the parallel work in >>TSVWG goes, and >> then write a separate spec that adds the Proxy Mode for the >>QoS NSLP. >> >> >>You can comment now on the mailing list, or at the meeting (or >>catch me in the hallways). >> >>Jukka >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 10:43:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwym-0002pC-1j; Mon, 10 Jul 2006 10:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwyl-0002p2-4o for nsis@ietf.org; Mon, 10 Jul 2006 10:43:19 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzwyj-0002Sp-M1 for nsis@ietf.org; Mon, 10 Jul 2006 10:43:19 -0400 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by mailer.gwdg.de with esmtp (Exim 4.60) (envelope-from ) id 1Fzwyg-00077C-DA; Mon, 10 Jul 2006 16:43:16 +0200 Received: from [132.219.28.219] (unknown [132.219.28.219]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP; Mon, 10 Jul 2006 16:43:13 +0200 (CEST) Message-ID: <44B2677C.1010009@cs.uni-goettingen.de> Date: Mon, 10 Jul 2006 10:43:08 -0400 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP WGLC ended References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required _SUMMARY_ X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I am in support of proxy mode in QoS NSLP Xiaoming Jukka MJ Manner wrote: > Dear all, > > The WGLC on the QoS NSLP ended July 7th, and there was only one comment, a > typo with QNI and QNR being mixed. Thus, the WG seems happy with the spec > as it is. > > Yet, I'd would suggest one functionality to be added, the Proxy Mode. > There were emails exchanged on the list end of April - beginning of May, > and there seemed to be support for it. I didn't take it into the draft > then, but it seems I perhaps should have. The reasons are: > > 1) Support in the WG > 2) NAT/FW NSLP also has the same functionality > 3) TSVWG is considering this issues for RSVP currently > > Proxy Mode would allow a QNE to operate on-behalf of an end-host to reply > to QoS NSLP signaling messages. This would allow to set up reservations > for outgoing and incoming flows. Not any QNE may operate as proxy, it must > be a previously configured node. > > The changes required would be > > 1) One Generic Flag bit to indicate a message is part of a Proxy Mode > session. > 2) One Message Flag bit to indiate a QUERY is meant to trigger a RESERVE > for an incoming flow. > 3) Updates here and there to add discussion and message processing rules > for the Proxy Mode. > > The Proxy Mode will probably be my main (only?) issue for the time slot at > the meeting. We basically have two options: > > a) Take the Proxy Mode into the NSLP spec now, or > > b) Wait a bit and see how we finalize the parallel work in TSVWG goes, and > then write a separate spec that adds the Proxy Mode for the QoS NSLP. > > > You can comment now on the mailing list, or at the meeting (or catch me in > the hallways). > > Jukka > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 10:45:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzx1J-0003ne-Jc; Mon, 10 Jul 2006 10:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzx1I-0003nQ-FH for nsis@ietf.org; Mon, 10 Jul 2006 10:45:56 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzx1G-0002Z9-WA for nsis@ietf.org; Mon, 10 Jul 2006 10:45:56 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6AEjrEl028128; Mon, 10 Jul 2006 17:45:53 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:45:49 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:45:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] NSIS next steps Date: Mon, 10 Jul 2006 17:45:49 +0300 Message-ID: In-Reply-To: <44AD380F.1060902@docomolab-euro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] NSIS next steps Thread-Index: AcahMGqLkr+DqXUoT665t2E5akBfkwC/v95g From: To: , X-OriginalArrivalTime: 10 Jul 2006 14:45:49.0665 (UTC) FILETIME=[89110510:01C6A42F] X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Paulo, >I would like to express interest on the MRM pattern (I had=20 >already done it in Dallas after Martin's presentation). > >As for Hannes question about applications that may make use of=20 >this MRM, I can mention one: a different type of=20 >interDomain-QoSM as the one that will be presented in Montreal=20 >(draft-zhang-nsis-interdomain-qosm-02): >- the draft to be presented in Montreal makes use of the new=20 >off-path MRM to break the end-to-end QoS signaling into=20 >inter-domain and intra-domain. >- with the MRM pattern the inter-domain signaling may be done=20 >in a different way, starting by the QoS-controller that=20 >triggers the navigation pattern. For instance: > - one QoS-controller may explore/monitor the capacity of=20 >neighbour networks (QoS-controllers) with a TTL defined in the=20 >query message and use the returned information to dimension=20 >its network. > - one QoS-controller may announce its own capability to=20 >its neighbours with a TTL defined in the query, and to collect=20 >the interest of other networks to make use of that capability. Very interesting - I'd be very interested in seeing this written up. >Another application may be to configuration over dispersed=20 >nodes, such as sensors, and to collect sensing information. That would be another use - though a bit more experimental ... John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 11:08:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxNS-0007kk-GD; Mon, 10 Jul 2006 11:08:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxNR-0007kf-Fu for nsis@ietf.org; Mon, 10 Jul 2006 11:08:49 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxNQ-000417-1G for nsis@ietf.org; Mon, 10 Jul 2006 11:08:49 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 10 Jul 2006 18:08:47 +0300 id 00087DDB.44B26D7F.000019FB Date: Mon, 10 Jul 2006 18:08:47 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] QoS NSLP WGLC ended In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Most comments were from Rob, Hannes, Roland and us authors (and various smaller comments from others). I can say I have included pretty much all suggested changes. Can't remember any major comment that would not have been included. Jukka On Mon, 10 Jul 2006 john.loughney@nokia.com wrote: > Additionally, I'd appreciate people speaking up that they have read > the draft & that their open issues have been resolved. You have until > Wednesday AM! > > John > > >-----Original Message----- > >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >Sent: 10 July, 2006 10:31 > >To: nsis@ietf.org > >Subject: [NSIS] QoS NSLP WGLC ended > > > > > >Dear all, > > > >The WGLC on the QoS NSLP ended July 7th, and there was only > >one comment, a typo with QNI and QNR being mixed. Thus, the WG > >seems happy with the spec as it is. > > > >Yet, I'd would suggest one functionality to be added, the Proxy Mode. > >There were emails exchanged on the list end of April - > >beginning of May, and there seemed to be support for it. I > >didn't take it into the draft then, but it seems I perhaps > >should have. The reasons are: > > > >1) Support in the WG > >2) NAT/FW NSLP also has the same functionality > >3) TSVWG is considering this issues for RSVP currently > > > >Proxy Mode would allow a QNE to operate on-behalf of an > >end-host to reply to QoS NSLP signaling messages. This would > >allow to set up reservations for outgoing and incoming flows. > >Not any QNE may operate as proxy, it must be a previously > >configured node. > > > >The changes required would be > > > >1) One Generic Flag bit to indicate a message is part of a Proxy Mode > > session. > >2) One Message Flag bit to indiate a QUERY is meant to trigger > >a RESERVE > > for an incoming flow. > >3) Updates here and there to add discussion and message > >processing rules > > for the Proxy Mode. > > > >The Proxy Mode will probably be my main (only?) issue for the > >time slot at the meeting. We basically have two options: > > > >a) Take the Proxy Mode into the NSLP spec now, or > > > >b) Wait a bit and see how we finalize the parallel work in > >TSVWG goes, and > > then write a separate spec that adds the Proxy Mode for the > >QoS NSLP. > > > > > >You can comment now on the mailing list, or at the meeting (or > >catch me in the hallways). > > > >Jukka > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 14:29:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00V8-0001ez-Ua; Mon, 10 Jul 2006 14:28:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00Uo-00013n-9t for nsis@ietf.org; Mon, 10 Jul 2006 14:28:38 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G00Um-0005lg-Qf for nsis@ietf.org; Mon, 10 Jul 2006 14:28:38 -0400 Received: from [132.219.24.165] (unknown [132.219.24.165]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6F5AA1BAC9E for ; Mon, 10 Jul 2006 20:14:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43600D44-CA8C-4746-B3CC-648AD86C3464@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: AW: [NSIS] NSIS next steps Date: Mon, 10 Jul 2006 13:34:56 -0400 To: nsis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Nice to see such a big interest about the "Additional Communication Patterns for NSIS" (draft-stiemerling-nsis-mrm-patterns-00.txt). To get to the roots of those additional communication patterns: The base idea originated in distributed network management, where you try to find other managed stations in your vicinity. If people are interested, we could meet for a chat after the presentation. Thanks, Martin Am 10.07.2006 um 10:45 schrieb : > Paulo, > >> I would like to express interest on the MRM pattern (I had >> already done it in Dallas after Martin's presentation). >> >> As for Hannes question about applications that may make use of >> this MRM, I can mention one: a different type of >> interDomain-QoSM as the one that will be presented in Montreal >> (draft-zhang-nsis-interdomain-qosm-02): >> - the draft to be presented in Montreal makes use of the new >> off-path MRM to break the end-to-end QoS signaling into >> inter-domain and intra-domain. >> - with the MRM pattern the inter-domain signaling may be done >> in a different way, starting by the QoS-controller that >> triggers the navigation pattern. For instance: >> - one QoS-controller may explore/monitor the capacity of >> neighbour networks (QoS-controllers) with a TTL defined in the >> query message and use the returned information to dimension >> its network. >> - one QoS-controller may announce its own capability to >> its neighbours with a TTL defined in the query, and to collect >> the interest of other networks to make use of that capability. > > Very interesting - I'd be very interested in seeing this written up. > >> Another application may be to configuration over dispersed >> nodes, such as sensors, and to collect sensing information. > > That would be another use - though a bit more experimental ... > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 14:35:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00bp-000712-76; Mon, 10 Jul 2006 14:35:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00bn-00070j-9b for nsis@ietf.org; Mon, 10 Jul 2006 14:35:51 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G00bl-0007Az-PZ for nsis@ietf.org; Mon, 10 Jul 2006 14:35:51 -0400 Received: from [132.219.24.165] (unknown [132.219.24.165]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 40F7C1BAC9E; Mon, 10 Jul 2006 20:21:41 +0200 (CEST) In-Reply-To: <44B24661.90709@cs.uni-goettingen.de> References: <44B24661.90709@cs.uni-goettingen.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <545AD321-8EE4-460F-926C-D7C1249792C5@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt Date: Mon, 10 Jul 2006 13:38:27 -0400 To: Xiaoming Fu X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Xiaoming, What do exactly refer as "detection of middlebox presence"? Basically, the NATFW NSLP, to be precise GIST, is already detecting the presence of NATFW NSLP enabled middleboxes. Martin Am 10.07.2006 um 08:21 schrieb Xiaoming Fu: > Hi Martin, all, > > Is it possible for NAT/FW NSIS NSLP to support detection of > middlebox presence? We find out this feature will be useful in MIP6 > FW traversal scenarios, as depicted in http://www.ietf.org/internet- > drafts/draft-thiruvengadam-nsis-mip6-fw-04.txt > This could save additional signaling message flows, especially if > one expects to install multiple rules in a firewall -- if exists -- > in a particular IP path, e.g., rules for allowing both BU and HoTI > messages to traverse between the MN and the HA. > > Cheers, > Xiaoming > > Internet-Drafts@ietf.org wrote: >> 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 : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) >> Author(s) : M. Stiemerling, et al. >> Filename : draft-ietf-nsis-nslp-natfw-12.txt >> Pages : 101 >> Date : 2006-6-29 >> >> This memo defines the NSIS Signaling Layer Protocol (NSLP) for >> Network Address Translators (NATs) and firewalls. This NSLP >> allows >> hosts to signal on the data path for NATs and firewalls to be >> configured according to the needs of the application data >> flows. It >> enables hosts behind NATs to obtain a public reachable address and >> hosts behind firewalls to receive data traffic. The overall >> architecture is given by the framework and requirements defined by >> the Next Steps in Signaling (NSIS) working group. The network >> scenarios, the protocol itself, and examples for path-coupled >> signaling are given in this memo. >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt >> To remove yourself from the I-D Announcement list, send a message >> to i-d-announce-request@ietf.org with the word unsubscribe in the >> body of the message. You can also visit https://www1.ietf.org/ >> mailman/listinfo/I-D-announce to change your subscription settings. >> Internet-Drafts are also available by anonymous FTP. Login with >> the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-nsis-nslp-natfw-12.txt". >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow- >> sites.txt >> Internet-Drafts can also be obtained by e-mail. >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> --------------------------------------------------------------------- >> --- >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 14:53:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00sV-0000l2-3S; Mon, 10 Jul 2006 14:53:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00sU-0000kx-DO for nsis@ietf.org; Mon, 10 Jul 2006 14:53:06 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G00sT-0000Jk-S8 for nsis@ietf.org; Mon, 10 Jul 2006 14:53:06 -0400 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by mailer.gwdg.de with esmtp (Exim 4.60) (envelope-from ) id 1G00sO-0008M9-Rq; Mon, 10 Jul 2006 20:53:05 +0200 Received: from [132.219.9.236] (unknown [132.219.9.236]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP; Mon, 10 Jul 2006 20:53:00 +0200 (CEST) Message-ID: <44B2A209.5040208@cs.uni-goettingen.de> Date: Mon, 10 Jul 2006 14:52:57 -0400 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt References: <44B24661.90709@cs.uni-goettingen.de> <545AD321-8EE4-460F-926C-D7C1249792C5@netlab.nec.de> In-Reply-To: <545AD321-8EE4-460F-926C-D7C1249792C5@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required _SUMMARY_ X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, I mean detection as a separate message exchange in NSLP level before signaling desired rules. It can be simply a request-response pair, but no real signaling action (install, response or removal of NAT/FW state). In principle one could use REA or a new message type for this purpose, e.g., for detecting firewalls between MN-HA - MN sends a REA message towards HA, resulting in a RESPONSE from a firewall and an ERROR RESPONSE from the HA. This way, MN will know whether there is a FW between them (but not the type). - alternatively, MN can issue a DETECT (no matter it is called) message towards the HA to collect all firewall information, if any, and RESPONSE from the HA gives the response to MN. This is similar to what diagnostics function covers. This feature could provide the NI some freedom e.g., choosing multiple rules in a single signaling message exchange, or even no NAT/FW signaling is needed (if it is clear that no firewall is encountered in the data path). Xiaoming Martin Stiemerling wrote: > Hi Xiaoming, > > What do exactly refer as "detection of middlebox presence"? Basically, > the NATFW NSLP, to be precise GIST, is already detecting the presence > of NATFW NSLP enabled middleboxes. > > Martin > > Am 10.07.2006 um 08:21 schrieb Xiaoming Fu: > >> Hi Martin, all, >> >> Is it possible for NAT/FW NSIS NSLP to support detection of middlebox >> presence? We find out this feature will be useful in MIP6 FW >> traversal scenarios, as depicted in http://www.ietf.org/internet- >> drafts/draft-thiruvengadam-nsis-mip6-fw-04.txt >> This could save additional signaling message flows, especially if one >> expects to install multiple rules in a firewall -- if exists -- in a >> particular IP path, e.g., rules for allowing both BU and HoTI >> messages to traverse between the MN and the HA. >> >> Cheers, >> Xiaoming >> >> Internet-Drafts@ietf.org wrote: >> >>> 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 : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) >>> Author(s) : M. Stiemerling, et al. >>> Filename : draft-ietf-nsis-nslp-natfw-12.txt >>> Pages : 101 >>> Date : 2006-6-29 >>> >>> This memo defines the NSIS Signaling Layer Protocol (NSLP) for >>> Network Address Translators (NATs) and firewalls. This NSLP allows >>> hosts to signal on the data path for NATs and firewalls to be >>> configured according to the needs of the application data flows. It >>> enables hosts behind NATs to obtain a public reachable address and >>> hosts behind firewalls to receive data traffic. The overall >>> architecture is given by the framework and requirements defined by >>> the Next Steps in Signaling (NSIS) working group. The network >>> scenarios, the protocol itself, and examples for path-coupled >>> signaling are given in this memo. >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body >>> of the message. You can also visit https://www1.ietf.org/ >>> mailman/listinfo/I-D-announce to change your subscription settings. >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username >>> "anonymous" and a password of your e-mail address. After logging in, >>> type "cd internet-drafts" and then >>> "get draft-ietf-nsis-nslp-natfw-12.txt". >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow- >>> sites.txt >>> Internet-Drafts can also be obtained by e-mail. >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> --------------------------------------------------------------------- >>> --- >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 16:36:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02Ug-0002H7-IJ; Mon, 10 Jul 2006 16:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02Ue-0002Gc-QN for nsis@ietf.org; Mon, 10 Jul 2006 16:36:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G00yh-0000g7-Vj for nsis@ietf.org; Mon, 10 Jul 2006 14:59:32 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G00nY-0006yG-3x for nsis@ietf.org; Mon, 10 Jul 2006 14:48:05 -0400 Received: from [132.219.24.165] (unknown [132.219.24.165]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CCDD61BAC9E for ; Mon, 10 Jul 2006 20:33:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) To: nsis Message-Id: References: From: Martin Stiemerling Subject: Fwd: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt Date: Mon, 10 Jul 2006 14:47:50 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.6 (--) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0641592586==" Errors-To: nsis-bounces@ietf.org --===============0641592586== Content-Type: multipart/alternative; boundary=Apple-Mail-7-303895067 --Apple-Mail-7-303895067 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear all, Please find the htmlized diff between -11 and -12 here: http://www.stiemerling.org/ietf/nsis/draft-ietf-nsis-nslp-natfw-12- diff-to-11.html Martin Anfang der weitergeleiteten E-Mail: > Von: Internet-Drafts@ietf.org > Datum: 29. Juni 2006 15:50:02 GMT-04:00 > An: i-d-announce@ietf.org > Kopie: nsis@ietf.org > Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Next Steps in Signaling Working > Group of the IETF. > > Title : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) > Author(s) : M. Stiemerling, et al. > Filename : draft-ietf-nsis-nslp-natfw-12.txt > Pages : 101 > Date : 2006-6-29 > > This memo defines the NSIS Signaling Layer Protocol (NSLP) for > Network Address Translators (NATs) and firewalls. This NSLP allows > hosts to signal on the data path for NATs and firewalls to be > configured according to the needs of the application data > flows. It > enables hosts behind NATs to obtain a public reachable address and > hosts behind firewalls to receive data traffic. The overall > architecture is given by the framework and requirements defined by > the Next Steps in Signaling (NSIS) working group. The network > scenarios, the protocol itself, and examples for path-coupled > signaling are given in this memo. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nsis-nslp-natfw-12.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-6-29112909.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --Apple-Mail-7-303895067 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear all,

Please find the htmlized = diff between -11 and -12 here:


=A0 = Martin

Anfang der weitergeleiteten E-Mail:

Datum: 29. Juni 2006 15:50:02 = GMT-04:00
An: i-d-announce@ietf.org
Kopie: = nsis@ietf.org
Betreff: = [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt=A0

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 = = : NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
Author(s) : M. = Stiemerling, et al.
= Filename = : draft-ietf-nsis-nslp-natfw-12.txt
= Pages = = : 101
Date : 2006-6-29


This memo = defines the NSIS Signaling Layer Protocol (NSLP) for
=A0=A0 = Network Address Translators (NATs) and firewalls.=A0 This NSLP allows
=A0=A0 = hosts to signal on the data path for NATs and firewalls to = be
=A0=A0 = configured according to the needs of the application data = flows.=A0 It
=A0=A0 = enables hosts behind NATs to obtain a public reachable address = and
=A0=A0 hosts behind firewalls to = receive data traffic.=A0 = The overall
=A0=A0 architecture is given by = the framework and requirements defined by
=A0=A0 the Next Steps in = Signaling (NSIS) working group.=A0 = The network
=A0=A0 scenarios, the protocol = itself, and examples for path-coupled
=A0=A0 signaling are given in = this memo.

A URL for this Internet-Draft is:

To remove yourself from the I-D Announcement list, = send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of the message. =A0
to = change your subscription settings.


Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" = and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get = draft-ietf-nsis-nslp-natfw-12.txt".

A list of Internet-Drafts = directories can be found in

Internet-Drafts can also be obtained by = e-mail.

Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

= =


Below is the = data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.
Content-Type: text/plain

=

= --Apple-Mail-7-303895067-- --===============0641592586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0641592586==-- From nsis-bounces@ietf.org Mon Jul 10 17:29:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G03JQ-0005IR-Qs; Mon, 10 Jul 2006 17:29:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G03J6-0004Kt-Vq for nsis@ietf.org; Mon, 10 Jul 2006 17:28:44 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G03J5-0008Os-Ky for nsis@ietf.org; Mon, 10 Jul 2006 17:28:44 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1152566881!12487831!5 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 3814 invoked from network); 10 Jul 2006 21:28:42 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-9.tower-120.messagelabs.com with SMTP; 10 Jul 2006 21:28:42 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452001A9053; Mon, 10 Jul 2006 17:28:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] comment on draft-ietf-nsis-qspec-10.txt Date: Mon, 10 Jul 2006 16:28:41 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7AB8@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9mshAIWY.1152332355.2827720.karagian@ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] comment on draft-ietf-nsis-qspec-10.txt Thread-Index: AcaiRcXTPqMe/2rTRt6rHDMUsLdGFwCIZ5/A From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, See below.=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Saturday, July 08, 2006 12:19 AM > To: nsis@ietf.org > Cc: karagian@cs.utwente.nl > Subject: [NSIS] comment on draft-ietf-nsis-qspec-10.txt >=20 > Hi Jerry, Cornelia and Attila >=20 > I have a comment on Section 6.1 of the QSpec template draft=20 > that may also > apply to Section 6.2. >=20 > In the last paragraph of the section you say: > "Regarding Control Information, the rule is that all parameters that > have been included in the RESERVE message by the QNI MUST also be > included in the RESPONSE message by the QNR with the value=20 > they had when > arriving at the QNR." >=20 > Note that for the Control Information defined by a QOSM this=20 > rule may be > overruled, since the QOSM defines how the control information=20 > should be > used by the domain that supports this QOSM. Therefore, I=20 > would very much > appreciate if you could modify the paragraph to allow this=20 > possibility. > A possible modification could be: >=20 > "Regarding Control Information, the default rule is that all=20 > parameters > that have been included in the RESERVE message by the QNI are also > included in the RESPONSE message by the QNR with the value=20 > they had when > arriving at the QNR. However, regarding the QOSM specific Control > Information, a QOSM may specify its own processing rules." >=20 > Please note that the same comment applies to Section 6.2. We agree that your suggested change is OK. Thanks, Jerry =20 > Best Regards, > Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 10 19:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G056S-0005OQ-Rf; Mon, 10 Jul 2006 19:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G056R-0005NO-7r for nsis@ietf.org; Mon, 10 Jul 2006 19:23:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzwom-000254-9z for nsis@ietf.org; Mon, 10 Jul 2006 10:33:00 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fzwan-0001qU-8a for nsis@ietf.org; Mon, 10 Jul 2006 10:18:34 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6AEI1nT019977; Mon, 10 Jul 2006 15:18:01 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 15:18:00 +0100 Message-ID: <44B26194.4050604@roke.co.uk> Date: Mon, 10 Jul 2006 15:17:56 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cheng Hong Subject: Re: [NSIS] WGLC on QoS NSLP References: <5F09D220B62F79418461A978CA0921BDFF4288@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BDFF4288@pslexc01.psl.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 14:18:01.0072 (UTC) FILETIME=[A681EF00:01C6A42B] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: john.loughney@nokia.com, Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Cheng Hong wrote: > Sorry for a late comment on the draft. I have gone through it, and quite > like the way it is. Thanks for reviewing it. > However, I got a question regarding one of the message format > definition. For the Reserve (also the QUERY) message, it is defined in > section 5.1.2.1 as: > > RESERVE = COMMON_HEADER > RSN [ RII ] [ REFRESH_PERIOD ] [ *BOUND_SESSION_ID ] > [ [ PACKET_CLASSIFIER ] [ QSPEC ] [ QSPEC ] ] > > As I read it, there could be multiple QSPEC stacked in the message, > however there is only one PACKET_ClASSIFIER object allowed. Shouldn't > this be [ [ PACKET_CLASSIFIER ] [ QSPEC ] [PACKET_CLASSIFIER] [ QSPEC ] > ] instead? (because the PACKET_CLASSIFIER would depend on the QoS Model > used) > > I remember there were some discussion regarding the issue around the Nov > meeting time last year. But, I could not remember how this is resolved. > Could you provide a pointer to the resolution? I do remember discussing this before. The conclusion was: We should only have a single PACKET_CLASSIFIER. The reasoning being that allowing for multiple classifiers means that the reservation may apply to different sets of packets along different path segments. The initiator then doesn't know whether the reservation along some part of the path actually applies to the packets it asked for the reservation for. This generally sounds like a bad idea. If you do need to have different PACKET_CLASSIFIERs then you can always use parallel signalling sessions (e.g. this is the way RMD handles this). regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 02:48:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0C35-0002JK-4S; Tue, 11 Jul 2006 02:48:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0C30-0002FB-Sq for nsis@ietf.org; Tue, 11 Jul 2006 02:48:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G08qE-0003jw-L0 for nsis@ietf.org; Mon, 10 Jul 2006 23:23:18 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G08eO-00019y-Oz for nsis@ietf.org; Mon, 10 Jul 2006 23:11:08 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k6B3AVon026169; Tue, 11 Jul 2006 12:10:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k6B3AWk15230; Tue, 11 Jul 2006 12:10:32 +0900 (JST) Received: from localhost ([127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id k6B3AWG20177; Tue, 11 Jul 2006 12:10:32 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] WGLC on QoS NSLP Date: Tue, 11 Jul 2006 11:08:17 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDFF432C@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC on QoS NSLP Thread-Index: Acakd46ttK3hxe0XQzuRHwEv6eSPiQAHbyFw From: "Cheng Hong" To: "Andrew McDonald" X-Spam-Score: -2.6 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: john.loughney@nokia.com, Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, Thanks for your reply.=20 Am I correct in reading it as following: - PACKET_CLASSIFIER shall only be set by the initiator;=20 - If there needs to be a change in PACKET_CLASSIFIER, the QSPEC stacking should not be allowed. In stead, method in section 4.6 should be used.=20 cheers Cheng Hong > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Monday, July 10, 2006 10:18 PM > To: Cheng Hong > Cc: john.loughney@nokia.com; Georgios Karagiannis; Jukka MJ=20 > Manner; nsis@ietf.org > Subject: Re: [NSIS] WGLC on QoS NSLP >=20 > Hi, >=20 > Cheng Hong wrote: > > Sorry for a late comment on the draft. I have gone through it, and=20 > > quite like the way it is. >=20 > Thanks for reviewing it. >=20 > > However, I got a question regarding one of the message format=20 > > definition. For the Reserve (also the QUERY) message, it is=20 > defined in=20 > > section 5.1.2.1 as: > >=20 > > RESERVE =3D COMMON_HEADER > > RSN [ RII ] [ REFRESH_PERIOD ] [ *BOUND_SESSION_ID ] > > [ [ PACKET_CLASSIFIER ] [ QSPEC ] [ QSPEC ] ] > >=20 > > As I read it, there could be multiple QSPEC stacked in the message,=20 > > however there is only one PACKET_ClASSIFIER object allowed.=20 > Shouldn't=20 > > this be [ [ PACKET_CLASSIFIER ] [ QSPEC ]=20 > [PACKET_CLASSIFIER] [ QSPEC=20 > > ] ] instead? (because the PACKET_CLASSIFIER would depend on the QoS=20 > > Model > > used) > >=20 > > I remember there were some discussion regarding the issue=20 > around the=20 > > Nov meeting time last year. But, I could not remember how=20 > this is resolved. > > Could you provide a pointer to the resolution? >=20 > I do remember discussing this before. The conclusion was: > We should only have a single PACKET_CLASSIFIER. The reasoning=20 > being that allowing for multiple classifiers means that the=20 > reservation may apply to different sets of packets along=20 > different path segments. The initiator then doesn't know=20 > whether the reservation along some part of the path actually=20 > applies to the packets it asked for the reservation for. This=20 > generally sounds like a bad idea. >=20 > If you do need to have different PACKET_CLASSIFIERs then you=20 > can always use parallel signalling sessions (e.g. this is the=20 > way RMD handles this). >=20 > regards, >=20 > Andrew >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 10:57:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Jg0-0001Mj-Mi; Tue, 11 Jul 2006 10:57:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Jg0-0001Md-4P for nsis@ietf.org; Tue, 11 Jul 2006 10:57:28 -0400 Received: from natlemon.rzone.de ([81.169.145.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Jfy-0006NV-OD for nsis@ietf.org; Tue, 11 Jul 2006 10:57:28 -0400 Received: from [192.168.178.200] (p5484BA4E.dip0.t-ipconnect.de [84.132.186.78]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k6BEvKb4017054; Tue, 11 Jul 2006 16:57:21 +0200 (MEST) Message-ID: <44B3BBAE.5020009@cs.uni-goettingen.de> Date: Tue, 11 Jul 2006 16:54:38 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gash@att.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nsis@ietf.org Subject: [NSIS] questions on y1541-qosm X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, I have some questions on your draft. Section 2.2 says: 262 It MUST be possible to perform the following QoS-NSLP signaling 263 functions to enable Y.1541-QOSM requirements: 264 265 a. accumulate delay, delay variation and loss ratio across the 266 end-to-end connection, which may span multiple domains How can the delay be identified across the path? AFAIK only the QNI can calculate the RTT since no timestamp of the QUERY msg is available at QNEs. Including e.g. a 32-bit long value containing the seconds since the Epoch would solve this. But how can the delay variation (and loss ratio) be gathered? Is this the variation of every single packet, e.g. voice streaming data, compared to the agreed delay rate? Since multiple values are requiered this can't be done with a single QUERY. These methods describe only the actual state, but don't say anything about future values. The values can change depending on the load of the routers. What does it mean when a QNI gets a RESPONSE with 0? Is this a guaranty that the delay never exceeds 100ms, the delay variation is always <=50 ms and the loss ratio <=10^-3? Or does the network service provider has to ensure these limits as mentioned in section 2.1? Thanks, Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 12:58:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0LYn-0005tU-Jb; Tue, 11 Jul 2006 12:58:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0LYm-0005tJ-W6 for nsis@ietf.org; Tue, 11 Jul 2006 12:58:08 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0LYl-0006he-C8 for nsis@ietf.org; Tue, 11 Jul 2006 12:58:08 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6BGvqif016046; Tue, 11 Jul 2006 17:57:53 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 17:57:52 +0100 From: "Robert Hancock" To: "'Ash, Gerald R \(Jerry\), ALABS'" , "'NSIS'" Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt Date: Tue, 11 Jul 2006 12:57:50 -0400 Message-ID: <001001c6a50b$2546d460$f803db84@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7AA5@KCCLUST06EVS1.ugd.att.com> Importance: Normal X-OriginalArrivalTime: 11 Jul 2006 16:57:52.0487 (UTC) FILETIME=[25D97770:01C6A50B] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi jerry, some comments on some of the comments: > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] [snip] > > > 3) page 11 last para: this seems to assume that there is an > > INTSERV-QOSM > > whereas in fact none is being defined. > > This is the reference: > [INTSERV-QOSM] Kappler, C., "A QoS Model for Signaling IntServ > Controlled-Load Service with NSIS," work in progress. > > This QOSM is being defined, but is not yet a WG draft. true - but it's not an INTSERV QoSM but a CL QoSM only (and only for 'pure' CL, not CL/Diffserv or CL/PCN). hence the follow up question about 'what is a QoSM'. someone reading the text might get the impression that there is a single QoSM that covers both CL and GS. [snip] > > 7) section 4.6 last para: i remember this point came up at the last > > IETF and I still hold the view that it would be more > sensible for this > > information about Qspec-related codepoints to be in the Qspec > > document. > > (this information isn't in any case in the extensibility document at > > the moment.) > > Can you point us to what "QSPEC-related codepoints" you're > referring to here? the paragraph in question is " Guidelines on the technical criteria to be followed in evaluating requests for new codepoint assignments are given for the overall NSIS protocol suite in a separate NSIS extensibility document [NSIS-EXTENSIBILITY]." This applies to all NSIS codepoints. My point is that it still seems preferable (to me) that Qspec related codepoints - i.e. the registries you define in section 9 - should have the guidelines in the qspec itself. > > 11) section 5.2.2: there are multiple references to the QNR > > having to do > > something for the egress link for the cumulative parameters. I don't > > see what this could mean. > > I'm not sure what is unclear in the references to QNR actions. E.g., > for jitter is says: > > " Each QNE MUST add the jitter of its outgoing link, which > includes the QNR adding the associated jitter for the egress link. > Furthermore, the QNI MUST add the jitter of the ingress link." > > Any suggestions on how to make this clearer? maybe if i understood it... take the trivial situation of a single link: QNI ----------- QNR the draft says (here for jitter): "Each QNE MUST add the jitter of its outgoing link, which includes the QNR adding the associated jitter for the egress link. Furthermore, the QNI MUST add the jitter of the ingress link." my question is, how many contributions to the e2e jitter are there? i would have thought that for a single link the expression would be a single term, but the draft implies two terms (one from QNI and one from QNR). but adding one more link would add only one term. i don't see how this would work. [snip] cheers, r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 13:04:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Lf6-0006P4-Pq; Tue, 11 Jul 2006 13:04:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Lf5-0006Or-T3 for nsis@ietf.org; Tue, 11 Jul 2006 13:04:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0ICc-0005kF-Lj for nsis@ietf.org; Tue, 11 Jul 2006 09:23:02 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0I1v-0005Wu-9e for nsis@ietf.org; Tue, 11 Jul 2006 09:12:00 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6BDBLcg007832; Tue, 11 Jul 2006 14:11:25 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 14:11:21 +0100 Message-ID: <44B3A37B.9060602@roke.co.uk> Date: Tue, 11 Jul 2006 14:11:23 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cheng Hong Subject: Re: [NSIS] WGLC on QoS NSLP References: <5F09D220B62F79418461A978CA0921BDFF432C@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BDFF432C@pslexc01.psl.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2006 13:11:21.0425 (UTC) FILETIME=[80F1FC10:01C6A4EB] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: john.loughney@nokia.com, Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Cheng Hong wrote: > Thanks for your reply. > > Am I correct in reading it as following: > - PACKET_CLASSIFIER shall only be set by the initiator; > - If there needs to be a change in PACKET_CLASSIFIER, the QSPEC stacking > should not be allowed. In stead, method in section 4.6 should be used. Yes, that is a correct summary. Andrew >> -----Original Message----- >> From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk] >> Sent: Monday, July 10, 2006 10:18 PM >> To: Cheng Hong >> Cc: john.loughney@nokia.com; Georgios Karagiannis; Jukka MJ >> Manner; nsis@ietf.org >> Subject: Re: [NSIS] WGLC on QoS NSLP >> >> Hi, >> >> Cheng Hong wrote: >>> Sorry for a late comment on the draft. I have gone through it, and >>> quite like the way it is. >> Thanks for reviewing it. >> >>> However, I got a question regarding one of the message format >>> definition. For the Reserve (also the QUERY) message, it is >> defined in >>> section 5.1.2.1 as: >>> >>> RESERVE = COMMON_HEADER >>> RSN [ RII ] [ REFRESH_PERIOD ] [ *BOUND_SESSION_ID ] >>> [ [ PACKET_CLASSIFIER ] [ QSPEC ] [ QSPEC ] ] >>> >>> As I read it, there could be multiple QSPEC stacked in the message, >>> however there is only one PACKET_ClASSIFIER object allowed. >> Shouldn't >>> this be [ [ PACKET_CLASSIFIER ] [ QSPEC ] >> [PACKET_CLASSIFIER] [ QSPEC >>> ] ] instead? (because the PACKET_CLASSIFIER would depend on the QoS >>> Model >>> used) >>> >>> I remember there were some discussion regarding the issue >> around the >>> Nov meeting time last year. But, I could not remember how >> this is resolved. >>> Could you provide a pointer to the resolution? >> I do remember discussing this before. The conclusion was: >> We should only have a single PACKET_CLASSIFIER. The reasoning >> being that allowing for multiple classifiers means that the >> reservation may apply to different sets of packets along >> different path segments. The initiator then doesn't know >> whether the reservation along some part of the path actually >> applies to the packets it asked for the reservation for. This >> generally sounds like a bad idea. >> >> If you do need to have different PACKET_CLASSIFIERs then you >> can always use parallel signalling sessions (e.g. this is the >> way RMD handles this). >> >> regards, >> >> Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 13:35:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0M8d-0008Pv-Ao; Tue, 11 Jul 2006 13:35:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0M8a-0008LD-II for nsis@ietf.org; Tue, 11 Jul 2006 13:35:08 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0M8Z-0001lz-45 for nsis@ietf.org; Tue, 11 Jul 2006 13:35:08 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6BHZ6Lv022358 for ; Tue, 11 Jul 2006 20:35:06 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 20:34:41 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 20:34:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jul 2006 20:34:41 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: update agenda posted & send your slides! Thread-Index: AcalEEodtcLPCO7QQiWfUe5HtbDe8Q== From: To: X-OriginalArrivalTime: 11 Jul 2006 17:34:41.0312 (UTC) FILETIME=[4A696A00:01C6A510] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [NSIS] update agenda posted & send your slides! X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I've updated the agenda for tomorrow's meeting. If you are presenting, please send the slides to me now! John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 13:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MPV-0001bt-Eq; Tue, 11 Jul 2006 13:52:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MPT-0001bo-L1 for nsis@ietf.org; Tue, 11 Jul 2006 13:52:35 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0MPT-0004jj-9h for nsis@ietf.org; Tue, 11 Jul 2006 13:52:35 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 11 Jul 2006 13:52:19 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006071113521824779 ; Tue, 11 Jul 2006 13:52:18 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Jul 2006 13:52:19 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230E40@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Robert Hancock Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt Date: Tue, 11 Jul 2006 13:51:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Robert: I agree with you. In addition, I have added my comments inline [RRR] with more elaboration. Best regards, Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Robert Hancock Sent: Tuesday, July 11, 2006 12:58 PM To: 'Ash, Gerald R (Jerry), ALABS'; 'NSIS' Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt hi jerry, some comments on some of the comments: > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] [snip] > > 7) section 4.6 last para: i remember this point came up at the last > > IETF and I still hold the view that it would be more > sensible for this > > information about Qspec-related codepoints to be in the Qspec > > document. > > (this information isn't in any case in the extensibility document at > > the moment.) > > Can you point us to what "QSPEC-related codepoints" you're > referring to here? the paragraph in question is " Guidelines on the technical criteria to be followed in evaluating requests for new codepoint assignments are given for the overall NSIS protocol suite in a separate NSIS extensibility document [NSIS-EXTENSIBILITY]." This applies to all NSIS codepoints. My point is that it still seems preferable (to me) that Qspec related codepoints - i.e. the registries you define in section 9 - should have the guidelines in the qspec itself. [RRR] Robert is right as QSPEC is the generic draft that will provide the general guidelines for the codepoints that are not specific to any QoS models. Y.1541 draft will deal with its QoS-model-specific codepoints. > > 11) section 5.2.2: there are multiple references to the QNR > > having to do > > something for the egress link for the cumulative parameters. I don't > > see what this could mean. > > I'm not sure what is unclear in the references to QNR actions. E.g., > for jitter is says: > > " Each QNE MUST add the jitter of its outgoing link, which > includes the QNR adding the associated jitter for the egress link. > Furthermore, the QNI MUST add the jitter of the ingress link." > > Any suggestions on how to make this clearer? maybe if i understood it... take the trivial situation of a single link: QNI ----------- QNR the draft says (here for jitter): "Each QNE MUST add the jitter of its outgoing link, which includes the QNR adding the associated jitter for the egress link. Furthermore, the QNI MUST add the jitter of the ingress link." my question is, how many contributions to the e2e jitter are there? i would have thought that for a single link the expression would be a single term, but the draft implies two terms (one from QNI and one from QNR). but adding one more link would add only one term. i don't see how this would work. [RRR] I see, if it is end-to-end codec, for example voice/video, it will be able to measure the end-to-end jitter per packet/frame on "aggregate" to playing out the buffer. Again, in no way, this jitter will provide any meaningful statistics specific to a given packet/frame of voice/video traffic. The same is also applicable for "end-to-end delay" and "packet loss." [RRR] Then the most interesting question comes is this that Robert has already raised the valid technical skepticisms: 1. How will it work to specify/measure the "jitter" individually in the "middle" of the network that Y.1541 is attempting to specify/measure as contributions as a part of the e2e jitter/delay/packet loss of a given packet that is a part of IP network layer (not in the "specific" e2e codec application layer at the "last" end) where contributions in jitter/delay/packet loss may come many different sources? 2. Is it possible to do so in the real-network per QNI/QNR basis as Y.1541 envisions? [RRR] The more important question is this: What does Y.1541 performance parameter (e2e delay, e2e jitter, or e2e packet jitter) specify? Is it the over all "aggregate" behavior of "any" packet that passes over between the QNI/QNR? Or, is it for each packet that each application (e.g., audio, video, or data) sends? [snip] cheers, r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 17:12:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0PWx-0002xf-G2; Tue, 11 Jul 2006 17:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0PWv-0002xa-PA for nsis@ietf.org; Tue, 11 Jul 2006 17:12:29 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0PWu-0004C5-9B for nsis@ietf.org; Tue, 11 Jul 2006 17:12:29 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6BLCKww003541; Tue, 11 Jul 2006 23:12:20 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6BLCJvb017330; Tue, 11 Jul 2006 23:12:20 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6BLCJ519137; Tue, 11 Jul 2006 23:12:19 +0200 (MEST) Date: Tue, 11 Jul 2006 23:12:19 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: gash@att.com, nsis@ietf.org Received: from 132.219.24.237 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 11 Jul 2006 21:12:17 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7AB8@KCCLUST06EVS1.ugd.att.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.652 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 11 Jul 2006 23:12:22 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: karagian@cs.utwente.nl Subject: [NSIS] additional comments on draft-ietf-nsis-qspec-10.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Cornelia and Attila I have some additional comments on QSpec template draft: * Use of X (Exclude) flag for each mandatory QoS parameter to show that a mandatory parameter cannot be interpreted. I like the way of how the notification of not interpreting the optional parameters is encoded in each QSpec parameter. This is accomplished by using the "N" (not supported) flag. It will be good (necessary) to have a similar flag for the mandatory parameters, which notifies that a mandatory parameter could not be interpreted. Currently, this is done by only one parameter ( parameter. In this case if the QNI receives the parameter set it will not know which of the mandatory parameters where not interpreted. Furthermore, note that when at least one manadory parameter cannot be interpreted, and when the parameter is used to notify this, then this situation can be considered to be identical with the situation that the QNE is NSIS unaware and that is definetely not the case. In this way and probably always the QNI will reject and release the successful reservation. If we use a flag like the N flag, say X flag (note that this should be different than the N flag), within each mandatory QSpec parameter then detailed information can be sent to the QNI, which is related to which mandatory parameters could not be interpreted. Therefore, the QNI could then more easily decide when to release or accept a succesful reservation. * If X flag is used then, we might not need to have the T flag. This is because when the X flag is used, for each QSpec parameter, information can be sent to QNI to inform it if the QSpec parameter could be interpreted by a node or by a domain. Thus if a mandatory parameter is tuneled and only used by edges then the X flag parameter for this parameter can be set. * Use of D flag for each QSpec mandatory parameter to show that a mandatory parameter has been downgraded. Note that the following paragraph in QSpec template, actually says that if a QNI uses Token Bucket as and a QOSM remaps the Token Bucket to Bandwidth, then this is identical on saying that the QOSM is NSIS unaware and that is definetely not the case. "In the latter case, the remapping of the to must be specified in the QOSM specification document. For example, QOSM X exclusively uses the parameter . It must define a mapping of the mandatory parameter . The mapping consists of interpreting the Token Bucket Rate as the parameter and disregarding the other Token Bucket parameters. Clearly, some information contained in the parameter is lost by this mapping, and the resulting QoS may not be quite what was intended by the QNI. Therefore, QOSM X also specifies that the flag be raised." Thus, in this case if the QNI receives the parameter being set, it will not know which of the mandatory parameters where downgraded or not interpreted. In this way and probably always the QNI will reject and release the successful reservation. If we use the D flag within each mandatory QSpec parameter then the detailed information can be sent to the QNI, which is related to exactly the mandatory parameters that were indeed downgraded. Therefore, the QNI could then more easily decide when to release or accept a succesful reservation. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 18:15:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0QWD-0004Bt-Fv; Tue, 11 Jul 2006 18:15:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0QWC-0004Bl-6Z for nsis@ietf.org; Tue, 11 Jul 2006 18:15:48 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0QWA-0006M7-Nl for nsis@ietf.org; Tue, 11 Jul 2006 18:15:48 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1152656081!9660783!12 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2643 invoked from network); 11 Jul 2006 22:15:45 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 11 Jul 2006 22:15:45 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452001D4929; Tue, 11 Jul 2006 18:15:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jul 2006 17:15:43 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7AC7@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: additional comments on draft-ietf-nsis-qspec-10.txt Thread-Index: AcalLrlfhaycSteTToqEMhcbaF0EUgABVhGQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] RE: additional comments on draft-ietf-nsis-qspec-10.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, See below.=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Tuesday, July 11, 2006 5:12 PM > To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Cc: karagian@cs.utwente.nl > Subject: additional comments on draft-ietf-nsis-qspec-10.txt >=20 >=20 > Hi Jerry, Cornelia and Attila >=20 > I have some additional comments on QSpec template draft: >=20 > * Use of X (Exclude) flag for each mandatory QoS parameter to=20 > show that a > mandatory parameter > cannot be interpreted. > I like the way of how the notification of not interpreting the > optional parameters is encoded in each QSpec parameter. This is > accomplished > by using the "N" (not supported) flag. It will be good (necessary) to > have a > similar flag for the mandatory parameters, which notifies that a > mandatory parameter > could not be interpreted.=20 As you know, the QSPEC draft requires that mandatory parameters MUST be interpreted, which means that they are either a) strictly interpreted according to referenced specifications, or b) remapped, as specified in a QOSM specification document. > Currently, this is done by only one=20 > parameter > ( > parameter.=20 To the contrary, the flag only indicates that a) a QNE supports another local QOSM different from the Initiator QOSM, and b) some mandatory parameters may have been remapped according to what is specified by local QOSM specification document. However, in this scenario, all mandatory parameters in the Initiator QSPEC still MUST be interpreted, as specified above (this will normally be done by the egress QNE in the local domain). > In this case if the QNI receives the Hop> parameter > set it will > not know which of the mandatory parameters where not interpreted. As above, all mandatory parameters MUST be interpreted. However, currently it is unknown which, if any, mandatory QSPEC parameters have been remapped. I've proposed that an R-flag ('remapped flag') be created per QSPEC parameter to indicate which parameters are remapped (if any) by a local QOSM. > Furthermore, note that when at least one mandatory parameter cannot be > interpreted, > and when the parameter is used to notify this, > then this situation can be considered to be identical with=20 > the situation > that the QNE is NSIS unaware and that is definitely not the case. > In this way and probably always the QNI will reject and release the > successful reservation. > If we use a flag like the N flag, say X flag (note that this should be > different > than the N flag), within each mandatory QSpec parameter > then detailed information can be sent to the QNI, which is related to > which mandatory parameters > could not be interpreted. Therefore, the QNI could then more easily > decide when to release > or accept a successful reservation. Again, all mandatory parameters MUST be interpreted. If your proposed X-flag is the same as the R-flag (remapped flag) mentioned above, then I agree that would be useful. However, if the X-flag means that a mandatory parameter is not interpreted (i.e., ignored), then that is not allowed by the QSPEC specification. =20 > * If X flag is used then, we might not need to have the T=20 > flag. This is > because > when the X flag is used, for each QSpec parameter, information can be > sent to QNI > to inform it if the QSpec parameter could be interpreted by a=20 > node or by > a domain. > Thus if a mandatory parameter is tunneled and only used by=20 > edges then the > X flag parameter for this > parameter can be set. The T-flag is only intended to indicate that a mandatory parameter in the initiator QSPEC may not be accurately interpreted if it is tunneled through a domain. However, the egress QNE in a local domain MUST still interpret all mandatory parameters in the initiatory QSPEC. In addition, the egress QNE in the local domain MUST NOT use the T-flag to ignore a mandatory parameter (that needs to be clarified in the QSPEC document). =20 > * Use of D flag for each QSpec mandatory parameter to show that a > mandatory > parameter has been downgraded. >=20 > Note that the following paragraph in QSpec template, actually=20 > says that > if a QNI uses Token Bucket > as and a QOSM remaps the Token Bucket=20 > to Bandwidth, > then this is identical > on saying that the QOSM is NSIS unaware and that is definitely not the > case. >=20 > "In the latter case, the remapping of the to > must be specified in the QOSM specification document. > For example, QOSM X exclusively uses the parameter . It > must define a mapping of the mandatory parameter . > The mapping consists of interpreting the Token Bucket Rate as > the parameter and disregarding the other Token Bucket > parameters. Clearly, some information contained in the Bucket> parameter is lost by this mapping, and the=20 > resulting QoS may > not be quite what was intended by the QNI. Therefore, QOSM X also > specifies that the flag be raised." >=20 >=20 > Thus, in this case if the QNI receives the > parameter being set, it will not know which of the mandatory > parameters where downgraded or not interpreted. In this way > and probably always the QNI will reject and release the successful > reservation. > If we use the D flag within each mandatory QSpec parameter > then the detailed information can be sent to the QNI, which is > related to exactly the mandatory parameters that were indeed=20 > downgraded. > Therefore, the QNI could then more easily > decide when to release or accept a successful reservation. You proposed D-flag looks the same as the R-flag (remapped flag) I mentioned above. In that case, I agree that the D-flag/R-flag would be useful. Thanks, Jerry > Best Regards, > Georgios >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 19:11:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ROQ-0004Cs-U6; Tue, 11 Jul 2006 19:11:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ROP-0004Cd-LK for nsis@ietf.org; Tue, 11 Jul 2006 19:11:49 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0ROO-0005hg-8t for nsis@ietf.org; Tue, 11 Jul 2006 19:11:49 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1152659490!9662343!5 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 28606 invoked from network); 11 Jul 2006 23:11:44 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 11 Jul 2006 23:11:44 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452001D58D3; Tue, 11 Jul 2006 19:11:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt Date: Tue, 11 Jul 2006 18:11:43 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7ACA@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <001001c6a50b$2546d460$f803db84@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt Thread-Index: AcalCzWR7WpjyiHQTZ69C7K/4DLMkwAMmdyw From: "Ash, Gerald R \(Jerry\), ALABS" To: "Robert Hancock" , "NSIS" X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, See below.=20 > -----Original Message----- > From: Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 > Sent: Tuesday, July 11, 2006 12:58 PM > To: Ash, Gerald R (Jerry), ALABS; 'NSIS' > Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt >=20 > hi jerry, >=20 > some comments on some of the comments: >=20 > > -----Original Message----- > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 >=20 > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 >=20 > [snip] >=20 > > =20 > > > 3) page 11 last para: this seems to assume that there is an=20 > > > INTSERV-QOSM > > > whereas in fact none is being defined.=20 > >=20 > > This is the reference: > > [INTSERV-QOSM] Kappler, C., "A QoS Model for Signaling IntServ > > Controlled-Load Service with NSIS," work in progress. > >=20 > > This QOSM is being defined, but is not yet a WG draft. >=20 > true - but it's not an INTSERV QoSM but a CL QoSM only (and=20 > only for 'pure' CL, not CL/Diffserv or CL/PCN). hence the follow > up question about 'what is a QoSM'. someone reading the text might > get the impression that there is a single QoSM that covers both > CL and GS. OK, we can change the reference to [CL-QOSM]. =20 > [snip] >=20 > > > 7) section 4.6 last para: i remember this point came up=20 > > > at the last > > > IETF and I still hold the view that it would be more=20 > > > sensible for this > > > information about Qspec-related codepoints to be in the Qspec=20 > > > document. > > > (this information isn't in any case in the extensibility=20 > > > document at > > > the moment.) > >=20 > > Can you point us to what "QSPEC-related codepoints" you're=20 > > referring to here? >=20 > the paragraph in question is > " Guidelines on the technical criteria to be followed in evaluating > requests for new codepoint assignments are given for the=20 > overall NSIS > protocol suite in a separate NSIS extensibility document > [NSIS-EXTENSIBILITY]." >=20 > This applies to all NSIS codepoints. My point is that it still seems=20 > preferable (to me) that Qspec related codepoints - i.e. the registries > you define in section 9 - should have the guidelines in the=20 > qspec itself. OK. Do you have any suggested guidelines or pointer to guidelines that should be included in the QSPEC document? =20 > > > 11) section 5.2.2: there are multiple references to the QNR=20 > > > having to do > > > something for the egress link for the cumulative=20 > > > parameters. I don't > > > see what this could mean. > >=20 > > I'm not sure what is unclear in the references to QNR=20 > > actions. E.g., > > for jitter is says: > >=20 > > " Each QNE MUST add the jitter of its outgoing link, which > > includes the QNR adding the associated jitter for the=20 > > egress link. > > Furthermore, the QNI MUST add the jitter of the ingress link." > >=20 > > Any suggestions on how to make this clearer? >=20 > maybe if i understood it... >=20 > take the trivial situation of a single link: >=20 > QNI ----------- QNR >=20 > the draft says (here for jitter):=20 > "Each QNE MUST add the jitter of its outgoing link, which > includes the QNR adding the associated jitter for the egress link.=20 > Furthermore, the QNI MUST add the jitter of the ingress link." >=20 > my question is, how many contributions to the e2e jitter are there? > i would have thought that for a single link the expression would be > a single term, but the draft implies two terms (one from QNI and one > from QNR). but adding one more link would add only one term. i don't > see how this would work. I think you picked up a problem with the text that I hadn't noticed before: "Each QNE MUST add the jitter/delay of its outgoing link, which includes the QNR adding the associated jitter/delay for the egress link.=20 Furthermore, the QNI MUST add the jitter/delay of the ingress link." Should say: "Each QNE MUST add the jitter/delay of its outgoing link (if it exists). Furthermore, the QNI MUST add the jitter/delay of the ingress link (if it exists)." The diagram we had in mind for your 'single link trivial situation' is a follows: a b c ----------- QNI ----------- QNR ----------- The QNI adds the jitter/delay of links a and b (if it exists), and the QNR adds the jitter/delay of link c (if it exists). If link a and/or link c do not exist, then the delay/jitter is not included of course in the cumulative value. Thanks, Regards, Jerry > [snip] >=20 > cheers, >=20 > r. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 19:19:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RVZ-0005Ok-AM; Tue, 11 Jul 2006 19:19:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RVX-0005OM-Ch for nsis@ietf.org; Tue, 11 Jul 2006 19:19:11 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0RVV-0005xv-RE for nsis@ietf.org; Tue, 11 Jul 2006 19:19:11 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6BNJ4W4008708; Wed, 12 Jul 2006 01:19:04 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6BNJ5vb028199; Wed, 12 Jul 2006 01:19:05 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6BNJ4l14491; Wed, 12 Jul 2006 01:19:04 +0200 (MEST) Date: Wed, 12 Jul 2006 01:19:04 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: gash@att.com, nsis@ietf.org Received: from 132.219.24.237 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 11 Jul 2006 23:19:03 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7AC7@KCCLUST06EVS1.ugd.att.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.488 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 12 Jul 2006 01:19:07 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] RE: additional comments on draft-ietf-nsis-qspec-10.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry Please note that I think that the semantic of X flag might be not clear! What I meant by the X flag is to include it in each mandatory parameter and use it in the same way as the N flag is used for the optional parameters. Thus not excluding the processing of any mandatory parameter. * Therefore, I think that the X flag (you may call it differently) I think taht it is needed. * Regarding the R flag, yes it is similar to the R flag that you mentioned. * I do not have any objection on also keeping the T flag. * Regarding the parameter, I think that it must only be set if a non NSIS aware received the RESERVE message. In all other cases this parameter must not be set. When a mandatory parameter is downgraded then the R flag is set, but the parameter must remein unset (if it was unset). Best Regards, Georgios On 7/11/2006, "Ash, Gerald R (Jerry), ALABS" wrote: >Hi Georgios, > >See below. > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: Tuesday, July 11, 2006 5:12 PM >> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >> Cc: karagian@cs.utwente.nl >> Subject: additional comments on draft-ietf-nsis-qspec-10.txt >> >> >> Hi Jerry, Cornelia and Attila >> >> I have some additional comments on QSpec template draft: >> >> * Use of X (Exclude) flag for each mandatory QoS parameter to >> show that a >> mandatory parameter >> cannot be interpreted. >> I like the way of how the notification of not interpreting the >> optional parameters is encoded in each QSpec parameter. This is >> accomplished >> by using the "N" (not supported) flag. It will be good (necessary) to >> have a >> similar flag for the mandatory parameters, which notifies that a >> mandatory parameter >> could not be interpreted. > >As you know, the QSPEC draft requires that mandatory parameters MUST be >interpreted, which means that they are either a) strictly interpreted >according to referenced specifications, or b) remapped, as specified in >a QOSM specification document. > >> Currently, this is done by only one >> parameter >> ( >> parameter. > >To the contrary, the flag only indicates that a) a QNE >supports another local QOSM different from the Initiator QOSM, and b) >some mandatory parameters may have been remapped according to what is >specified by local QOSM specification document. However, in this >scenario, all mandatory parameters in the Initiator QSPEC still MUST be >interpreted, as specified above (this will normally be done by the >egress QNE in the local domain). > >> In this case if the QNI receives the > Hop> parameter >> set it will >> not know which of the mandatory parameters where not interpreted. > >As above, all mandatory parameters MUST be interpreted. However, >currently it is unknown which, if any, mandatory QSPEC parameters have >been remapped. I've proposed that an R-flag ('remapped flag') be >created per QSPEC parameter to indicate which parameters are remapped >(if any) by a local QOSM. > >> Furthermore, note that when at least one mandatory parameter cannot be >> interpreted, >> and when the parameter is used to notify this, >> then this situation can be considered to be identical with >> the situation >> that the QNE is NSIS unaware and that is definitely not the case. >> In this way and probably always the QNI will reject and release the >> successful reservation. >> If we use a flag like the N flag, say X flag (note that this should be >> different >> than the N flag), within each mandatory QSpec parameter >> then detailed information can be sent to the QNI, which is related to >> which mandatory parameters >> could not be interpreted. Therefore, the QNI could then more easily >> decide when to release >> or accept a successful reservation. > >Again, all mandatory parameters MUST be interpreted. If your proposed >X-flag is the same as the R-flag (remapped flag) mentioned above, then I >agree that would be useful. However, if the X-flag means that a >mandatory parameter is not interpreted (i.e., ignored), then that is not >allowed by the QSPEC specification. > >> * If X flag is used then, we might not need to have the T >> flag. This is >> because >> when the X flag is used, for each QSpec parameter, information can be >> sent to QNI >> to inform it if the QSpec parameter could be interpreted by a >> node or by >> a domain. >> Thus if a mandatory parameter is tunneled and only used by >> edges then the >> X flag parameter for this >> parameter can be set. > >The T-flag is only intended to indicate that a mandatory parameter in >the initiator QSPEC may not be accurately interpreted if it is tunneled >through a domain. However, the egress QNE in a local domain MUST still >interpret all mandatory parameters in the initiatory QSPEC. In >addition, the egress QNE in the local domain MUST NOT use the T-flag to >ignore a mandatory parameter (that needs to be clarified in the QSPEC >document). > >> * Use of D flag for each QSpec mandatory parameter to show that a >> mandatory >> parameter has been downgraded. >> >> Note that the following paragraph in QSpec template, actually >> says that >> if a QNI uses Token Bucket >> as and a QOSM remaps the Token Bucket >> to Bandwidth, >> then this is identical >> on saying that the QOSM is NSIS unaware and that is definitely not the >> case. >> >> "In the latter case, the remapping of the to >> must be specified in the QOSM specification document. >> For example, QOSM X exclusively uses the parameter . It >> must define a mapping of the mandatory parameter . >> The mapping consists of interpreting the Token Bucket Rate as >> the parameter and disregarding the other Token Bucket >> parameters. Clearly, some information contained in the > Bucket> parameter is lost by this mapping, and the >> resulting QoS may >> not be quite what was intended by the QNI. Therefore, QOSM X also >> specifies that the flag be raised." >> >> >> Thus, in this case if the QNI receives the >> parameter being set, it will not know which of the mandatory >> parameters where downgraded or not interpreted. In this way >> and probably always the QNI will reject and release the successful >> reservation. >> If we use the D flag within each mandatory QSpec parameter >> then the detailed information can be sent to the QNI, which is >> related to exactly the mandatory parameters that were indeed >> downgraded. >> Therefore, the QNI could then more easily >> decide when to release or accept a successful reservation. > >You proposed D-flag looks the same as the R-flag (remapped flag) I >mentioned above. In that case, I agree that the D-flag/R-flag would be >useful. > >Thanks, >Jerry > >> Best Regards, >> Georgios >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 19:37:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RnL-0007fR-Ta; Tue, 11 Jul 2006 19:37:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RnK-0007e2-EK for nsis@ietf.org; Tue, 11 Jul 2006 19:37:34 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0RnJ-0006VW-5S for nsis@ietf.org; Tue, 11 Jul 2006 19:37:34 -0400 Received: (qmail invoked by alias); 11 Jul 2006 23:37:31 -0000 Received: from h01fd-net84db.lab.risq.net (EHLO [132.219.1.253]) [132.219.1.253] by mail.gmx.net (mp043) with SMTP; 12 Jul 2006 01:37:31 +0200 X-Authenticated: #29516787 Message-ID: <44B4363D.5060100@gmx.net> Date: Tue, 11 Jul 2006 19:37:33 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [NSIS] NSIS Slides X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I have uploaded the slides I received to the following webpage: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 22:29:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0UU0-00055s-LC; Tue, 11 Jul 2006 22:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0UTy-000555-Pw for nsis@ietf.org; Tue, 11 Jul 2006 22:29:46 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0UTw-0000vr-DL for nsis@ietf.org; Tue, 11 Jul 2006 22:29:46 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1152671372!11137179!2 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23105 invoked from network); 12 Jul 2006 02:29:43 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-121.messagelabs.com with SMTP; 12 Jul 2006 02:29:43 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452001D7C2E; Tue, 11 Jul 2006 22:29:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jul 2006 21:29:42 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7AD0@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44B3BBAE.5020009@cs.uni-goettingen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: questions on y1541-qosm Thread-Index: Acak+lZKvibv5kpjTV2CxmX93Vi2HwAD4f8A From: "Ash, Gerald R \(Jerry\), ALABS" To: "Bernd Schloer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org Subject: [NSIS] RE: questions on y1541-qosm X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd, Please see below.=20 > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 > Sent: Tuesday, July 11, 2006 10:55 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: nsis@ietf.org > Subject: questions on y1541-qosm >=20 > Hi Jerry, >=20 > I have some questions on your draft. Section 2.2 says: >=20 > 262 It MUST be possible to perform the following=20 > QoS-NSLP signaling > 263 functions to enable Y.1541-QOSM requirements: > 264 > 265 a. accumulate delay, delay variation and loss=20 > ratio across the > 266 end-to-end connection, which may span multiple domains >=20 > How can the delay be identified across the path? AFAIK only=20 > the QNI can=20 > calculate the RTT since no timestamp of the QUERY msg is=20 > available at QNEs.=20 > Including e.g. a 32-bit long value containing the seconds=20 > since the Epoch would=20 > solve this. The parameter is not intended as a RTT measurement from the QNI. As described in Section 7.2.8 of the QSPEC draft http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: "The Path Latency is a single 32-bit integer in network byte order. The composition rule for the parameter is summation with a clamp of (2**32 - 1) on the maximum value. The latencies are average values reported in units of one microsecond. A system with resolution less than one microsecond MUST set unused digits to zero. An individual QNE can advertise a latency value between 1 and 2**28 (somewhat over two minutes) and the total latency added across all QNEs can range as high as (2**32)-2. If the sum of the different elements delays exceeds (2**32)-2, the end-to-end advertised delay SHOULD be reported as indeterminate. A QNE that cannot accurately predict the latency of packets it is processing MUST raise the not-supported flag and either leave the value of Path Latency as is, or add its best estimate of its lower bound. A raised not-supported flag indicates the value of Path Latency is a lower bound of the real Path Latency. The distinguished value (2**32)-1 is taken to mean indeterminate latency because the composition function limits the composed sum to this value, it indicates the range of the composition calculation was exceeded." Hence average values are used by each QNE in the path to determine the cumulative , which could include propagation delay, average queuing delay, etc. =20 > But how can the delay variation (and loss ratio) be gathered?=20 > Is this the=20 > variation of every single packet, e.g. voice streaming data,=20 > compared to the=20 > agreed delay rate? Since multiple values are required this=20 > can't be done with a=20 > single QUERY. and are determined in analogous ways. E.g., the is accumulated as described in Section 7.2.9 in the QSPEC draft: "The Path Jitter is a set of three 32-bit integers in network byte order. The Path Jitter parameter is the combination of three statistics describing the Jitter distribution with a clamp of (2**32 - 1) on the maximum of each value. The jitter STATs are reported in units of one microsecond. A system with resolution less than one microsecond MUST set unused digits to zero. An individual QNE can advertise jitter values between 1 and 2**28 (somewhat over two minutes) and the total jitter computed across all QNEs can range as high as (2**32)-2. If the combination of the different element values exceeds (2**32)-2, the end-to-end advertised jitter SHOULD be reported as indeterminate. A QNE that cannot accurately predict the jitter of packets it is processing MUST raise the not-supported flag and either leave the value of Path Jitter as is, or add its best estimate of its STAT values. A raised not-supported flag indicates the value of Path Jitter is a lower bound of the real Path Jitter. The distinguished value (2**32)-1 is taken to mean indeterminate jitter. A QNE that cannot accurately predict the jitter of packets it is processing SHOULD set its local parameter to this value. Because the composition function limits the total to this value, receipt of this value at a network element or application indicates that the true path jitter is not known. This MAY happen because one or more network elements could not supply a value, or because the range of the composition calculation was exceeded. NOTE: The Jitter composition function makes use of the parameter. Composition functions for loss, latency and jitter may be found in [Y.1541]." =20 > These methods describe only the actual state, but don't say=20 > anything about=20 > future values. The values can change depending on the load of=20 > the routers. These are 'average' values rather than instantaneous or 'future' values. =20 > What does it mean when a QNI gets a RESPONSE with Class> 0? Is this=20 > a guaranty that the delay never exceeds 100ms, the delay=20 > variation is always=20 > <=3D50 ms and the loss ratio <=3D10^-3? It means that the cumulative is < 100 ms., cumulative < 50 ms., etc. > Or does the network service provider has to ensure these=20 > limits as mentioned in=20 > section 2.1? As explained in Section 2.1, the Y.1541 QoS classes enable the service provider to define SLAs based on the QoS requirements; the SP needs to ensure that the requirements are recognized and receive appropriate treatment (as discussed above) in the network. Thanks, Jerry >=20 > Thanks, > Bernd >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 11 23:08:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0V5O-0006sT-QO; Tue, 11 Jul 2006 23:08:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0V5N-0006sO-Gx for nsis@ietf.org; Tue, 11 Jul 2006 23:08:25 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0V5M-0000oB-10 for nsis@ietf.org; Tue, 11 Jul 2006 23:08:25 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6C38JxG019028 for ; Wed, 12 Jul 2006 06:08:22 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 06:08:22 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 06:08:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jul 2006 06:08:22 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (most) NSIS presentations up, please review! Thread-Index: AcalYGwH70LvSF6zS+eP4ov5kQzBHw== From: To: X-OriginalArrivalTime: 12 Jul 2006 03:08:22.0680 (UTC) FILETIME=[6F255980:01C6A560] X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [NSIS] (most) NSIS presentations up, please review! X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I've assembled most of the presentations for tomorrow's meeting, so if you have insomnia tonight are wake-up early tomorrow, please have a look: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 6 I'm most interested that folks look at the agenda slides, for the WG Update and Next Steps proposal: http://www3.ietf.org/proceedings/06jul/slides/nsis-6.ppt Please come with an opinion on what you'd like the WG to do next. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 12 09:57:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fDn-0002bq-UO; Wed, 12 Jul 2006 09:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fDk-0002bj-Us for nsis@ietf.org; Wed, 12 Jul 2006 09:57:44 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fDj-0006ET-Hy for nsis@ietf.org; Wed, 12 Jul 2006 09:57:44 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Wed, 12 Jul 2006 09:57:36 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006071209573516878 ; Wed, 12 Jul 2006 09:57:35 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Jul 2006 09:57:35 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209D90@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Bernd Schloer Subject: RE: [NSIS] RE: questions on y1541-qosm Date: Wed, 12 Jul 2006 09:57:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Bernd: The draft makes some "factual" statements to "gather" statistics of "e2e delay, e2e jitter, and e2e path loss." The field are there also defined. These answers have made one of the technical clarifications: All statistics gatherings are based on "average." Like you, I am also confused due to the following: 1. ITU-T Y.1541 QoS model is based on the "precise" value of each performance parameter of "e2e delay, e2e jitter, and e2e path loss" for each so-called QoS class. So, the Y.1541-QOSM draft MUST define the "exact" clear mechanism for calculation of each parameter using mathematical formulae that need to be used by all Service Providers (SPs) so that no technical dispute arises. For example, in RSVP standard, mathematical formulae are being defined how to proceed with calculations of delay, jitter, etc. 2. The Y.1541-QOSM draft MUST also provide the actual technical mechanisms for measurements/calculations instead of "factual" statements like: "statistics gathering," and those statistics represent "average" values. If this draft does not define this, what value does this draft add to the IETF because there can be a wide variations in "values" of the so-called statistics collections if they are not based on the same mathematical formulae as can be seen as an example in RSVP? 3. Will the Y.1541-QOSM draft not sew the seeds for technical discords among the service providers if it does not define the exact mathematical formulae for measurements/calculations where a variation of " a few 10s of milliseconds in delays and jitters" will cause changes from one Y.1541 QoS class to another or even non-compliance of QoS-classes service contracts? Please more inline [RRR]. Best regards, Radhika R. Roy _____ From: nsis-bounces@ietf.org on behalf of Ash, Gerald R (Jerry), ALABS Sent: Tue 7/11/2006 10:29 PM To: Bernd Schloer Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org Subject: [NSIS] RE: questions on y1541-qosm Hi Bernd, Please see below. > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de ] > Sent: Tuesday, July 11, 2006 10:55 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: nsis@ietf.org > Subject: questions on y1541-qosm > > Hi Jerry, > > I have some questions on your draft. Section 2.2 says: > > 262 It MUST be possible to perform the following > QoS-NSLP signaling > 263 functions to enable Y.1541-QOSM requirements: > 264 > 265 a. accumulate delay, delay variation and loss > ratio across the > 266 end-to-end connection, which may span multiple domains > > How can the delay be identified across the path? AFAIK only > the QNI can > calculate the RTT since no timestamp of the QUERY msg is > available at QNEs. > Including e.g. a 32-bit long value containing the seconds > since the Epoch would > solve this. The parameter is not intended as a RTT measurement from the QNI. As described in Section 7.2.8 of the QSPEC draft http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: "The Path Latency is a single 32-bit integer in network byte order. The composition rule for the parameter is summation with a clamp of (2**32 - 1) on the maximum value. The latencies are average values reported in units of one microsecond. A system with resolution less than one microsecond MUST set unused digits to zero. An individual QNE can advertise a latency value between 1 and 2**28 (somewhat over two minutes) and the total latency added across all QNEs can range as high as (2**32)-2. If the sum of the different elements delays exceeds (2**32)-2, the end-to-end advertised delay SHOULD be reported as indeterminate. A QNE that cannot accurately predict the latency of packets it is processing MUST raise the not-supported flag and either leave the value of Path Latency as is, or add its best estimate of its lower bound. A raised not-supported flag indicates the value of Path Latency is a lower bound of the real Path Latency. The distinguished value (2**32)-1 is taken to mean indeterminate latency because the composition function limits the composed sum to this value, it indicates the range of the composition calculation was exceeded." Hence average values are used by each QNE in the path to determine the cumulative , which could include propagation delay, average queuing delay, etc. > But how can the delay variation (and loss ratio) be gathered? > Is this the > variation of every single packet, e.g. voice streaming data, > compared to the > agreed delay rate? Since multiple values are required this > can't be done with a > single QUERY. and are determined in analogous ways. E.g., the is accumulated as described in Section 7.2.9 in the QSPEC draft: "The Path Jitter is a set of three 32-bit integers in network byte order. The Path Jitter parameter is the combination of three statistics describing the Jitter distribution with a clamp of (2**32 - 1) on the maximum of each value. The jitter STATs are reported in units of one microsecond. A system with resolution less than one microsecond MUST set unused digits to zero. An individual QNE can advertise jitter values between 1 and 2**28 (somewhat over two minutes) and the total jitter computed across all QNEs can range as high as (2**32)-2. If the combination of the different element values exceeds (2**32)-2, the end-to-end advertised jitter SHOULD be reported as indeterminate. A QNE that cannot accurately predict the jitter of packets it is processing MUST raise the not-supported flag and either leave the value of Path Jitter as is, or add its best estimate of its STAT values. A raised not-supported flag indicates the value of Path Jitter is a lower bound of the real Path Jitter. The distinguished value (2**32)-1 is taken to mean indeterminate jitter. A QNE that cannot accurately predict the jitter of packets it is processing SHOULD set its local parameter to this value. Because the composition function limits the total to this value, receipt of this value at a network element or application indicates that the true path jitter is not known. This MAY happen because one or more network elements could not supply a value, or because the range of the composition calculation was exceeded. NOTE: The Jitter composition function makes use of the parameter. Composition functions for loss, latency and jitter may be found in [Y.1541]." > These methods describe only the actual state, but don't say > anything about > future values. The values can change depending on the load of > the routers. These are 'average' values rather than instantaneous or 'future' values. [RRR] What is the mathematical formula used to calculate these performance parameters representing "AVERAGE" that all SPs can use? > What does it mean when a QNI gets a RESPONSE with Class> 0? Is this > a guaranty that the delay never exceeds 100ms, the delay > variation is always > <=50 ms and the loss ratio <=10^-3? It means that the cumulative is < 100 ms., cumulative < 50 ms., etc. [RRR] What is the mathematical formula used to calculate these performance parameters so that all SPs can use to have a common reference, for example, similar to that defined in RSVP? > Or does the network service provider has to ensure these > limits as mentioned in > section 2.1? As explained in Section 2.1, the Y.1541 QoS classes enable the service provider to define SLAs based on the QoS requirements; the SP needs to ensure that the requirements are recognized and receive appropriate treatment (as discussed above) in the network. Thanks, Jerry > > Thanks, > Bernd > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 12 10:18:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fXQ-0005Oc-T3; Wed, 12 Jul 2006 10:18:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fXP-0005NY-Fb for nsis@ietf.org; Wed, 12 Jul 2006 10:18:03 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fXO-0007My-79 for nsis@ietf.org; Wed, 12 Jul 2006 10:18:03 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Wed, 12 Jul 2006 10:17:57 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006071210175520192 ; Wed, 12 Jul 2006 10:17:56 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Jul 2006 10:17:54 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209D91@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Robert Hancock , bschloer@cs.uni-goettingen.de Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt Date: Wed, 12 Jul 2006 10:17:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Robert; As I also mentioned in Bernd's email, the gathering of statistics of "e2e delay, e2e jitter, and e2e path loss" between QNI and QNR is rather a "factual" statement. The key questions are as follows: * How do we measure/collect the statistics if the draft does not provide the precise mathematical formulae for all these performance parameters as can be seen as an example in RSVP? * How will the Service Providers (SPs) ensure that the "average" statistics collected by all parameters are the based on the common mathematical formulae/measurements where a variation of " a few 10s of milliseconds in delays and jitters" will cause changes from one Y.1541 QoS class to another or even non-compliance of QoS-classes service contracts? Please see inline [RRR]. Best regards, Radhika > > > 11) section 5.2.2: there are multiple references to the QNR > > > having to do > > > something for the egress link for the cumulative > > > parameters. I don't > > > see what this could mean. > > > > I'm not sure what is unclear in the references to QNR > > actions. E.g., > > for jitter is says: > > > > " Each QNE MUST add the jitter of its outgoing link, which > > includes the QNR adding the associated jitter for the > > egress link. > > Furthermore, the QNI MUST add the jitter of the ingress link." > > > > Any suggestions on how to make this clearer? > > maybe if i understood it... > > take the trivial situation of a single link: > > QNI ----------- QNR > > the draft says (here for jitter): > "Each QNE MUST add the jitter of its outgoing link, which > includes the QNR adding the associated jitter for the egress link. > Furthermore, the QNI MUST add the jitter of the ingress link." > > my question is, how many contributions to the e2e jitter are there? > i would have thought that for a single link the expression would be > a single term, but the draft implies two terms (one from QNI and one > from QNR). but adding one more link would add only one term. i don't > see how this would work. I think you picked up a problem with the text that I hadn't noticed before: "Each QNE MUST add the jitter/delay of its outgoing link, which includes the QNR adding the associated jitter/delay for the egress link. Furthermore, the QNI MUST add the jitter/delay of the ingress link." Should say: "Each QNE MUST add the jitter/delay of its outgoing link (if it exists). Furthermore, the QNI MUST add the jitter/delay of the ingress link (if it exists)." The diagram we had in mind for your 'single link trivial situation' is a follows: a b c ----------- QNI ----------- QNR ----------- The QNI adds the jitter/delay of links a and b (if it exists), and the QNR adds the jitter/delay of link c (if it exists). If link a and/or link c do not exist, then the delay/jitter is not included of course in the cumulative value. [RRR] Please see note provided above. Thanks, Regards, Jerry > [snip] > > cheers, > > r. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 12 10:42:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fvH-0001S6-U9; Wed, 12 Jul 2006 10:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fvH-0001QF-29 for nsis@ietf.org; Wed, 12 Jul 2006 10:42:43 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fvF-0008SD-Pw for nsis@ietf.org; Wed, 12 Jul 2006 10:42:43 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Wed, 12 Jul 2006 10:42:30 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006071210423024492 ; Wed, 12 Jul 2006 10:42:30 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Jul 2006 10:42:28 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209D94@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Robert Hancock , NSIS , bschloer@cs.uni-goettingen.de Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt Date: Wed, 12 Jul 2006 10:42:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Bernd, Robert, and all: Now it is also time to collect all information from ITU-T related to Y.1541 through IETF liaison to establish the rational and creditability for all precise "values" of all performance parameters. The followings are noted, not limited to: 1. Simulation results and/or mathematical analysis for rational in defining the precise values of e2e delay, e2e jitter, and e2e path loss in defining each Y.1541 QoS class. 2. Mathematical formulae for calculations/measurements of e2e delay, e2e jitter, and e2e path loss. If nothing is available from ITU-T, we, in IETF, have to define at least item 2 before the Y.1541-QOSM draft goes forward. Best regards, Radhika R. Roy _____ From: Roy, Radhika R. Sent: Wed 7/12/2006 10:17 AM To: Robert Hancock; bschloer@cs.uni-goettingen.de Cc: NSIS Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt Hi, Robert; As I also mentioned in Bernd's email, the gathering of statistics of "e2e delay, e2e jitter, and e2e path loss" between QNI and QNR is rather a "factual" statement. The key questions are as follows: * How do we measure/collect the statistics if the draft does not provide the precise mathematical formulae for all these performance parameters as can be seen as an example in RSVP? * How will the Service Providers (SPs) ensure that the "average" statistics collected by all parameters are the based on the common mathematical formulae/measurements where a variation of " a few 10s of milliseconds in delays and jitters" will cause changes from one Y.1541 QoS class to another or even non-compliance of QoS-classes service contracts? Please see inline [RRR]. Best regards, Radhika _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 12 12:31:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hcO-00034r-Ku; Wed, 12 Jul 2006 12:31:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hcO-00034m-13 for nsis@ietf.org; Wed, 12 Jul 2006 12:31:20 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0hcK-00051Q-H8 for nsis@ietf.org; Wed, 12 Jul 2006 12:31:19 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6CGVF8g032506 for ; Wed, 12 Jul 2006 19:31:15 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 19:31:13 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 19:31:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jul 2006 19:31:12 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interop testing event interest Thread-Index: Acal0JbB/MeovfxZQ+SDyI1SGsEUgA== From: To: X-OriginalArrivalTime: 12 Jul 2006 16:31:12.0899 (UTC) FILETIME=[96D57530:01C6A5D0] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [NSIS] Interop testing event interest X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org There seems to be some interest in an interop event. Are folks interested in this - what would be tested? GIST, QoS NSLP, NAT-FW NSLP? Let me know and an approximate time-frame for this. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 12 12:32:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hdT-0003BD-4W; Wed, 12 Jul 2006 12:32:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hdR-0003B8-Hb for nsis@ietf.org; Wed, 12 Jul 2006 12:32:25 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0hdP-000549-43 for nsis@ietf.org; Wed, 12 Jul 2006 12:32:25 -0400 Received: from [84.163.35.173] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1G0hdM0AIz-0002V9; Wed, 12 Jul 2006 18:32:20 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id 151C95E805E; Wed, 12 Jul 2006 18:32:13 +0200 (CEST) Date: Wed, 12 Jul 2006 18:32:13 +0200 From: Matthias Friedrich To: nsis@ietf.org Message-ID: <20060712163212.GA8050@mafr.de> Mail-Followup-To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [NSIS] NATFW: LE-MRM and NATFW_DTINFO_IPv4/IPv6 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I'm wondering why there is no NATFW_DTINFO_IPv6 object in the current draft revision (draft-ietf-nsis-nslp-natfw-12). Suppose an NI+ is behind a firewall (no other firewalls, no NATs) and wants to send a REA message upstream to block traffic from a range of addresses. Then there is no known sender address, and it would IMHO make sense to use the LE-MRM with an appropriate SDA. At least that's what I think the LE-MRM was designed for. In the IPv6 case, a NATFW_DTINFO_IPv6 or a generalized NATFW_DTINFO object would be needed. According to section 3.7.2, in this case the PC-MRM should be used with the "data flow source IP address set to wildcard". I must admit I'm a bit lost here, the "two different signaling scenarios" on page 36 are difficult to read. Splitting the text into more paragraphs with some more explanations would probably help. What I don't understand is: If the PC-MRM may be used when the data sender is unknown, why do we need the LE-MRM at all? Witout it, we would get rid of the NATFW_DTINFO object(s) altogether. One last thing, I heard that the REA message is going to be renamed. It's not very creative, but why don't you rename CREATE to SCREATE (Sender/Source CREATE) or ICREATE (Initiator CREATE), and REA to RCREATE (Receiver/Responder CREATE)? Maybe the whole NI+/NR+ terminology could be dropped, too. Thanks in advance, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 12 13:27:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iUK-0007XM-3Q; Wed, 12 Jul 2006 13:27:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iUI-0007WN-QA for nsis@ietf.org; Wed, 12 Jul 2006 13:27:02 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0iUH-00086O-6W for nsis@ietf.org; Wed, 12 Jul 2006 13:27:02 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6CHQpxn021280 for ; Wed, 12 Jul 2006 18:26:51 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 18:26:50 +0100 From: "Robert Hancock" To: "'NSIS'" Date: Wed, 12 Jul 2006 13:26:50 -0400 Message-ID: <001201c6a5d8$5cb9d780$f604db84@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-OriginalArrivalTime: 12 Jul 2006 17:26:51.0080 (UTC) FILETIME=[5C8B7480:01C6A5D8] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [NSIS] reminder: input on the NSLPID allocation policy X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, following on from today's meeting, a reminder: the GIST spec currently says that to allocate a new NSLPID (effectively, to define a new NSLP), you can either - make it private/experimental, in which case you can only use it on your own network, or - get IESG approval (including but not only standards action as a possible approach) if people think that some space should be provided for less formal policies (e.g. expert review), they should say so now & with justification. at the moment, we are hoping to send the revised v10 to the IESG next week, by default with the current policy left in. cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 12 13:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iWl-0007tA-3O; Wed, 12 Jul 2006 13:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iWj-0007t4-Q7 for nsis@ietf.org; Wed, 12 Jul 2006 13:29:33 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0iWj-0008Ig-5K for nsis@ietf.org; Wed, 12 Jul 2006 13:29:33 -0400 Received: from [132.219.24.165] (unknown [132.219.24.165]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 26B531BACA3; Wed, 12 Jul 2006 19:15:10 +0200 (CEST) In-Reply-To: <44B2A209.5040208@cs.uni-goettingen.de> References: <44B24661.90709@cs.uni-goettingen.de> <545AD321-8EE4-460F-926C-D7C1249792C5@netlab.nec.de> <44B2A209.5040208@cs.uni-goettingen.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6DCFC36F-70A7-49EB-9C5F-68AF012CC26E@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt Date: Wed, 12 Jul 2006 13:17:07 -0400 To: Xiaoming Fu X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Xiaoming, Am 10.07.2006 um 14:52 schrieb Xiaoming Fu: > Hi Martin, > > I mean detection as a separate message exchange in NSLP level > before signaling desired rules. It can be simply a request-response > pair, but no real signaling action (install, response or removal of > NAT/FW state). In principle one could use REA or a new message type > for this purpose, e.g., for detecting firewalls between MN-HA > - MN sends a REA message towards HA, resulting in a RESPONSE from a > firewall and an ERROR RESPONSE from the HA. This way, MN will know > whether there is a FW between them (but not the type). Hmm, that is not the NATFW NSLP behaviour. The REA message would hop- by-hop (if any) forwarded to the HA and it would return an error response. All other nodes would see this error response and forget about the session. There is no separated response of the firewall. > - alternatively, MN can issue a DETECT (no matter it is called) > message towards the HA to collect all firewall information, if any, > and RESPONSE from the HA gives the response to MN. This is similar > to what diagnostics function covers. > > This feature could provide the NI some freedom e.g., choosing > multiple rules in a single signaling message exchange, or even no > NAT/FW signaling is needed (if it is clear that no firewall is > encountered in the data path). This is talking about two different things here. First, the a detection message exchange and aggregation of policy rules into a signalling message. There is basically no need for having a separated detection mechanisms, since you run one message exchange just for nothing. You suggest to run the detection mechanisms to find out if there is any firewall/NAT and afterwards to signal for the desired rules. Isn't it better to directly signal for the desired rules? If there is any firewall/NAT en route, it is automatically configured as requested. Adding a detection mechanism will require another round trip and is not saving anything. Second, the aggregation of policy rules into a signalling message. This is not supported by the NATFW NSLP. You can signal for a specific flow (which in turn can be quite unspecific) and say it is running from A to B with IPv6. This would cover packets of this flow out of mobile IP and the latter data traffic. Martin > > Xiaoming > > Martin Stiemerling wrote: >> Hi Xiaoming, >> What do exactly refer as "detection of middlebox presence"? >> Basically, the NATFW NSLP, to be precise GIST, is already >> detecting the presence of NATFW NSLP enabled middleboxes. >> Martin >> Am 10.07.2006 um 08:21 schrieb Xiaoming Fu: >>> Hi Martin, all, >>> >>> Is it possible for NAT/FW NSIS NSLP to support detection of >>> middlebox presence? We find out this feature will be useful in >>> MIP6 FW traversal scenarios, as depicted in http://www.ietf.org/ >>> internet- drafts/draft-thiruvengadam-nsis-mip6-fw-04.txt >>> This could save additional signaling message flows, especially >>> if one expects to install multiple rules in a firewall -- if >>> exists -- in a particular IP path, e.g., rules for allowing both >>> BU and HoTI messages to traverse between the MN and the HA. >>> >>> Cheers, >>> Xiaoming >>> >>> Internet-Drafts@ietf.org wrote: >>> >>>> 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 : NAT/Firewall NSIS Signaling Layer Protocol >>>> (NSLP) >>>> Author(s) : M. Stiemerling, et al. >>>> Filename : draft-ietf-nsis-nslp-natfw-12.txt >>>> Pages : 101 >>>> Date : 2006-6-29 >>>> This memo defines the NSIS Signaling Layer Protocol (NSLP) for >>>> Network Address Translators (NATs) and firewalls. This NSLP >>>> allows >>>> hosts to signal on the data path for NATs and firewalls to be >>>> configured according to the needs of the application data >>>> flows. It >>>> enables hosts behind NATs to obtain a public reachable >>>> address and >>>> hosts behind firewalls to receive data traffic. The overall >>>> architecture is given by the framework and requirements >>>> defined by >>>> the Next Steps in Signaling (NSIS) working group. The network >>>> scenarios, the protocol itself, and examples for path-coupled >>>> signaling are given in this memo. >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp- >>>> natfw-12.txt >>>> To remove yourself from the I-D Announcement list, send a >>>> message to i-d-announce-request@ietf.org with the word >>>> unsubscribe in the body of the message. You can also visit >>>> https://www1.ietf.org/ mailman/listinfo/I-D-announce to change >>>> your subscription settings. >>>> Internet-Drafts are also available by anonymous FTP. Login with >>>> the username >>>> "anonymous" and a password of your e-mail address. After logging >>>> in, >>>> type "cd internet-drafts" and then >>>> "get draft-ietf-nsis-nslp-natfw-12.txt". >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/ >>>> 1shadow- sites.txt >>>> Internet-Drafts can also be obtained by e-mail. >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt". >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant mail >>>> readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local >>>> documentation on >>>> how to manipulate these messages. >>>> Below is the data which will enable a MIME >>>> compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> ------------------------------------------------------------------- >>>> -- --- >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 12 15:19:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kFD-0006oD-5s; Wed, 12 Jul 2006 15:19:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kFC-0006o0-6u for nsis@ietf.org; Wed, 12 Jul 2006 15:19:34 -0400 Received: from natlemon.rzone.de ([81.169.145.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0kFB-0006Wi-CS for nsis@ietf.org; Wed, 12 Jul 2006 15:19:34 -0400 Received: from [192.168.178.200] (p5484BB43.dip0.t-ipconnect.de [84.132.187.67]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k6CJJOYG020158; Wed, 12 Jul 2006 21:19:25 +0200 (MEST) Message-ID: <44B54A98.2030909@cs.uni-goettingen.de> Date: Wed, 12 Jul 2006 21:16:40 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R (Jerry), ALABS" References: <9473683187ADC049A855ED2DA739ABCA0DDC7AD0@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7AD0@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: nsis@ietf.org Subject: [NSIS] Re: questions on y1541-qosm X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, ok, average values are used. But how do I get these values? The sections about and don't describe a method which can be implemented. Are there any examples or source which is commonly used? How do I get this Y.1541 Recommendation? I'm only allowed to register at itu.int when I belong to a certain company. Bernd Ash, Gerald R (Jerry), ALABS wrote: > Hi Bernd, > > Please see below. > > >>-----Original Message----- >>From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] >>Sent: Tuesday, July 11, 2006 10:55 AM >>To: Ash, Gerald R (Jerry), ALABS >>Cc: nsis@ietf.org >>Subject: questions on y1541-qosm >> >>Hi Jerry, >> >>I have some questions on your draft. Section 2.2 says: >> >> 262 It MUST be possible to perform the following >>QoS-NSLP signaling >> 263 functions to enable Y.1541-QOSM requirements: >> 264 >> 265 a. accumulate delay, delay variation and loss >>ratio across the >> 266 end-to-end connection, which may span multiple domains >> >>How can the delay be identified across the path? AFAIK only >>the QNI can >>calculate the RTT since no timestamp of the QUERY msg is >>available at QNEs. >>Including e.g. a 32-bit long value containing the seconds >>since the Epoch would >>solve this. > > > The parameter is not intended as a RTT measurement from > the QNI. As described in Section 7.2.8 of the QSPEC draft > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: > > "The Path Latency is a single 32-bit integer in network byte order. > The composition rule for the parameter is summation > with a clamp of (2**32 - 1) on the maximum value. The latencies are > average values reported in units of one microsecond. A system with > resolution less than one microsecond MUST set unused digits to zero. > An individual QNE can advertise a latency value between 1 and 2**28 > (somewhat over two minutes) and the total latency added across all > QNEs can range as high as (2**32)-2. If the sum of the different > elements delays exceeds (2**32)-2, the end-to-end advertised delay > SHOULD be reported as indeterminate. A QNE that cannot accurately > predict the latency of packets it is processing MUST raise the > not-supported flag and either leave the value of Path Latency as is, > or add its best estimate of its lower bound. A raised not-supported > flag indicates the value of Path Latency is a lower bound of the > real Path Latency. The distinguished value (2**32)-1 is taken to > mean indeterminate latency because the composition function limits > the composed sum to this value, it indicates the range of the > composition calculation was exceeded." > > Hence average values are used by each QNE in the path to determine the > cumulative , which could include propagation delay, > average queuing delay, etc. > > >>But how can the delay variation (and loss ratio) be gathered? >>Is this the >>variation of every single packet, e.g. voice streaming data, >>compared to the >>agreed delay rate? Since multiple values are required this >>can't be done with a >>single QUERY. > > > and are determined in analogous ways. E.g., > the is accumulated as described in Section 7.2.9 in the > QSPEC draft: > > "The Path Jitter is a set of three 32-bit integers in network byte > order. The Path Jitter parameter is the combination of three > statistics describing the Jitter distribution with a clamp of > (2**32 - 1) on the maximum of each value. The jitter STATs are > reported in units of one microsecond. A system with resolution less > than one microsecond MUST set unused digits to zero. An individual > QNE can advertise jitter values between 1 and 2**28 (somewhat over > two minutes) and the total jitter computed across all QNEs can range > as high as (2**32)-2. If the combination of the different element > values exceeds (2**32)-2, the end-to-end advertised jitter SHOULD be > reported as indeterminate. A QNE that cannot accurately predict the > jitter of packets it is processing MUST raise the not-supported flag > and either leave the value of Path Jitter as is, or add its best > estimate of its STAT values. A raised not-supported flag indicates > the value of Path Jitter is a lower bound of the real Path Jitter. > The distinguished value (2**32)-1 is taken to mean indeterminate > jitter. A QNE that cannot accurately predict the jitter of packets > it is processing SHOULD set its local parameter to this value. > Because the composition function limits the total to this value, > receipt of this value at a network element or application indicates > that the true path jitter is not known. This MAY happen because one > or more network elements could not supply a value, or because the > range of the composition calculation was exceeded. > > NOTE: The Jitter composition function makes use of the > parameter. Composition functions for loss, latency and jitter may be > found in [Y.1541]." > > >>These methods describe only the actual state, but don't say >>anything about >>future values. The values can change depending on the load of >>the routers. > > > These are 'average' values rather than instantaneous or 'future' values. > > >>What does it mean when a QNI gets a RESPONSE with >Class> 0? Is this >>a guaranty that the delay never exceeds 100ms, the delay >>variation is always >><=50 ms and the loss ratio <=10^-3? > > > It means that the cumulative is < 100 ms., cumulative > < 50 ms., etc. > > >>Or does the network service provider has to ensure these >>limits as mentioned in >>section 2.1? > > > As explained in Section 2.1, the Y.1541 QoS classes enable the service > provider to define SLAs based on the QoS requirements; the SP needs to > ensure that the requirements are recognized and receive appropriate > treatment (as discussed above) in the network. > > Thanks, > Jerry > > >>Thanks, >>Bernd > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 12 15:44:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kd4-0000md-AN; Wed, 12 Jul 2006 15:44:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kd1-0000kZ-W1; Wed, 12 Jul 2006 15:44:11 -0400 Received: from mail.uc.pt ([193.137.200.37] helo=mail-1.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0kcz-0004zw-G5; Wed, 12 Jul 2006 15:44:11 -0400 Received: from mail-1.ci.uc.pt (mail-1.ci.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id E892625F6FA; Wed, 12 Jul 2006 20:44:05 +0100 (WEST) Received: from zoing (unknown [132.219.27.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail-1.ci.uc.pt (Postfix) with ESMTP id 0E75825F6F7; Wed, 12 Jul 2006 20:44:04 +0100 (WEST) From: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= To: , Date: Wed, 12 Jul 2006 15:43:56 +0100 Message-ID: <004601c6a5c1$9be73590$911bdb84@zoing> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcalwZoF4/tIBxBRTYO5PF+8t42VrA== X-Spam-Score: 0.3 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Subject: [NSIS] Interop meeting X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0414926081==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0414926081== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C6A5C9.FDAB9D90" This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C6A5C9.FDAB9D90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 As discussed in the 66th IETF NSIS meeting, the University of Coimbra - Portugal (http://www.dei.uc.pt) is glad to host a new NSIS = interoperability meeting. =20 Best regards, Lu=EDs Cordeiro ------=_NextPart_000_0047_01C6A5C9.FDAB9D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As discussed in the 66th IETF NSIS meeting, = the University of Coimbra - Portugal (http://www.dei.uc.pt) is glad to host a new NSIS interoperability = meeting.

 

Best regards,

Lu=EDs Cordeiro

------=_NextPart_000_0047_01C6A5C9.FDAB9D90-- --===============0414926081== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0414926081==-- From nsis-bounces@ietf.org Thu Jul 13 05:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0x6J-0005eD-PG; Thu, 13 Jul 2006 05:03:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0x5o-0004dz-Nd for nsis@ietf.org; Thu, 13 Jul 2006 05:02:44 -0400 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0x5m-00050e-95 for nsis@ietf.org; Thu, 13 Jul 2006 05:02:44 -0400 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Thu, 13 Jul 2006 11:02:01 +0200 Received: from [172.27.99.67] ([172.27.99.67]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 13 Jul 2006 11:01:47 +0200 Message-ID: <44B60BFB.2010704@docomolab-euro.com> Date: Thu, 13 Jul 2006 11:01:47 +0200 From: mendes User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: AW: [NSIS] NSIS next steps References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2006 09:01:47.0539 (UTC) FILETIME=[F8A3CE30:01C6A65A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: robert.hancock@roke.co.uk, nsis@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John I'll be very interested in contributing to describe a different type on interDomain-QoSM based on a pattern MRM. But before that I would like to see you else is interested in this. Moreover, all this work depends on the evolution of the pattern MRM itself. At this point in time, I would say that would be interesting to explore a Echo pattern to allow QoS controllers to locate other peers in its (network) vicinity. Paulo john.loughney@nokia.com wrote: > Paulo, > > >> I would like to express interest on the MRM pattern (I had >> already done it in Dallas after Martin's presentation). >> >> As for Hannes question about applications that may make use of >> this MRM, I can mention one: a different type of >> interDomain-QoSM as the one that will be presented in Montreal >> (draft-zhang-nsis-interdomain-qosm-02): >> - the draft to be presented in Montreal makes use of the new >> off-path MRM to break the end-to-end QoS signaling into >> inter-domain and intra-domain. >> - with the MRM pattern the inter-domain signaling may be done >> in a different way, starting by the QoS-controller that >> triggers the navigation pattern. For instance: >> - one QoS-controller may explore/monitor the capacity of >> neighbour networks (QoS-controllers) with a TTL defined in the >> query message and use the returned information to dimension >> its network. >> - one QoS-controller may announce its own capability to >> its neighbours with a TTL defined in the query, and to collect >> the interest of other networks to make use of that capability. >> > > Very interesting - I'd be very interested in seeing this written up. > > >> Another application may be to configuration over dispersed >> nodes, such as sensors, and to collect sensing information. >> > > That would be another use - though a bit more experimental ... > > John > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 08:58:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G10ls-0002Vs-Co; Thu, 13 Jul 2006 08:58:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G10ls-0002Vn-21 for nsis@ietf.org; Thu, 13 Jul 2006 08:58:24 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G10lq-0002qG-Ot for nsis@ietf.org; Thu, 13 Jul 2006 08:58:24 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1G10lm-0008PP-EV; Thu, 13 Jul 2006 14:58:20 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (unknown [IPv6:2001:638:204:6::dead:beef]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 2A118C66F; Thu, 13 Jul 2006 14:58:18 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1G10ll-0003lm-Jv; Thu, 13 Jul 2006 14:58:17 +0200 Message-ID: <44B64368.1010101@tm.uka.de> Date: Thu, 13 Jul 2006 14:58:16 +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: john.loughney@nokia.com Subject: Re: [NSIS] Interop testing event interest References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org john.loughney@nokia.com schrieb: > There seems to be some interest in an interop event. Are folks > interested in this - what would be tested? GIST, QoS NSLP, NAT-FW NSLP? > Let me know and an approximate time-frame for this. Yes, we are interested with all three protocols. An appropriate time-frame is a good question though. Maybe we need some time to upgrade to the latest drafts. I would suggest that Luis proposes some dates. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 09:15:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1120-0004Ww-R7; Thu, 13 Jul 2006 09:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G111z-0004Wl-Bv for nsis@ietf.org; Thu, 13 Jul 2006 09:15:03 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G111x-0003MR-PD for nsis@ietf.org; Thu, 13 Jul 2006 09:15:03 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 409186E0001; Thu, 13 Jul 2006 15:15:01 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 15:15:00 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 15:15:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Interop testing event interest Date: Thu, 13 Jul 2006 15:15:00 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D055DFE8F@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interop testing event interest Thread-Index: Acal0JbB/MeovfxZQ+SDyI1SGsEUgAArQufQ From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: , X-OriginalArrivalTime: 13 Jul 2006 13:15:00.0890 (UTC) FILETIME=[58952FA0:01C6A67E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, We would like to participate with a QoS-NSLP proto.=20 Best regards, Attila > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, July 12, 2006 6:31 PM > To:=20 > Subject: [NSIS] Interop testing event interest >=20 >=20 > There seems to be some interest in an interop event. Are folks > interested in this - what would be tested? GIST, QoS NSLP,=20 > NAT-FW NSLP? > Let me know and an approximate time-frame for this. >=20 > thanks, > John >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 09:20:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G117R-0005CH-BA; Thu, 13 Jul 2006 09:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G117P-0005At-MS for nsis@ietf.org; Thu, 13 Jul 2006 09:20:39 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G117N-0003cn-9J for nsis@ietf.org; Thu, 13 Jul 2006 09:20:39 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6DDKT6u026696; Thu, 13 Jul 2006 15:20:29 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6DDKTvb018105; Thu, 13 Jul 2006 15:20:29 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6DDKTl13416; Thu, 13 Jul 2006 15:20:29 +0200 (MEST) Date: Thu, 13 Jul 2006 15:20:29 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: gash@att.com, nsis@ietf.org Received: from 132.219.25.235 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 13 Jul 2006 13:20:28 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <3dL76scY.1152796828.0382790.karagian@ewi.utwente.nl> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7AC7@KCCLUST06EVS1.ugd.att.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.702 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 13 Jul 2006 15:20:33 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] how a non QOSm node can be detected? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Cornelia and Attila The Qspec template draft does not describe how a non QOSM aware hop can be detected. I think that a similar solution as followed by RSVP should be followed, see text from RFC2205: "RSVP must also test for the presence of non-RSVP hops in the path and pass this information to traffic control. From this flag bit that the RSVP process supplies and from its own local knowledge, traffic control can detect the presence of a hop in the path that is not capable of QoS control, and it passes this information to the receivers in Adspecs [RFC 2210]. With normal IP forwarding, RSVP can detect a non-RSVP hop by comparing the IP TTL with which a Path message is sent to the TTL with which it is received; for this purpose, the transmission TTL is placed in the common header. However, the TTL is not always a reliable indicator of non-RSVP hops, and other means must sometimes be used. For example, if the routing protocol uses IP encapsulating tunnels, then the routing protocol must inform RSVP when non-RSVP hops are included. If no automatic mechanism will work, manual configuration will be required." The same way must be used by the QSPEC template draft! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 09:33:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11JU-0004fv-Qq; Thu, 13 Jul 2006 09:33:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11JT-0004cZ-MN for nsis@ietf.org; Thu, 13 Jul 2006 09:33:07 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11JS-00047X-99 for nsis@ietf.org; Thu, 13 Jul 2006 09:33:07 -0400 Received: from [132.219.15.192] (unknown [132.219.15.192]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 680851BAC9E for ; Thu, 13 Jul 2006 15:18:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Thu, 13 Jul 2006 09:32:52 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [NSIS] REA Naming Contest (reanco) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear All, We have discussed about the naming issues for the NATFW NSLP's RESERVE-EXTERNAL-ADDRESS (REA) message. In the past revisions of the NATFW NSLP REA has been used to obtain an external IP address/port at the outermost NAT (and at in between NATs too). But the semantics of REA changed over time from purely NAT usage to a combined NAT and firewall usage, i.e., a combination of the old REA and the old UCREATE. REA is used for: - Used to get external address/port at NAT - Used to install firewall rules for inbound traffic - Used in proxy mode usage So the current name is not really describing the semantics/usage anymore and we need to something different. Since the authors haven't had any good idea and some off-line discussions didn't bring a good name, we are starting the REA naming contest (reanco) This contest calls the NSIS WG for input on name suggestions for the message currently called REA. The contest starts today (actually already yesterday during the session) and will run until August 3rd 8am EST. Suggestion made after August 3rd EST are not accepted anymore. All suggestions must be sent to the NSIS working group list (nsis@ietf.org). It is not valid to use a naming generator that simply tries combinations of characters. The one who has suggested the name that will be finally taken as the new name for REA will be awarded with a six-pack of local beer at next IETF in San Diego. If there are multiple people suggesting the same name, they must share the six pack (sorry for that, but not enough money for it ;-) Of course all things apply here: participants must be older than 18 or 21 years (depending on location of IETF and the local laws), no guarantees, not entitled for anything, must be at the next IETF meeting in San Diego in November 2006, no monetary refunding, etc... So, looking forward to many suggestion for a "new REA". Martin for the NATFW NSLP authors. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 09:35:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11Lt-00085S-1Z; Thu, 13 Jul 2006 09:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11Ls-00085N-8f for nsis@ietf.org; Thu, 13 Jul 2006 09:35:36 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11Lr-0004Dt-Fr for nsis@ietf.org; Thu, 13 Jul 2006 09:35:36 -0400 Received: from [132.219.15.192] (unknown [132.219.15.192]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CE2C71BAC9F for ; Thu, 13 Jul 2006 15:21:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) To: nsis Message-Id: References: From: Martin Stiemerling Subject: Fwd: [NSIS] REA Naming Contest (reanco) Date: Thu, 13 Jul 2006 09:35:24 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1805569919==" Errors-To: nsis-bounces@ietf.org --===============1805569919== Content-Type: multipart/alternative; boundary=Apple-Mail-47-544349137 --Apple-Mail-47-544349137 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Forgot one thing: The name suggestions will be discussed by the NSIS WG and the WG will vote on the suggestions to find the new name. Martin Anfang der weitergeleiteten E-Mail: > Von: Martin Stiemerling > Datum: 13. Juli 2006 09:32:52 GMT-04:00 > An: nsis > Betreff: [NSIS] REA Naming Contest (reanco) > > Dear All, > > We have discussed about the naming issues for the NATFW NSLP's > RESERVE-EXTERNAL-ADDRESS (REA) message. > > In the past revisions of the NATFW NSLP REA has been used to obtain an > external IP address/port at the outermost NAT (and at in between > NATs too). > But the semantics of REA changed over time from purely NAT usage to a > combined NAT and firewall usage, i.e., a combination of the old REA > and > the old UCREATE. > > REA is used for: > - Used to get external address/port at NAT > - Used to install firewall rules for inbound traffic > - Used in proxy mode usage > > So the current name is not really describing the semantics/usage > anymore > and we need to something different. Since the authors haven't had any > good idea and some off-line discussions didn't bring a good name, we > are starting the > > REA naming contest (reanco) > > This contest calls the NSIS WG for input on name suggestions for the > message currently called REA. > > The contest starts today (actually already yesterday during the > session) > and will run until August 3rd 8am EST. Suggestion made after > August 3rd EST are not accepted anymore. All suggestions must be sent > to the NSIS working group list (nsis@ietf.org). It is not valid to > use a > naming generator that simply tries combinations of characters. > > The one who has suggested the name that will be finally taken as > the new > name for REA will be awarded with a six-pack of local beer at next > IETF in > San Diego. If there are multiple people suggesting the same name, they > must share the six pack (sorry for that, but not enough money for > it ;-) > > Of course all things apply here: participants must be older than 18 > or 21 years > (depending on location of IETF and the local laws), no guarantees, > not entitled > for anything, must be at the next IETF meeting in San Diego in > November 2006, > no monetary refunding, etc... > > > So, looking forward to many suggestion for a "new REA". > > Martin for the NATFW NSLP authors. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --Apple-Mail-47-544349137 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Forgot one thing:=A0

The name suggestions will = be discussed by the NSIS WG and the WG will
vote on the = suggestions to find the new name.
=A0=A0
=A0 = Martin

Anfang der weitergeleiteten E-Mail:

Von: = Martin Stiemerling <stiemerling@netlab.nec.de>= ;
Datum: 13. Juli 2006 09:32:52 = GMT-04:00
An: nsis <nsis@ietf.org>
Betreff: = [NSIS] REA Naming Contest (reanco)

Dear = All,

We have discussed about the naming issues for the = NATFW NSLP's
RESERVE-EXTERNAL-ADDRESS (REA) = message.

In the past revisions of the NATFW NSLP REA has been = used to obtain an
external IP address/port at the = outermost NAT (and at in between NATs too).
But the = semantics of REA changed over time from purely NAT usage to a
combined NAT and firewall usage, i.e., a combination = of the old REA and
the old UCREATE.

REA is = used for:
- Used to get external = address/port at NAT
- Used to install firewall = rules for inbound traffic
- Used in = proxy mode usage

So the current name is not really describing the = semantics/usage anymore
and we need = to something different. Since the authors haven't had any
good idea and some off-line discussions didn't bring = a good name, we
are starting the

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 REA naming contest (reanco)

This = contest calls the NSIS WG for input on name suggestions for = the
message currently called = REA.

The contest starts today (actually already yesterday = during the session)
and will run until=A0 August 3rd 8am EST. = Suggestion made after
August 3rd EST are not = accepted anymore. All suggestions must be sent
to the NSIS working group list (nsis@ietf.org). It is not valid to use = a
naming generator that simply tries combinations = of characters.

The one who has suggested the name that will be = finally taken as the new
name for REA = will be awarded with a six-pack of local beer at next IETF in
San Diego. If there are multiple people suggesting = the same name, they
must share the six pack = (sorry for that, but not enough money for it ;-)

Of = course all things apply here: participants must be older than 18 or 21 = years
(depending on location of IETF = and the local laws), no guarantees, not entitled
for anything, must be at the next IETF meeting in = San Diego in November 2006,
no monetary = refunding, etc...


So, = looking forward to many suggestion for a "new REA".

=A0 Martin for the NATFW NSLP = authors.

nsis mailing list
=

= --Apple-Mail-47-544349137-- --===============1805569919== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1805569919==-- From nsis-bounces@ietf.org Thu Jul 13 09:49:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11Yv-0003Gv-Nv; Thu, 13 Jul 2006 09:49:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11Yu-0003Gq-Jz for nsis@ietf.org; Thu, 13 Jul 2006 09:49:04 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11Ys-0004lS-0p for nsis@ietf.org; Thu, 13 Jul 2006 09:49:04 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6DDmhRY018323; Thu, 13 Jul 2006 14:48:43 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 14:48:43 +0100 Message-ID: <44B64F3D.6070605@roke.co.uk> Date: Thu, 13 Jul 2006 14:48:45 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] how a non QOSm node can be detected? References: <3dL76scY.1152796828.0382790.karagian@ewi.utwente.nl> In-Reply-To: <3dL76scY.1152796828.0382790.karagian@ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2006 13:48:43.0459 (UTC) FILETIME=[0E20B930:01C6A683] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, I've also been thinking about this one over the last few days. I think the problem is about QoS NSLP unaware hops (which includes GIST-unaware hops), rather than what is referred to in the QSpec draft as a "non QOSM hop". There are two parts to this problem: a) identifying that a non QoS NSLP hop exists b) signalling this end-to-end The core part of (a) is covered by GIST, by providing TTL information over the API. I'm not sure what special things (if anything) we need to do to handle tunnels. If we need something here then it probably needs to go in the QoS NSLP document. In previous versions of the QSpec draft I had interpreted the flag as providing the functionality necessary for (b). However, following further clarifications of the document I now think this isn't the case. A separate flag may, therefore, be needed. regards, Andrew Georgios Karagiannis wrote: > > The Qspec template draft does not describe how a non QOSM aware hop can > be detected. I think that a similar solution as followed by RSVP should > be followed, see text from RFC2205: > "RSVP must also test for the presence of non-RSVP hops in the path > and pass this information to traffic control. From this flag bit > that the RSVP process supplies and from its own local knowledge, > traffic control can detect the presence of a hop in the path that > is not capable of QoS control, and it passes this information to > the receivers in Adspecs [RFC 2210]. > > With normal IP forwarding, RSVP can detect a non-RSVP hop by > comparing the IP TTL with which a Path message is sent to the TTL > with which it is received; for this purpose, the transmission TTL > is placed in the common header. However, the TTL is not always a > reliable indicator of non-RSVP hops, and other means must > sometimes be used. For example, if the routing protocol uses IP > encapsulating tunnels, then the routing protocol must inform RSVP > when non-RSVP hops are included. If no automatic mechanism will > work, manual configuration will be required." > > The same way must be used by the QSPEC template draft! > > Best Regards, > Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 09:54:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11e4-0003wc-BH; Thu, 13 Jul 2006 09:54:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11e2-0003uW-IA for nsis@ietf.org; Thu, 13 Jul 2006 09:54:22 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11e0-0004vc-Vm for nsis@ietf.org; Thu, 13 Jul 2006 09:54:22 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6DDsFuq029091; Thu, 13 Jul 2006 15:54:15 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6DDsEvb022920; Thu, 13 Jul 2006 15:54:14 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6DDsFK14885; Thu, 13 Jul 2006 15:54:15 +0200 (MEST) Date: Thu, 13 Jul 2006 15:54:15 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: andrew.mcdonald@roke.co.uk Subject: Re: [NSIS] how a non QOSm node can be detected? Received: from 194.237.142.10 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 13 Jul 2006 13:54:13 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <44B64F3D.6070605@roke.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.899 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 13 Jul 2006 15:54:17 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "gash@att.com" , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew Yes I agree with your remarks! I also thought that the flag as providing the functionality necessary for (b), but this is not the case. Regarding where this should be handled, I am not sure of! Anyway the current semantics of the Non QoSm Hop parameter in the QSepc template is wrong and it has to be changed! Best Regards, Georgios On 7/13/2006, "Andrew McDonald" wrote: >Hi Georgios, > >I've also been thinking about this one over the last few days. I think >the problem is about QoS NSLP unaware hops (which includes GIST-unaware >hops), rather than what is referred to in the QSpec draft as a "non QOSM >hop". > >There are two parts to this problem: >a) identifying that a non QoS NSLP hop exists >b) signalling this end-to-end > >The core part of (a) is covered by GIST, by providing TTL information >over the API. I'm not sure what special things (if anything) we need to >do to handle tunnels. If we need something here then it probably needs >to go in the QoS NSLP document. > >In previous versions of the QSpec draft I had interpreted the HOP> flag as providing the functionality necessary for (b). However, >following further clarifications of the document I now think this isn't >the case. A separate flag may, therefore, be needed. > >regards, > >Andrew > >Georgios Karagiannis wrote: >> >> The Qspec template draft does not describe how a non QOSM aware hop can >> be detected. I think that a similar solution as followed by RSVP should >> be followed, see text from RFC2205: >> "RSVP must also test for the presence of non-RSVP hops in the path >> and pass this information to traffic control. From this flag bit >> that the RSVP process supplies and from its own local knowledge, >> traffic control can detect the presence of a hop in the path that >> is not capable of QoS control, and it passes this information to >> the receivers in Adspecs [RFC 2210]. >> >> With normal IP forwarding, RSVP can detect a non-RSVP hop by >> comparing the IP TTL with which a Path message is sent to the TTL >> with which it is received; for this purpose, the transmission TTL >> is placed in the common header. However, the TTL is not always a >> reliable indicator of non-RSVP hops, and other means must >> sometimes be used. For example, if the routing protocol uses IP >> encapsulating tunnels, then the routing protocol must inform RSVP >> when non-RSVP hops are included. If no automatic mechanism will >> work, manual configuration will be required." >> >> The same way must be used by the QSPEC template draft! >> >> Best Regards, >> Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 10:00:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11js-0005dT-Dt; Thu, 13 Jul 2006 10:00:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11jq-0005dL-N4 for nsis@ietf.org; Thu, 13 Jul 2006 10:00:22 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11jp-0005DX-80 for nsis@ietf.org; Thu, 13 Jul 2006 10:00:22 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6DE08xg020250; Thu, 13 Jul 2006 15:00:08 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 15:00:08 +0100 Message-ID: <44B651E7.9040709@roke.co.uk> Date: Thu, 13 Jul 2006 15:00:07 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] how a non QOSm node can be detected? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2006 14:00:08.0834 (UTC) FILETIME=[A6A4A620:01C6A684] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: "gash@att.com" , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios Karagiannis wrote: > Yes I agree with your remarks! > I also thought that the HOP> flag as providing the functionality necessary for (b), but this is > not the case. Regarding where this should be handled, I am not sure of! > Anyway the current semantics of the Non QoSm Hop parameter in the QSepc > template is wrong and it has to be changed! Is it wrong, or is it just doing a different job? i.e. does the definition of need to change, or is a separate flag needed? My perception was that a new flag was needed. regards, Andrew > On 7/13/2006, "Andrew McDonald" wrote: > >> Hi Georgios, >> >> I've also been thinking about this one over the last few days. I think >> the problem is about QoS NSLP unaware hops (which includes GIST-unaware >> hops), rather than what is referred to in the QSpec draft as a "non QOSM >> hop". >> >> There are two parts to this problem: >> a) identifying that a non QoS NSLP hop exists >> b) signalling this end-to-end >> >> The core part of (a) is covered by GIST, by providing TTL information >> over the API. I'm not sure what special things (if anything) we need to >> do to handle tunnels. If we need something here then it probably needs >> to go in the QoS NSLP document. >> >> In previous versions of the QSpec draft I had interpreted the > HOP> flag as providing the functionality necessary for (b). However, >> following further clarifications of the document I now think this isn't >> the case. A separate flag may, therefore, be needed. >> >> regards, >> >> Andrew >> >> Georgios Karagiannis wrote: >>> The Qspec template draft does not describe how a non QOSM aware hop can >>> be detected. I think that a similar solution as followed by RSVP should >>> be followed, see text from RFC2205: >>> "RSVP must also test for the presence of non-RSVP hops in the path >>> and pass this information to traffic control. From this flag bit >>> that the RSVP process supplies and from its own local knowledge, >>> traffic control can detect the presence of a hop in the path that >>> is not capable of QoS control, and it passes this information to >>> the receivers in Adspecs [RFC 2210]. >>> >>> With normal IP forwarding, RSVP can detect a non-RSVP hop by >>> comparing the IP TTL with which a Path message is sent to the TTL >>> with which it is received; for this purpose, the transmission TTL >>> is placed in the common header. However, the TTL is not always a >>> reliable indicator of non-RSVP hops, and other means must >>> sometimes be used. For example, if the routing protocol uses IP >>> encapsulating tunnels, then the routing protocol must inform RSVP >>> when non-RSVP hops are included. If no automatic mechanism will >>> work, manual configuration will be required." >>> >>> The same way must be used by the QSPEC template draft! >>> >>> Best Regards, >>> Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 10:07:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11qm-0006Ni-KZ; Thu, 13 Jul 2006 10:07:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11qm-0006Nc-0m for nsis@ietf.org; Thu, 13 Jul 2006 10:07:32 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11qk-0005X7-Gx for nsis@ietf.org; Thu, 13 Jul 2006 10:07:32 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6DE7OcR000329; Thu, 13 Jul 2006 16:07:24 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6DE7Ovb026598; Thu, 13 Jul 2006 16:07:24 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6DE7Kn15221; Thu, 13 Jul 2006 16:07:20 +0200 (MEST) Date: Thu, 13 Jul 2006 16:07:20 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: andrew.mcdonald@roke.co.uk Subject: Re: [NSIS] how a non QOSm node can be detected? Received: from 194.237.142.10 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 13 Jul 2006 14:07:19 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <44B651E7.9040709@roke.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.482 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 13 Jul 2006 16:07:26 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "gash@att.com" , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andy The only useful functionality of this NON QOSM Hop parameter is to emphasi\e that a node has been passed that was not able to process the QOSM QSpec or the QoS-NSLP message. In order to show if some parameters are downgraded or not interpreted additional flags can be used, such as: N flag: shows that an optional parameter could not be interpreted M flag (not yet available): shows that a mandatory parameter could not be interpreted R flag (not yet available): shows that a parameter has been downgraded T flag: shows that a parameter has been tunelled. Based on the above information a QNI will be able to make the right decission on accepting or rejecting a succesful reservation. Best Regards, Georgios On 7/13/2006, "Andrew McDonald" wrote: >Georgios Karagiannis wrote: >> Yes I agree with your remarks! >> I also thought that the > HOP> flag as providing the functionality necessary for (b), but this is >> not the case. Regarding where this should be handled, I am not sure of! >> Anyway the current semantics of the Non QoSm Hop parameter in the QSepc >> template is wrong and it has to be changed! > >Is it wrong, or is it just doing a different job? >i.e. does the definition of need to change, or is a >separate flag needed? > >My perception was that a new flag was needed. > >regards, >Andrew > >> On 7/13/2006, "Andrew McDonald" wrote: >> >>> Hi Georgios, >>> >>> I've also been thinking about this one over the last few days. I think >>> the problem is about QoS NSLP unaware hops (which includes GIST-unaware >>> hops), rather than what is referred to in the QSpec draft as a "non QOSM >>> hop". >>> >>> There are two parts to this problem: >>> a) identifying that a non QoS NSLP hop exists >>> b) signalling this end-to-end >>> >>> The core part of (a) is covered by GIST, by providing TTL information >>> over the API. I'm not sure what special things (if anything) we need to >>> do to handle tunnels. If we need something here then it probably needs >>> to go in the QoS NSLP document. >>> >>> In previous versions of the QSpec draft I had interpreted the >> HOP> flag as providing the functionality necessary for (b). However, >>> following further clarifications of the document I now think this isn't >>> the case. A separate flag may, therefore, be needed. >>> >>> regards, >>> >>> Andrew >>> >>> Georgios Karagiannis wrote: >>>> The Qspec template draft does not describe how a non QOSM aware hop can >>>> be detected. I think that a similar solution as followed by RSVP should >>>> be followed, see text from RFC2205: >>>> "RSVP must also test for the presence of non-RSVP hops in the path >>>> and pass this information to traffic control. From this flag bit >>>> that the RSVP process supplies and from its own local knowledge, >>>> traffic control can detect the presence of a hop in the path that >>>> is not capable of QoS control, and it passes this information to >>>> the receivers in Adspecs [RFC 2210]. >>>> >>>> With normal IP forwarding, RSVP can detect a non-RSVP hop by >>>> comparing the IP TTL with which a Path message is sent to the TTL >>>> with which it is received; for this purpose, the transmission TTL >>>> is placed in the common header. However, the TTL is not always a >>>> reliable indicator of non-RSVP hops, and other means must >>>> sometimes be used. For example, if the routing protocol uses IP >>>> encapsulating tunnels, then the routing protocol must inform RSVP >>>> when non-RSVP hops are included. If no automatic mechanism will >>>> work, manual configuration will be required." >>>> >>>> The same way must be used by the QSPEC template draft! >>>> >>>> Best Regards, >>>> Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 10:19:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G121v-0000DY-6f; Thu, 13 Jul 2006 10:19:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G121u-0000DP-3T for nsis@ietf.org; Thu, 13 Jul 2006 10:19:02 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G121s-0005xh-R8 for nsis@ietf.org; Thu, 13 Jul 2006 10:19:02 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 13 Jul 2006 17:18:57 +0300 id 00087D93.44B65651.000068BC Date: Thu, 13 Jul 2006 17:18:57 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [NSIS] Any resolution to the QSPEC mandatory parameter list? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I think the discussion on the mandatory and optional parameters ended without a clear resolution. I think there were good notes on making the list of mandatory parameters shorter and/or allow an "ignore" interpretation of a mandatory parameter, and other ways to make the template less strict. I also support these comments. Any views from the QSPEC people on how to resolve these comments? Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 10:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G128A-0002KO-G5; Thu, 13 Jul 2006 10:25:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1289-0002JK-Lq for nsis@ietf.org; Thu, 13 Jul 2006 10:25:29 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1288-0006JO-84 for nsis@ietf.org; Thu, 13 Jul 2006 10:25:29 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6DEPPkn001282; Thu, 13 Jul 2006 16:25:25 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6DEPOvb029123; Thu, 13 Jul 2006 16:25:24 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6DEPPt16473; Thu, 13 Jul 2006 16:25:25 +0200 (MEST) Date: Thu, 13 Jul 2006 16:25:25 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: jmanner@cs.Helsinki.FI, nsis@ietf.org Subject: Re: [NSIS] Any resolution to the QSPEC mandatory parameter list? Received: from 194.237.142.10 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 13 Jul 2006 14:25:23 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.196 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 13 Jul 2006 16:25:26 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all There are many discussion showing that the interpretation of mandatory parameters may problems. It has been requested to decrease the number of mandatory parameters to 4. However, I think that such decissions cannot be made in the QSpec template draft. It will be better that each QOSM specification MUST specify which parameters are mandatory and which are optional. Thus the QNEs that will support a QOSM will also have to support the mandatory and optional parameters specified in each QOSM. Thus my proposal is that the QSepc template should list the QSpec parameters, but each QOSM specification MUST specify which of them are mandatory and which are optional! Best regards, Georgios On 7/13/2006, "Jukka MJ Manner" wrote: > >I think the discussion on the mandatory and optional parameters ended >without a clear resolution. I think there were good notes on making the >list of mandatory parameters shorter and/or allow an "ignore" >interpretation of a mandatory parameter, and other ways to make the >template less strict. I also support these comments. > >Any views from the QSPEC people on how to resolve these comments? > >Regards, >Jukka > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 10:42:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12OP-0003DK-PJ; Thu, 13 Jul 2006 10:42:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12OO-0003Cb-1B for nsis@ietf.org; Thu, 13 Jul 2006 10:42:16 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12OM-00078R-Kp for nsis@ietf.org; Thu, 13 Jul 2006 10:42:16 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6DEgCaS002071 for ; Thu, 13 Jul 2006 16:42:12 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6DEgBvb000759 for ; Thu, 13 Jul 2006 16:42:11 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6DEgBn18598; Thu, 13 Jul 2006 16:42:11 +0200 (MEST) Date: Thu, 13 Jul 2006 16:42:11 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nsis@ietf.org Received: from 194.237.142.10 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 13 Jul 2006 14:42:10 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.24 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 13 Jul 2006 16:42:12 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [NSIS] regarding downgrading token bucket X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Cornelia and Attila Regarding downgrading the Token Bucket parameter. What does this exactly mean? When you remap the per flow token bucket to an aggregate token bucket. Is this also a downgrade? When a QNE is only using the token bucket burst size. Does this mean downgrading? When a QNE is only using the average rate from the Token Bucket. Does this mean downgrading? So, when a QNI receives the Token Bucket in the above examples with the R bit flag set, how the QNI will know which of the token Bucket variables where used during the downgrade? What I would like to propose is a sentence like the following that can be used in the QSpec template draft: "Downgrading the Token Bucket means that the Token Bucket MUST be remapped to Bandwidth." Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 10:52:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12YD-0002w6-DK; Thu, 13 Jul 2006 10:52:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12YB-0002vw-Jb for nsis@ietf.org; Thu, 13 Jul 2006 10:52:23 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12YB-0007cz-3j for nsis@ietf.org; Thu, 13 Jul 2006 10:52:23 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6DEqDEQ002699; Thu, 13 Jul 2006 16:52:13 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6DEqDvb001804; Thu, 13 Jul 2006 16:52:13 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6DEqDj20302; Thu, 13 Jul 2006 16:52:13 +0200 (MEST) Date: Thu, 13 Jul 2006 16:52:13 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: andrew.mcdonald@roke.co.uk Subject: Re: [NSIS] how a non QOSm node can be detected? Received: from 194.237.142.10 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 13 Jul 2006 14:52:11 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <22W4SVO7.1152802331.4889490.karagian@ewi.utwente.nl> In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.25 () ALL_TRUSTED,AWL,BAYES_00,MIME_QP_LONG_LINE X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 13 Jul 2006 16:52:15 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: "gash@att.com" , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all Please note that instead of flag M listed below, I meant flag X: X flag (not yet available): shows that a mandatory parameter could not be interpreted Best Regards, Georgios On 7/13/2006, "Georgios Karagiannis" wrote: > >Hi Andy > >The only useful functionality of this NON QOSM Hop parameter is to >emphasi\e that a node has been passed that was not able to process the >QOSM QSpec or the QoS-NSLP message. >In order to show if some parameters are downgraded or not interpreted >additional flags can be used, such as: >N flag: shows that an optional parameter could not be interpreted >M flag (not yet available): shows that a mandatory parameter could not be >interpreted >R flag (not yet available): shows that a parameter has been downgraded >T flag: shows that a parameter has been tunelled. > >Based on the above information a QNI will be able to make the right >decission on accepting or rejecting a succesful reservation. > >Best Regards, >Georgios > >On 7/13/2006, "Andrew McDonald" wrote: > >>Georgios Karagiannis wrote: >>> Yes I agree with your remarks! >>> I also thought that the >> HOP> flag as providing the functionality necessary for (b), but this is >>> not the case. Regarding where this should be handled, I am not sure of! >>> Anyway the current semantics of the Non QoSm Hop parameter in the QSepc >>> template is wrong and it has to be changed! >> >>Is it wrong, or is it just doing a different job? >>i.e. does the definition of need to change, or is a >>separate flag needed? >> >>My perception was that a new flag was needed. >> >>regards, >>Andrew >> >>> On 7/13/2006, "Andrew McDonald" wrote: >>> >>>> Hi Georgios, >>>> >>>> I've also been thinking about this one over the last few days. I think >>>> the problem is about QoS NSLP unaware hops (which includes GIST-unaware >>>> hops), rather than what is referred to in the QSpec draft as a "non QOSM >>>> hop". >>>> >>>> There are two parts to this problem: >>>> a) identifying that a non QoS NSLP hop exists >>>> b) signalling this end-to-end >>>> >>>> The core part of (a) is covered by GIST, by providing TTL information >>>> over the API. I'm not sure what special things (if anything) we need to >>>> do to handle tunnels. If we need something here then it probably needs >>>> to go in the QoS NSLP document. >>>> >>>> In previous versions of the QSpec draft I had interpreted the >>> HOP> flag as providing the functionality necessary for (b). However, >>>> following further clarifications of the document I now think this isn't >>>> the case. A separate flag may, therefore, be needed. >>>> >>>> regards, >>>> >>>> Andrew >>>> >>>> Georgios Karagiannis wrote: >>>>> The Qspec template draft does not describe how a non QOSM aware hop can >>>>> be detected. I think that a similar solution as followed by RSVP should >>>>> be followed, see text from RFC2205: >>>>> "RSVP must also test for the presence of non-RSVP hops in the path >>>>> and pass this information to traffic control. From this flag bit >>>>> that the RSVP process supplies and from its own local knowledge, >>>>> traffic control can detect the presence of a hop in the path that >>>>> is not capable of QoS control, and it passes this information to >>>>> the receivers in Adspecs [RFC 2210]. >>>>> >>>>> With normal IP forwarding, RSVP can detect a non-RSVP hop by >>>>> comparing the IP TTL with which a Path message is sent to the TTL >>>>> with which it is received; for this purpose, the transmission TTL >>>>> is placed in the common header. However, the TTL is not always a >>>>> reliable indicator of non-RSVP hops, and other means must >>>>> sometimes be used. For example, if the routing protocol uses IP >>>>> encapsulating tunnels, then the routing protocol must inform RSVP >>>>> when non-RSVP hops are included. If no automatic mechanism will >>>>> work, manual configuration will be required." >>>>> >>>>> The same way must be used by the QSPEC template draft! >>>>> >>>>> Best Regards, >>>>> Georgios > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 11:09:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12od-0004Vi-UT; Thu, 13 Jul 2006 11:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12oY-0004MD-Nt for nsis@ietf.org; Thu, 13 Jul 2006 11:09:18 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12oX-00005F-B2 for nsis@ietf.org; Thu, 13 Jul 2006 11:09:18 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6DF9ECQ003744 for ; Thu, 13 Jul 2006 17:09:14 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6DF9Evb003872 for ; Thu, 13 Jul 2006 17:09:14 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6DF9Fm22543; Thu, 13 Jul 2006 17:09:15 +0200 (MEST) Date: Thu, 13 Jul 2006 17:09:15 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nsis@ietf.org Received: from 194.237.142.10 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 13 Jul 2006 15:09:13 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <44B651E7.9040709@roke.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.237 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 13 Jul 2006 17:09:15 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [NSIS] unclear how qos reserved should be set X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Cornelia and Attila I do not understand the following sentence in Section 4.5.5: "The QSpec in the RESPONSE message includes the QSPEC object with all parameters values set to zero (or equivalent)." What equivalent means? I think that Section 6.1 is also unclear on this point, where it says: "The parameter types included in QoS Reserved in the RESPONSE MUST be the same as those in QoS Desired in RESERVE." Do you here mean parameter values, instead of parameter types? If so then please include this also in the first cited sentence, see above! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 11:23:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G132T-0003DQ-18; Thu, 13 Jul 2006 11:23:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ol-0004u0-7g for nsis@ietf.org; Thu, 13 Jul 2006 11:09:31 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G12cS-0007so-KZ for nsis@ietf.org; Thu, 13 Jul 2006 10:56:49 -0400 Received: (qmail invoked by alias); 13 Jul 2006 14:56:47 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp010) with SMTP; 13 Jul 2006 16:56:47 +0200 X-Authenticated: #29516787 Message-ID: <44B65F2E.4080308@gmx.net> Date: Thu, 13 Jul 2006 10:56:46 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "nsis@ietf.org" References: <22W4SVO7.1152802331.4889490.karagian@ewi.utwente.nl> In-Reply-To: <22W4SVO7.1152802331.4889490.karagian@ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [NSIS] Indicating Mandatory Parameters X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, in a chat with Hui-Lan Lu she pointed me to something that I also noticed in my review: It is difficult for a reader to figure out what parameters are mandatory. It would be good to state this more explicitly in the text. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 13:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14nv-0006nf-3x; Thu, 13 Jul 2006 13:16:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14nt-0006na-Vy for nsis@ietf.org; Thu, 13 Jul 2006 13:16:45 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14nt-000847-Bu for nsis@ietf.org; Thu, 13 Jul 2006 13:16:45 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6DHGf6d004146; Thu, 13 Jul 2006 20:16:42 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 20:16:40 +0300 Received: from sdebe101.NOE.Nokia.com ([172.19.222.105]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 12:16:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt Date: Thu, 13 Jul 2006 10:16:34 -0700 Message-ID: <84CA64E50179964E8EF67403019ABB940230D470@sdebe101.NOE.Nokia.com> In-Reply-To: <6DCFC36F-70A7-49EB-9C5F-68AF012CC26E@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt Thread-Index: Acal258623P/2ePIRJeWRSXjhuS0ZAALtcrg From: To: , X-OriginalArrivalTime: 13 Jul 2006 17:16:37.0150 (UTC) FILETIME=[1906EBE0:01C6A6A0] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, =20 >-----Original Message----- >From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 >Sent: Wednesday, July 12, 2006 10:17 AM >To: Xiaoming Fu >Cc: nsis@ietf.org >Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt > >> - alternatively, MN can issue a DETECT (no matter it is called)=20 >> message towards the HA to collect all firewall information, if any,=20 >> and RESPONSE from the HA gives the response to MN. This is=20 >similar to=20 >> what diagnostics function covers. >> >> This feature could provide the NI some freedom e.g.,=20 >choosing multiple=20 >> rules in a single signaling message exchange, or even no NAT/FW=20 >> signaling is needed (if it is clear that no firewall is=20 >encountered in=20 >> the data path). > >This is talking about two different things here. First, the a=20 >detection message exchange and aggregation of policy rules=20 >into a signalling message. > >There is basically no need for having a separated detection=20 >mechanisms, since you run one message exchange just for=20 >nothing. You suggest to run the detection mechanisms to find=20 >out if there is any firewall/NAT and afterwards to signal for=20 >the desired rules. Isn't it better to directly signal for the=20 >desired rules? If there is any firewall/NAT en route, it is=20 >automatically configured as requested. =20 >Adding a detection mechanism will require another round trip=20 >and is not saving anything. The MN may want to know if there is any firewall on the path between the MN's new CoA and the HA and the CN, respectively. If there is no firewall, then there is no reason using NSLP. Not using NSLP would save one round trip for each mipv6 signalling and also data connection setup for each pair of (CoA, HA) and (CoA, CN) connections. It would probably be preferable to have a firewall detection mechanism inbuilt into MIPv6, instead of NSLP.=20 Gabor >Second, the aggregation of policy rules into a signalling message. =20 >This is not supported by the NATFW NSLP. You can signal for a=20 >specific flow (which in turn can be quite unspecific) and say=20 >it is running from A to B with IPv6. This would cover packets=20 >of this flow out of mobile IP and the latter data traffic. > > Martin > >> >> Xiaoming >> >> Martin Stiemerling wrote: >>> Hi Xiaoming, >>> What do exactly refer as "detection of middlebox presence"? =20 >>> Basically, the NATFW NSLP, to be precise GIST, is already=20 >detecting =20 >>> the presence of NATFW NSLP enabled middleboxes. >>> Martin >>> Am 10.07.2006 um 08:21 schrieb Xiaoming Fu: >>>> Hi Martin, all, >>>> >>>> Is it possible for NAT/FW NSIS NSLP to support detection of =20 >>>> middlebox presence? We find out this feature will be useful in >>>> MIP6 FW traversal scenarios, as depicted in http://www.ietf.org/ >>>> internet- drafts/draft-thiruvengadam-nsis-mip6-fw-04.txt >>>> This could save additional signaling message flows, especially if =20 >>>> one expects to install multiple rules in a firewall -- if=20 >exists -- =20 >>>> in a particular IP path, e.g., rules for allowing both BU=20 >and HoTI =20 >>>> messages to traverse between the MN and the HA. >>>> >>>> Cheers, >>>> Xiaoming >>>> >>>> Internet-Drafts@ietf.org wrote: >>>> >>>>> A New Internet-Draft is available from the on-line=20 >Internet- Drafts =20 >>>>> directories. >>>>> This draft is a work item of the Next Steps in Signaling Working =20 >>>>> Group of the IETF. >>>>> Title : NAT/Firewall NSIS Signaling Layer Protocol =20 >>>>> (NSLP) >>>>> Author(s) : M. Stiemerling, et al. >>>>> Filename : draft-ietf-nsis-nslp-natfw-12.txt >>>>> Pages : 101 >>>>> Date : 2006-6-29 >>>>> This memo defines the NSIS Signaling Layer Protocol (NSLP) for >>>>> Network Address Translators (NATs) and firewalls. This NSLP =20 >>>>> allows >>>>> hosts to signal on the data path for NATs and firewalls to be >>>>> configured according to the needs of the application data =20 >>>>> flows. It >>>>> enables hosts behind NATs to obtain a public reachable address=20 >>>>> and >>>>> hosts behind firewalls to receive data traffic. The overall >>>>> architecture is given by the framework and=20 >requirements defined=20 >>>>> by >>>>> the Next Steps in Signaling (NSIS) working group. The network >>>>> scenarios, the protocol itself, and examples for path-coupled >>>>> signaling are given in this memo. >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp- >>>>> natfw-12.txt >>>>> To remove yourself from the I-D Announcement list, send a=20 >message =20 >>>>> to i-d-announce-request@ietf.org with the word=20 >unsubscribe in the =20 >>>>> body of the message. You can also visit https://www1.ietf.org/=20 >>>>> mailman/listinfo/I-D-announce to change your subscription=20 >settings. >>>>> Internet-Drafts are also available by anonymous FTP. Login with =20 >>>>> the username >>>>> "anonymous" and a password of your e-mail address. After logging=20 >>>>> in, type "cd internet-drafts" and then >>>>> "get draft-ietf-nsis-nslp-natfw-12.txt". >>>>> A list of Internet-Drafts directories can be found in=20 >>>>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/ >>>>> 1shadow- sites.txt >>>>> Internet-Drafts can also be obtained by e-mail. >>>>> Send a message to: >>>>> mailserv@ietf.org. >>>>> In the body type: >>>>> "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt". >>>>> NOTE: The mail server at ietf.org can return the=20 >document in >>>>> MIME-encoded form by using the "mpack" utility. To use this >>>>> feature, insert the command "ENCODING mime" before the "FILE" >>>>> command. To decode the response(s), you will need=20 >"munpack" or >>>>> a MIME-compliant mail reader. Different MIME-compliant mail=20 >>>>> readers >>>>> exhibit different behavior, especially when dealing with >>>>> "multipart" MIME messages (i.e. documents which have=20 >been split >>>>> up into multiple messages), so check your local documentation=20 >>>>> on >>>>> how to manipulate these messages. >>>>> Below is the data which will enable a MIME=20 >compliant=20 >>>>> mail reader implementation to automatically retrieve the ASCII=20 >>>>> version of the Internet-Draft. >>>>>=20 >------------------------------------------------------------------- >>>>> -- --- >>>>> _______________________________________________ >>>>> nsis mailing list >>>>> nsis@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>> >>>> >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/nsis >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 17:27:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18iY-0000RI-7o; Thu, 13 Jul 2006 17:27:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18iX-0000RD-5r for nsis@ietf.org; Thu, 13 Jul 2006 17:27:29 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G18iV-00014e-J8 for nsis@ietf.org; Thu, 13 Jul 2006 17:27:29 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1152825993!13708207!11 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 26184 invoked from network); 13 Jul 2006 21:27:25 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-120.messagelabs.com with SMTP; 13 Jul 2006 21:27:25 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB45200222FEC; Thu, 13 Jul 2006 17:27:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jul 2006 16:27:07 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7AEE@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44B54A98.2030909@cs.uni-goettingen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: questions on y1541-qosm Thread-Index: Acal6B46dM3g+559SeSFj+AHLhKMkwAwD42g From: "Ash, Gerald R \(Jerry\), ALABS" To: "Bernd Schloer" X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org Subject: [NSIS] RE: questions on y1541-qosm X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd, Please see below.=20 > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 > Sent: Wednesday, July 12, 2006 3:17 PM > To: Ash, Gerald R (Jerry), ALABS > Cc: nsis@ietf.org > Subject: Re: questions on y1541-qosm >=20 > Hi Jerry, >=20 > ok, average values are used. But how do I get these values? > The sections about=20 > and don't describe a method which can be=20 > implemented. Are there any examples or source which is commonly used? The methods for cumulative , , are described in Section 8 of the pre-published Y.1541 Recommendation http://home.comcast.net/~acmacm/IDcheck/y1541_Rev_04.doc posted last August to the NSIS mailing list (see http://www1.ietf.org/mail-archive/web/nsis/current/msg05320.html). 'Average' values more or less apply to these computations, as described. For , the cumulative computation is described in the updated Y.1541 recommendation now being published. This computation estimates the pseudo range of jitter, 99.9-tile of delay minus minimum, and uses the mean, variance, and the percentile of individual domain distributions. > How do I get this Y.1541 Recommendation? I'm only allowed to=20 > register at itu.int=20 > when I belong to a certain company. Anyone can download 3 ITU-T recommendations for free per year per email address from the ITU web-site at http://www.itu.int/publications/template.aspx?lang=3De&menu=3Dmain&media=3D= dow nload&target=3D/publications/EBookshop.html. With more than one email address (easy to obtain), any number of free recommendations can be downloaded. Thanks, Regards, Jerry >=20 > Bernd >=20 >=20 >=20 > Ash, Gerald R (Jerry), ALABS wrote: > > Hi Bernd, > >=20 > > Please see below.=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 > >>Sent: Tuesday, July 11, 2006 10:55 AM > >>To: Ash, Gerald R (Jerry), ALABS > >>Cc: nsis@ietf.org > >>Subject: questions on y1541-qosm > >> > >>Hi Jerry, > >> > >>I have some questions on your draft. Section 2.2 says: > >> > >> 262 It MUST be possible to perform the following=20 > >>QoS-NSLP signaling > >> 263 functions to enable Y.1541-QOSM requirements: > >> 264 > >> 265 a. accumulate delay, delay variation and loss=20 > >>ratio across the > >> 266 end-to-end connection, which may span=20 > >>multiple domains > >> > >>How can the delay be identified across the path? AFAIK only=20 > >>the QNI can=20 > >>calculate the RTT since no timestamp of the QUERY msg is=20 > >>available at QNEs.=20 > >>Including e.g. a 32-bit long value containing the seconds=20 > >>since the Epoch would=20 > >>solve this. > >=20 > >=20 > > The parameter is not intended as a RTT=20 > > measurement from > > the QNI. As described in Section 7.2.8 of the QSPEC draft > > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: > >=20 > > "The Path Latency is a single 32-bit integer in network=20 > > byte order. > > The composition rule for the parameter is=20 > > summation > > with a clamp of (2**32 - 1) on the maximum value. The=20 > > latencies are > > average values reported in units of one microsecond. A=20 > > system with > > resolution less than one microsecond MUST set unused=20 > > digits to zero. > > An individual QNE can advertise a latency value between=20 > > 1 and 2**28 > > (somewhat over two minutes) and the total latency added=20 > > across all > > QNEs can range as high as (2**32)-2. If the sum of the different > > elements delays exceeds (2**32)-2, the end-to-end=20 > > advertised delay > > SHOULD be reported as indeterminate. A QNE that cannot=20 > > accurately > > predict the latency of packets it is processing MUST raise the > > not-supported flag and either leave the value of Path=20 > > Latency as is, > > or add its best estimate of its lower bound. A raised=20 > > not-supported > > flag indicates the value of Path Latency is a lower bound of the > > real Path Latency. The distinguished value (2**32)-1 is taken to > > mean indeterminate latency because the composition=20 > > function limits > > the composed sum to this value, it indicates the range of the > > composition calculation was exceeded." > >=20 > > Hence average values are used by each QNE in the path to=20 > > determine the > > cumulative , which could include propagation delay, > > average queuing delay, etc. > > =20 > >=20 > >>But how can the delay variation (and loss ratio) be gathered?=20 > >>Is this the=20 > >>variation of every single packet, e.g. voice streaming data,=20 > >>compared to the=20 > >>agreed delay rate? Since multiple values are required this=20 > >>can't be done with a=20 > >>single QUERY. > >=20 > >=20 > > and are determined in analogous=20 > > ways. E.g., > > the is accumulated as described in Section=20 > > 7.2.9 in the > > QSPEC draft: > >=20 > > "The Path Jitter is a set of three 32-bit integers in network byte > > order. The Path Jitter parameter is the combination of three > > statistics describing the Jitter distribution with a clamp of > > (2**32 - 1) on the maximum of each value. The jitter STATs are > > reported in units of one microsecond. A system with=20 > > resolution less > > than one microsecond MUST set unused digits to zero. An=20 > > individual > > QNE can advertise jitter values between 1 and 2**28=20 > > (somewhat over > > two minutes) and the total jitter computed across all=20 > > QNEs can range > > as high as (2**32)-2. If the combination of the different element > > values exceeds (2**32)-2, the end-to-end advertised=20 > > jitter SHOULD be > > reported as indeterminate. A QNE that cannot accurately=20 > > predict the > > jitter of packets it is processing MUST raise the=20 > > not-supported flag > > and either leave the value of Path Jitter as is, or add its best > > estimate of its STAT values. A raised not-supported=20 > > flag indicates > > the value of Path Jitter is a lower bound of the real=20 > > Path Jitter. > > The distinguished value (2**32)-1 is taken to mean indeterminate > > jitter. A QNE that cannot accurately predict the jitter=20 > > of packets > > it is processing SHOULD set its local parameter to this value. > > Because the composition function limits the total to this value, > > receipt of this value at a network element or=20 > > application indicates > > that the true path jitter is not known. This MAY happen=20 > > because one > > or more network elements could not supply a value, or because the > > range of the composition calculation was exceeded. > >=20 > > NOTE: The Jitter composition function makes use of the=20 > > > > parameter. Composition functions for loss, latency and=20 > > jitter may be > > found in [Y.1541]." > > =20 > >=20 > >>These methods describe only the actual state, but don't say=20 > >>anything about=20 > >>future values. The values can change depending on the load of=20 > >>the routers. > >=20 > >=20 > > These are 'average' values rather than instantaneous or=20 > > 'future' values. > > =20 > >=20 > >>What does it mean when a QNI gets a RESPONSE with >>Class> 0? Is this=20 > >>a guaranty that the delay never exceeds 100ms, the delay=20 > >>variation is always=20 > >><=3D50 ms and the loss ratio <=3D10^-3? > >=20 > >=20 > > It means that the cumulative is < 100 ms., cumulative > > < 50 ms., etc. > >=20 > >=20 > >>Or does the network service provider has to ensure these=20 > >>limits as mentioned in=20 > >>section 2.1? > >=20 > >=20 > > As explained in Section 2.1, the Y.1541 QoS classes enable=20 > > the service > > provider to define SLAs based on the QoS requirements; the=20 > > SP needs to > > ensure that the requirements are recognized and receive appropriate > > treatment (as discussed above) in the network. > >=20 > > Thanks, > > Jerry > >=20 > >=20 > >>Thanks, > >>Bernd > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 17:28:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18jU-0000Xl-LW; Thu, 13 Jul 2006 17:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18jT-0000XD-6G for nsis@ietf.org; Thu, 13 Jul 2006 17:28:27 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G18jR-00017A-PN for nsis@ietf.org; Thu, 13 Jul 2006 17:28:27 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1152826045!10142164!14 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9054 invoked from network); 13 Jul 2006 21:28:24 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 13 Jul 2006 21:28:24 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB45200223073; Thu, 13 Jul 2006 17:28:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] how a non QOSm node can be detected? Date: Thu, 13 Jul 2006 16:28:21 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7AEF@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44B64F3D.6070605@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] how a non QOSm node can be detected? Thread-Index: AcamgyHCHnK//eWKQeeeLjuIQZ115gANASgg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Andrew McDonald" , "Georgios Karagiannis" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, Georgios, See below.=20 > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Thursday, July 13, 2006 9:49 AM > To: Georgios Karagiannis > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: Re: [NSIS] how a non QOSm node can be detected? >=20 > Hi Georgios, >=20 > I've also been thinking about this one over the last few=20 > days. I think=20 > the problem is about QoS NSLP unaware hops (which includes=20 > GIST-unaware=20 > hops), rather than what is referred to in the QSpec draft as=20 > a "non QOSM=20 > hop". >=20 > There are two parts to this problem: > a) identifying that a non QoS NSLP hop exists > b) signalling this end-to-end >=20 > The core part of (a) is covered by GIST, by providing TTL information=20 > over the API. I'm not sure what special things (if anything)=20 > we need to=20 > do to handle tunnels. If we need something here then it=20 > probably needs=20 > to go in the QoS NSLP document. I agree that GIST and QoS NSLP would be the right way to detect problem a) (i.e., that a non QoS NSLP hop exists in the path). > In previous versions of the QSpec draft I had interpreted the=20 > HOP> flag as providing the functionality necessary for (b). However,=20 > following further clarifications of the document I now think=20 > this isn't=20 > the case. A separate flag may, therefore, be needed. I'm not quite sure what is meant by problem b) above. Maybe there is misunderstanding about the flag and how/when it is set. The parameter is set whenever a local QOSM different from the initiator QOSM is encountered. IMO this is useful for the QNI to know that a QOSM is encountered in the path that is different from the initiator QOSM (and that some parameters may have been remapped). =20 For example, if the RMD-QOSM is encountered in the path and the initiator QOSM is the Y.1541-QOSM, then the egress QNE in the local RMD domain would set the flag. However, if the initiator QSPEC is RMD and all the QNEs in the path use the RMD-QOSM, then the flag is *not* set. Again, I think an R-flag (remapped flag) per QSPEC parameter would be useful to denote that a QSPEC parameter had been remapped by a local QOSM rather than strictly interpreted. The flag is then set when the initiator QSPEC (e.g., Y.1541-QOSM) sets the parameter and the egress QNE in the local domain (e.g., RMD-QOSM) remaps to bandwidth (and ignores setting the other parameters in ).=20 The combination of the flag and R-flag provide useful information for the QNI to decide whether to accept or reject a reservation. Thanks, Regards, Jerry =20 >=20 > regards, >=20 > Andrew >=20 > Georgios Karagiannis wrote: > >=20 > > The Qspec template draft does not describe how a non QOSM=20 > aware hop can > > be detected. I think that a similar solution as followed by=20 > RSVP should > > be followed, see text from RFC2205: > > "RSVP must also test for the presence of non-RSVP hops in the path > > and pass this information to traffic control. From=20 > this flag bit > > that the RSVP process supplies and from its own local=20 > knowledge, > > traffic control can detect the presence of a hop in=20 > the path that > > is not capable of QoS control, and it passes this=20 > information to > > the receivers in Adspecs [RFC 2210]. > >=20 > > With normal IP forwarding, RSVP can detect a non-RSVP hop by > > comparing the IP TTL with which a Path message is=20 > sent to the TTL > > with which it is received; for this purpose, the=20 > transmission TTL > > is placed in the common header. However, the TTL is=20 > not always a > > reliable indicator of non-RSVP hops, and other means must > > sometimes be used. For example, if the routing=20 > protocol uses IP > > encapsulating tunnels, then the routing protocol must=20 > inform RSVP > > when non-RSVP hops are included. If no automatic=20 > mechanism will > > work, manual configuration will be required." > >=20 > > The same way must be used by the QSPEC template draft! > >=20 > > Best Regards, > > Georgios >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 17:29:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18kC-0000e1-0r; Thu, 13 Jul 2006 17:29:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18kA-0000dw-9z for nsis@ietf.org; Thu, 13 Jul 2006 17:29:10 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G18k8-00019J-UQ for nsis@ietf.org; Thu, 13 Jul 2006 17:29:10 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-126.messagelabs.com!1152826126!1883021!6 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 12150 invoked from network); 13 Jul 2006 21:29:07 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-126.messagelabs.com with SMTP; 13 Jul 2006 21:29:07 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452002230F0; Thu, 13 Jul 2006 17:29:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Thu, 13 Jul 2006 16:29:07 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7AF0@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: Acamh3EG0zv8/mOySJu5mKYem+dH3AANBY/g From: "Ash, Gerald R \(Jerry\), ALABS" To: "Jukka MJ Manner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, See below.=20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: Thursday, July 13, 2006 10:19 AM > To: nsis@ietf.org > Subject: [NSIS] Any resolution to the QSPEC mandatory parameter list? >=20 >=20 > I think the discussion on the mandatory and optional parameters ended > without a clear resolution. I think there were good notes on=20 > making the > list of mandatory parameters shorter and/or allow an "ignore" =20 > interpretation of a mandatory parameter, and other ways to make the > template less strict. I also support these comments. >=20 > Any views from the QSPEC people on how to resolve these comments? I'm not in favor of fundamentally changing the definition of mandatory and optional QSPEC parameters, as I think is being proposed. In effect, to allow a mandatory parameter to be ignored would eliminate the distinction between mandatory parameters (MUST interpret if populated) and optional parameters (SHOULD interpret if populated). The original idea of the QSPEC template is to provide a common set of mandatory parameters that would be interpreted (if populated by the QNI) by all QOSMs. This would allow a degree of interoperability. The set of mandatory parameters is based in part on parameters from the INTSERV and DIFFSERV models that should be commonly interpreted by all QOSMs (that was the original charge to the QSPEC template draft approach). The other alternative (i.e., to be able to 'ignore' mandatory parameters) is essentially to make all parameters optional parameters (SHOULD interpret if populated). Optional parameters allow the N-flag (not supported flag) to be set if a QOSM wishes to 'ignore' (not interpret) a parameter. =20 I'm not clear on the motivation for this other alternative. Perhaps some particular QOSM wants to introduce the possibility of 'ignoring' mandatory parameters. Y.1541-QOSM doesn't require this nor does the CL-QOSM (AFAIK). Perhaps the RMD-QOSM for some reason requires this -- if so, I'm not clear what is the justification? =20 I haven't seen that much support for a major change in the QSPEC template approach to be able to 'ignore' mandatory parameters. =20 Thanks, Jerry >=20 > Regards, > Jukka >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 17:29:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18ka-0000kX-GU; Thu, 13 Jul 2006 17:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18kZ-0000kN-1R for nsis@ietf.org; Thu, 13 Jul 2006 17:29:35 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G18kX-0001CS-Q7 for nsis@ietf.org; Thu, 13 Jul 2006 17:29:35 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-7.tower-121.messagelabs.com!1152826060!12670255!29 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15137 invoked from network); 13 Jul 2006 21:29:33 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-7.tower-121.messagelabs.com with SMTP; 13 Jul 2006 21:29:33 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB4520022312A; Thu, 13 Jul 2006 17:29:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Indicating Mandatory Parameters Date: Thu, 13 Jul 2006 16:29:32 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7AF1@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44B65F2E.4080308@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Indicating Mandatory Parameters Thread-Index: AcamkFq+21wOvjiRSsWKpMq4yTSPUAAMOx7A From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes,=20 See below. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, July 13, 2006 10:57 AM > To: nsis@ietf.org > Subject: [NSIS] Indicating Mandatory Parameters >=20 > Hi all, >=20 > in a chat with Hui-Lan Lu she pointed me to something that I also=20 > noticed in my review: It is difficult for a reader to figure out what=20 > parameters are mandatory. >=20 > It would be good to state this more explicitly in the text. I agree, this is a good suggestion. Thanks, Jerry >=20 > Ciao > Hannes >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 17:46:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G191N-0002MQ-Gq; Thu, 13 Jul 2006 17:46:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G191M-0002ML-Ih for nsis@ietf.org; Thu, 13 Jul 2006 17:46:56 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G191L-0002V3-3Q for nsis@ietf.org; Thu, 13 Jul 2006 17:46:56 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 14 Jul 2006 00:46:54 +0300 id 00087DDF.44B6BF4E.000010E8 Date: Fri, 14 Jul 2006 00:46:30 +0300 (EEST) From: Jukka MJ Manner To: "Ash, Gerald R \\(Jerry\\), ALABS" Subject: RE: [NSIS] Any resolution to the QSPEC mandatory parameter list? In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7AF0@KCCLUST06EVS1.ugd.att.com> Message-ID: References: <9473683187ADC049A855ED2DA739ABCA0DDC7AF0@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I think the problem is that setting too many mandatory parameters effectively limits people to define new QOSMs (even the current ones) - all QOSMs must be based on IntServ or DiffServ. Interworking is an important issue, I fully agree. That is why I'm not sure which way we should actually go: more or less mandatory parameters. (I think I'm inclined towards more flexibility) About the need for a change, I haven't seen any comment so far for keeping the longish list of mandatory parameters. All messages have been about introducing more flexibility. We should have had a hummm at the meeting to see what people would want. Maybe people could speak up about what they want? Jukka On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote: > Hi Jukka, > > See below. > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: Thursday, July 13, 2006 10:19 AM > > To: nsis@ietf.org > > Subject: [NSIS] Any resolution to the QSPEC mandatory parameter list? > > > > > > I think the discussion on the mandatory and optional parameters ended > > without a clear resolution. I think there were good notes on > > making the > > list of mandatory parameters shorter and/or allow an "ignore" > > interpretation of a mandatory parameter, and other ways to make the > > template less strict. I also support these comments. > > > > Any views from the QSPEC people on how to resolve these comments? > > I'm not in favor of fundamentally changing the definition of mandatory > and optional QSPEC parameters, as I think is being proposed. In effect, > to allow a mandatory parameter to be ignored would eliminate the > distinction between mandatory parameters (MUST interpret if populated) > and optional parameters (SHOULD interpret if populated). The original > idea of the QSPEC template is to provide a common set of mandatory > parameters that would be interpreted (if populated by the QNI) by all > QOSMs. This would allow a degree of interoperability. The set of > mandatory parameters is based in part on parameters from the INTSERV and > DIFFSERV models that should be commonly interpreted by all QOSMs (that > was the original charge to the QSPEC template draft approach). > > The other alternative (i.e., to be able to 'ignore' mandatory > parameters) is essentially to make all parameters optional parameters > (SHOULD interpret if populated). Optional parameters allow the N-flag > (not supported flag) to be set if a QOSM wishes to 'ignore' (not > interpret) a parameter. > > I'm not clear on the motivation for this other alternative. Perhaps > some particular QOSM wants to introduce the possibility of 'ignoring' > mandatory parameters. Y.1541-QOSM doesn't require this nor does the > CL-QOSM (AFAIK). Perhaps the RMD-QOSM for some reason requires this -- > if so, I'm not clear what is the justification? > > I haven't seen that much support for a major change in the QSPEC > template approach to be able to 'ignore' mandatory parameters. > > Thanks, > Jerry > > > > > Regards, > > Jukka > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 19:13:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1AMj-0005sj-7P; Thu, 13 Jul 2006 19:13:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1AMh-0005se-Mg for nsis@ietf.org; Thu, 13 Jul 2006 19:13:03 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1AMf-0004Ss-Er for nsis@ietf.org; Thu, 13 Jul 2006 19:13:03 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Thu, 13 Jul 2006 19:12:54 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006071319125416746 ; Thu, 13 Jul 2006 19:12:54 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Thu, 13 Jul 2006 19:12:54 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209DA1@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Bernd Schloer Subject: RE: [NSIS] RE: questions on y1541-qosm Date: Thu, 13 Jul 2006 19:12:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Bernd and all: Has not been instructed by AD last time that ITU-T specs need to be posted in a Web site, like IETF's Web site, that can be accessed by all IETF members? If so, why do the IETF members need to download those ITU-T specs with fees because it not for anyone's personal use? Where is this liaison for between the IETF and the ITU-T to create standards? Best regards, Radhika R. Roy _____ From: nsis-bounces@ietf.org on behalf of Ash, Gerald R (Jerry), ALABS Sent: Thu 7/13/2006 5:27 PM To: Bernd Schloer Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org Subject: [NSIS] RE: questions on y1541-qosm Hi Bernd, . Anyone can download 3 ITU-T recommendations for free per year per email address from the ITU web-site at http://www.itu.int/publications/template.aspx?lang=e &menu=main&media=dow nload&target=/publications/EBookshop.html. With more than one email address (easy to obtain), any number of free recommendations can be downloaded. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 13 20:13:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1BJV-0003Ve-N4; Thu, 13 Jul 2006 20:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1BJU-0003VZ-K3 for nsis@ietf.org; Thu, 13 Jul 2006 20:13:48 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1BJS-0007TH-WB for nsis@ietf.org; Thu, 13 Jul 2006 20:13:48 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6E0DURA006142; Fri, 14 Jul 2006 01:13:30 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 01:13:30 +0100 Message-ID: <44B6E1AB.1000905@roke.co.uk> Date: Fri, 14 Jul 2006 01:13:31 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] how a non QOSm node can be detected? References: <9473683187ADC049A855ED2DA739ABCA0DDC7AEF@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7AEF@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2006 00:13:30.0536 (UTC) FILETIME=[562ABA80:01C6A6DA] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Ash, Gerald R (Jerry), ALABS wrote: >> -----Original Message----- >> From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk] >> Sent: Thursday, July 13, 2006 9:49 AM >> To: Georgios Karagiannis >> Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >> Subject: Re: [NSIS] how a non QOSm node can be detected? >> >> Hi Georgios, >> >> I've also been thinking about this one over the last few >> days. I think >> the problem is about QoS NSLP unaware hops (which includes >> GIST-unaware >> hops), rather than what is referred to in the QSpec draft as >> a "non QOSM >> hop". >> >> There are two parts to this problem: >> a) identifying that a non QoS NSLP hop exists >> b) signalling this end-to-end >> >> The core part of (a) is covered by GIST, by providing TTL information >> over the API. I'm not sure what special things (if anything) >> we need to >> do to handle tunnels. If we need something here then it >> probably needs >> to go in the QoS NSLP document. > > I agree that GIST and QoS NSLP would be the right way to detect problem > a) (i.e., that a non QoS NSLP hop exists in the path). Good. >> In previous versions of the QSpec draft I had interpreted the >> > HOP> flag as providing the functionality necessary for (b). However, >> following further clarifications of the document I now think >> this isn't >> the case. A separate flag may, therefore, be needed. > > I'm not quite sure what is meant by problem b) above. Maybe there is > misunderstanding about the flag and how/when it is set. > The parameter is set whenever a local QOSM different from > the initiator QOSM is encountered. IMO this is useful for the QNI to > know that a QOSM is encountered in the path that is different from the > initiator QOSM (and that some parameters may have been remapped). In this case we're not talking about a different QOSM being encountered, but a node where no QOSM (no QoS NSLP, no GIST, etc) is available at all. e.g. the situation where we have: A -- B -- C A and C support QoS NSLP (and same QOSM as identified in QSpec) B doesn't have any NSIS support My interpretation of the Non QOSM Hop text in the QSpec is that it is set if (and only if) QoS NSLP is supported but the QOSM identified in the QSpec is not supported. It would not be set in the the case above where there are no QOSM 'mismatches' but a non-NSIS hop is identified. The situations are a bit different since in one case we're identifying that the QoS description has been reinterpreted, in the other we're identifying that the QoS request hasn't been processed at all. Does that make sense? regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 14 00:39:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1FSz-0005gx-Db; Fri, 14 Jul 2006 00:39:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1FSy-0005gs-1I for nsis@ietf.org; Fri, 14 Jul 2006 00:39:52 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1FSw-00081l-OE for nsis@ietf.org; Fri, 14 Jul 2006 00:39:52 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1152851961!8845204!2 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 17852 invoked from network); 14 Jul 2006 04:39:49 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-9.tower-121.messagelabs.com with SMTP; 14 Jul 2006 04:39:49 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB45200228FAB; Fri, 14 Jul 2006 00:39:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] how a non QOSm node can be detected? Date: Thu, 13 Jul 2006 23:39:46 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7AFB@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44B6E1AB.1000905@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] how a non QOSm node can be detected? Thread-Index: Acam2mHRvWgwR0YcQFmtlIAY+tmKLgAI3Qew From: "Ash, Gerald R \(Jerry\), ALABS" To: "Andrew McDonald" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: "Ash, Gerald R \(Jerry\), ALABS" , Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, Please see below.=20 > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Thursday, July 13, 2006 8:14 PM > To: Ash, Gerald R (Jerry), ALABS > Cc: Georgios Karagiannis; nsis@ietf.org > Subject: Re: [NSIS] how a non QOSm node can be detected? >=20 > Hi Jerry, >=20 > Ash, Gerald R (Jerry), ALABS wrote: > >> -----Original Message----- > >> From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > >> Sent: Thursday, July 13, 2006 9:49 AM > >> To: Georgios Karagiannis > >> Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > >> Subject: Re: [NSIS] how a non QOSm node can be detected? > >> > >> Hi Georgios, > >> > >> I've also been thinking about this one over the last few=20 > >> days. I think=20 > >> the problem is about QoS NSLP unaware hops (which includes=20 > >> GIST-unaware=20 > >> hops), rather than what is referred to in the QSpec draft as=20 > >> a "non QOSM=20 > >> hop". > >> > >> There are two parts to this problem: > >> a) identifying that a non QoS NSLP hop exists > >> b) signalling this end-to-end > >> > >> The core part of (a) is covered by GIST, by providing TTL=20 > >> information=20 > >> over the API. I'm not sure what special things (if anything)=20 > >> we need to=20 > >> do to handle tunnels. If we need something here then it=20 > >> probably needs=20 > >> to go in the QoS NSLP document. > >=20 > > I agree that GIST and QoS NSLP would be the right way to=20 > > detect problem > > a) (i.e., that a non QoS NSLP hop exists in the path). >=20 > Good. >=20 > >> In previous versions of the QSpec draft I had interpreted the=20 > >> >> HOP> flag as providing the functionality necessary for=20 > >> (b). However,=20 > >> following further clarifications of the document I now think=20 > >> this isn't=20 > >> the case. A separate flag may, therefore, be needed. > >=20 > > I'm not quite sure what is meant by problem b) above. =20 > > Maybe there is > > misunderstanding about the flag and how/when=20 > > it is set. > > The parameter is set whenever a local QOSM=20 > > different from > > the initiator QOSM is encountered. IMO this is useful for=20 > > the QNI to > > know that a QOSM is encountered in the path that is=20 > > different from the > > initiator QOSM (and that some parameters may have been remapped). =20 >=20 > In this case we're not talking about a different QOSM being=20 > encountered,=20 > but a node where no QOSM (no QoS NSLP, no GIST, etc) is=20 > available at all. >=20 > e.g. the situation where we have: > A -- B -- C > A and C support QoS NSLP (and same QOSM as identified in QSpec) > B doesn't have any NSIS support >=20 > My interpretation of the Non QOSM Hop text in the QSpec is that it is=20 > set if (and only if) QoS NSLP is supported but the QOSM identified in=20 > the QSpec is not supported.=20 Yes, exactly. > It would not be set in the case above=20 > where there are no QOSM 'mismatches' but a non-NSIS hop is identified. Agreed. Also, I'm not sure how node B could set the flag anyway, since it does not support QoS NSLP/QSPEC. So other methods of detecting this situation are need in GIST and QoS NSLP, as you point out. =20 > The situations are a bit different since in one case we're=20 > identifying=20 > that the QoS description has been reinterpreted, in the other we're=20 > identifying that the QoS request hasn't been processed at all. >=20 > Does that make sense? Yes, it makes perfect sense. Thanks, Regards, Jerry > regards, >=20 > Andrew >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 14 09:14:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NUR-0007VQ-Ro; Fri, 14 Jul 2006 09:13:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NUQ-0007V7-Vo for nsis@ietf.org; Fri, 14 Jul 2006 09:13:54 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1NRP-0003sd-0t for nsis@ietf.org; Fri, 14 Jul 2006 09:10:49 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 14 Jul 2006 16:10:46 +0300 id 00087E87.44B797D6.00006781 Date: Fri, 14 Jul 2006 16:10:17 +0300 (EEST) From: Jukka MJ Manner To: "Ash, Gerald R \\(Jerry\\), ALABS" Subject: RE: [NSIS] how a non QOSm node can be detected? In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7AFB@KCCLUST06EVS1.ugd.att.com> Message-ID: References: <9473683187ADC049A855ED2DA739ABCA0DDC7AFB@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Andrew McDonald , Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, so what does this mean for the QoS NSLP? Is there a need to change text somewhere? If so, please provide the text that is needed, and indicate the place for it. Jukka On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote: > Hi Andrew, > > Please see below. > > > -----Original Message----- > > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk] > > Sent: Thursday, July 13, 2006 8:14 PM > > To: Ash, Gerald R (Jerry), ALABS > > Cc: Georgios Karagiannis; nsis@ietf.org > > Subject: Re: [NSIS] how a non QOSm node can be detected? > > > > Hi Jerry, > > > > Ash, Gerald R (Jerry), ALABS wrote: > > >> -----Original Message----- > > >> From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk] > > >> Sent: Thursday, July 13, 2006 9:49 AM > > >> To: Georgios Karagiannis > > >> Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > >> Subject: Re: [NSIS] how a non QOSm node can be detected? > > >> > > >> Hi Georgios, > > >> > > >> I've also been thinking about this one over the last few > > >> days. I think > > >> the problem is about QoS NSLP unaware hops (which includes > > >> GIST-unaware > > >> hops), rather than what is referred to in the QSpec draft as > > >> a "non QOSM > > >> hop". > > >> > > >> There are two parts to this problem: > > >> a) identifying that a non QoS NSLP hop exists > > >> b) signalling this end-to-end > > >> > > >> The core part of (a) is covered by GIST, by providing TTL > > >> information > > >> over the API. I'm not sure what special things (if anything) > > >> we need to > > >> do to handle tunnels. If we need something here then it > > >> probably needs > > >> to go in the QoS NSLP document. > > > > > > I agree that GIST and QoS NSLP would be the right way to > > > detect problem > > > a) (i.e., that a non QoS NSLP hop exists in the path). > > > > Good. > > > > >> In previous versions of the QSpec draft I had interpreted the > > >> > >> HOP> flag as providing the functionality necessary for > > >> (b). However, > > >> following further clarifications of the document I now think > > >> this isn't > > >> the case. A separate flag may, therefore, be needed. > > > > > > I'm not quite sure what is meant by problem b) above. > > > Maybe there is > > > misunderstanding about the flag and how/when > > > it is set. > > > The parameter is set whenever a local QOSM > > > different from > > > the initiator QOSM is encountered. IMO this is useful for > > > the QNI to > > > know that a QOSM is encountered in the path that is > > > different from the > > > initiator QOSM (and that some parameters may have been remapped). > > > > In this case we're not talking about a different QOSM being > > encountered, > > but a node where no QOSM (no QoS NSLP, no GIST, etc) is > > available at all. > > > > e.g. the situation where we have: > > A -- B -- C > > A and C support QoS NSLP (and same QOSM as identified in QSpec) > > B doesn't have any NSIS support > > > > My interpretation of the Non QOSM Hop text in the QSpec is that it is > > set if (and only if) QoS NSLP is supported but the QOSM identified in > > the QSpec is not supported. > > Yes, exactly. > > > It would not be set in the case above > > where there are no QOSM 'mismatches' but a non-NSIS hop is identified. > > Agreed. Also, I'm not sure how node B could set the flag > anyway, since it does not support QoS NSLP/QSPEC. So other methods of > detecting this situation are need in GIST and QoS NSLP, as you point > out. > > > The situations are a bit different since in one case we're > > identifying > > that the QoS description has been reinterpreted, in the other we're > > identifying that the QoS request hasn't been processed at all. > > > > Does that make sense? > > Yes, it makes perfect sense. > > Thanks, > Regards, > Jerry > > > regards, > > > > Andrew > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 14 09:22:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Nd3-000094-Nw; Fri, 14 Jul 2006 09:22:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Nd1-00008p-Qp for nsis@ietf.org; Fri, 14 Jul 2006 09:22:47 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Ncz-0004yk-0U for nsis@ietf.org; Fri, 14 Jul 2006 09:22:47 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6EDMUmF009735; Fri, 14 Jul 2006 14:22:34 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 14:22:30 +0100 Message-ID: <44B79A97.3030407@roke.co.uk> Date: Fri, 14 Jul 2006 14:22:31 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] how a non QOSm node can be detected? References: <9473683187ADC049A855ED2DA739ABCA0DDC7AFB@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7AFB@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2006 13:22:30.0303 (UTC) FILETIME=[8EDDEAF0:01C6A748] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Ash, Gerald R (Jerry), ALABS wrote: >> In this case we're not talking about a different QOSM being >> encountered, >> but a node where no QOSM (no QoS NSLP, no GIST, etc) is >> available at all. >> >> e.g. the situation where we have: >> A -- B -- C >> A and C support QoS NSLP (and same QOSM as identified in QSpec) >> B doesn't have any NSIS support >> >> My interpretation of the Non QOSM Hop text in the QSpec is that it is >> set if (and only if) QoS NSLP is supported but the QOSM identified in >> the QSpec is not supported. > > Yes, exactly. > >> It would not be set in the case above >> where there are no QOSM 'mismatches' but a non-NSIS hop is identified. > > Agreed. Also, I'm not sure how node B could set the flag > anyway, since it does not support QoS NSLP/QSPEC. So other methods of > detecting this situation are need in GIST and QoS NSLP, as you point > out. Ah, I see the possible confusion. I'm not expecting B to set a flag - I'm expecting C to do it. Information is available at C from the GIST layer about the number of IP hops between A and C. C can use this to determine that it is not adjacent to B and so set a flag. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 14 12:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QGe-0007IW-Fi; Fri, 14 Jul 2006 12:11:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QGd-0007IH-TG for nsis@ietf.org; Fri, 14 Jul 2006 12:11:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1PVH-0006co-LY for nsis@ietf.org; Fri, 14 Jul 2006 11:22:55 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1OzY-0007Xc-B8 for nsis@ietf.org; Fri, 14 Jul 2006 10:50:11 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6EEo0HP011824; Fri, 14 Jul 2006 16:50:00 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6EEo0vb013613; Fri, 14 Jul 2006 16:50:00 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6EEo0l22064; Fri, 14 Jul 2006 16:50:00 +0200 (MEST) Date: Fri, 14 Jul 2006 16:50:00 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: andrew.mcdonald@roke.co.uk, gash@att.com Subject: Re: [NSIS] how a non QOSm node can be detected? Received: from 132.219.24.237 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 14 Jul 2006 14:49:58 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <44B79A97.3030407@roke.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.722 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 14 Jul 2006 16:50:01 +0200 (MEST) X-Spam-Score: -2.6 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew and Jerry Yes, I agree with Andrew's opinion on this. Therefore, I think that the best way is to leave the definition of as is defined now and then define a new flag in the QSepc template or QoS-NSLP to emphasize when a node in the path did not process the QOS-NSLP/QOSM information. Best Regards, Georgios On 7/14/2006, "Andrew McDonald" wrote: >Hi Jerry, > >Ash, Gerald R (Jerry), ALABS wrote: >>> In this case we're not talking about a different QOSM being >>> encountered, >>> but a node where no QOSM (no QoS NSLP, no GIST, etc) is >>> available at all. >>> >>> e.g. the situation where we have: >>> A -- B -- C >>> A and C support QoS NSLP (and same QOSM as identified in QSpec) >>> B doesn't have any NSIS support >>> >>> My interpretation of the Non QOSM Hop text in the QSpec is that it is >>> set if (and only if) QoS NSLP is supported but the QOSM identified in >>> the QSpec is not supported. >> >> Yes, exactly. >> >>> It would not be set in the case above >>> where there are no QOSM 'mismatches' but a non-NSIS hop is identified. >> >> Agreed. Also, I'm not sure how node B could set the flag >> anyway, since it does not support QoS NSLP/QSPEC. So other methods of >> detecting this situation are need in GIST and QoS NSLP, as you point >> out. > >Ah, I see the possible confusion. I'm not expecting B to set a flag - >I'm expecting C to do it. > >Information is available at C from the GIST layer about the number of IP >hops between A and C. C can use this to determine that it is not >adjacent to B and so set a flag. > >regards, > >Andrew > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 14 14:19:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SFn-0006iF-BE; Fri, 14 Jul 2006 14:19:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SFl-0006iA-Kz for nsis@ietf.org; Fri, 14 Jul 2006 14:19:05 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1SFk-0007kr-0L for nsis@ietf.org; Fri, 14 Jul 2006 14:19:05 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6EIIqer022392 for ; Fri, 14 Jul 2006 19:18:56 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 19:18:52 +0100 From: "Robert Hancock" To: "'NSIS'" Date: Fri, 14 Jul 2006 14:18:49 -0400 Message-ID: <018601c6a771$f4ae6250$f803db84@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-OriginalArrivalTime: 14 Jul 2006 18:18:52.0616 (UTC) FILETIME=[F5F38C80:01C6A771] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [NSIS] backoff, rate limiting and other parameters X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, at the session on Wednesday, there was some discussion about the various parameters for rate limiting, backoff during the handshake process, and other timers. i'm summarising the proposed v10 text here in case people = want to comment: in section 4.4.3 for routing state refresh time (also probe frequency in 7.1.2): "Each item of routing state expires after a lifetime which is negotiated during the Query/Response/Confirm handshake. The Network Layer Info (NLI) object in the Query contains a proposal for the lifetime value, and the NLI in the Response contains the value the Responding node requires. A default timer value of 30 seconds is RECOMMENDED. Nodes which can exploit alternative, more powerful, route change detection methods such as those described in Section 7.1.2 MAY choose to use much longer times. Nodes MAY use shorter times to provide more rapid change detection, but MUST take into account the fact that the Query messages generated may stress the rate limits applied to D-mode traffic (Section 5.3.3)." in section 4.4.3 for the default time to hold an unused MA open: "During messaging association setup, each node indicates its own MA-Hold- Time as part of the Stack-Configuration-Data. A node MUST NOT tear down the association if it has received traffic from its peer over that period. A peer which has generated no traffic but still wants the association retained may use a special null message (GIST-MA-Hello) to indicate the fact. A default value for MA- Hold-Time of 30 seconds is RECOMMENDED. Nodes MAY use shorter times to achieve more rapid peer failure detection, but need to take into account the load on the network created by the Hello messages. Nodes MAY use longer times, but need to take into account the cost of retaining idle connections for extended periods." in section 5.3.3 for the backoff during Query handshakes: "Query messages which do not receive Responses MAY be retransmitted; retransmissions MUST use a binary exponential backoff. The initial timer value is T1, which the backoff process can increase up to a maximum value of T2 seconds. The default value for T1 is 500 ms. T1 is an estimate of the RTT between the querying and responding nodes. Elements MAY use smaller values of T1 if it is known that the Query should be answered within the local network. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high latency access links) that the RTT is larger. A default value of T2 is 64*T1. Note that Queries may go unanswered either because of message loss (in either direction), or because there is no reachable GIST peer. Therefore, implementations MAY trade off reliability (large T2) against promptness of error feedback to applications (small T2). If the NSLP has indicated a timeout on the validity of this payload (see Appendix B.1), T2 MUST be chosen to be less than this value." in section 5.3.3 for rate limiting: "The basic rate-control requirements for D-mode traffic are deliberately minimal. A single rate limiter applies to all traffic, for all interfaces and message types. It applies to retransmissions as well as new messages, although an implementation MAY choose to prioritise one over the other. Rate-control applies only to locally generated D-mode messages, not to messages which are being forwarded. When the rate limiter is in effect, D-mode messages MUST be queued until transmission is re-enabled, or an error condition MAY be indicated back to local signaling applications. The rate limiting mechanism is implementation-defined, but it is RECOMMENDED that a token bucket limiter as described in [31] be used. The token bucket should be sized to ensure that a node cannot saturate the network with D-mode traffic, for example when re-probing the network for multiple flows after a route change. A suitable approach is to restrict the token bucket parameters so that the mean output rate is a small fraction of the nodes lowest-speed interface, such as 5%." cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 15 13:35:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1o2k-0001eg-BX; Sat, 15 Jul 2006 13:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1o2j-0001eb-Kn for nsis@ietf.org; Sat, 15 Jul 2006 13:35:05 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1o2h-0005rt-5d for nsis@ietf.org; Sat, 15 Jul 2006 13:35:05 -0400 Received: from [192.168.178.200] (p54849D3B.dip0.t-ipconnect.de [84.132.157.59]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k6FHYstQ005236; Sat, 15 Jul 2006 19:34:54 +0200 (MEST) Message-ID: <44B92696.2090008@cs.uni-goettingen.de> Date: Sat, 15 Jul 2006 19:32:06 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Any resolution to the QSPEC mandatory parameter list? References: <9473683187ADC049A855ED2DA739ABCA0DDC7AF0@KCCLUST06EVS1.ugd.att.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: "Ash, Gerald R \\\(Jerry\\\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, it would be easier to define new QOSMs, when the mapping of mandatory parameters is listed in a central draft. This would also ensure interoperability. Bernd Jukka MJ Manner wrote: > Hi, > > I think the problem is that setting too many mandatory parameters > effectively limits people to define new QOSMs (even the current ones) - > all QOSMs must be based on IntServ or DiffServ. Interworking is an > important issue, I fully agree. That is why I'm not sure which way we > should actually go: more or less mandatory parameters. (I think I'm > inclined towards more flexibility) > > About the need for a change, I haven't seen any comment so far for keeping > the longish list of mandatory parameters. All messages have been about > introducing more flexibility. We should have had a hummm at the meeting to > see what people would want. > > Maybe people could speak up about what they want? > > Jukka > > On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote: > > >>Hi Jukka, >> >>See below. >> >> >>>-----Original Message----- >>>From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >>>Sent: Thursday, July 13, 2006 10:19 AM >>>To: nsis@ietf.org >>>Subject: [NSIS] Any resolution to the QSPEC mandatory parameter list? >>> >>> >>>I think the discussion on the mandatory and optional parameters ended >>>without a clear resolution. I think there were good notes on >>>making the >>>list of mandatory parameters shorter and/or allow an "ignore" >>>interpretation of a mandatory parameter, and other ways to make the >>>template less strict. I also support these comments. >>> >>>Any views from the QSPEC people on how to resolve these comments? >> >>I'm not in favor of fundamentally changing the definition of mandatory >>and optional QSPEC parameters, as I think is being proposed. In effect, >>to allow a mandatory parameter to be ignored would eliminate the >>distinction between mandatory parameters (MUST interpret if populated) >>and optional parameters (SHOULD interpret if populated). The original >>idea of the QSPEC template is to provide a common set of mandatory >>parameters that would be interpreted (if populated by the QNI) by all >>QOSMs. This would allow a degree of interoperability. The set of >>mandatory parameters is based in part on parameters from the INTSERV and >>DIFFSERV models that should be commonly interpreted by all QOSMs (that >>was the original charge to the QSPEC template draft approach). >> >>The other alternative (i.e., to be able to 'ignore' mandatory >>parameters) is essentially to make all parameters optional parameters >>(SHOULD interpret if populated). Optional parameters allow the N-flag >>(not supported flag) to be set if a QOSM wishes to 'ignore' (not >>interpret) a parameter. >> >>I'm not clear on the motivation for this other alternative. Perhaps >>some particular QOSM wants to introduce the possibility of 'ignoring' >>mandatory parameters. Y.1541-QOSM doesn't require this nor does the >>CL-QOSM (AFAIK). Perhaps the RMD-QOSM for some reason requires this -- >>if so, I'm not clear what is the justification? >> >>I haven't seen that much support for a major change in the QSPEC >>template approach to be able to 'ignore' mandatory parameters. >> >>Thanks, >>Jerry >> >> >>>Regards, >>>Jukka >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 15 13:58:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1oOv-00036K-Cm; Sat, 15 Jul 2006 13:58:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1oOu-00036F-KE for nsis@ietf.org; Sat, 15 Jul 2006 13:58:00 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1oOu-0007kB-5W for nsis@ietf.org; Sat, 15 Jul 2006 13:58:00 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6FHvixu024262; Sat, 15 Jul 2006 19:57:47 +0200 (MEST) From: "Georgios Karagiannis" To: "'Bernd Schloer'" , "'Jukka MJ Manner'" Subject: RE: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Sat, 15 Jul 2006 19:57:46 +0200 Message-ID: <000401c6a838$2df6c5e0$4c0d5982@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaoNSJeZwMm/sULQwWDwVHSfFS3zgAAvfGQ In-Reply-To: <44B92696.2090008@cs.uni-goettingen.de> X-Spam-Score: -5.533 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Sat, 15 Jul 2006 19:57:49 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: "'Ash, Gerald R \\\(Jerry\\\), ALABS'" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Okay, but how many mandatory parameters should the central draft contain? Best Regards, Georgios -----Original Message----- From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] Sent: zaterdag 15 juli 2006 19:32 To: Jukka MJ Manner Cc: Ash, Gerald R \(Jerry\), ALABS; nsis@ietf.org Subject: Re: [NSIS] Any resolution to the QSPEC mandatory parameter list? Hi, it would be easier to define new QOSMs, when the mapping of mandatory parameters is listed in a central draft. This would also ensure interoperability. Bernd Jukka MJ Manner wrote: > Hi, > > I think the problem is that setting too many mandatory parameters > effectively limits people to define new QOSMs (even the current ones) > - all QOSMs must be based on IntServ or DiffServ. Interworking is an > important issue, I fully agree. That is why I'm not sure which way we > should actually go: more or less mandatory parameters. (I think I'm > inclined towards more flexibility) > > About the need for a change, I haven't seen any comment so far for > keeping the longish list of mandatory parameters. All messages have > been about introducing more flexibility. We should have had a hummm at > the meeting to see what people would want. > > Maybe people could speak up about what they want? > > Jukka > > On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote: > > >>Hi Jukka, >> >>See below. >> >> >>>-----Original Message----- >>>From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >>>Sent: Thursday, July 13, 2006 10:19 AM >>>To: nsis@ietf.org >>>Subject: [NSIS] Any resolution to the QSPEC mandatory parameter list? >>> >>> >>>I think the discussion on the mandatory and optional parameters ended >>>without a clear resolution. I think there were good notes on making >>>the list of mandatory parameters shorter and/or allow an "ignore" >>>interpretation of a mandatory parameter, and other ways to make the >>>template less strict. I also support these comments. >>> >>>Any views from the QSPEC people on how to resolve these comments? >> >>I'm not in favor of fundamentally changing the definition of mandatory >>and optional QSPEC parameters, as I think is being proposed. In >>effect, to allow a mandatory parameter to be ignored would eliminate >>the distinction between mandatory parameters (MUST interpret if >>populated) and optional parameters (SHOULD interpret if populated). >>The original idea of the QSPEC template is to provide a common set of >>mandatory parameters that would be interpreted (if populated by the >>QNI) by all QOSMs. This would allow a degree of interoperability. >>The set of mandatory parameters is based in part on parameters from >>the INTSERV and DIFFSERV models that should be commonly interpreted by >>all QOSMs (that was the original charge to the QSPEC template draft approach). >> >>The other alternative (i.e., to be able to 'ignore' mandatory >>parameters) is essentially to make all parameters optional parameters >>(SHOULD interpret if populated). Optional parameters allow the N-flag >>(not supported flag) to be set if a QOSM wishes to 'ignore' (not >>interpret) a parameter. >> >>I'm not clear on the motivation for this other alternative. Perhaps >>some particular QOSM wants to introduce the possibility of 'ignoring' >>mandatory parameters. Y.1541-QOSM doesn't require this nor does the >>CL-QOSM (AFAIK). Perhaps the RMD-QOSM for some reason requires this >>-- if so, I'm not clear what is the justification? >> >>I haven't seen that much support for a major change in the QSPEC >>template approach to be able to 'ignore' mandatory parameters. >> >>Thanks, >>Jerry >> >> >>>Regards, >>>Jukka >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 16 17:45:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2EPa-00034X-3O; Sun, 16 Jul 2006 17:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2EPZ-00034S-2z for nsis@ietf.org; Sun, 16 Jul 2006 17:44:25 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2EPX-0004cJ-PK for nsis@ietf.org; Sun, 16 Jul 2006 17:44:25 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 17 Jul 2006 00:44:20 +0300 id 00087D93.44BAB334.000054CF Date: Mon, 17 Jul 2006 00:43:57 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [NSIS] Proposal for implementing QoS NSLP Proxy Mode X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org We had a good discussion with Robert about the QoS NSLP Proxy mode, and at the end we agreed that the QoS NSLP does not really need much. Actually, we only need a new scope (besides single link and e2e) called e.g. "proxy", and the domain admin must define manually, which QNE operates as proxy (Proxy-QNE, P-QNE). Here is how the fing works: [End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver or sender] For outgoing flows, the end host is the QNI, and sends a RESERVE with the new proxy-scope bit set. The P-QNE will receive the RESERVE and reply with a RESPONSE (if requested), and NOT forward the RESERVE further to the next peer. The receiver-oriented reservation works the same way (QUERY towards P-QNE, RESERVE back, then RESPONSE to P-QNE, all carrying the proxy-scope bit). For incoming flows, the end host is also the QNI, and it sends a RESERVE towards the data sender with the proxy-scope bit set. Here the end host sets the MRI so that it indicates the end host as the receiver of the data, and the D-flag is set. If there is only one P-QNE in the domain, GIST gets the RESERVE to the P-QNE. If there are more than one P-QNEs, GIST will do its best, but may reply with an error indicating destination unreachable. Jukka ps. I'll be out of emails for a couple of weeks now. I intend to finalize the QoS NSLP draft in August and we can then send it for AD review. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 17 05:06:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2P3Z-00009u-Qm; Mon, 17 Jul 2006 05:06:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2P3Z-00009p-8X for nsis@ietf.org; Mon, 17 Jul 2006 05:06:25 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2P3X-0000ap-M5 for nsis@ietf.org; Mon, 17 Jul 2006 05:06:25 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k6H96MUH029474; Mon, 17 Jul 2006 11:06:22 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id k6H96LND007261; Mon, 17 Jul 2006 11:06:22 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 11:06:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] REA Naming Contest (reanco) Date: Mon, 17 Jul 2006 11:06:19 +0200 Message-ID: <69D2C30BFA177E4DB3E6C93A94C87F1F958097@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] REA Naming Contest (reanco) thread-index: AcamgU0TgqLqoBcMRseywRGNAfvQIAC/qqxw From: "Pashalidis, Andreas" To: "Martin Stiemerling" , "nsis" X-OriginalArrivalTime: 17 Jul 2006 09:06:21.0826 (UTC) FILETIME=[45C7AE20:01C6A980] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, A few ideas for replace "REA". Open Internal Path (OIP) message <-- my favourite Configure Internal Path (CIP) message Prepare For Ucreate (PFU) message (I am not sure that the message that opens nat binding is actually called "Ucreate". If not, replace "Ucreate" with that message name) Internal Network Configuration (INC) message That's all for now... :) Andreas ________________________________ From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 Sent: Donnerstag, 13. Juli 2006 15:35 To: nsis Subject: Fwd: [NSIS] REA Naming Contest (reanco) Forgot one thing: =20 The name suggestions will be discussed by the NSIS WG and the WG will vote on the suggestions to find the new name.=20 =20 Martin Anfang der weitergeleiteten E-Mail: Von: Martin Stiemerling Datum: 13. Juli 2006 09:32:52 GMT-04:00 An: nsis Betreff: [NSIS] REA Naming Contest (reanco) Dear All, We have discussed about the naming issues for the NATFW NSLP's RESERVE-EXTERNAL-ADDRESS (REA) message. In the past revisions of the NATFW NSLP REA has been used to obtain an external IP address/port at the outermost NAT (and at in between NATs too). But the semantics of REA changed over time from purely NAT usage to a combined NAT and firewall usage, i.e., a combination of the old REA and the old UCREATE. REA is used for: - Used to get external address/port at NAT - Used to install firewall rules for inbound traffic - Used in proxy mode usage So the current name is not really describing the semantics/usage anymore and we need to something different. Since the authors haven't had any good idea and some off-line discussions didn't bring a good name, we are starting the REA naming contest (reanco) This contest calls the NSIS WG for input on name suggestions for the message currently called REA. The contest starts today (actually already yesterday during the session) and will run until August 3rd 8am EST. Suggestion made after August 3rd EST are not accepted anymore. All suggestions must be sent to the NSIS working group list (nsis@ietf.org). It is not valid to use a naming generator that simply tries combinations of characters. The one who has suggested the name that will be finally taken as the new name for REA will be awarded with a six-pack of local beer at next IETF in San Diego. If there are multiple people suggesting the same name, they must share the six pack (sorry for that, but not enough money for it ;-) Of course all things apply here: participants must be older than 18 or 21 years (depending on location of IETF and the local laws), no guarantees, not entitled for anything, must be at the next IETF meeting in San Diego in November 2006, no monetary refunding, etc... So, looking forward to many suggestion for a "new REA". Martin for the NATFW NSLP authors. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 17 06:24:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2QHT-0003Ja-BL; Mon, 17 Jul 2006 06:24:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2QHS-0003J8-3p for nsis@ietf.org; Mon, 17 Jul 2006 06:24:50 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2QFZ-0000ad-D8 for nsis@ietf.org; Mon, 17 Jul 2006 06:22:54 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6HAMheD022159; Mon, 17 Jul 2006 12:22:43 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6HAMhvb021989; Mon, 17 Jul 2006 12:22:43 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6HAMd823050; Mon, 17 Jul 2006 12:22:39 +0200 (MEST) Date: Mon, 17 Jul 2006 12:22:39 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: jmanner@cs.Helsinki.FI, nsis@ietf.org Subject: Re: [NSIS] Proposal for implementing QoS NSLP Proxy Mode Received: from 83.236.152.202 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 17 Jul 2006 10:22:37 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.899 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 17 Jul 2006 12:22:48 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka Great! I think that the use of the QoS-NSLP proxy mode is useful and the additional complexity introduced in the QoS-NSLP by this mode is not big. Therefore, I agree to include it in the QoS-NSLP draft. Best regards, Georgios On 7/16/2006, "Jukka MJ Manner" wrote: > >We had a good discussion with Robert about the QoS NSLP Proxy mode, and at >the end we agreed that the QoS NSLP does not really need much. Actually, >we only need a new scope (besides single link and e2e) called e.g. >"proxy", and the domain admin must define manually, which QNE operates as >proxy (Proxy-QNE, P-QNE). Here is how the fing works: > >[End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver or sender] > >For outgoing flows, the end host is the QNI, and sends a RESERVE with the >new proxy-scope bit set. The P-QNE will receive the RESERVE and reply with >a RESPONSE (if requested), and NOT forward the RESERVE further to the next >peer. The receiver-oriented reservation works the same way (QUERY towards >P-QNE, RESERVE back, then RESPONSE to P-QNE, all carrying the proxy-scope >bit). > >For incoming flows, the end host is also the QNI, and it sends a RESERVE >towards the data sender with the proxy-scope bit set. Here the end host >sets the MRI so that it indicates the end host as the receiver of the >data, and the D-flag is set. If there is only one P-QNE in the domain, >GIST gets the RESERVE to the P-QNE. If there are more than one P-QNEs, >GIST will do its best, but may reply with an error indicating destination >unreachable. > >Jukka > >ps. I'll be out of emails for a couple of weeks now. I intend to finalize >the QoS NSLP draft in August and we can then send it for AD review. > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 17 06:33:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2QQD-0000Kp-Sc; Mon, 17 Jul 2006 06:33:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2QQC-0000Kk-QA for nsis@ietf.org; Mon, 17 Jul 2006 06:33:52 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2QQB-00026N-Du for nsis@ietf.org; Mon, 17 Jul 2006 06:33:52 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6HAXmn6022715 for ; Mon, 17 Jul 2006 12:33:48 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6HAXmvb022996 for ; Mon, 17 Jul 2006 12:33:48 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6HAXmZ24889; Mon, 17 Jul 2006 12:33:48 +0200 (MEST) Date: Mon, 17 Jul 2006 12:33:48 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nsis@ietf.org Received: from 83.236.152.202 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 17 Jul 2006 10:33:46 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <44B79A97.3030407@roke.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.199 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 17 Jul 2006 12:33:49 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [NSIS] agreement on QSPEC template draft? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all If we include an additional flag into the QOS-NSLP draft to show that a non QoS-NSLP Hop, say "Non QoS-NSLP Hop", has been passed during the end-to-end path followed by a RESERVE, then regarding the QSpec template, I agree to: * add the R bit flag proposed by Jerry, where each parameter will carry such a flag and it will be used in the situation that a parameter, mandatory or optional is downgraded. * use the "Non QOSM Hop" flag as currently used! * use the T flag as currently used * use of N flag as currently used * use of E flag as currently used * try to use as less as possible mandatory parameters Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 17 08:13:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Ryt-0006rs-Ky; Mon, 17 Jul 2006 08:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Rys-0006rn-1J for nsis@ietf.org; Mon, 17 Jul 2006 08:13:46 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Ryq-0004EW-El for nsis@ietf.org; Mon, 17 Jul 2006 08:13:46 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id k6HCDQWJ004886; Mon, 17 Jul 2006 14:13:26 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id k6HCDPJd030967; Mon, 17 Jul 2006 14:13:25 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 14:13:26 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Mon, 17 Jul 2006 14:12:24 +0200 Message-ID: In-Reply-To: <000401c6a838$2df6c5e0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: AcaoNSJeZwMm/sULQwWDwVHSfFS3zgAAvfGQAFhcShA= From: "Kappler, Cornelia" To: "Georgios Karagiannis" , "Bernd Schloer" , "Jukka MJ Manner" X-OriginalArrivalTime: 17 Jul 2006 12:13:26.0150 (UTC) FILETIME=[67FF9A60:01C6A99A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: "Ash, Gerald R \\\(Jerry\\\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all,=20 I've been off-list for the last 10 days and may have difficulties = grasping the real point of the debate.=20 I'd prefer some concrete suggestions to which parameters should not be = mandatory. Rather than blanket statements "List is too long" or "List is = too short" or "we should have N parameters".=20 The question is not really whether it should be 2 or 8 or 20 mandatory = parameters. It is _which_ parameters are necessary to _just_ accomodate = the key ideas of typical QOSMs.=20 Cornelia > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Gesendet: Samstag, 15. Juli 2006 19:58 > An: 'Bernd Schloer'; 'Jukka MJ Manner' > Cc: 'Ash, Gerald R \(Jerry\), ALABS'; nsis@ietf.org > Betreff: RE: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 > Hi=20 >=20 > Okay, but how many mandatory parameters should the central=20 > draft contain? >=20 > Best Regards, > Georgios=20 >=20 > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 > Sent: zaterdag 15 juli 2006 19:32 > To: Jukka MJ Manner > Cc: Ash, Gerald R \(Jerry\), ALABS; nsis@ietf.org > Subject: Re: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 > Hi, >=20 > it would be easier to define new QOSMs, when the mapping of mandatory > parameters is listed in a central draft. This would also ensure > interoperability. >=20 > Bernd >=20 >=20 > Jukka MJ Manner wrote: > > Hi, > >=20 > > I think the problem is that setting too many mandatory parameters=20 > > effectively limits people to define new QOSMs (even the=20 > current ones)=20 > > - all QOSMs must be based on IntServ or DiffServ.=20 > Interworking is an=20 > > important issue, I fully agree. That is why I'm not sure=20 > which way we=20 > > should actually go: more or less mandatory parameters. (I think I'm=20 > > inclined towards more flexibility) > >=20 > > About the need for a change, I haven't seen any comment so far for=20 > > keeping the longish list of mandatory parameters. All messages have=20 > > been about introducing more flexibility. We should have had=20 > a hummm at=20 > > the meeting to see what people would want. > >=20 > > Maybe people could speak up about what they want? > >=20 > > Jukka > >=20 > > On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote: > >=20 > >=20 > >>Hi Jukka, > >> > >>See below.=20 > >> > >> > >>>-----Original Message----- > >>>From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >>>Sent: Thursday, July 13, 2006 10:19 AM > >>>To: nsis@ietf.org > >>>Subject: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? > >>> > >>> > >>>I think the discussion on the mandatory and optional=20 > parameters ended=20 > >>>without a clear resolution. I think there were good notes=20 > on making=20 > >>>the list of mandatory parameters shorter and/or allow an "ignore" > >>>interpretation of a mandatory parameter, and other ways to=20 > make the=20 > >>>template less strict. I also support these comments. > >>> > >>>Any views from the QSPEC people on how to resolve these comments? > >> > >>I'm not in favor of fundamentally changing the definition=20 > of mandatory=20 > >>and optional QSPEC parameters, as I think is being proposed. In=20 > >>effect, to allow a mandatory parameter to be ignored would=20 > eliminate=20 > >>the distinction between mandatory parameters (MUST interpret if=20 > >>populated) and optional parameters (SHOULD interpret if=20 > populated). =20 > >>The original idea of the QSPEC template is to provide a=20 > common set of=20 > >>mandatory parameters that would be interpreted (if populated by the=20 > >>QNI) by all QOSMs. This would allow a degree of interoperability. =20 > >>The set of mandatory parameters is based in part on parameters from=20 > >>the INTSERV and DIFFSERV models that should be commonly=20 > interpreted by=20 > >>all QOSMs (that was the original charge to the QSPEC template draft > approach). > >> > >>The other alternative (i.e., to be able to 'ignore' mandatory > >>parameters) is essentially to make all parameters optional=20 > parameters=20 > >>(SHOULD interpret if populated). Optional parameters allow=20 > the N-flag=20 > >>(not supported flag) to be set if a QOSM wishes to 'ignore' (not > >>interpret) a parameter. =20 > >> > >>I'm not clear on the motivation for this other alternative.=20 > Perhaps=20 > >>some particular QOSM wants to introduce the possibility of=20 > 'ignoring' > >>mandatory parameters. Y.1541-QOSM doesn't require this nor=20 > does the=20 > >>CL-QOSM (AFAIK). Perhaps the RMD-QOSM for some reason=20 > requires this=20 > >>-- if so, I'm not clear what is the justification? > >> > >>I haven't seen that much support for a major change in the QSPEC=20 > >>template approach to be able to 'ignore' mandatory parameters. > >> > >>Thanks, > >>Jerry > >> > >> > >>>Regards, > >>>Jukka > >>> > >>>_______________________________________________ > >>>nsis mailing list > >>>nsis@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/nsis > >>> > >> > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 17 09:08:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2SpN-0007si-HI; Mon, 17 Jul 2006 09:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2SpL-0007rq-GK for nsis@ietf.org; Mon, 17 Jul 2006 09:07:59 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2SpK-00065Y-Rm for nsis@ietf.org; Mon, 17 Jul 2006 09:07:59 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6HD7iv0000602; Mon, 17 Jul 2006 15:07:44 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6HD7ivb011271; Mon, 17 Jul 2006 15:07:44 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6HD7il10317; Mon, 17 Jul 2006 15:07:44 +0200 (MEST) Date: Mon, 17 Jul 2006 15:07:44 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: cornelia.kappler@siemens.com, bschloer@cs.uni-goettingen.de, jmanner@cs.Helsinki.FI Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Received: from 83.236.152.206 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 17 Jul 2006 13:07:42 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.13 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, MIME_QP_LONG_LINE X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 17 Jul 2006 15:07:47 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: "Ash, Gerald R \(Jerry\), ALABS" , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cornelia >From my point of view the only mandatory parameters are the Traffic specification parameters i.e., , and the "Non QoSM Hop", assuming that the QoS-NSLP will include the "non QoS-NSLP Hop" parameter, see my previous e-mail on this! Best regards, Georgios On 7/17/2006, "Kappler, Cornelia" wrote: >Dear all, > >I've been off-list for the last 10 days and may have difficulties grasping t= he real point of the debate. > >I'd prefer some concrete suggestions to which parameters should not be manda= tory. Rather than blanket statements "List is too long" or "List is too short= " or "we should have N parameters". > >The question is not really whether it should be 2 or 8 or 20 mandatory param= eters. It is _which_ parameters are necessary to _just_ accomodate the key id= eas of typical QOSMs. > >Cornelia > >> -----Urspr=FCngliche Nachricht----- >> Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Gesendet: Samstag, 15. Juli 2006 19:58 >> An: 'Bernd Schloer'; 'Jukka MJ Manner' >> Cc: 'Ash, Gerald R \(Jerry\), ALABS'; nsis@ietf.org >> Betreff: RE: [NSIS] Any resolution to the QSPEC mandatory >> parameter list? >> >> Hi >> >> Okay, but how many mandatory parameters should the central >> draft contain? >> >> Best Regards, >> Georgios >> >> -----Original Message----- >> From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] >> Sent: zaterdag 15 juli 2006 19:32 >> To: Jukka MJ Manner >> Cc: Ash, Gerald R \(Jerry\), ALABS; nsis@ietf.org >> Subject: Re: [NSIS] Any resolution to the QSPEC mandatory >> parameter list? >> >> Hi, >> >> it would be easier to define new QOSMs, when the mapping of mandatory >> parameters is listed in a central draft. This would also ensure >> interoperability. >> >> Bernd >> >> >> Jukka MJ Manner wrote: >> > Hi, >> > >> > I think the problem is that setting too many mandatory parameters >> > effectively limits people to define new QOSMs (even the >> current ones) >> > - all QOSMs must be based on IntServ or DiffServ. >> Interworking is an >> > important issue, I fully agree. That is why I'm not sure >> which way we >> > should actually go: more or less mandatory parameters. (I think I'm >> > inclined towards more flexibility) >> > >> > About the need for a change, I haven't seen any comment so far for >> > keeping the longish list of mandatory parameters. All messages have >> > been about introducing more flexibility. We should have had >> a hummm at >> > the meeting to see what people would want. >> > >> > Maybe people could speak up about what they want? >> > >> > Jukka >> > >> > On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote: >> > >> > >> >>Hi Jukka, >> >> >> >>See below. >> >> >> >> >> >>>-----Original Message----- >> >>>From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >> >>>Sent: Thursday, July 13, 2006 10:19 AM >> >>>To: nsis@ietf.org >> >>>Subject: [NSIS] Any resolution to the QSPEC mandatory >> parameter list? >> >>> >> >>> >> >>>I think the discussion on the mandatory and optional >> parameters ended >> >>>without a clear resolution. I think there were good notes >> on making >> >>>the list of mandatory parameters shorter and/or allow an "ignore" >> >>>interpretation of a mandatory parameter, and other ways to >> make the >> >>>template less strict. I also support these comments. >> >>> >> >>>Any views from the QSPEC people on how to resolve these comments? >> >> >> >>I'm not in favor of fundamentally changing the definition >> of mandatory >> >>and optional QSPEC parameters, as I think is being proposed. In >> >>effect, to allow a mandatory parameter to be ignored would >> eliminate >> >>the distinction between mandatory parameters (MUST interpret if >> >>populated) and optional parameters (SHOULD interpret if >> populated). >> >>The original idea of the QSPEC template is to provide a >> common set of >> >>mandatory parameters that would be interpreted (if populated by the >> >>QNI) by all QOSMs. This would allow a degree of interoperability. >> >>The set of mandatory parameters is based in part on parameters from >> >>the INTSERV and DIFFSERV models that should be commonly >> interpreted by >> >>all QOSMs (that was the original charge to the QSPEC template draft >> approach). >> >> >> >>The other alternative (i.e., to be able to 'ignore' mandatory >> >>parameters) is essentially to make all parameters optional >> parameters >> >>(SHOULD interpret if populated). Optional parameters allow >> the N-flag >> >>(not supported flag) to be set if a QOSM wishes to 'ignore' (not >> >>interpret) a parameter. >> >> >> >>I'm not clear on the motivation for this other alternative. >> Perhaps >> >>some particular QOSM wants to introduce the possibility of >> 'ignoring' >> >>mandatory parameters. Y.1541-QOSM doesn't require this nor >> does the >> >>CL-QOSM (AFAIK). Perhaps the RMD-QOSM for some reason >> requires this >> >>-- if so, I'm not clear what is the justification? >> >> >> >>I haven't seen that much support for a major change in the QSPEC >> >>template approach to be able to 'ignore' mandatory parameters. >> >> >> >>Thanks, >> >>Jerry >> >> >> >> >> >>>Regards, >> >>>Jukka >> >>> >> >>>_______________________________________________ >> >>>nsis mailing list >> >>>nsis@ietf.org >> >>>https://www1.ietf.org/mailman/listinfo/nsis >> >>> >> >> >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 17 10:21:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2TyY-0003Xg-Rg; Mon, 17 Jul 2006 10:21:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2TyX-0003Xb-Ar for nsis@ietf.org; Mon, 17 Jul 2006 10:21:33 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2TyV-0001Tp-0A for nsis@ietf.org; Mon, 17 Jul 2006 10:21:33 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 17 Jul 2006 10:21:23 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006071710212217257 ; Mon, 17 Jul 2006 10:21:22 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Jul 2006 10:21:22 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230E44@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: "Pashalidis, Andreas" , Martin Stiemerling Subject: RE: [NSIS] REA Naming Contest (reanco) Date: Mon, 17 Jul 2006 10:21:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andreas, Martin, and all: Also, here are a couple of suggestions: 1. Open Path Interactive (OPI) message 2. Open Interactive Path (OIP) message 3. Path Opening Interactive (POI) message 4. Interactive Path Opening (IPO) message Note: The word "interactive" has been emphasized in ICE (a standard for FW/NAT crossing for signaling and media in SIP) because the "path" is kept open through interactive communications that are defined in ICE protocol standard. I guess the same is also true here. Cheers, Radhika R. Roy -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Pashalidis, Andreas Sent: Monday, July 17, 2006 5:06 AM To: Martin Stiemerling; nsis Subject: RE: [NSIS] REA Naming Contest (reanco) Hi, A few ideas for replace "REA". Open Internal Path (OIP) message <-- my favourite Configure Internal Path (CIP) message Prepare For Ucreate (PFU) message (I am not sure that the message that opens nat binding is actually called "Ucreate". If not, replace "Ucreate" with that message name) Internal Network Configuration (INC) message That's all for now... :) Andreas ________________________________ From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] Sent: Donnerstag, 13. Juli 2006 15:35 To: nsis Subject: Fwd: [NSIS] REA Naming Contest (reanco) Forgot one thing: The name suggestions will be discussed by the NSIS WG and the WG will vote on the suggestions to find the new name. Martin Anfang der weitergeleiteten E-Mail: Von: Martin Stiemerling Datum: 13. Juli 2006 09:32:52 GMT-04:00 An: nsis Betreff: [NSIS] REA Naming Contest (reanco) Dear All, We have discussed about the naming issues for the NATFW NSLP's RESERVE-EXTERNAL-ADDRESS (REA) message. In the past revisions of the NATFW NSLP REA has been used to obtain an external IP address/port at the outermost NAT (and at in between NATs too). But the semantics of REA changed over time from purely NAT usage to a combined NAT and firewall usage, i.e., a combination of the old REA and the old UCREATE. REA is used for: - Used to get external address/port at NAT - Used to install firewall rules for inbound traffic - Used in proxy mode usage So the current name is not really describing the semantics/usage anymore and we need to something different. Since the authors haven't had any good idea and some off-line discussions didn't bring a good name, we are starting the REA naming contest (reanco) This contest calls the NSIS WG for input on name suggestions for the message currently called REA. The contest starts today (actually already yesterday during the session) and will run until August 3rd 8am EST. Suggestion made after August 3rd EST are not accepted anymore. All suggestions must be sent to the NSIS working group list (nsis@ietf.org). It is not valid to use a naming generator that simply tries combinations of characters. The one who has suggested the name that will be finally taken as the new name for REA will be awarded with a six-pack of local beer at next IETF in San Diego. If there are multiple people suggesting the same name, they must share the six pack (sorry for that, but not enough money for it ;-) Of course all things apply here: participants must be older than 18 or 21 years (depending on location of IETF and the local laws), no guarantees, not entitled for anything, must be at the next IETF meeting in San Diego in November 2006, no monetary refunding, etc... So, looking forward to many suggestion for a "new REA". Martin for the NATFW NSLP authors. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 18 07:52:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2o7b-0000fz-3T; Tue, 18 Jul 2006 07:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2o7Z-0000ff-QL for nsis@ietf.org; Tue, 18 Jul 2006 07:52:13 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2o7Y-0002ei-Am for nsis@ietf.org; Tue, 18 Jul 2006 07:52:13 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k6IBqBxw012361 for ; Tue, 18 Jul 2006 13:52:11 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k6IBqAox028312 for ; Tue, 18 Jul 2006 13:52:11 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 13:52:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jul 2006 13:52:08 +0200 Message-ID: <69D2C30BFA177E4DB3E6C93A94C87F1F9C2838@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Traversal of GIST-aware NATs & traversal of legacy NATs thread-index: AcaprJHWhRxDN2aLT1O6SQfrOBDRggAp3F3Q From: "Pashalidis, Andreas" To: "nsis" X-OriginalArrivalTime: 18 Jul 2006 11:52:10.0738 (UTC) FILETIME=[9A34ED20:01C6AA60] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [NSIS] Traversal of GIST-aware NATs & traversal of legacy NATs X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hello WG, Recent mailing list discussions and rechartering discussions at the IETF66 ( see, for example, slide 8 of http://www3.ietf.org/proceedings/06jul/slides/nsis-6.ppt ) indicate that the traversal of legacy NATs, as well as the traversal of GIST-aware NATs in the context of non-NATFW NSLP signalling are topics that should be addressed with a relatively high priority. Two relevant documents are now available that address each of the above problems http://www.ietf.org/internet-drafts/draft-pashalidis-nsis-gist-legacynat s-00.txt [new!] and http://www.ietf.org/internet-drafts/draft-pashalidis-nsis-gimps-nattrave rsal-03.txt Unfortunately, I did not the a chance to present the above documents at the meeting due to insufficient time. Nevertheless, I think that the time is right to gauge the WG's interest in the documents. Hence: Are you comfortable with accepting these documents as WG items once there is enough space on the charter? Best Regards, Andreas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 18 08:52:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2p49-0002ir-2H; Tue, 18 Jul 2006 08:52:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2p3i-0002XV-AV for nsis@ietf.org; Tue, 18 Jul 2006 08:52:18 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2owm-00066w-4y for nsis@ietf.org; Tue, 18 Jul 2006 08:45:09 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k6ICj7DC026033 for ; Tue, 18 Jul 2006 14:45:07 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k6ICj6hB008784 for ; Tue, 18 Jul 2006 14:45:06 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 14:45:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jul 2006 14:44:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QoS NSLP Review thread-index: AcaqZ9CdJ62ijGLiT2iMDgdPqzMAMQ== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 18 Jul 2006 12:45:06.0128 (UTC) FILETIME=[FEE2FD00:01C6AA67] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [NSIS] QoS NSLP Review X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all,=20 I have reviewed the QoS NSLP draft again (as I promised). The document looks good. I have only a few minor comments: Technical: * Section 3.1.3. Change from: " The protocol does not currently define a way to carry such additional information (sometimes called "Policy data"), but this could be provided as a later extension. Some work in this direction is described in [NSLP-AUTH]. " to: " The QoS NSLP does not contain objects to carry authorization information. [NSLP-AUTH] provides this functionality for the QoS NSLP and the NATFW NSLP.=20 " * In Section 3.3.1 (overview section) you use RFC 2119 language. I don't think it is necessary.=20 * Section 3.3.5 describes two different aspects. Put the second paragraph into a separate subsection, if you think it is needed.=20 * Section 5.1.1: Difference between message-specific flags and generic flags is not obvious since even the generic flags are not applicable to all messages. Is this still inline with your thinking?=20 * Section 5.1.2.1, TEAR(T) flag: The usage of a QSPEC seems to depend on a few things that are not described. This might make it more difficult for interoperability. Would a QoSM describe the semantic. The same is true for the usage of the QSPEC object in a QUERY, a RESPONSE or a NOTIFY. Is it sufficient to point to the QSPEC or QoSMs with regard to the behavior? * Section 5.1.3.5: You might want to include an MRI identifier if you think that the parameter description is different for other MRIs. Hence, delete the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Method-specific classifier data (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Section 5.3.6: The following text is wrong: " Yet, if the top most QSPEC (i.e., te first QSPEC in the message) defines an unknown QOSM not understood by the RMF, the QNE MUST send an RESPONSE containing an INFO_SPEC and MUST NOT attempt to recover by inspecting the other QSPEC at the bottom of the stack. " If a QNE does not understand the QOSM then it looks at the mandatory objects. You could just point to the QSPEC template draft.=20 * IANA Consideration Section: - How can you define new Error Source Identifiers? - For the QoS NSLP ID you don't need IANA to instruct a new registry. Delete the text in Section 6.4 and ask IANA to allocate a value from the registry created by GIST. - I guess you need to create a registry for the BOUND_SESSION_ID Binding Codes.=20 - I guess you also have to create a registry for the PACKET_CLASSIFIER flags.=20 - With Section 6.2 I was not quite sure what you ask IANA todo. How would the registry look like?=20 Editorial: * Editor: Check the document for missing 'the' in front of "QoS NSLP". I got the impression that many of them are missing.=20 * Make the RFC editors job easier by using capitalized headings. This is what I mean: Change from: "3.1. Overall approach" to ""3.1. Overall Approach" Not a lot of work but the editor will be thankful.=20 * Use only QoS NSLP (instead of QoS-NSLP). See, for example, Section 3.1, first paragraph.=20 * Section 5.3.4 " There are two time parameters relevant to each QoS NSLP state in a node: the refresh period R between generation of successive refreshes for the state by the neighbor node, and the local state's lifetime L. Each RESERVE message may contain a REFRESH_PERIOD object specifying the R value that was used to generate this (refresh) message. This R value is then used to determine the value for L when the state is received and stored. The values for R and L may vary from peer to peer. This peer-to-peer refreshing (as opposed to the QNI initiating a refresh which travels all the way to the QNR) allows QNEs to choose refresh intervals as appropriate for their environment. For example, it is conceivable that refreshing intervals in the backbone, where reservations are relatively stable, are much larger than in an access network. " to: " There are two time parameters relevant to each QoS NSLP state in a node: the refresh period R between generation of successive refreshes for the state by the neighbor node, and the local state's lifetime L. Each RESERVE message may contain a REFRESH_PERIOD object specifying the R value that was used to generate this (refresh) message. This R value is then used to determine the value for L when the state is received and stored. The values for R and L may vary from peer to peer. " Reason: The deleted text appeared already in a previous paragraph.=20 Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 18 11:12:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rFi-0005sm-5x; Tue, 18 Jul 2006 11:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rFg-0005s2-FB for nsis@ietf.org; Tue, 18 Jul 2006 11:12:48 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2rFd-0006Lf-Mf for nsis@ietf.org; Tue, 18 Jul 2006 11:12:48 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6IFCYm3011268; Tue, 18 Jul 2006 16:12:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Tue, 18 Jul 2006 16:12:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: AcapoiRAA5MaVSJNQcWtc+KvNhzU6wA2Y0yg From: "Hancock, Robert" To: "Ash, Gerald R \(Jerry\), ALABS" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, just to check I understand the draft correctly: the *current* list of mandatory parameters (that can occur in a QoS description object) is: 7.2.3 7.2.5 Parameters (1st instance only) 7.2.6 Parameters (3 subtypes) 7.2.7 Priority Parameters (3 subtypes) 7.2.12 Parameters is this correct? r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: 17 July 2006 14:08 > To: cornelia.kappler@siemens.com;=20 > bschloer@cs.uni-goettingen.de; jmanner@cs.Helsinki.FI > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 >=20 >=20 > Hi Cornelia >=20 > >From my point of view the only mandatory parameters are the Traffic > specification parameters i.e., , =20 > and the "Non > QoSM Hop", assuming that the QoS-NSLP will include the "non QoS-NSLP > Hop" parameter, see my previous e-mail on this! >=20 > Best regards, > Georgios >=20 > On 7/17/2006, "Kappler, Cornelia"=20 > wrote: >=20 > >Dear all, > > > >I've been off-list for the last 10 days and may have=20 > difficulties grasping the real point of the debate. > > > >I'd prefer some concrete suggestions to which parameters=20 > should not be mandatory. Rather than blanket statements "List=20 > is too long" or "List is too short" or "we should have N parameters". > > > >The question is not really whether it should be 2 or 8 or 20=20 > mandatory parameters. It is _which_ parameters are necessary=20 > to _just_ accomodate the key ideas of typical QOSMs. > > > >Cornelia > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> Gesendet: Samstag, 15. Juli 2006 19:58 > >> An: 'Bernd Schloer'; 'Jukka MJ Manner' > >> Cc: 'Ash, Gerald R \(Jerry\), ALABS'; nsis@ietf.org > >> Betreff: RE: [NSIS] Any resolution to the QSPEC mandatory > >> parameter list? > >> > >> Hi > >> > >> Okay, but how many mandatory parameters should the central > >> draft contain? > >> > >> Best Regards, > >> Georgios > >> > >> -----Original Message----- > >> From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] > >> Sent: zaterdag 15 juli 2006 19:32 > >> To: Jukka MJ Manner > >> Cc: Ash, Gerald R \(Jerry\), ALABS; nsis@ietf.org > >> Subject: Re: [NSIS] Any resolution to the QSPEC mandatory > >> parameter list? > >> > >> Hi, > >> > >> it would be easier to define new QOSMs, when the mapping=20 > of mandatory > >> parameters is listed in a central draft. This would also ensure > >> interoperability. > >> > >> Bernd > >> > >> > >> Jukka MJ Manner wrote: > >> > Hi, > >> > > >> > I think the problem is that setting too many mandatory parameters > >> > effectively limits people to define new QOSMs (even the > >> current ones) > >> > - all QOSMs must be based on IntServ or DiffServ. > >> Interworking is an > >> > important issue, I fully agree. That is why I'm not sure > >> which way we > >> > should actually go: more or less mandatory parameters.=20 > (I think I'm > >> > inclined towards more flexibility) > >> > > >> > About the need for a change, I haven't seen any comment=20 > so far for > >> > keeping the longish list of mandatory parameters. All=20 > messages have > >> > been about introducing more flexibility. We should have had > >> a hummm at > >> > the meeting to see what people would want. > >> > > >> > Maybe people could speak up about what they want? > >> > > >> > Jukka > >> > > >> > On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote: > >> > > >> > > >> >>Hi Jukka, > >> >> > >> >>See below. > >> >> > >> >> > >> >>>-----Original Message----- > >> >>>From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >> >>>Sent: Thursday, July 13, 2006 10:19 AM > >> >>>To: nsis@ietf.org > >> >>>Subject: [NSIS] Any resolution to the QSPEC mandatory > >> parameter list? > >> >>> > >> >>> > >> >>>I think the discussion on the mandatory and optional > >> parameters ended > >> >>>without a clear resolution. I think there were good notes > >> on making > >> >>>the list of mandatory parameters shorter and/or allow=20 > an "ignore" > >> >>>interpretation of a mandatory parameter, and other ways to > >> make the > >> >>>template less strict. I also support these comments. > >> >>> > >> >>>Any views from the QSPEC people on how to resolve these=20 > comments? > >> >> > >> >>I'm not in favor of fundamentally changing the definition > >> of mandatory > >> >>and optional QSPEC parameters, as I think is being proposed. In > >> >>effect, to allow a mandatory parameter to be ignored would > >> eliminate > >> >>the distinction between mandatory parameters (MUST interpret if > >> >>populated) and optional parameters (SHOULD interpret if > >> populated). > >> >>The original idea of the QSPEC template is to provide a > >> common set of > >> >>mandatory parameters that would be interpreted (if=20 > populated by the > >> >>QNI) by all QOSMs. This would allow a degree of=20 > interoperability. > >> >>The set of mandatory parameters is based in part on=20 > parameters from > >> >>the INTSERV and DIFFSERV models that should be commonly > >> interpreted by > >> >>all QOSMs (that was the original charge to the QSPEC=20 > template draft > >> approach). > >> >> > >> >>The other alternative (i.e., to be able to 'ignore' mandatory > >> >>parameters) is essentially to make all parameters optional > >> parameters > >> >>(SHOULD interpret if populated). Optional parameters allow > >> the N-flag > >> >>(not supported flag) to be set if a QOSM wishes to 'ignore' (not > >> >>interpret) a parameter. > >> >> > >> >>I'm not clear on the motivation for this other alternative. > >> Perhaps > >> >>some particular QOSM wants to introduce the possibility of > >> 'ignoring' > >> >>mandatory parameters. Y.1541-QOSM doesn't require this nor > >> does the > >> >>CL-QOSM (AFAIK). Perhaps the RMD-QOSM for some reason > >> requires this > >> >>-- if so, I'm not clear what is the justification? > >> >> > >> >>I haven't seen that much support for a major change in the QSPEC > >> >>template approach to be able to 'ignore' mandatory parameters. > >> >> > >> >>Thanks, > >> >>Jerry > >> >> > >> >> > >> >>>Regards, > >> >>>Jukka > >> >>> > >> >>>_______________________________________________ > >> >>>nsis mailing list > >> >>>nsis@ietf.org > >> >>>https://www1.ietf.org/mailman/listinfo/nsis > >> >>> > >> >> > >> > > >> > _______________________________________________ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 18 17:07:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wn8-0007gE-Gp; Tue, 18 Jul 2006 17:07:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wn7-0007g9-2q for nsis@ietf.org; Tue, 18 Jul 2006 17:07:41 -0400 Received: from natlemon.rzone.de ([81.169.145.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2wn6-0007MR-Ga for nsis@ietf.org; Tue, 18 Jul 2006 17:07:41 -0400 Received: from [192.168.178.200] (p5484C268.dip0.t-ipconnect.de [84.132.194.104]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k6IL7aPr008552; Tue, 18 Jul 2006 23:07:36 +0200 (MEST) Message-ID: <44BD4CEA.6020506@cs.uni-goettingen.de> Date: Tue, 18 Jul 2006 23:04:42 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, currently the following parameters are mandatory (where the M-Flag is set= ): 7.2.1 7.2.2 7.2.3 7.2.5 Parameters (1st instance only) 7.2.6 Parameters (3 subtypes) 7.2.7 Priority Parameters (3 subtypes) Bernd Hancock, Robert wrote: > hi all, >=20 > just to check I understand the draft correctly: the > *current* list of mandatory parameters (that can occur > in a QoS description object) is: >=20 > 7.2.3 > 7.2.5 Parameters (1st instance only) > 7.2.6 Parameters (3 subtypes) > 7.2.7 Priority Parameters (3 subtypes) > 7.2.12 Parameters >=20 > is this correct? >=20 > r. >=20 >=20 >>-----Original Message----- >>From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >>Sent: 17 July 2006 14:08 >>To: cornelia.kappler@siemens.com;=20 >>bschloer@cs.uni-goettingen.de; jmanner@cs.Helsinki.FI >>Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >>Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 >>parameter list? >> >> >> >>Hi Cornelia >> >>>From my point of view the only mandatory parameters are the Traffic >>specification parameters i.e., , =20 >>and the "Non >>QoSM Hop", assuming that the QoS-NSLP will include the "non QoS-NSLP >>Hop" parameter, see my previous e-mail on this! >> >>Best regards, >>Georgios >> >>On 7/17/2006, "Kappler, Cornelia"=20 >> wrote: >> >> >>>Dear all, >>> >>>I've been off-list for the last 10 days and may have=20 >> >>difficulties grasping the real point of the debate. >> >>>I'd prefer some concrete suggestions to which parameters=20 >> >>should not be mandatory. Rather than blanket statements "List=20 >>is too long" or "List is too short" or "we should have N parameters". >> >>>The question is not really whether it should be 2 or 8 or 20=20 >> >>mandatory parameters. It is _which_ parameters are necessary=20 >>to _just_ accomodate the key ideas of typical QOSMs. >> >>>Cornelia >>> >>> >>>>-----Urspr=FCngliche Nachricht----- >>>>Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>Gesendet: Samstag, 15. Juli 2006 19:58 >>>>An: 'Bernd Schloer'; 'Jukka MJ Manner' >>>>Cc: 'Ash, Gerald R \(Jerry\), ALABS'; nsis@ietf.org >>>>Betreff: RE: [NSIS] Any resolution to the QSPEC mandatory >>>>parameter list? >>>> >>>>Hi >>>> >>>>Okay, but how many mandatory parameters should the central >>>>draft contain? >>>> >>>>Best Regards, >>>>Georgios >>>> >>>>-----Original Message----- >>>>From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] >>>>Sent: zaterdag 15 juli 2006 19:32 >>>>To: Jukka MJ Manner >>>>Cc: Ash, Gerald R \(Jerry\), ALABS; nsis@ietf.org >>>>Subject: Re: [NSIS] Any resolution to the QSPEC mandatory >>>>parameter list? >>>> >>>>Hi, >>>> >>>>it would be easier to define new QOSMs, when the mapping=20 >> >>of mandatory >> >>>>parameters is listed in a central draft. This would also ensure >>>>interoperability. >>>> >>>>Bernd >>>> >>>> >>>>Jukka MJ Manner wrote: >>>> >>>>>Hi, >>>>> >>>>>I think the problem is that setting too many mandatory parameters >>>>>effectively limits people to define new QOSMs (even the >>>> >>>>current ones) >>>> >>>>>- all QOSMs must be based on IntServ or DiffServ. >>>> >>>>Interworking is an >>>> >>>>>important issue, I fully agree. That is why I'm not sure >>>> >>>>which way we >>>> >>>>>should actually go: more or less mandatory parameters.=20 >> >>(I think I'm >> >>>>>inclined towards more flexibility) >>>>> >>>>>About the need for a change, I haven't seen any comment=20 >> >>so far for >> >>>>>keeping the longish list of mandatory parameters. All=20 >> >>messages have >> >>>>>been about introducing more flexibility. We should have had >>>> >>>>a hummm at >>>> >>>>>the meeting to see what people would want. >>>>> >>>>>Maybe people could speak up about what they want? >>>>> >>>>>Jukka >>>>> >>>>>On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote: >>>>> >>>>> >>>>> >>>>>>Hi Jukka, >>>>>> >>>>>>See below. >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >>>>>>>Sent: Thursday, July 13, 2006 10:19 AM >>>>>>>To: nsis@ietf.org >>>>>>>Subject: [NSIS] Any resolution to the QSPEC mandatory >>>> >>>>parameter list? >>>> >>>>>>> >>>>>>>I think the discussion on the mandatory and optional >>>> >>>>parameters ended >>>> >>>>>>>without a clear resolution. I think there were good notes >>>> >>>>on making >>>> >>>>>>>the list of mandatory parameters shorter and/or allow=20 >> >>an "ignore" >> >>>>>>>interpretation of a mandatory parameter, and other ways to >>>> >>>>make the >>>> >>>>>>>template less strict. I also support these comments. >>>>>>> >>>>>>>Any views from the QSPEC people on how to resolve these=20 >> >>comments? >> >>>>>>I'm not in favor of fundamentally changing the definition >>>> >>>>of mandatory >>>> >>>>>>and optional QSPEC parameters, as I think is being proposed. In >>>>>>effect, to allow a mandatory parameter to be ignored would >>>> >>>>eliminate >>>> >>>>>>the distinction between mandatory parameters (MUST interpret if >>>>>>populated) and optional parameters (SHOULD interpret if >>>> >>>>populated). >>>> >>>>>>The original idea of the QSPEC template is to provide a >>>> >>>>common set of >>>> >>>>>>mandatory parameters that would be interpreted (if=20 >> >>populated by the >> >>>>>>QNI) by all QOSMs. This would allow a degree of=20 >> >>interoperability. >> >>>>>>The set of mandatory parameters is based in part on=20 >> >>parameters from >> >>>>>>the INTSERV and DIFFSERV models that should be commonly >>>> >>>>interpreted by >>>> >>>>>>all QOSMs (that was the original charge to the QSPEC=20 >> >>template draft >> >>>>approach). >>>> >>>>>>The other alternative (i.e., to be able to 'ignore' mandatory >>>>>>parameters) is essentially to make all parameters optional >>>> >>>>parameters >>>> >>>>>>(SHOULD interpret if populated). Optional parameters allow >>>> >>>>the N-flag >>>> >>>>>>(not supported flag) to be set if a QOSM wishes to 'ignore' (not >>>>>>interpret) a parameter. >>>>>> >>>>>>I'm not clear on the motivation for this other alternative. >>>> >>>> Perhaps >>>> >>>>>>some particular QOSM wants to introduce the possibility of >>>> >>>>'ignoring' >>>> >>>>>>mandatory parameters. Y.1541-QOSM doesn't require this nor >>>> >>>>does the >>>> >>>>>>CL-QOSM (AFAIK). Perhaps the RMD-QOSM for some reason >>>> >>>>requires this >>>> >>>>>>-- if so, I'm not clear what is the justification? >>>>>> >>>>>>I haven't seen that much support for a major change in the QSPEC >>>>>>template approach to be able to 'ignore' mandatory parameters. >>>>>> >>>>>>Thanks, >>>>>>Jerry >>>>>> >>>>>> >>>>>> >>>>>>>Regards, >>>>>>>Jukka >>>>>>> >>>>>>>_______________________________________________ >>>>>>>nsis mailing list >>>>>>>nsis@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>>>> >>>>>> >>>>>_______________________________________________ >>>>>nsis mailing list >>>>>nsis@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>> >>>>_______________________________________________ >>>>nsis mailing list >>>>nsis@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/nsis >>>> >>>> >>>> >>>>_______________________________________________ >>>>nsis mailing list >>>>nsis@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/nsis >>>> >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 18 17:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wpQ-0008Ti-Lp; Tue, 18 Jul 2006 17:10:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wpP-0008Td-ED for nsis@ietf.org; Tue, 18 Jul 2006 17:10:03 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G2wpN-0007iY-SF for nsis@ietf.org; Tue, 18 Jul 2006 17:10:03 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-126.messagelabs.com!1153256893!13359296!29 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 18808 invoked from network); 18 Jul 2006 21:10:00 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-10.tower-126.messagelabs.com with SMTP; 18 Jul 2006 21:10:00 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452002A987B; Tue, 18 Jul 2006 17:09:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Tue, 18 Jul 2006 16:09:59 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7B1C@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: AcapoiRAA5MaVSJNQcWtc+KvNhzU6wA2Y0ygAAulZ/A= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hancock, Robert" X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, See below.=20 > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > Sent: Tuesday, July 18, 2006 11:13 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: nsis@ietf.org > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 > hi all, >=20 > just to check I understand the draft correctly: the > *current* list of mandatory parameters (that can occur > in a QoS description object) is: >=20 > 7.2.3 > 7.2.5 Parameters (1st instance only) > 7.2.6 Parameters (3 subtypes) > 7.2.7 Priority Parameters (3 subtypes) > 7.2.12 Parameters >=20 > is this correct? Yes to the first 3 QSPEC parameters ( ), however are optional QSPEC = parameters. Also, I agree with the above characterization. We can group into only 3 = mandatory QSPEC QoS Description parameters (containers), as follows: 1. : ; (populate = only one) 2. : ; ; (populate = only one) 3. : ; (populate only = one pair) These plus one mandatory QSPEC control information parameter () makes only 4 mandatory QSPEC parameters in total, which = seems minimal, and is consistent with the original concept. Thanks, Jerry >=20 > r. >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > > Sent: 17 July 2006 14:08 > > To: cornelia.kappler@siemens.com;=20 > > bschloer@cs.uni-goettingen.de; jmanner@cs.Helsinki.FI > > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > > parameter list? > >=20 > >=20 > > Hi Cornelia > >=20 > > >From my point of view the only mandatory parameters are the Traffic > > specification parameters i.e., , =20 > > and the "Non > > QoSM Hop", assuming that the QoS-NSLP will include the "non QoS-NSLP > > Hop" parameter, see my previous e-mail on this! > >=20 > > Best regards, > > Georgios > >=20 > > On 7/17/2006, "Kappler, Cornelia"=20 > > wrote: > >=20 > > >Dear all, > > > > > >I've been off-list for the last 10 days and may have=20 > > >difficulties grasping the real point of the debate. > > > > > >I'd prefer some concrete suggestions to which parameters=20 > > >should not be mandatory. Rather than blanket statements "List=20 > > >is too long" or "List is too short" or "we should have N=20 > > >parameters". > > > > > >The question is not really whether it should be 2 or 8 or 20=20 > > >mandatory parameters. It is _which_ parameters are necessary=20 > > >to _just_ accomodate the key ideas of typical QOSMs. > > > > > >Cornelia > > > > > >> -----Urspr=FCngliche Nachricht----- > > >> Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > >> Gesendet: Samstag, 15. Juli 2006 19:58 > > >> An: 'Bernd Schloer'; 'Jukka MJ Manner' > > >> Cc: 'Ash, Gerald R \(Jerry\), ALABS'; nsis@ietf.org > > >> Betreff: RE: [NSIS] Any resolution to the QSPEC mandatory > > >> parameter list? > > >> > > >> Hi > > >> > > >> Okay, but how many mandatory parameters should the central > > >> draft contain? > > >> > > >> Best Regards, > > >> Georgios > > >> > > >> -----Original Message----- > > >> From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] > > >> Sent: zaterdag 15 juli 2006 19:32 > > >> To: Jukka MJ Manner > > >> Cc: Ash, Gerald R \(Jerry\), ALABS; nsis@ietf.org > > >> Subject: Re: [NSIS] Any resolution to the QSPEC mandatory > > >> parameter list? > > >> > > >> Hi, > > >> > > >> it would be easier to define new QOSMs, when the mapping=20 > > >> of mandatory > > >> parameters is listed in a central draft. This would also ensure > > >> interoperability. > > >> > > >> Bernd > > >> > > >> > > >> Jukka MJ Manner wrote: > > >> > Hi, > > >> > > > >> > I think the problem is that setting too many mandatory=20 > > >> > parameters > > >> > effectively limits people to define new QOSMs (even the > > >> > current ones) > > >> > - all QOSMs must be based on IntServ or DiffServ. > > >> > Interworking is an > > >> > important issue, I fully agree. That is why I'm not sure > > >> > which way we > > >> > should actually go: more or less mandatory parameters.=20 > > >> > (I think I'm > > >> > inclined towards more flexibility) > > >> > > > >> > About the need for a change, I haven't seen any comment=20 > > >> > so far for > > >> > keeping the longish list of mandatory parameters. All=20 > > >> > messages have > > >> > been about introducing more flexibility. We should have had > > >> > a hummm at > > >> > the meeting to see what people would want. > > >> > > > >> > Maybe people could speak up about what they want? > > >> > > > >> > Jukka > > >> > > > >> > On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote: > > >> > > > >> > > > >> >>Hi Jukka, > > >> >> > > >> >>See below. > > >> >> > > >> >> > > >> >>>-----Original Message----- > > >> >>>From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > >> >>>Sent: Thursday, July 13, 2006 10:19 AM > > >> >>>To: nsis@ietf.org > > >> >>>Subject: [NSIS] Any resolution to the QSPEC mandatory > > >> >>>parameter list? > > >> >>> > > >> >>> > > >> >>>I think the discussion on the mandatory and optional > > >> >>>parameters ended > > >> >>>without a clear resolution. I think there were good notes > > >> >>>on making > > >> >>>the list of mandatory parameters shorter and/or allow=20 > > >> >>>an "ignore" > > >> >>>interpretation of a mandatory parameter, and other ways to > > >> >>>make the > > >> >>>template less strict. I also support these comments. > > >> >>> > > >> >>>Any views from the QSPEC people on how to resolve these=20 > > >> >>>comments? > > >> >> > > >> >>I'm not in favor of fundamentally changing the definition > > >> >>of mandatory > > >> >>and optional QSPEC parameters, as I think is being=20 > > >> >>proposed. In > > >> >>effect, to allow a mandatory parameter to be ignored would > > >> >>eliminate > > >> >>the distinction between mandatory parameters (MUST interpret if > > >> >>populated) and optional parameters (SHOULD interpret if > > >> >>populated). > > >> >>The original idea of the QSPEC template is to provide a > > >> >>common set of > > >> >>mandatory parameters that would be interpreted (if=20 > > >> >>populated by the > > >> >>QNI) by all QOSMs. This would allow a degree of=20 > > >> >>interoperability. > > >> >>The set of mandatory parameters is based in part on=20 > > >> >>parameters from > > >> >>the INTSERV and DIFFSERV models that should be commonly > > >> >>interpreted by > > >> >>all QOSMs (that was the original charge to the QSPEC=20 > > >> >>template draft > > >> >>approach). > > >> >> > > >> >>The other alternative (i.e., to be able to 'ignore' mandatory > > >> >>parameters) is essentially to make all parameters optional > > >> >>parameters > > >> >>(SHOULD interpret if populated). Optional parameters allow > > >> >>the N-flag > > >> >>(not supported flag) to be set if a QOSM wishes to=20 > > >> >>'ignore' (not > > >> >>interpret) a parameter. > > >> >> > > >> >>I'm not clear on the motivation for this other alternative. > > >> >> Perhaps > > >> >>some particular QOSM wants to introduce the possibility of > > >> >>'ignoring' > > >> >>mandatory parameters. Y.1541-QOSM doesn't require this nor > > >> >>does the > > >> >>CL-QOSM (AFAIK). Perhaps the RMD-QOSM for some reason > > >> >>requires this > > >> >>-- if so, I'm not clear what is the justification? > > >> >> > > >> >>I haven't seen that much support for a major change in=20 > > >> >>the QSPEC > > >> >>template approach to be able to 'ignore' mandatory parameters. > > >> >> > > >> >>Thanks, > > >> >>Jerry > > >> >> > > >> >> > > >> >>>Regards, > > >> >>>Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 19 01:50:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G34xO-0000Fy-LM; Wed, 19 Jul 2006 01:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G34xN-00007h-0U for nsis@ietf.org; Wed, 19 Jul 2006 01:50:49 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G34xL-0004z1-KX for nsis@ietf.org; Wed, 19 Jul 2006 01:50:48 -0400 Received: from [84.163.32.88] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1G34xH1ESA-0005iw; Wed, 19 Jul 2006 07:50:43 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id CEA045E81E9; Wed, 19 Jul 2006 07:50:27 +0200 (CEST) Date: Wed, 19 Jul 2006 07:50:27 +0200 From: Matthias Friedrich To: nsis@ietf.org Subject: Re: [NSIS] REA Naming Contest (reanco) Message-ID: <20060719055026.GA28430@mafr.de> Mail-Followup-To: nsis@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Thursday, 2006-07-13, Martin Stiemerling wrote: [...] > REA is used for: > - Used to get external address/port at NAT > - Used to install firewall rules for inbound traffic > - Used in proxy mode usage I'd like to take part in the contest, too, so I'll repeat my suggestion from last week's mail :-) As I don't think there can be the perfect name describing all of REA's use cases in a catchy acronym, we could name it after the instance which sends the message (NR/NI+/DR). For symmetry, the CREATE message should also be renamed: * CREATE -> ICREATE (Initiator CREATE); REA -> RCREATE (Responder CREATE) or, alternatively: * CREATE -> SCREATE (Sender CREATE); REA -> RCREATE (Receiver CREATE) This would also give us the opportunity to talk about I-Sessions and R-Sessions in the spec, which emphasizes that they are different things. Regards, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 19 04:48:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G37jd-0001qx-57; Wed, 19 Jul 2006 04:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G37jb-0001q8-ON for nsis@ietf.org; Wed, 19 Jul 2006 04:48:47 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G37jb-0005Ej-2r for nsis@ietf.org; Wed, 19 Jul 2006 04:48:47 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6J8mWTw010343; Wed, 19 Jul 2006 09:48:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Wed, 19 Jul 2006 09:48:32 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: AcapoiRAA5MaVSJNQcWtc+KvNhzU6wA2Y0ygAAulZ/AAGSR+oA== From: "Hancock, Robert" To: "Ash, Gerald R \(Jerry\), ALABS" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi jerry, all, a list of 3 does not seem too bad to me; possibly the actual=20 number of mandatory parameters hasn't been too obvious to=20 everyone up to now. (and i was surprised to be including the ctot etc. parameters, but i couldn't find where it said they were optional ... i guess it's clear how to fix that.) i would make one tweak to the text (not sure where), which might have some interactions with some of the other comments on the list recently: since the class/priority parameters are=20 at least in principle extensible, and parameter support is mandatory, should one consider an extension to one of these=20 parameters be considered as having a similar impact to defining a new mandatory parameter? the effect on existing implementations is the same, i think. and hence there is some value in getting all the variants of the mandatory parameters in the base spec. also, i think this underlines that some ABNF for the Qspec contents would be a big help. cheers, r. > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > Sent: 18 July 2006 22:10 > To: Hancock, Robert > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 >=20 > Hi Robert, >=20 > See below.=20 >=20 > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > > Sent: Tuesday, July 18, 2006 11:13 AM > > To: Ash, Gerald R (Jerry), ALABS > > Cc: nsis@ietf.org > > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > > parameter list? > >=20 > > hi all, > >=20 > > just to check I understand the draft correctly: the > > *current* list of mandatory parameters (that can occur > > in a QoS description object) is: > >=20 > > 7.2.3 > > 7.2.5 Parameters (1st instance only) > > 7.2.6 Parameters (3 subtypes) > > 7.2.7 Priority Parameters (3 subtypes) > > 7.2.12 Parameters > >=20 > > is this correct? >=20 > Yes to the first 3 QSPEC parameters ( Bucket> ), however are=20 > optional QSPEC parameters. >=20 > Also, I agree with the above characterization. We can group=20 > into only 3 mandatory QSPEC QoS Description parameters=20 > (containers), as follows: >=20 > 1. : ; =20 > (populate only one) > 2. : ; ; type> (populate only one) > 3. : ; =20 > (populate only one pair) >=20 > These plus one mandatory QSPEC control information parameter=20 > () makes only 4 mandatory QSPEC parameters=20 > in total, which seems minimal, and is consistent with the=20 > original concept. >=20 > Thanks, > Jerry >=20 > >=20 > > r. > >=20 > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > > > Sent: 17 July 2006 14:08 > > > To: cornelia.kappler@siemens.com;=20 > > > bschloer@cs.uni-goettingen.de; jmanner@cs.Helsinki.FI > > > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > > > parameter list? > > >=20 > > >=20 > > > Hi Cornelia > > >=20 > > > >From my point of view the only mandatory parameters are=20 > the Traffic > > > specification parameters i.e., , =20 > > > and the "Non > > > QoSM Hop", assuming that the QoS-NSLP will include the=20 > "non QoS-NSLP > > > Hop" parameter, see my previous e-mail on this! > > >=20 > > > Best regards, > > > Georgios > > >=20 > > > On 7/17/2006, "Kappler, Cornelia"=20 > > > wrote: > > >=20 > > > >Dear all, > > > > > > > >I've been off-list for the last 10 days and may have=20 > > > >difficulties grasping the real point of the debate. > > > > > > > >I'd prefer some concrete suggestions to which parameters=20 > > > >should not be mandatory. Rather than blanket statements "List=20 > > > >is too long" or "List is too short" or "we should have N=20 > > > >parameters". > > > > > > > >The question is not really whether it should be 2 or 8 or 20=20 > > > >mandatory parameters. It is _which_ parameters are necessary=20 > > > >to _just_ accomodate the key ideas of typical QOSMs. > > > > > > > >Cornelia > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > >> Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > >> Gesendet: Samstag, 15. Juli 2006 19:58 > > > >> An: 'Bernd Schloer'; 'Jukka MJ Manner' > > > >> Cc: 'Ash, Gerald R \(Jerry\), ALABS'; nsis@ietf.org > > > >> Betreff: RE: [NSIS] Any resolution to the QSPEC mandatory > > > >> parameter list? > > > >> > > > >> Hi > > > >> > > > >> Okay, but how many mandatory parameters should the central > > > >> draft contain? > > > >> > > > >> Best Regards, > > > >> Georgios > > > >> > > > >> -----Original Message----- > > > >> From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] > > > >> Sent: zaterdag 15 juli 2006 19:32 > > > >> To: Jukka MJ Manner > > > >> Cc: Ash, Gerald R \(Jerry\), ALABS; nsis@ietf.org > > > >> Subject: Re: [NSIS] Any resolution to the QSPEC mandatory > > > >> parameter list? > > > >> > > > >> Hi, > > > >> > > > >> it would be easier to define new QOSMs, when the mapping=20 > > > >> of mandatory > > > >> parameters is listed in a central draft. This would also ensure > > > >> interoperability. > > > >> > > > >> Bernd > > > >> > > > >> > > > >> Jukka MJ Manner wrote: > > > >> > Hi, > > > >> > > > > >> > I think the problem is that setting too many mandatory=20 > > > >> > parameters > > > >> > effectively limits people to define new QOSMs (even the > > > >> > current ones) > > > >> > - all QOSMs must be based on IntServ or DiffServ. > > > >> > Interworking is an > > > >> > important issue, I fully agree. That is why I'm not sure > > > >> > which way we > > > >> > should actually go: more or less mandatory parameters.=20 > > > >> > (I think I'm > > > >> > inclined towards more flexibility) > > > >> > > > > >> > About the need for a change, I haven't seen any comment=20 > > > >> > so far for > > > >> > keeping the longish list of mandatory parameters. All=20 > > > >> > messages have > > > >> > been about introducing more flexibility. We should have had > > > >> > a hummm at > > > >> > the meeting to see what people would want. > > > >> > > > > >> > Maybe people could speak up about what they want? > > > >> > > > > >> > Jukka > > > >> > > > > >> > On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote: > > > >> > > > > >> > > > > >> >>Hi Jukka, > > > >> >> > > > >> >>See below. > > > >> >> > > > >> >> > > > >> >>>-----Original Message----- > > > >> >>>From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > >> >>>Sent: Thursday, July 13, 2006 10:19 AM > > > >> >>>To: nsis@ietf.org > > > >> >>>Subject: [NSIS] Any resolution to the QSPEC mandatory > > > >> >>>parameter list? > > > >> >>> > > > >> >>> > > > >> >>>I think the discussion on the mandatory and optional > > > >> >>>parameters ended > > > >> >>>without a clear resolution. I think there were good notes > > > >> >>>on making > > > >> >>>the list of mandatory parameters shorter and/or allow=20 > > > >> >>>an "ignore" > > > >> >>>interpretation of a mandatory parameter, and other ways to > > > >> >>>make the > > > >> >>>template less strict. I also support these comments. > > > >> >>> > > > >> >>>Any views from the QSPEC people on how to resolve these=20 > > > >> >>>comments? > > > >> >> > > > >> >>I'm not in favor of fundamentally changing the definition > > > >> >>of mandatory > > > >> >>and optional QSPEC parameters, as I think is being=20 > > > >> >>proposed. In > > > >> >>effect, to allow a mandatory parameter to be ignored would > > > >> >>eliminate > > > >> >>the distinction between mandatory parameters (MUST=20 > interpret if > > > >> >>populated) and optional parameters (SHOULD interpret if > > > >> >>populated). > > > >> >>The original idea of the QSPEC template is to provide a > > > >> >>common set of > > > >> >>mandatory parameters that would be interpreted (if=20 > > > >> >>populated by the > > > >> >>QNI) by all QOSMs. This would allow a degree of=20 > > > >> >>interoperability. > > > >> >>The set of mandatory parameters is based in part on=20 > > > >> >>parameters from > > > >> >>the INTSERV and DIFFSERV models that should be commonly > > > >> >>interpreted by > > > >> >>all QOSMs (that was the original charge to the QSPEC=20 > > > >> >>template draft > > > >> >>approach). > > > >> >> > > > >> >>The other alternative (i.e., to be able to 'ignore' mandatory > > > >> >>parameters) is essentially to make all parameters optional > > > >> >>parameters > > > >> >>(SHOULD interpret if populated). Optional parameters allow > > > >> >>the N-flag > > > >> >>(not supported flag) to be set if a QOSM wishes to=20 > > > >> >>'ignore' (not > > > >> >>interpret) a parameter. > > > >> >> > > > >> >>I'm not clear on the motivation for this other alternative. > > > >> >> Perhaps > > > >> >>some particular QOSM wants to introduce the possibility of > > > >> >>'ignoring' > > > >> >>mandatory parameters. Y.1541-QOSM doesn't require this nor > > > >> >>does the > > > >> >>CL-QOSM (AFAIK). Perhaps the RMD-QOSM for some reason > > > >> >>requires this > > > >> >>-- if so, I'm not clear what is the justification? > > > >> >> > > > >> >>I haven't seen that much support for a major change in=20 > > > >> >>the QSPEC > > > >> >>template approach to be able to 'ignore' mandatory=20 > parameters. > > > >> >> > > > >> >>Thanks, > > > >> >>Jerry > > > >> >> > > > >> >> > > > >> >>>Regards, > > > >> >>>Jukka >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 19 11:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EK9-0005jl-St; Wed, 19 Jul 2006 11:50:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EK8-0005jg-8S for nsis@ietf.org; Wed, 19 Jul 2006 11:50:56 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3EK7-0004us-KM for nsis@ietf.org; Wed, 19 Jul 2006 11:50:56 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-8.tower-126.messagelabs.com!1153323517!11706245!86 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 7001 invoked from network); 19 Jul 2006 15:43:33 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-126.messagelabs.com with SMTP; 19 Jul 2006 15:43:33 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452002C1D56; Wed, 19 Jul 2006 11:43:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Wed, 19 Jul 2006 10:43:32 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7B26@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: AcapoiRAA5MaVSJNQcWtc+KvNhzU6wA2Y0ygAAulZ/AAGSR+oAAN7ypw From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hancock, Robert" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, See below.=20 > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > Sent: Wednesday, July 19, 2006 4:49 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: nsis@ietf.org > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 > hi jerry, all, >=20 > a list of 3 does not seem too bad to me; possibly the actual=20 > number of mandatory parameters hasn't been too obvious to=20 > everyone up to now. (and i was surprised to be including the > ctot etc. parameters, but i couldn't find where it said they > were optional ... i guess it's clear how to fix that.) Definitely. We'll group and clearly identify the mandatory and optional = QSPEC parameters. =20 > i would make one tweak to the text (not sure where), which > might have some interactions with some of the other comments > on the list recently: since the class/priority parameters are=20 > at least in principle extensible, and parameter support is > mandatory, should one consider an extension to one of these=20 > parameters be considered as having a similar impact to > defining a new mandatory parameter? the effect on existing > implementations is the same, i think. and hence there is some > value in getting all the variants of the mandatory parameters > in the base spec. Agree that an extension to one of the mandatory parameters would be the = same as defining a new mandatory parameter. =20 > also, i think this underlines that some ABNF for the Qspec > contents would be a big help. OK, we'll pursue ABNF notation in the QSPEC document. Thanks, Jerry >=20 > cheers, >=20 > r. >=20 > > -----Original Message----- > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > > Sent: 18 July 2006 22:10 > > To: Hancock, Robert > > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > > parameter list? > >=20 > >=20 > > Hi Robert, > >=20 > > See below.=20 > >=20 > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > > > Sent: Tuesday, July 18, 2006 11:13 AM > > > To: Ash, Gerald R (Jerry), ALABS > > > Cc: nsis@ietf.org > > > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > > > parameter list? > > >=20 > > > hi all, > > >=20 > > > just to check I understand the draft correctly: the > > > *current* list of mandatory parameters (that can occur > > > in a QoS description object) is: > > >=20 > > > 7.2.3 > > > 7.2.5 Parameters (1st instance only) > > > 7.2.6 Parameters (3 subtypes) > > > 7.2.7 Priority Parameters (3 subtypes) > > > 7.2.12 Parameters > > >=20 > > > is this correct? > >=20 > > Yes to the first 3 QSPEC parameters ( > Bucket> ), however are=20 > > optional QSPEC parameters. > >=20 > > Also, I agree with the above characterization. We can group=20 > > into only 3 mandatory QSPEC QoS Description parameters=20 > > (containers), as follows: > >=20 > > 1. : ; =20 > > (populate only one) > > 2. : ; ; > type> (populate only one) > > 3. : ; =20 > > (populate only one pair) > >=20 > > These plus one mandatory QSPEC control information parameter=20 > > () makes only 4 mandatory QSPEC parameters=20 > > in total, which seems minimal, and is consistent with the=20 > > original concept. > >=20 > > Thanks, > > Jerry > >=20 > > >=20 > > > r. > > >=20 > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > > > > Sent: 17 July 2006 14:08 > > > > To: cornelia.kappler@siemens.com;=20 > > > > bschloer@cs.uni-goettingen.de; jmanner@cs.Helsinki.FI > > > > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > > > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > > > > parameter list? > > > >=20 > > > >=20 > > > > Hi Cornelia > > > >=20 > > > > >From my point of view the only mandatory parameters are=20 > > > > the Traffic > > > > specification parameters i.e., , =20 > > > > and the "Non > > > > QoSM Hop", assuming that the QoS-NSLP will include the=20 > > > > "non QoS-NSLP > > > > Hop" parameter, see my previous e-mail on this! > > > >=20 > > > > Best regards, > > > > Georgios > > > >=20 > > > > On 7/17/2006, "Kappler, Cornelia"=20 > > > > wrote: > > > >=20 > > > > >Dear all, > > > > > > > > > >I've been off-list for the last 10 days and may have=20 > > > > >difficulties grasping the real point of the debate. > > > > > > > > > >I'd prefer some concrete suggestions to which parameters=20 > > > > >should not be mandatory. Rather than blanket statements "List=20 > > > > >is too long" or "List is too short" or "we should have N=20 > > > > >parameters". > > > > > > > > > >The question is not really whether it should be 2 or 8 or 20=20 > > > > >mandatory parameters. It is _which_ parameters are necessary=20 > > > > >to _just_ accomodate the key ideas of typical QOSMs. > > > > > > > > > >Cornelia > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > > >> Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > >> Gesendet: Samstag, 15. Juli 2006 19:58 > > > > >> An: 'Bernd Schloer'; 'Jukka MJ Manner' > > > > >> Cc: 'Ash, Gerald R \(Jerry\), ALABS'; nsis@ietf.org > > > > >> Betreff: RE: [NSIS] Any resolution to the QSPEC mandatory > > > > >> parameter list? > > > > >> > > > > >> Hi > > > > >> > > > > >> Okay, but how many mandatory parameters should the central > > > > >> draft contain? > > > > >> > > > > >> Best Regards, > > > > >> Georgios > > > > >> > > > > >> -----Original Message----- > > > > >> From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] > > > > >> Sent: zaterdag 15 juli 2006 19:32 > > > > >> To: Jukka MJ Manner > > > > >> Cc: Ash, Gerald R \(Jerry\), ALABS; nsis@ietf.org > > > > >> Subject: Re: [NSIS] Any resolution to the QSPEC mandatory > > > > >> parameter list? > > > > >> > > > > >> Hi, > > > > >> > > > > >> it would be easier to define new QOSMs, when the mapping=20 > > > > >> of mandatory > > > > >> parameters is listed in a central draft. This would=20 > > > > >> also ensure > > > > >> interoperability. > > > > >> > > > > >> Bernd > > > > >> > > > > >> > > > > >> Jukka MJ Manner wrote: > > > > >> > Hi, > > > > >> > > > > > >> > I think the problem is that setting too many mandatory=20 > > > > >> > parameters > > > > >> > effectively limits people to define new QOSMs (even the > > > > >> > current ones) > > > > >> > - all QOSMs must be based on IntServ or DiffServ. > > > > >> > Interworking is an > > > > >> > important issue, I fully agree. That is why I'm not sure > > > > >> > which way we > > > > >> > should actually go: more or less mandatory parameters.=20 > > > > >> > (I think I'm > > > > >> > inclined towards more flexibility) > > > > >> > > > > > >> > About the need for a change, I haven't seen any comment=20 > > > > >> > so far for > > > > >> > keeping the longish list of mandatory parameters. All=20 > > > > >> > messages have > > > > >> > been about introducing more flexibility. We should have had > > > > >> > a hummm at > > > > >> > the meeting to see what people would want. > > > > >> > > > > > >> > Maybe people could speak up about what they want? > > > > >> > > > > > >> > Jukka > > > > >> > > > > > >> > On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote: > > > > >> > > > > > >> > > > > > >> >>Hi Jukka, > > > > >> >> > > > > >> >>See below. > > > > >> >> > > > > >> >> > > > > >> >>>-----Original Message----- > > > > >> >>>From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > >> >>>Sent: Thursday, July 13, 2006 10:19 AM > > > > >> >>>To: nsis@ietf.org > > > > >> >>>Subject: [NSIS] Any resolution to the QSPEC mandatory > > > > >> >>>parameter list? > > > > >> >>> > > > > >> >>> > > > > >> >>>I think the discussion on the mandatory and optional > > > > >> >>>parameters ended > > > > >> >>>without a clear resolution. I think there were good notes > > > > >> >>>on making > > > > >> >>>the list of mandatory parameters shorter and/or allow=20 > > > > >> >>>an "ignore" > > > > >> >>>interpretation of a mandatory parameter, and other ways to > > > > >> >>>make the > > > > >> >>>template less strict. I also support these comments. > > > > >> >>> > > > > >> >>>Any views from the QSPEC people on how to resolve these=20 > > > > >> >>>comments? > > > > >> >> > > > > >> >>I'm not in favor of fundamentally changing the definition > > > > >> >>of mandatory > > > > >> >>and optional QSPEC parameters, as I think is being=20 > > > > >> >>proposed. In > > > > >> >>effect, to allow a mandatory parameter to be ignored would > > > > >> >>eliminate > > > > >> >>the distinction between mandatory parameters (MUST=20 > > > > >> >>interpret if > > > > >> >>populated) and optional parameters (SHOULD interpret if > > > > >> >>populated). > > > > >> >>The original idea of the QSPEC template is to provide a > > > > >> >>common set of > > > > >> >>mandatory parameters that would be interpreted (if=20 > > > > >> >>populated by the > > > > >> >>QNI) by all QOSMs. This would allow a degree of=20 > > > > >> >>interoperability. > > > > >> >>The set of mandatory parameters is based in part on=20 > > > > >> >>parameters from > > > > >> >>the INTSERV and DIFFSERV models that should be commonly > > > > >> >>interpreted by > > > > >> >>all QOSMs (that was the original charge to the QSPEC=20 > > > > >> >>template draft > > > > >> >>approach). > > > > >> >> > > > > >> >>The other alternative (i.e., to be able to=20 > > > > >> >>'ignore' mandatory > > > > >> >>parameters) is essentially to make all parameters optional > > > > >> >>parameters > > > > >> >>(SHOULD interpret if populated). Optional parameters allow > > > > >> >>the N-flag > > > > >> >>(not supported flag) to be set if a QOSM wishes to=20 > > > > >> >>'ignore' (not > > > > >> >>interpret) a parameter. > > > > >> >> > > > > >> >>I'm not clear on the motivation for this other alternative. > > > > >> >> Perhaps > > > > >> >>some particular QOSM wants to introduce the possibility of > > > > >> >>'ignoring' > > > > >> >>mandatory parameters. Y.1541-QOSM doesn't require this nor > > > > >> >>does the > > > > >> >>CL-QOSM (AFAIK). Perhaps the RMD-QOSM for some reason > > > > >> >>requires this > > > > >> >>-- if so, I'm not clear what is the justification? > > > > >> >> > > > > >> >>I haven't seen that much support for a major change in=20 > > > > >> >>the QSPEC > > > > >> >>template approach to be able to 'ignore' mandatory=20 > > > > >> >>parameters. > > > > >> >> > > > > >> >>Thanks, > > > > >> >>Jerry > > > > >> >> > > > > >> >> > > > > >> >>>Regards, > > > > >> >>>Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 19 13:58:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GJE-0005Th-5U; Wed, 19 Jul 2006 13:58:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GJC-0005S9-FP for nsis@ietf.org; Wed, 19 Jul 2006 13:58:06 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3GJB-000298-7F for nsis@ietf.org; Wed, 19 Jul 2006 13:58:06 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k6JHw403012173; Wed, 19 Jul 2006 13:58:04 -0400 (EDT) In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7B1C@KCCLUST06EVS1.ugd.att.com> Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? To: "Ash, Gerald R \(Jerry\), ALABS" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Wed, 19 Jul 2006 13:58:01 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/19/2006 01:56:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org "Ash, Gerald R \(Jerry\), ALABS" wrote on 07/18/2006 05:09:59 PM: > ... > Also, I agree with the above characterization. We can group into > only 3 mandatory QSPEC QoS Description parameters (containers), as follows: > > 1. : ; > (populate only one) > 2. : ; ; > (populate only one) > 3. : ; (populate > only one pair) > >... > Thanks, > Jerry A couple of questions/comments. With regard to the Priority parameters, it was not at all clear to me (even going back and reading it again) that you could only populate ONE pair: OR but NOT BOTH. If that is the case, then it needs to be made clearer in the text. In fact, it isn't even clear that admission/RPH have to be there as a pair. The text says: " As specified in [RFC3181], and are 16-bit integer values and both MUST be populated if the parameter is used.", so it is clear that you have to have neither or both of those. But it also says: " Note that the parameter MAY be used in combination with the parameter, which depends on the supported QOSM." which leads me to believe you can have one without the other. It also says: "[SIP-PRIORITY] defines a resource priority header (RPH) with parameters "RPH Namespace" and "RPH Priority" combination, and if populated is applicable only to flows with high reservation priority," If "reservations priority" = "admission priority" (and I think it probably does), then it would be clearer to use one term instead of two. This text then implies to me that it is permissible to have "admission priority" without "RPH", but not permissible to have "RPH" without "admission priority" (although it might also mean that RPH is ignored in instances without "admission priority"). Then my next question is - Why can't you have ALL FOUR of ? or three ? or just one ? as well as the cases with exactly two of them? I can certainly think of use cases. For instance, if you want to implement eMLPP-like functionality (as defined in 3GPP), you would want an (corresponding to the "queueing allowed" part of eMLPP) as well as (corresponding to the "preemption capable" and "may be preempted" parts of eMLPP). Am I missing something? Thanks, Janet _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 19 16:45:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Iv2-0007iB-Tk; Wed, 19 Jul 2006 16:45:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Iv1-0007Xv-Qb for nsis@ietf.org; Wed, 19 Jul 2006 16:45:19 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3Iv0-0003mK-GM for nsis@ietf.org; Wed, 19 Jul 2006 16:45:19 -0400 Received: (qmail invoked by alias); 19 Jul 2006 20:45:17 -0000 Received: from p54985EF9.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.94.249] by mail.gmx.net (mp027) with SMTP; 19 Jul 2006 22:45:17 +0200 X-Authenticated: #29516787 Message-ID: <44BE99DB.7080703@gmx.net> Date: Wed, 19 Jul 2006 22:45:15 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [NSIS] IETF#66 Meeting Minutes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, please take a look at the meeting minutes: http://www3.ietf.org/proceedings/06jul/minutes/nsis.txt (first version) Thanks to Al, Gabor, Victor and Martin. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 19 16:47:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3IxI-0008IR-FO; Wed, 19 Jul 2006 16:47:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3IxG-0008He-Ng for nsis@ietf.org; Wed, 19 Jul 2006 16:47:38 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3IxF-00048l-BK for nsis@ietf.org; Wed, 19 Jul 2006 16:47:38 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1153341959!6451!26 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 25259 invoked from network); 19 Jul 2006 20:47:35 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-120.messagelabs.com with SMTP; 19 Jul 2006 20:47:35 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452002D7DC0; Wed, 19 Jul 2006 16:47:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Wed, 19 Jul 2006 15:47:34 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7B2D@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: AcarXO4V7vdDb7xRQ42S797irNCtIwAE15vA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Janet P Gunn" X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Janet, See below.=20 > -----Original Message----- > From: Janet P Gunn [mailto:jgunn6@csc.com]=20 > Sent: Wednesday, July 19, 2006 1:58 PM > To: Ash, Gerald R (Jerry), ALABS > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org; Hancock,Robert > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 > "Ash, Gerald R \(Jerry\), ALABS" wrote on 07/18/2006 > 05:09:59 PM: >=20 > > ... > > Also, I agree with the above characterization. We can group into > > only 3 mandatory QSPEC QoS Description parameters (containers), as > follows: > > > > 1. : ; > > (populate only one) > > 2. : ; ; > > (populate only one) > > 3. : ; (populate > > only one pair) > > > >... > > Thanks, > > Jerry >=20 > A couple of questions/comments. >=20 > With regard to the Priority parameters, it was not at all=20 > clear to me (even > going back and reading it again) that you could only populate=20 > ONE pair: > OR but NOT BOTH. >=20 > If that is the case, then it needs to be made clearer in the text. In > fact, it isn't even clear that admission/RPH have to be there=20 > as a pair. Agreed. The text has to be clearer on these points (there was also some prior comment on this on the list). =20 > The text says: > " As specified in [RFC3181], and Priority> are 16-bit integer values and both MUST be=20 > populated if the > parameter is used.", so it is clear that you have to have=20 > neither or > both of those. >=20 > But it also says: > " Note that the parameter MAY be used in > combination with the parameter, which depends on the > supported QOSM." which leads me to believe you can have=20 > one without the > other. Right. =20 > It also says: > "[SIP-PRIORITY] defines a resource priority header (RPH) with > parameters "RPH Namespace" and "RPH Priority" combination, and if > populated is applicable only to flows with high=20 > reservation priority," >=20 > If "reservations priority" =3D "admission priority" (and I=20 > think it probably > does), then it would be clearer to use one term instead of=20 > two. =20 Good point, I agree. > This text > then implies to me that it is permissible to have "admission priority" > without "RPH", but not permissible to have "RPH" without "admission > priority" (although it might also mean that RPH is ignored in=20 > instances > without "admission priority"). Right. This should be clarified also. =20 > Then my next question is - Why can't you have ALL FOUR of > ? > or three > ? > or just one > ? > as well as the cases with exactly two of them? priority without RPH is allowed, which needs to be better clarified as per above comments. =20 > I can certainly think of use cases. For instance, if you=20 > want to implement > eMLPP-like functionality (as defined in 3GPP), you would want=20 > an priority> (corresponding to the "queueing allowed" part of=20 > eMLPP) as well > as (corresponding to the "preemption=20 > capable" and > "may be preempted" parts of eMLPP). >=20 > Am I missing something? The procedures for the cases of two parameters being used, that is priority and priority are given in normative references. Similarly, there need to be referenced normative procedures for how to treat the case of 3 or all 4 being populated, if these are also specified: Are there such normative references that specify procedures for how to handle these above cases or 3 or 4 parameters being specified? Alternatively, procedures for these cases can be specified in the QSPEC document. If this approach is used, suggested text is appreciated. Another approach is that the procedures for the cases of 3 or 4 parameters being used can be contained in separate QOSM specification documents (that would be pointed out the text in the QSPEC document).=20 Thanks, Jerry =20 > Thanks, >=20 > Janet _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 19 17:15:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JNv-0005nr-9N; Wed, 19 Jul 2006 17:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JNu-0005nh-Nm for nsis@ietf.org; Wed, 19 Jul 2006 17:15:10 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3JNt-0002Sc-Cz for nsis@ietf.org; Wed, 19 Jul 2006 17:15:10 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k6JLF80U029399; Wed, 19 Jul 2006 17:15:08 -0400 (EDT) In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7B2D@KCCLUST06EVS1.ugd.att.com> Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? To: "Ash, Gerald R \(Jerry\), ALABS" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Wed, 19 Jul 2006 17:15:06 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/19/2006 05:13:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I will find the appropriate references for eMLPP in 3GPP. 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. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- "Ash, Gerald R \(Jerry\), ALABS" wrote on 07/19/2006 04:47:34 PM: > Janet, > > See below. > > > -----Original Message----- > > From: Janet P Gunn [mailto:jgunn6@csc.com] > > Sent: Wednesday, July 19, 2006 1:58 PM > > To: Ash, Gerald R (Jerry), ALABS > > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org; Hancock,Robert > > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory > > parameter list? > > > > "Ash, Gerald R \(Jerry\), ALABS" wrote on 07/18/2006 > > 05:09:59 PM: > > > > > ... > > > Also, I agree with the above characterization. We can group into > > > only 3 mandatory QSPEC QoS Description parameters (containers), as > > follows: > > > > > > 1. : ; > > > (populate only one) > > > 2. : ; ; > > > (populate only one) > > > 3. : ; (populate > > > only one pair) > > > > > >... > > > Thanks, > > > Jerry > > > > A couple of questions/comments. > > > > With regard to the Priority parameters, it was not at all > > clear to me (even > > going back and reading it again) that you could only populate > > ONE pair: > > OR but NOT BOTH. > > > > If that is the case, then it needs to be made clearer in the text. In > > fact, it isn't even clear that admission/RPH have to be there > > as a pair. > > Agreed. The text has to be clearer on these points (there was also some > prior comment on this on the list). > > > The text says: > > " As specified in [RFC3181], and > Priority> are 16-bit integer values and both MUST be > > populated if the > > parameter is used.", so it is clear that you have to have > > neither or > > both of those. > > > > But it also says: > > " Note that the parameter MAY be used in > > combination with the parameter, which depends on the > > supported QOSM." which leads me to believe you can have > > one without the > > other. > > Right. > > > It also says: > > "[SIP-PRIORITY] defines a resource priority header (RPH) with > > parameters "RPH Namespace" and "RPH Priority" combination, and if > > populated is applicable only to flows with high > > reservation priority," > > > > If "reservations priority" = "admission priority" (and I > > think it probably > > does), then it would be clearer to use one term instead of > > two. > > Good point, I agree. > > > This text > > then implies to me that it is permissible to have "admission priority" > > without "RPH", but not permissible to have "RPH" without "admission > > priority" (although it might also mean that RPH is ignored in > > instances > > without "admission priority"). > > Right. This should be clarified also. > > > Then my next question is - Why can't you have ALL FOUR of > > ? > > or three > > ? > > or just one > > ? > > as well as the cases with exactly two of them? > > priority without RPH is allowed, which needs to be better > clarified as per above comments. > > > I can certainly think of use cases. For instance, if you > > want to implement > > eMLPP-like functionality (as defined in 3GPP), you would want > > an > priority> (corresponding to the "queueing allowed" part of > > eMLPP) as well > > as (corresponding to the "preemption > > capable" and > > "may be preempted" parts of eMLPP). > > > > Am I missing something? > > The procedures for the cases of two parameters being used, that is > priority and > priority > are given in normative references. > > Similarly, there need to be referenced normative procedures for how to > treat the case of 3 or all 4 being populated, if these are also > specified: > > > > Are there such normative references that specify procedures for how to > handle these above cases or 3 or 4 parameters being specified? > > Alternatively, procedures for these cases can be specified in the QSPEC > document. If this approach is used, suggested text is appreciated. > > Another approach is that the procedures for the cases of 3 or 4 > parameters being used can be contained in separate QOSM specification > documents (that would be pointed out the text in the QSPEC document). > > Thanks, > Jerry > > > Thanks, > > > > Janet _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 19 18:01:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3K70-0003U0-Oa; Wed, 19 Jul 2006 18:01:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3K6z-0003Qb-4h for nsis@ietf.org; Wed, 19 Jul 2006 18:01:45 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3JyQ-0004bw-DR for nsis@ietf.org; Wed, 19 Jul 2006 17:52:55 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k6JLqrTo008132; Wed, 19 Jul 2006 17:52:54 -0400 (EDT) In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7B2D@KCCLUST06EVS1.ugd.att.com> Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? To: "Ash, Gerald R \(Jerry\), ALABS" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Wed, 19 Jul 2006 17:52:37 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/19/2006 05:51:41 PM MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0072969484==" Errors-To: nsis-bounces@ietf.org --===============0072969484== Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 DQoNCg0KDQpKZXJyeSwNCg0KSGVyZSBhcmUgc29tZSBPTEQgKHJlbGVhc2UgOTkpIG5vcm1hdGl2 ZSByZWZlcmVuY2VzIGZvciBlTUxQUC4NCg0KIDNHUFAgVFMgMjIuMDY3IHZlcnNpb24gMy4wLjEg KDE5OTktMTApLCDigJwzcmQgR2VuZXJhdGlvbiBQYXJ0bmVyc2hpcA0KUHJvamVjdDsNClRlY2hu aWNhbCBTcGVjaWZpY2F0aW9uIEdyb3VwIFNlcnZpY2VzIGFuZCBTeXN0ZW0gQXNwZWN0czsgZW5o YW5jZWQNCk11bHRpLUxldmVsDQpQcmVjZWRlbmNlIGFuZCBQcmUtZW1wdGlvbiAoZU1MUFApIOKA kyBTdGFnZSAxIChSZWxlYXNlIDE5OTkpLuKAnQ0KDQogM0dQUCBUUyAyMy4wNjcgdmVyc2lvbiAz LjMuMCAoMjAwMS0wNiksIOKAnDNyZCBHZW5lcmF0aW9uIFBhcnRuZXJzaGlwDQpQcm9qZWN0Ow0K VGVjaG5pY2FsIFNwZWNpZmljYXRpb24gR3JvdXAgQ29yZSBOZXR3b3JrOyBlbmhhbmNlZCBNdWx0 aS1MZXZlbCBQcmVjZWRlbmNlDQphbmQNClByZS1lbXB0aW9uIChlTUxQUCkg4oCTIFN0YWdlIDIg KFJlbGVhc2UgMTk5OSku4oCdDQoNCiAzR1BQIFRTIDI0LjA2NyB2ZXJzaW9uIDMuMi4wICgyMDAx LTA2KSwg4oCcM3JkIEdlbmVyYXRpb24gUGFydG5lcnNoaXANClByb2plY3Q7DQpUZWNobmljYWwg U3BlY2lmaWNhdGlvbiBHcm91cCBDb3JlIE5ldHdvcms7IGVuaGFuY2VkIE11bHRpLUxldmVsIFBy ZWNlZGVuY2UNCmFuZA0KUHJlLWVtcHRpb24gKGVNTFBQKSDigJMgU3RhZ2UgMyAoUmVsZWFzZSAx OTk5KS7igJ0NCg0KSSdsbCB3b3JrIG9uIG5haWxpbmcgZG93biBzb21lIG1vcmUgcmVjZW50IG9u ZXMuDQoNCkphbmV0DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlDQpkZWxldGUgd2l0aG91 dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBp bg0KZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hh bGwgbm90IG9wZXJhdGUgdG8NCmJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFj dCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbg0KYWdyZWVtZW50IG9yIGdvdmVy bm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbA0K Zm9yIHN1Y2ggcHVycG9zZS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQoiQXNoLCBHZXJhbGQgUiBcKEplcnJ5XCks IEFMQUJTIiA8Z2FzaEBhdHQuY29tPiB3cm90ZSBvbiAwNy8xOS8yMDA2DQowNDo0NzozNCBQTToN Cg0KPiBKYW5ldCwNCj4NCj4gU2VlIGJlbG93Lg0KPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogSmFuZXQgUCBHdW5uIFttYWlsdG86amd1bm42QGNzYy5jb21dDQo+ ID4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDE5LCAyMDA2IDE6NTggUE0NCj4gPiBUbzogQXNoLCBH ZXJhbGQgUiAoSmVycnkpLCBBTEFCUw0KPiA+IENjOiBBc2gsIEdlcmFsZCBSIChKZXJyeSksIEFM QUJTOyBuc2lzQGlldGYub3JnOyBIYW5jb2NrLFJvYmVydA0KPiA+IFN1YmplY3Q6IFJFOiBBVzog W05TSVNdIEFueSByZXNvbHV0aW9uIHRvIHRoZSBRU1BFQyBtYW5kYXRvcnkNCj4gPiBwYXJhbWV0 ZXIgbGlzdD8NCj4gPg0KPiA+ICJBc2gsIEdlcmFsZCBSIFwoSmVycnlcKSwgQUxBQlMiIDxnYXNo QGF0dC5jb20+IHdyb3RlIG9uIDA3LzE4LzIwMDYNCj4gPiAwNTowOTo1OSBQTToNCj4gPg0KPiA+ ID4gLi4uDQo+ID4gPiBBbHNvLCBJIGFncmVlIHdpdGggdGhlIGFib3ZlIGNoYXJhY3Rlcml6YXRp b24uICBXZSBjYW4gZ3JvdXAgaW50bw0KPiA+ID4gb25seSAzIG1hbmRhdG9yeSBRU1BFQyBRb1Mg RGVzY3JpcHRpb24gcGFyYW1ldGVycyAoY29udGFpbmVycyksIGFzDQo+ID4gZm9sbG93czoNCj4g PiA+DQo+ID4gPiAxLiA8VHJhZmZpYz46IDxiYW5kd2lkdGg+OyA8dG9rZW4gYnVja2V0IChmaXJz dCBpbnN0YW5jZSk+DQo+ID4gPiAocG9wdWxhdGUgb25seSBvbmUpDQo+ID4gPiAyLiA8UW9TIGNs YXNzPjogPFBIQiBjbGFzcz47IDx5LjE1NDEgY2xhc3M+OyA8RFNURSBjbGFzcyB0eXBlPg0KPiA+ ID4gKHBvcHVsYXRlIG9ubHkgb25lKQ0KPiA+ID4gMy4gPFByaW9yaXR5PjogPHByZWVtcHRpb24v ZGVmZW5kaW5nPjsgPGFkbWlzc2lvbi9SUEg+IChwb3B1bGF0ZQ0KPiA+ID4gb25seSBvbmUgcGFp cikNCj4gPiA+DQo+ID4gPi4uLg0KPiA+ID4gVGhhbmtzLA0KPiA+ID4gSmVycnkNCj4gPg0KPiA+ IEEgY291cGxlIG9mIHF1ZXN0aW9ucy9jb21tZW50cy4NCj4gPg0KPiA+IFdpdGggcmVnYXJkIHRv IHRoZSBQcmlvcml0eSBwYXJhbWV0ZXJzLCBpdCB3YXMgbm90IGF0IGFsbA0KPiA+IGNsZWFyIHRv IG1lIChldmVuDQo+ID4gZ29pbmcgYmFjayBhbmQgcmVhZGluZyBpdCBhZ2FpbikgdGhhdCB5b3Ug Y291bGQgb25seSBwb3B1bGF0ZQ0KPiA+IE9ORSBwYWlyOg0KPiA+IDxwcmVlbXB0aW9uL2RlZmVu ZGluZz4gT1IgPGFkbWlzc2lvbi9SUEg+IGJ1dCBOT1QgQk9USC4NCj4gPg0KPiA+IElmIHRoYXQg aXMgdGhlIGNhc2UsIHRoZW4gaXQgbmVlZHMgdG8gYmUgbWFkZSBjbGVhcmVyIGluIHRoZSB0ZXh0 LiAgSW4NCj4gPiBmYWN0LCBpdCBpc24ndCBldmVuIGNsZWFyIHRoYXQgYWRtaXNzaW9uL1JQSCBo YXZlIHRvIGJlIHRoZXJlDQo+ID4gYXMgYSBwYWlyLg0KPg0KPiBBZ3JlZWQuICBUaGUgdGV4dCBo YXMgdG8gYmUgY2xlYXJlciBvbiB0aGVzZSBwb2ludHMgKHRoZXJlIHdhcyBhbHNvIHNvbWUNCj4g cHJpb3IgY29tbWVudCBvbiB0aGlzIG9uIHRoZSBsaXN0KS4NCj4NCj4gPiBUaGUgdGV4dCBzYXlz Og0KPiA+ICIgICBBcyBzcGVjaWZpZWQgaW4gW1JGQzMxODFdLCA8UHJlZW1wdGlvbiBQcmlvcml0 eT4gYW5kIDxEZWZlbmRpbmcNCj4gPiAgICBQcmlvcml0eT4gYXJlIDE2LWJpdCBpbnRlZ2VyIHZh bHVlcyBhbmQgYm90aCBNVVNUIGJlDQo+ID4gcG9wdWxhdGVkIGlmIHRoZQ0KPiA+ICAgIHBhcmFt ZXRlciBpcyB1c2VkLiIsIHNvIGl0IGlzIGNsZWFyIHRoYXQgeW91IGhhdmUgdG8gaGF2ZQ0KPiA+ IG5laXRoZXIgb3INCj4gPiBib3RoIG9mIHRob3NlLg0KPiA+DQo+ID4gQnV0IGl0IGFsc28gc2F5 czoNCj4gPiAiICAgTm90ZSB0aGF0IHRoZSA8QWRtaXNzaW9uIFByaW9yaXR5PiBwYXJhbWV0ZXIg TUFZIGJlIHVzZWQgaW4NCj4gPiAgICBjb21iaW5hdGlvbiB3aXRoIHRoZSA8UlBIIFByaW9yaXR5 PiBwYXJhbWV0ZXIsIHdoaWNoIGRlcGVuZHMgb24gdGhlDQo+ID4gICAgc3VwcG9ydGVkIFFPU00u IiB3aGljaCBsZWFkcyBtZSB0byBiZWxpZXZlIHlvdSBjYW4gaGF2ZQ0KPiA+IG9uZSB3aXRob3V0 IHRoZQ0KPiA+IG90aGVyLg0KPg0KPiBSaWdodC4NCj4NCj4gPiBJdCBhbHNvIHNheXM6DQo+ID4g IltTSVAtUFJJT1JJVFldIGRlZmluZXMgYSByZXNvdXJjZSBwcmlvcml0eSBoZWFkZXIgKFJQSCkg d2l0aA0KPiA+ICAgIHBhcmFtZXRlcnMgIlJQSCBOYW1lc3BhY2UiIGFuZCAiUlBIIFByaW9yaXR5 IiBjb21iaW5hdGlvbiwgYW5kIGlmDQo+ID4gICAgcG9wdWxhdGVkIGlzIGFwcGxpY2FibGUgb25s eSB0byBmbG93cyB3aXRoIGhpZ2gNCj4gPiByZXNlcnZhdGlvbiBwcmlvcml0eSwiDQo+ID4NCj4g PiBJZiAicmVzZXJ2YXRpb25zIHByaW9yaXR5IiA9ICJhZG1pc3Npb24gIHByaW9yaXR5IiAoYW5k IEkNCj4gPiB0aGluayBpdCBwcm9iYWJseQ0KPiA+IGRvZXMpLCB0aGVuIGl0IHdvdWxkIGJlIGNs ZWFyZXIgdG8gdXNlIG9uZSB0ZXJtIGluc3RlYWQgb2YNCj4gPiB0d28uDQo+DQo+IEdvb2QgcG9p bnQsIEkgYWdyZWUuDQo+DQo+ID4gVGhpcyB0ZXh0DQo+ID4gdGhlbiBpbXBsaWVzIHRvIG1lIHRo YXQgaXQgaXMgcGVybWlzc2libGUgdG8gaGF2ZSAiYWRtaXNzaW9uIHByaW9yaXR5Ig0KPiA+IHdp dGhvdXQgIlJQSCIsIGJ1dCBub3QgcGVybWlzc2libGUgdG8gaGF2ZSAiUlBIIiB3aXRob3V0ICJh ZG1pc3Npb24NCj4gPiBwcmlvcml0eSIgKGFsdGhvdWdoIGl0IG1pZ2h0IGFsc28gbWVhbiB0aGF0 IFJQSCBpcyBpZ25vcmVkIGluDQo+ID4gaW5zdGFuY2VzDQo+ID4gd2l0aG91dCAiYWRtaXNzaW9u IHByaW9yaXR5IikuDQo+DQo+IFJpZ2h0LiAgVGhpcyBzaG91bGQgYmUgY2xhcmlmaWVkIGFsc28u DQo+DQo+ID4gVGhlbiBteSBuZXh0IHF1ZXN0aW9uIGlzIC0gV2h5IGNhbid0IHlvdSBoYXZlIEFM TCBGT1VSIG9mDQo+ID4gIDxwcmVlbXB0aW9uL2RlZmVuZGluZy9hZG1pc3Npb24vUlBIPj8NCj4g PiBvciB0aHJlZQ0KPiA+IDxwcmVlbXB0aW9uL2RlZmVuZGluZy9hZG1pc3Npb24+Pw0KPiA+IG9y IGp1c3Qgb25lDQo+ID4gPGFkbWlzc2lvbj4/DQo+ID4gYXMgd2VsbCBhcyB0aGUgY2FzZXMgd2l0 aCBleGFjdGx5IHR3byBvZiB0aGVtPw0KPg0KPiA8YWRtaXNzaW9uPiBwcmlvcml0eSB3aXRob3V0 IFJQSCBpcyBhbGxvd2VkLCB3aGljaCBuZWVkcyB0byBiZSBiZXR0ZXINCj4gY2xhcmlmaWVkIGFz IHBlciBhYm92ZSBjb21tZW50cy4NCj4NCj4gPiBJIGNhbiBjZXJ0YWlubHkgdGhpbmsgb2YgdXNl IGNhc2VzLiAgRm9yIGluc3RhbmNlLCBpZiB5b3UNCj4gPiB3YW50IHRvIGltcGxlbWVudA0KPiA+ IGVNTFBQLWxpa2UgZnVuY3Rpb25hbGl0eSAoYXMgZGVmaW5lZCBpbiAzR1BQKSwgeW91IHdvdWxk IHdhbnQNCj4gPiBhbiA8YWRtaXNzaW9uDQo+ID4gcHJpb3JpdHk+IChjb3JyZXNwb25kaW5nIHRv IHRoZSAicXVldWVpbmcgYWxsb3dlZCIgcGFydCBvZg0KPiA+IGVNTFBQKSBhcyB3ZWxsDQo+ID4g YXMgPHByZWVtcHRpb24vZGVmZW5kaW5nPiAoY29ycmVzcG9uZGluZyB0byB0aGUgInByZWVtcHRp b24NCj4gPiBjYXBhYmxlIiBhbmQNCj4gPiAibWF5IGJlIHByZWVtcHRlZCIgcGFydHMgb2YgZU1M UFApLg0KPiA+DQo+ID4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCj4NCj4gVGhlIHByb2NlZHVy ZXMgZm9yIHRoZSBjYXNlcyBvZiB0d28gcGFyYW1ldGVycyBiZWluZyB1c2VkLCB0aGF0IGlzDQo+ IDxwcmVlbXB0aW9uL2RlZmVuZGluZz4gcHJpb3JpdHkgYW5kDQo+IDxhZG1pc3Npb24vUlBIPiBw cmlvcml0eQ0KPiBhcmUgZ2l2ZW4gaW4gbm9ybWF0aXZlIHJlZmVyZW5jZXMuDQo+DQo+IFNpbWls YXJseSwgdGhlcmUgbmVlZCB0byBiZSByZWZlcmVuY2VkIG5vcm1hdGl2ZSBwcm9jZWR1cmVzIGZv ciBob3cgdG8NCj4gdHJlYXQgdGhlIGNhc2Ugb2YgMyBvciBhbGwgNCBiZWluZyBwb3B1bGF0ZWQs IGlmIHRoZXNlIGFyZSBhbHNvDQo+IHNwZWNpZmllZDoNCj4gPHByZWVtcHRpb24vZGVmZW5kaW5n L2FkbWlzc2lvbj4NCj4gPHByZWVtcHRpb24vZGVmZW5kaW5nL2FkbWlzc2lvbi9SUEg+DQo+DQo+ IEFyZSB0aGVyZSBzdWNoIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRoYXQgc3BlY2lmeSBwcm9jZWR1 cmVzIGZvciBob3cgdG8NCj4gaGFuZGxlIHRoZXNlIGFib3ZlIGNhc2VzIG9yIDMgb3IgNCBwYXJh bWV0ZXJzIGJlaW5nIHNwZWNpZmllZD8NCj4NCj4gQWx0ZXJuYXRpdmVseSwgcHJvY2VkdXJlcyBm b3IgdGhlc2UgY2FzZXMgY2FuIGJlIHNwZWNpZmllZCBpbiB0aGUgUVNQRUMNCj4gZG9jdW1lbnQu ICBJZiB0aGlzIGFwcHJvYWNoIGlzIHVzZWQsIHN1Z2dlc3RlZCB0ZXh0IGlzIGFwcHJlY2lhdGVk Lg0KPg0KPiBBbm90aGVyIGFwcHJvYWNoIGlzIHRoYXQgdGhlIHByb2NlZHVyZXMgZm9yIHRoZSBj YXNlcyBvZiAzIG9yIDQNCj4gcGFyYW1ldGVycyBiZWluZyB1c2VkIGNhbiBiZSBjb250YWluZWQg aW4gc2VwYXJhdGUgUU9TTSBzcGVjaWZpY2F0aW9uDQo+IGRvY3VtZW50cyAodGhhdCB3b3VsZCBi ZSBwb2ludGVkIG91dCB0aGUgdGV4dCBpbiB0aGUgUVNQRUMgZG9jdW1lbnQpLg0KPg0KPiBUaGFu a3MsDQo+IEplcnJ5DQo+DQo+ID4gVGhhbmtzLA0KPiA+DQo+ID4gSmFuZXQ= --===============0072969484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0072969484==-- From nsis-bounces@ietf.org Wed Jul 19 22:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Odx-0001c2-Nj; Wed, 19 Jul 2006 22:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Odw-0001bP-EP for nsis@ietf.org; Wed, 19 Jul 2006 22:52:04 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Odw-00064l-0f for nsis@ietf.org; Wed, 19 Jul 2006 22:52:04 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k6K2q3la001187; Wed, 19 Jul 2006 22:52:03 -0400 (EDT) In-Reply-To: Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? To: Janet P Gunn X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Wed, 19 Jul 2006 22:52:00 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/19/2006 10:50:51 PM MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0991576292==" Errors-To: nsis-bounces@ietf.org --===============0991576292== Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 DQoNCg0KDQpUaGUgbmV3IHZlcnNpb25zIGFyZQ0KDQozR1BQIFRTIDIyLjA2NyBWNy4wLjAgKDIw MDYtMDMpDQpUZWNobmljYWwgU3BlY2lmaWNhdGlvbg0KM3JkIEdlbmVyYXRpb24gUGFydG5lcnNo aXAgUHJvamVjdDsNClRlY2huaWNhbCBTcGVjaWZpY2F0aW9uIEdyb3VwIFNlcnZpY2VzIGFuZCBT eXN0ZW0gQXNwZWN0czsNCmVuaGFuY2VkIE11bHRp77eTTGV2ZWwgUHJlY2VkZW5jZSBhbmQgUHJl 77eTZW1wdGlvbiBzZXJ2aWNlDQooZU1MUFApIO+3kyBTdGFnZSAxDQooUmVsZWFzZSA3KQ0KDQoz R1BQIFRTIDIzLjA2NyBWNy4xLjAgKDIwMDYtMDMpDQpUZWNobmljYWwgU3BlY2lmaWNhdGlvbg0K M3JkIEdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVjdDsNClRlY2huaWNhbCBTcGVjaWZpY2F0 aW9uIEdyb3VwIENvcmUgTmV0d29yazsNCmVuaGFuY2VkIE11bHRpLUxldmVsIFByZWNlZGVuY2Ug YW5kDQpQcmUtZW1wdGlvbiBzZXJ2aWNlIChlTUxQUCkgLSBTdGFnZSAyDQooUmVsZWFzZSA3KQ0K DQozR1BQIFRTIDI0LjA2NyBWNi4wLjAgKDIwMDQtMTIpDQpUZWNobmljYWwgU3BlY2lmaWNhdGlv bg0KM3JkIEdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVjdDsNClRlY2huaWNhbCBTcGVjaWZp Y2F0aW9uIEdyb3VwIENvcmUgTmV0d29yazsNCmVuaGFuY2VkIE11bHRpLUxldmVsIFByZWNlZGVu Y2UgYW5kDQpQcmUtZW1wdGlvbiBzZXJ2aWNlIChlTUxQUCkgLSBTdGFnZSAzDQooUmVsZWFzZSA2 KQ0KDQooSSdtIG5vdCBzdXJlIHdoZW4gdGhlIFJlbGVhc2UgNyB2ZXJzaW9uIG9mIDI0LjA2NyB3 aWxsIGJlIG91dC4pDQoNCkphbmV0DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGlzIGlzIGEgUFJJVkFURSBt ZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UNCmRl bGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRo ZSBtaXN0YWtlIGluDQpkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlz IGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0bw0KYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90 aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuDQphZ3JlZW1l bnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ug b2YgZS1tYWlsDQpmb3Igc3VjaCBwdXJwb3NlLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCkphbmV0IFAgR3Vubi9G RUQvQ1NDQENTQyB3cm90ZSBvbiAwNy8xOS8yMDA2IDA1OjUyOjM3IFBNOg0KDQo+DQo+DQo+DQo+ DQo+IEplcnJ5LA0KPg0KPiBIZXJlIGFyZSBzb21lIE9MRCAocmVsZWFzZSA5OSkgbm9ybWF0aXZl IHJlZmVyZW5jZXMgZm9yIGVNTFBQLg0KPg0KPiAgM0dQUCBUUyAyMi4wNjcgdmVyc2lvbiAzLjAu MSAoMTk5OS0xMCksIOKAnDNyZCBHZW5lcmF0aW9uIFBhcnRuZXJzaGlwDQo+IFByb2plY3Q7DQo+ IFRlY2huaWNhbCBTcGVjaWZpY2F0aW9uIEdyb3VwIFNlcnZpY2VzIGFuZCBTeXN0ZW0gQXNwZWN0 czsgZW5oYW5jZWQNCj4gTXVsdGktTGV2ZWwNCj4gUHJlY2VkZW5jZSBhbmQgUHJlLWVtcHRpb24g KGVNTFBQKSDigJMgU3RhZ2UgMSAoUmVsZWFzZSAxOTk5KS7igJ0NCj4NCj4gIDNHUFAgVFMgMjMu MDY3IHZlcnNpb24gMy4zLjAgKDIwMDEtMDYpLCDigJwzcmQgR2VuZXJhdGlvbiBQYXJ0bmVyc2hp cA0KPiBQcm9qZWN0Ow0KPiBUZWNobmljYWwgU3BlY2lmaWNhdGlvbiBHcm91cCBDb3JlIE5ldHdv cms7IGVuaGFuY2VkIE11bHRpLUxldmVsDQpQcmVjZWRlbmNlDQo+IGFuZA0KPiBQcmUtZW1wdGlv biAoZU1MUFApIOKAkyBTdGFnZSAyIChSZWxlYXNlIDE5OTkpLuKAnQ0KPg0KPiAgM0dQUCBUUyAy NC4wNjcgdmVyc2lvbiAzLjIuMCAoMjAwMS0wNiksIOKAnDNyZCBHZW5lcmF0aW9uIFBhcnRuZXJz aGlwDQo+IFByb2plY3Q7DQo+IFRlY2huaWNhbCBTcGVjaWZpY2F0aW9uIEdyb3VwIENvcmUgTmV0 d29yazsgZW5oYW5jZWQgTXVsdGktTGV2ZWwNClByZWNlZGVuY2UNCj4gYW5kDQo+IFByZS1lbXB0 aW9uIChlTUxQUCkg4oCTIFN0YWdlIDMgKFJlbGVhc2UgMTk5OSku4oCdDQo+DQo+IEknbGwgd29y ayBvbiBuYWlsaW5nIGRvd24gc29tZSBtb3JlIHJlY2VudCBvbmVzLg0KPg0KPiBKYW5ldA0KPg0K Pg0KPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KPg0KPiBUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UNCj4gZGVsZXRlIHdpdGhvdXQgY29w eWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4NCj4g ZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwg bm90IG9wZXJhdGUgdG8NCj4gYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0 IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdA0Kd3JpdHRlbg0KPiBhZ3JlZW1lbnQgb3IgZ292 ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWls DQo+IGZvciBzdWNoIHB1cnBvc2UuDQo+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+DQo+DQo+DQo+ICJBc2gsIEdlcmFs ZCBSIFwoSmVycnlcKSwgQUxBQlMiIDxnYXNoQGF0dC5jb20+IHdyb3RlIG9uIDA3LzE5LzIwMDYN Cj4gMDQ6NDc6MzQgUE06DQo+DQo+ID4gSmFuZXQsDQo+ID4NCj4gPiBTZWUgYmVsb3cuDQo+ID4N Cj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBKYW5ldCBQIEd1 bm4gW21haWx0bzpqZ3VubjZAY3NjLmNvbV0NCj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAx OSwgMjAwNiAxOjU4IFBNDQo+ID4gPiBUbzogQXNoLCBHZXJhbGQgUiAoSmVycnkpLCBBTEFCUw0K PiA+ID4gQ2M6IEFzaCwgR2VyYWxkIFIgKEplcnJ5KSwgQUxBQlM7IG5zaXNAaWV0Zi5vcmc7IEhh bmNvY2ssUm9iZXJ0DQo+ID4gPiBTdWJqZWN0OiBSRTogQVc6IFtOU0lTXSBBbnkgcmVzb2x1dGlv biB0byB0aGUgUVNQRUMgbWFuZGF0b3J5DQo+ID4gPiBwYXJhbWV0ZXIgbGlzdD8NCj4gPiA+DQo+ ID4gPiAiQXNoLCBHZXJhbGQgUiBcKEplcnJ5XCksIEFMQUJTIiA8Z2FzaEBhdHQuY29tPiB3cm90 ZSBvbiAwNy8xOC8yMDA2DQo+ID4gPiAwNTowOTo1OSBQTToNCj4gPiA+DQo+ID4gPiA+IC4uLg0K PiA+ID4gPiBBbHNvLCBJIGFncmVlIHdpdGggdGhlIGFib3ZlIGNoYXJhY3Rlcml6YXRpb24uICBX ZSBjYW4gZ3JvdXAgaW50bw0KPiA+ID4gPiBvbmx5IDMgbWFuZGF0b3J5IFFTUEVDIFFvUyBEZXNj cmlwdGlvbiBwYXJhbWV0ZXJzIChjb250YWluZXJzKSwgYXMNCj4gPiA+IGZvbGxvd3M6DQo+ID4g PiA+DQo+ID4gPiA+IDEuIDxUcmFmZmljPjogPGJhbmR3aWR0aD47IDx0b2tlbiBidWNrZXQgKGZp cnN0IGluc3RhbmNlKT4NCj4gPiA+ID4gKHBvcHVsYXRlIG9ubHkgb25lKQ0KPiA+ID4gPiAyLiA8 UW9TIGNsYXNzPjogPFBIQiBjbGFzcz47IDx5LjE1NDEgY2xhc3M+OyA8RFNURSBjbGFzcyB0eXBl Pg0KPiA+ID4gPiAocG9wdWxhdGUgb25seSBvbmUpDQo+ID4gPiA+IDMuIDxQcmlvcml0eT46IDxw cmVlbXB0aW9uL2RlZmVuZGluZz47IDxhZG1pc3Npb24vUlBIPiAocG9wdWxhdGUNCj4gPiA+ID4g b25seSBvbmUgcGFpcikNCj4gPiA+ID4NCj4gPiA+ID4uLi4NCj4gPiA+ID4gVGhhbmtzLA0KPiA+ ID4gPiBKZXJyeQ0KPiA+ID4NCj4gPiA+IEEgY291cGxlIG9mIHF1ZXN0aW9ucy9jb21tZW50cy4N Cj4gPiA+DQo+ID4gPiBXaXRoIHJlZ2FyZCB0byB0aGUgUHJpb3JpdHkgcGFyYW1ldGVycywgaXQg d2FzIG5vdCBhdCBhbGwNCj4gPiA+IGNsZWFyIHRvIG1lIChldmVuDQo+ID4gPiBnb2luZyBiYWNr IGFuZCByZWFkaW5nIGl0IGFnYWluKSB0aGF0IHlvdSBjb3VsZCBvbmx5IHBvcHVsYXRlDQo+ID4g PiBPTkUgcGFpcjoNCj4gPiA+IDxwcmVlbXB0aW9uL2RlZmVuZGluZz4gT1IgPGFkbWlzc2lvbi9S UEg+IGJ1dCBOT1QgQk9USC4NCj4gPiA+DQo+ID4gPiBJZiB0aGF0IGlzIHRoZSBjYXNlLCB0aGVu IGl0IG5lZWRzIHRvIGJlIG1hZGUgY2xlYXJlciBpbiB0aGUgdGV4dC4NCkluDQo+ID4gPiBmYWN0 LCBpdCBpc24ndCBldmVuIGNsZWFyIHRoYXQgYWRtaXNzaW9uL1JQSCBoYXZlIHRvIGJlIHRoZXJl DQo+ID4gPiBhcyBhIHBhaXIuDQo+ID4NCj4gPiBBZ3JlZWQuICBUaGUgdGV4dCBoYXMgdG8gYmUg Y2xlYXJlciBvbiB0aGVzZSBwb2ludHMgKHRoZXJlIHdhcyBhbHNvDQpzb21lDQo+ID4gcHJpb3Ig Y29tbWVudCBvbiB0aGlzIG9uIHRoZSBsaXN0KS4NCj4gPg0KPiA+ID4gVGhlIHRleHQgc2F5czoN Cj4gPiA+ICIgICBBcyBzcGVjaWZpZWQgaW4gW1JGQzMxODFdLCA8UHJlZW1wdGlvbiBQcmlvcml0 eT4gYW5kIDxEZWZlbmRpbmcNCj4gPiA+ICAgIFByaW9yaXR5PiBhcmUgMTYtYml0IGludGVnZXIg dmFsdWVzIGFuZCBib3RoIE1VU1QgYmUNCj4gPiA+IHBvcHVsYXRlZCBpZiB0aGUNCj4gPiA+ICAg IHBhcmFtZXRlciBpcyB1c2VkLiIsIHNvIGl0IGlzIGNsZWFyIHRoYXQgeW91IGhhdmUgdG8gaGF2 ZQ0KPiA+ID4gbmVpdGhlciBvcg0KPiA+ID4gYm90aCBvZiB0aG9zZS4NCj4gPiA+DQo+ID4gPiBC dXQgaXQgYWxzbyBzYXlzOg0KPiA+ID4gIiAgIE5vdGUgdGhhdCB0aGUgPEFkbWlzc2lvbiBQcmlv cml0eT4gcGFyYW1ldGVyIE1BWSBiZSB1c2VkIGluDQo+ID4gPiAgICBjb21iaW5hdGlvbiB3aXRo IHRoZSA8UlBIIFByaW9yaXR5PiBwYXJhbWV0ZXIsIHdoaWNoIGRlcGVuZHMgb24NCnRoZQ0KPiA+ ID4gICAgc3VwcG9ydGVkIFFPU00uIiB3aGljaCBsZWFkcyBtZSB0byBiZWxpZXZlIHlvdSBjYW4g aGF2ZQ0KPiA+ID4gb25lIHdpdGhvdXQgdGhlDQo+ID4gPiBvdGhlci4NCj4gPg0KPiA+IFJpZ2h0 Lg0KPiA+DQo+ID4gPiBJdCBhbHNvIHNheXM6DQo+ID4gPiAiW1NJUC1QUklPUklUWV0gZGVmaW5l cyBhIHJlc291cmNlIHByaW9yaXR5IGhlYWRlciAoUlBIKSB3aXRoDQo+ID4gPiAgICBwYXJhbWV0 ZXJzICJSUEggTmFtZXNwYWNlIiBhbmQgIlJQSCBQcmlvcml0eSIgY29tYmluYXRpb24sIGFuZCBp Zg0KPiA+ID4gICAgcG9wdWxhdGVkIGlzIGFwcGxpY2FibGUgb25seSB0byBmbG93cyB3aXRoIGhp Z2gNCj4gPiA+IHJlc2VydmF0aW9uIHByaW9yaXR5LCINCj4gPiA+DQo+ID4gPiBJZiAicmVzZXJ2 YXRpb25zIHByaW9yaXR5IiA9ICJhZG1pc3Npb24gIHByaW9yaXR5IiAoYW5kIEkNCj4gPiA+IHRo aW5rIGl0IHByb2JhYmx5DQo+ID4gPiBkb2VzKSwgdGhlbiBpdCB3b3VsZCBiZSBjbGVhcmVyIHRv IHVzZSBvbmUgdGVybSBpbnN0ZWFkIG9mDQo+ID4gPiB0d28uDQo+ID4NCj4gPiBHb29kIHBvaW50 LCBJIGFncmVlLg0KPiA+DQo+ID4gPiBUaGlzIHRleHQNCj4gPiA+IHRoZW4gaW1wbGllcyB0byBt ZSB0aGF0IGl0IGlzIHBlcm1pc3NpYmxlIHRvIGhhdmUgImFkbWlzc2lvbg0KcHJpb3JpdHkiDQo+ ID4gPiB3aXRob3V0ICJSUEgiLCBidXQgbm90IHBlcm1pc3NpYmxlIHRvIGhhdmUgIlJQSCIgd2l0 aG91dCAiYWRtaXNzaW9uDQo+ID4gPiBwcmlvcml0eSIgKGFsdGhvdWdoIGl0IG1pZ2h0IGFsc28g bWVhbiB0aGF0IFJQSCBpcyBpZ25vcmVkIGluDQo+ID4gPiBpbnN0YW5jZXMNCj4gPiA+IHdpdGhv dXQgImFkbWlzc2lvbiBwcmlvcml0eSIpLg0KPiA+DQo+ID4gUmlnaHQuICBUaGlzIHNob3VsZCBi ZSBjbGFyaWZpZWQgYWxzby4NCj4gPg0KPiA+ID4gVGhlbiBteSBuZXh0IHF1ZXN0aW9uIGlzIC0g V2h5IGNhbid0IHlvdSBoYXZlIEFMTCBGT1VSIG9mDQo+ID4gPiAgPHByZWVtcHRpb24vZGVmZW5k aW5nL2FkbWlzc2lvbi9SUEg+Pw0KPiA+ID4gb3IgdGhyZWUNCj4gPiA+IDxwcmVlbXB0aW9uL2Rl ZmVuZGluZy9hZG1pc3Npb24+Pw0KPiA+ID4gb3IganVzdCBvbmUNCj4gPiA+IDxhZG1pc3Npb24+ Pw0KPiA+ID4gYXMgd2VsbCBhcyB0aGUgY2FzZXMgd2l0aCBleGFjdGx5IHR3byBvZiB0aGVtPw0K PiA+DQo+ID4gPGFkbWlzc2lvbj4gcHJpb3JpdHkgd2l0aG91dCBSUEggaXMgYWxsb3dlZCwgd2hp Y2ggbmVlZHMgdG8gYmUgYmV0dGVyDQo+ID4gY2xhcmlmaWVkIGFzIHBlciBhYm92ZSBjb21tZW50 cy4NCj4gPg0KPiA+ID4gSSBjYW4gY2VydGFpbmx5IHRoaW5rIG9mIHVzZSBjYXNlcy4gIEZvciBp bnN0YW5jZSwgaWYgeW91DQo+ID4gPiB3YW50IHRvIGltcGxlbWVudA0KPiA+ID4gZU1MUFAtbGlr ZSBmdW5jdGlvbmFsaXR5IChhcyBkZWZpbmVkIGluIDNHUFApLCB5b3Ugd291bGQgd2FudA0KPiA+ ID4gYW4gPGFkbWlzc2lvbg0KPiA+ID4gcHJpb3JpdHk+IChjb3JyZXNwb25kaW5nIHRvIHRoZSAi cXVldWVpbmcgYWxsb3dlZCIgcGFydCBvZg0KPiA+ID4gZU1MUFApIGFzIHdlbGwNCj4gPiA+IGFz IDxwcmVlbXB0aW9uL2RlZmVuZGluZz4gKGNvcnJlc3BvbmRpbmcgdG8gdGhlICJwcmVlbXB0aW9u DQo+ID4gPiBjYXBhYmxlIiBhbmQNCj4gPiA+ICJtYXkgYmUgcHJlZW1wdGVkIiBwYXJ0cyBvZiBl TUxQUCkuDQo+ID4gPg0KPiA+ID4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCj4gPg0KPiA+IFRo ZSBwcm9jZWR1cmVzIGZvciB0aGUgY2FzZXMgb2YgdHdvIHBhcmFtZXRlcnMgYmVpbmcgdXNlZCwg dGhhdCBpcw0KPiA+IDxwcmVlbXB0aW9uL2RlZmVuZGluZz4gcHJpb3JpdHkgYW5kDQo+ID4gPGFk bWlzc2lvbi9SUEg+IHByaW9yaXR5DQo+ID4gYXJlIGdpdmVuIGluIG5vcm1hdGl2ZSByZWZlcmVu Y2VzLg0KPiA+DQo+ID4gU2ltaWxhcmx5LCB0aGVyZSBuZWVkIHRvIGJlIHJlZmVyZW5jZWQgbm9y bWF0aXZlIHByb2NlZHVyZXMgZm9yIGhvdyB0bw0KPiA+IHRyZWF0IHRoZSBjYXNlIG9mIDMgb3Ig YWxsIDQgYmVpbmcgcG9wdWxhdGVkLCBpZiB0aGVzZSBhcmUgYWxzbw0KPiA+IHNwZWNpZmllZDoN Cj4gPiA8cHJlZW1wdGlvbi9kZWZlbmRpbmcvYWRtaXNzaW9uPg0KPiA+IDxwcmVlbXB0aW9uL2Rl ZmVuZGluZy9hZG1pc3Npb24vUlBIPg0KPiA+DQo+ID4gQXJlIHRoZXJlIHN1Y2ggbm9ybWF0aXZl IHJlZmVyZW5jZXMgdGhhdCBzcGVjaWZ5IHByb2NlZHVyZXMgZm9yIGhvdyB0bw0KPiA+IGhhbmRs ZSB0aGVzZSBhYm92ZSBjYXNlcyBvciAzIG9yIDQgcGFyYW1ldGVycyBiZWluZyBzcGVjaWZpZWQ/ DQo+ID4NCj4gPiBBbHRlcm5hdGl2ZWx5LCBwcm9jZWR1cmVzIGZvciB0aGVzZSBjYXNlcyBjYW4g YmUgc3BlY2lmaWVkIGluIHRoZSBRU1BFQw0KPiA+IGRvY3VtZW50LiAgSWYgdGhpcyBhcHByb2Fj aCBpcyB1c2VkLCBzdWdnZXN0ZWQgdGV4dCBpcyBhcHByZWNpYXRlZC4NCj4gPg0KPiA+IEFub3Ro ZXIgYXBwcm9hY2ggaXMgdGhhdCB0aGUgcHJvY2VkdXJlcyBmb3IgdGhlIGNhc2VzIG9mIDMgb3Ig NA0KPiA+IHBhcmFtZXRlcnMgYmVpbmcgdXNlZCBjYW4gYmUgY29udGFpbmVkIGluIHNlcGFyYXRl IFFPU00gc3BlY2lmaWNhdGlvbg0KPiA+IGRvY3VtZW50cyAodGhhdCB3b3VsZCBiZSBwb2ludGVk IG91dCB0aGUgdGV4dCBpbiB0aGUgUVNQRUMgZG9jdW1lbnQpLg0KPiA+DQo+ID4gVGhhbmtzLA0K PiA+IEplcnJ5DQo+ID4NCj4gPiA+IFRoYW5rcywNCj4gPiA+DQo+ID4gPiBKYW5ldF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5zaXMgbWFpbGluZyBs aXN0DQo+IG5zaXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbnNpcw== --===============0991576292== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0991576292==-- From nsis-bounces@ietf.org Wed Jul 19 23:02:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Onc-0002Gz-CX; Wed, 19 Jul 2006 23:02:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Onb-0002Gu-Tf for nsis@ietf.org; Wed, 19 Jul 2006 23:02:03 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3OnZ-0006vG-Gl for nsis@ietf.org; Wed, 19 Jul 2006 23:02:03 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-11.tower-121.messagelabs.com!1153364520!9648743!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 17854 invoked from network); 20 Jul 2006 03:02:00 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-11.tower-121.messagelabs.com with SMTP; 20 Jul 2006 03:02:00 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452002DE883; Wed, 19 Jul 2006 23:01:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Wed, 19 Jul 2006 22:01:58 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7B35@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: Acarp40mFjajlSpiTaOt5yyhz/YgRQAAKAgg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Janet P Gunn" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Thanks Janet, will reference these icw procedures for these 2 cases: Regards, Jerry -----Original Message----- From: Janet P Gunn [mailto:jgunn6@csc.com]=20 Sent: Wednesday, July 19, 2006 10:52 PM To: Janet P Gunn Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org; Hancock,Robert Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? The new versions are 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 Pre emption service (eMLPP) Stage 1 (Release 7) 3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Pre-emption service (eMLPP) - Stage 2 (Release 7) 3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Pre-emption service (eMLPP) - Stage 3 (Release 6) (I'm not sure when the Release 7 version of 24.067 will be out.) Janet Janet P Gunn/FED/CSC@CSC wrote on 07/19/2006 05:52:37 PM: > Jerry, > > Here are some OLD (release 99) normative references for eMLPP. > > 3GPP TS 22.067 version 3.0.1 (1999-10), "3rd Generation Partnership > Project; > Technical Specification Group Services and System Aspects; enhanced > Multi-Level > Precedence and Pre-emption (eMLPP) - Stage 1 (Release 1999)." > > 3GPP TS 23.067 version 3.3.0 (2001-06), "3rd Generation Partnership > Project; > Technical Specification Group Core Network; enhanced Multi-Level Precedence > and > Pre-emption (eMLPP) - Stage 2 (Release 1999)." > > 3GPP TS 24.067 version 3.2.0 (2001-06), "3rd Generation Partnership > Project; > Technical Specification Group Core Network; enhanced Multi-Level Precedence > and > Pre-emption (eMLPP) - Stage 3 (Release 1999)." > > I'll work on nailing down some more recent ones. > > Janet > > "Ash, Gerald R \(Jerry\), ALABS" wrote on 07/19/2006 > 04:47:34 PM: > > > Janet, > > > > See below. > > > > > -----Original Message----- > > > From: Janet P Gunn [mailto:jgunn6@csc.com] > > > Sent: Wednesday, July 19, 2006 1:58 PM > > > To: Ash, Gerald R (Jerry), ALABS > > > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org; Hancock,Robert > > > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory > > > parameter list? > > > > > > "Ash, Gerald R \(Jerry\), ALABS" wrote on 07/18/2006 > > > 05:09:59 PM: > > > > > > > ... > > > > Also, I agree with the above characterization. We can group into > > > > only 3 mandatory QSPEC QoS Description parameters (containers), as > > > follows: > > > > > > > > 1. : ; > > > > (populate only one) > > > > 2. : ; ; > > > > (populate only one) > > > > 3. : ; (populate > > > > only one pair) > > > > > > > >... > > > > Thanks, > > > > Jerry > > > > > > A couple of questions/comments. > > > > > > With regard to the Priority parameters, it was not at all > > > clear to me (even > > > going back and reading it again) that you could only populate > > > ONE pair: > > > OR but NOT BOTH. > > > > > > If that is the case, then it needs to be made clearer in the text. In > > > fact, it isn't even clear that admission/RPH have to be there > > > as a pair. > > > > Agreed. The text has to be clearer on these points (there was also some > > prior comment on this on the list). > > > > > The text says: > > > " As specified in [RFC3181], and > > Priority> are 16-bit integer values and both MUST be > > > populated if the > > > parameter is used.", so it is clear that you have to have > > > neither or > > > both of those. > > > > > > But it also says: > > > " Note that the parameter MAY be used in > > > combination with the parameter, which depends on the > > > supported QOSM." which leads me to believe you can have > > > one without the > > > other. > > > > Right. > > > > > It also says: > > > "[SIP-PRIORITY] defines a resource priority header (RPH) with > > > parameters "RPH Namespace" and "RPH Priority" combination, and if > > > populated is applicable only to flows with high > > > reservation priority," > > > > > > If "reservations priority" =3D "admission priority" (and I > > > think it probably > > > does), then it would be clearer to use one term instead of > > > two. > > > > Good point, I agree. > > > > > This text > > > then implies to me that it is permissible to have "admission priority" > > > without "RPH", but not permissible to have "RPH" without "admission > > > priority" (although it might also mean that RPH is ignored in > > > instances > > > without "admission priority"). > > > > Right. This should be clarified also. > > > > > Then my next question is - Why can't you have ALL FOUR of > > > ? > > > or three > > > ? > > > or just one > > > ? > > > as well as the cases with exactly two of them? > > > > priority without RPH is allowed, which needs to be better > > clarified as per above comments. > > > > > I can certainly think of use cases. For instance, if you > > > want to implement > > > eMLPP-like functionality (as defined in 3GPP), you would want > > > an > > priority> (corresponding to the "queueing allowed" part of > > > eMLPP) as well > > > as (corresponding to the "preemption > > > capable" and > > > "may be preempted" parts of eMLPP). > > > > > > Am I missing something? > > > > The procedures for the cases of two parameters being used, that is > > priority and > > priority > > are given in normative references. > > > > Similarly, there need to be referenced normative procedures for how to > > treat the case of 3 or all 4 being populated, if these are also > > specified: > > > > > > > > Are there such normative references that specify procedures for how to > > handle these above cases or 3 or 4 parameters being specified? > > > > Alternatively, procedures for these cases can be specified in the QSPEC > > document. If this approach is used, suggested text is appreciated. > > > > Another approach is that the procedures for the cases of 3 or 4 > > parameters being used can be contained in separate QOSM specification > > documents (that would be pointed out the text in the QSPEC document). > > > > Thanks, > > Jerry > > > > > Thanks, > > > > > > Janet_______________________________________________ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 21 17:29:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G42ZC-00080h-5c; Fri, 21 Jul 2006 17:29:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G42ZA-0007uk-NZ for nsis@ietf.org; Fri, 21 Jul 2006 17:29:48 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G42Z6-0002tF-FH for nsis@ietf.org; Fri, 21 Jul 2006 17:29:48 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k6LLTiGq014392 for ; Fri, 21 Jul 2006 17:29:44 -0400 (EDT) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6LLThoN023686 for ; Fri, 21 Jul 2006 17:29:43 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jul 2006 17:29:43 -0400 Message-ID: From: Black_David@emc.com To: nsis@ietf.org Date: Fri, 21 Jul 2006 17:29:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.21.141432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [NSIS] Late QSPEC comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I reviewed draft-ietf-nsis-qspec-10.txt, looking mostly for DiffServ issues. I found a couple of things: Section 7.2.2 I understand "drop" as a single value, but not "shape" or "remark". Shape to what? Remark to what? Section 7.2.6.1 This format is a subset of RFC 3140. It's missing the "X" bit in bit 14 for a set of PHBs (e.g., AF), and fails to cover the Case 2 format on p.4 of RFC 3140, even though the registry for the codes used in Case 2 is currently empty. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 21 20:50:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G45gs-00047z-4f; Fri, 21 Jul 2006 20:49:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G45gq-000400-2R for nsis@ietf.org; Fri, 21 Jul 2006 20:49:56 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G45go-0007Aw-PO for nsis@ietf.org; Fri, 21 Jul 2006 20:49:56 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k6M0nrBd011170 for ; Fri, 21 Jul 2006 20:49:54 -0400 (EDT) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6M0notw028093 for ; Fri, 21 Jul 2006 20:49:52 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jul 2006 20:49:50 -0400 Message-ID: From: Black_David@emc.com To: nsis@ietf.org Date: Fri, 21 Jul 2006 20:49:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.21.171433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [NSIS] Late RMD comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I realize that Last Call on this draft ended yesterday, but I have a couple of things to add: (1) The format in Section 4.1.1 has the same limitation as the corresponding format in the QSPEC draft. Both of them should be expanded to be capable of signaling everything defined in RFC 3140. A set of PHBs would make sense if RMD were used to provide a reserved bandwidth path for an AF PHB set across a domain. (2) I'm still uncomfortable with the potential DSCP consumption for severe congestion handling. Section 4.6.1.6.2.1 says: It is RECOMMENDED that the total number of additional DSCPs needed for severe congestion handling within an RMD domain should be as low as possible and it should not exceed the limit of 16. DSCPs are a rather scarce resource - 16 is: - 25% of the total number that exist - 50% of the EXP/LU space (cf. RFC 2474) - 100% of Pool 2, the EXP/LU space not subject to future standardization. It would be acceptable to me if the number 16 were changed to 8. Another possibility would be to go through the traffic classes in draft-ietf-tsvwg-diffserv-service-classes-02.txt and explain which ones RMD congestion control is applicable to motivate the selected limit. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 24 07:21:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4yUq-0007jM-Fd; Mon, 24 Jul 2006 07:21:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4yUo-0007jH-Mg for nsis@ietf.org; Mon, 24 Jul 2006 07:21:10 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4yUn-0005ui-64 for nsis@ietf.org; Mon, 24 Jul 2006 07:21:10 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 41646F1F; Mon, 24 Jul 2006 13:21:08 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 13:21:07 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 13:21:07 +0200 Message-ID: <44C4AD22.90609@ericsson.com> Date: Mon, 24 Jul 2006 13:21:06 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] backoff, rate limiting and other parameters References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2006 11:21:07.0082 (UTC) FILETIME=[41DC16A0:01C6AF13] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I think the new text is acceptable. I would have preferred clearer rate-limiting rules. However I will accept this as one area where further work and deployement hopefully will clarify the impact. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 25 03:15:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5H8p-00084j-QV; Tue, 25 Jul 2006 03:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5H8o-00082t-Dk for nsis@ietf.org; Tue, 25 Jul 2006 03:15:42 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5H8n-0004My-OK for nsis@ietf.org; Tue, 25 Jul 2006 03:15:42 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k6P7EpVk004154; Tue, 25 Jul 2006 16:14:51 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k6P7Eq600943; Tue, 25 Jul 2006 16:14:52 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k6P7EqJ27199; Tue, 25 Jul 2006 16:14:52 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Proposal for implementing QoS NSLP Proxy Mode Date: Tue, 25 Jul 2006 15:14:05 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD0107395E@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal for implementing QoS NSLP Proxy Mode Thread-Index: Acapi0tsgvuOwZguTkqj/fM0EZtkbwGJxQuQ From: "Cheng Hong" To: "Georgios Karagiannis" , , X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Toyoki Ue , Pek Yew Tan , Takako Sanda X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I would also agree that the proxy mode is very useful and should be included into the QoS-NSLP draft. However, regarding the operation procedure mentioned by Jukka below, I have some questions: > >[End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver or sender] > > > >For incoming flows, the end host is also the QNI, and it sends a=20 > >RESERVE towards the data sender with the proxy-scope bit=20 > set. Here the=20 > >end host sets the MRI so that it indicates the end host as=20 > the receiver=20 > >of the data, and the D-flag is set. If there is only one=20 > P-QNE in the=20 > >domain, GIST gets the RESERVE to the P-QNE. If there are=20 > more than one=20 > >P-QNEs, GIST will do its best, but may reply with an error=20 > indicating=20 > >destination unreachable. How does this work? When the data path is asymmetric, how could the P-QNE be identified from the receiver (End Host) side? cheers Cheng Hong =20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Monday, July 17, 2006 6:23 PM > To: jmanner@cs.Helsinki.FI; nsis@ietf.org > Subject: Re: [NSIS] Proposal for implementing QoS NSLP Proxy Mode >=20 >=20 > Hi Jukka >=20 > Great! > I think that the use of the QoS-NSLP proxy mode is useful and=20 > the additional complexity introduced in the QoS-NSLP by this=20 > mode is not big. > Therefore, I agree to include it in the QoS-NSLP draft. >=20 > Best regards, > Georgios >=20 > On 7/16/2006, "Jukka MJ Manner" wrote: >=20 > > > >We had a good discussion with Robert about the QoS NSLP=20 > Proxy mode, and=20 > >at the end we agreed that the QoS NSLP does not really need much.=20 > >Actually, we only need a new scope (besides single link and=20 > e2e) called e.g. > >"proxy", and the domain admin must define manually, which=20 > QNE operates=20 > >as proxy (Proxy-QNE, P-QNE). Here is how the fing works: > > > >[End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver or sender] > > > >For outgoing flows, the end host is the QNI, and sends a=20 > RESERVE with=20 > >the new proxy-scope bit set. The P-QNE will receive the RESERVE and=20 > >reply with a RESPONSE (if requested), and NOT forward the RESERVE=20 > >further to the next peer. The receiver-oriented reservation=20 > works the=20 > >same way (QUERY towards P-QNE, RESERVE back, then RESPONSE to P-QNE,=20 > >all carrying the proxy-scope bit). > > > >For incoming flows, the end host is also the QNI, and it sends a=20 > >RESERVE towards the data sender with the proxy-scope bit=20 > set. Here the=20 > >end host sets the MRI so that it indicates the end host as=20 > the receiver=20 > >of the data, and the D-flag is set. If there is only one=20 > P-QNE in the=20 > >domain, GIST gets the RESERVE to the P-QNE. If there are=20 > more than one=20 > >P-QNEs, GIST will do its best, but may reply with an error=20 > indicating=20 > >destination unreachable. > > > >Jukka > > > >ps. I'll be out of emails for a couple of weeks now. I intend to=20 > >finalize the QoS NSLP draft in August and we can then send=20 > it for AD review. > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 25 05:13:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Iz6-0003C6-Gp; Tue, 25 Jul 2006 05:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Iz5-0003AS-Ox for nsis@ietf.org; Tue, 25 Jul 2006 05:13:47 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Iz4-0008Iw-Kc for nsis@ietf.org; Tue, 25 Jul 2006 05:13:47 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6P9DZCG012276; Tue, 25 Jul 2006 10:13:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Proposal for implementing QoS NSLP Proxy Mode Date: Tue, 25 Jul 2006 10:13:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal for implementing QoS NSLP Proxy Mode Thread-Index: Acapi0tsgvuOwZguTkqj/fM0EZtkbwGJxQuQAAWql4A= From: "Hancock, Robert" To: "Cheng Hong" , "Georgios Karagiannis" , , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: Toyoki Ue , Takako Sanda , Pek Yew Tan X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi cheng hong, the point you raise is a valid one: > Hi all, >=20 > I would also agree that the proxy mode is very useful and should be > included into the QoS-NSLP draft. However, regarding the operation > procedure mentioned by Jukka below, I have some questions: >=20 > > >[End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver or sender] > > > > > > > >For incoming flows, the end host is also the QNI, and it sends a=20 > > >RESERVE towards the data sender with the proxy-scope bit=20 > > set. Here the=20 > > >end host sets the MRI so that it indicates the end host as=20 > > the receiver=20 > > >of the data, and the D-flag is set. If there is only one=20 > > P-QNE in the=20 > > >domain, GIST gets the RESERVE to the P-QNE. If there are=20 > > more than one=20 > > >P-QNEs, GIST will do its best, but may reply with an error=20 > > indicating=20 > > >destination unreachable. >=20 > How does this work? When the data path is asymmetric, how could the > P-QNE be identified from the receiver (End Host) side? basically, this is known and accepted to be a Hard Problem.=20 because it is a problem about message routing, the proposal for the QoS-NSLP (as I discussed it with Jukka and Andy) is that this hard problem should be delegated to GIST. what's then necessary is for GIST to be able to set up routing state upstream for the MRMs that the QoS-NSLP uses (which is just the path-coupled MRM).=20 GIST includes functionality to achieve this (see section 5.8.1.3). it only works in a limited range of environments, but it does work robustly in there, and it covers the key scenarios where this functionality is needed in practice. if we want the proxy=20 mode in more general scenarios, the right way to achieve that is to work on solving the reverse routing problem in general, and extending GIST in that direction. see http://www1.ietf.org/mail-archive/web/nsis/current/msg04537.html for further background on how this got into GIST. r. >=20 > cheers >=20 > Cheng Hong >=20 > =20 >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > > Sent: Monday, July 17, 2006 6:23 PM > > To: jmanner@cs.Helsinki.FI; nsis@ietf.org > > Subject: Re: [NSIS] Proposal for implementing QoS NSLP Proxy Mode > >=20 > >=20 > > Hi Jukka > >=20 > > Great! > > I think that the use of the QoS-NSLP proxy mode is useful and=20 > > the additional complexity introduced in the QoS-NSLP by this=20 > > mode is not big. > > Therefore, I agree to include it in the QoS-NSLP draft. > >=20 > > Best regards, > > Georgios > >=20 > > On 7/16/2006, "Jukka MJ Manner" wrote: > >=20 > > > > > >We had a good discussion with Robert about the QoS NSLP=20 > > Proxy mode, and=20 > > >at the end we agreed that the QoS NSLP does not really need much.=20 > > >Actually, we only need a new scope (besides single link and=20 > > e2e) called e.g. > > >"proxy", and the domain admin must define manually, which=20 > > QNE operates=20 > > >as proxy (Proxy-QNE, P-QNE). Here is how the fing works: > > > > > >[End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver or sender] > > > > > >For outgoing flows, the end host is the QNI, and sends a=20 > > RESERVE with=20 > > >the new proxy-scope bit set. The P-QNE will receive the=20 > RESERVE and=20 > > >reply with a RESPONSE (if requested), and NOT forward the RESERVE=20 > > >further to the next peer. The receiver-oriented reservation=20 > > works the=20 > > >same way (QUERY towards P-QNE, RESERVE back, then RESPONSE=20 > to P-QNE,=20 > > >all carrying the proxy-scope bit). > > > > > >For incoming flows, the end host is also the QNI, and it sends a=20 > > >RESERVE towards the data sender with the proxy-scope bit=20 > > set. Here the=20 > > >end host sets the MRI so that it indicates the end host as=20 > > the receiver=20 > > >of the data, and the D-flag is set. If there is only one=20 > > P-QNE in the=20 > > >domain, GIST gets the RESERVE to the P-QNE. If there are=20 > > more than one=20 > > >P-QNEs, GIST will do its best, but may reply with an error=20 > > indicating=20 > > >destination unreachable. > > > > > >Jukka > > > > > >ps. I'll be out of emails for a couple of weeks now. I intend to=20 > > >finalize the QoS NSLP draft in August and we can then send=20 > > it for AD review. > > > > > >_______________________________________________ > > >nsis mailing list > > >nsis@ietf.org > > >https://www1.ietf.org/mailman/listinfo/nsis > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 25 11:05:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OTJ-0003ki-Mk; Tue, 25 Jul 2006 11:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OTI-0003kG-D6 for nsis@ietf.org; Tue, 25 Jul 2006 11:05:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5KJg-00065w-4p for nsis@ietf.org; Tue, 25 Jul 2006 06:39:08 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5K5Y-0000wW-Dj for nsis@ietf.org; Tue, 25 Jul 2006 06:24:34 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k6PAO1TC009857; Tue, 25 Jul 2006 19:24:01 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k6PAO3E26304; Tue, 25 Jul 2006 19:24:03 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id k6PAO3521136; Tue, 25 Jul 2006 19:24:03 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Proposal for implementing QoS NSLP Proxy Mode Date: Tue, 25 Jul 2006 18:23:33 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01073A06@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal for implementing QoS NSLP Proxy Mode Thread-Index: Acapi0tsgvuOwZguTkqj/fM0EZtkbwGJxQuQAAWql4AAAo+zQA== From: "Cheng Hong" To: "Hancock, Robert" , "Georgios Karagiannis" , , X-Spam-Score: -2.6 (--) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: Toyoki Ue , Takako Sanda , Pek Yew Tan X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Thanks a lot for pointing out the information. Will check the details when I go back to the office. Delegating the problem to GIST is a reasonable choice, since it is a general issue for all NSLP applications. Extending GIST for a general solution sounds interesting. I guess it may also be part of the MRM Pattern discussions. cheers Cheng Hong > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > Sent: Tuesday, July 25, 2006 5:14 PM > To: Cheng Hong; Georgios Karagiannis; jmanner@cs.Helsinki.FI;=20 > nsis@ietf.org > Cc: Toyoki Ue; Pek Yew Tan; Takako Sanda > Subject: RE: [NSIS] Proposal for implementing QoS NSLP Proxy Mode >=20 > hi cheng hong, >=20 > the point you raise is a valid one: >=20 > > Hi all, > >=20 > > I would also agree that the proxy mode is very useful and should be=20 > > included into the QoS-NSLP draft. However, regarding the operation=20 > > procedure mentioned by Jukka below, I have some questions: > >=20 > > > >[End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver=20 > or sender] > > > > > > > > > > > >For incoming flows, the end host is also the QNI, and it sends a=20 > > > >RESERVE towards the data sender with the proxy-scope bit > > > set. Here the > > > >end host sets the MRI so that it indicates the end host as > > > the receiver > > > >of the data, and the D-flag is set. If there is only one > > > P-QNE in the > > > >domain, GIST gets the RESERVE to the P-QNE. If there are > > > more than one > > > >P-QNEs, GIST will do its best, but may reply with an error > > > indicating > > > >destination unreachable. > >=20 > > How does this work? When the data path is asymmetric, how could the=20 > > P-QNE be identified from the receiver (End Host) side? >=20 > basically, this is known and accepted to be a Hard Problem.=20 > because it is a problem about message routing, the proposal=20 > for the QoS-NSLP (as I discussed it with Jukka and Andy) is=20 > that this hard problem should be delegated to GIST. what's=20 > then necessary is for GIST to be able to set up routing state=20 > upstream for the MRMs that the QoS-NSLP uses (which is just=20 > the path-coupled MRM).=20 >=20 > GIST includes functionality to achieve this (see section 5.8.1.3). > it only works in a limited range of environments, but it does=20 > work robustly in there, and it covers the key scenarios where=20 > this functionality is needed in practice. if we want the=20 > proxy mode in more general scenarios, the right way to=20 > achieve that is to work on solving the reverse routing=20 > problem in general, and extending GIST in that direction. >=20 > see http://www1.ietf.org/mail-archive/web/nsis/current/msg04537.html > for further background on how this got into GIST. >=20 > r. >=20 > >=20 > > cheers > >=20 > > Cheng Hong > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Monday, July 17, 2006 6:23 PM > > > To: jmanner@cs.Helsinki.FI; nsis@ietf.org > > > Subject: Re: [NSIS] Proposal for implementing QoS NSLP Proxy Mode > > >=20 > > >=20 > > > Hi Jukka > > >=20 > > > Great! > > > I think that the use of the QoS-NSLP proxy mode is useful and the=20 > > > additional complexity introduced in the QoS-NSLP by this=20 > mode is not=20 > > > big. > > > Therefore, I agree to include it in the QoS-NSLP draft. > > >=20 > > > Best regards, > > > Georgios > > >=20 > > > On 7/16/2006, "Jukka MJ Manner" wrote: > > >=20 > > > > > > > >We had a good discussion with Robert about the QoS NSLP > > > Proxy mode, and > > > >at the end we agreed that the QoS NSLP does not really=20 > need much.=20 > > > >Actually, we only need a new scope (besides single link and > > > e2e) called e.g. > > > >"proxy", and the domain admin must define manually, which > > > QNE operates > > > >as proxy (Proxy-QNE, P-QNE). Here is how the fing works: > > > > > > > >[End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver=20 > or sender] > > > > > > > >For outgoing flows, the end host is the QNI, and sends a > > > RESERVE with > > > >the new proxy-scope bit set. The P-QNE will receive the > > RESERVE and > > > >reply with a RESPONSE (if requested), and NOT forward=20 > the RESERVE=20 > > > >further to the next peer. The receiver-oriented reservation > > > works the > > > >same way (QUERY towards P-QNE, RESERVE back, then RESPONSE > > to P-QNE, > > > >all carrying the proxy-scope bit). > > > > > > > >For incoming flows, the end host is also the QNI, and it sends a=20 > > > >RESERVE towards the data sender with the proxy-scope bit > > > set. Here the > > > >end host sets the MRI so that it indicates the end host as > > > the receiver > > > >of the data, and the D-flag is set. If there is only one > > > P-QNE in the > > > >domain, GIST gets the RESERVE to the P-QNE. If there are > > > more than one > > > >P-QNEs, GIST will do its best, but may reply with an error > > > indicating > > > >destination unreachable. > > > > > > > >Jukka > > > > > > > >ps. I'll be out of emails for a couple of weeks now. I intend to=20 > > > >finalize the QoS NSLP draft in August and we can then send > > > it for AD review. > > > > > > > >_______________________________________________ > > > >nsis mailing list > > > >nsis@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 25 11:09:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OXU-0004de-5T; Tue, 25 Jul 2006 11:09:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OXS-0004dZ-B3 for nsis@ietf.org; Tue, 25 Jul 2006 11:09:38 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5OXQ-0007Lw-Tm for nsis@ietf.org; Tue, 25 Jul 2006 11:09:38 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1G5OXA-0002Gv-8N; Tue, 25 Jul 2006 17:09:26 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 03E4DC678; Tue, 25 Jul 2006 17:09:20 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1G5OX9-00038T-Oa; Tue, 25 Jul 2006 17:09:19 +0200 Message-ID: <44C6341F.2040508@tm.uka.de> Date: Tue, 25 Jul 2006 17:09:19 +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: "Kappler, Cornelia" Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org, "Ash, Gerald R ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, > I've been off-list for the last 10 days and may have difficulties > grasping the real point of the debate. Sorry, I missed the discussion, though we had some informal discussion in Dallas one morning at a roundtable :-) > I'd prefer some concrete suggestions to which parameters should not > be mandatory. Rather than blanket statements "List is too long" or > "List is too short" or "we should have N parameters". > > The question is not really whether it should be 2 or 8 or 20 > mandatory parameters. It is _which_ parameters are necessary to > _just_ accomodate the key ideas of typical QOSMs. Now I'll repeat what I already said in Dallas: I'd prefer to not prescribe any mandatory parameters for all QoS models. Thus I don't actually like the approach: "Mandatory parameters in the QSPEC must be meaningfully interpreted by all QNEs in the path, independent of which QOSM they support." I disagree, because we may have different QoS models that not even require these parameters or future QoS models that require even more mandatory parameters which are not covered by the QSPEC template anyway. But trying to be constructive: I would rather prefer to leave it up to each QoS model which parameters are mandatory and which are not, like defining a profile (e.g. similar to MPEG profiles). Furthermore, interworking between different QoS models can be defined that describes which parameters can mapped onto which in the other QoSM. I agree on this statement in the introduction: " A particular QOSM specifies a) a set of mandatory and optional QSPEC parameters, and b) how the QSPEC information is interpreted by the RMF with respect to the QoS description, resources desired, resources available, and control information." The value of the QSPEC is still retained, because a QoSM only needs to pick certain parameters of the QSPEC which are already defined therein. Just my two cents, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 25 11:19:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Ogf-0007nn-GS; Tue, 25 Jul 2006 11:19:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Ogd-0007nh-LJ for nsis@ietf.org; Tue, 25 Jul 2006 11:19:07 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Ogb-00012a-9F for nsis@ietf.org; Tue, 25 Jul 2006 11:19:07 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 25 Jul 2006 11:18:56 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006072511185528361 ; Tue, 25 Jul 2006 11:18:55 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Jul 2006 11:18:55 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230E63@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Roland Bless Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Tue, 25 Jul 2006 11:18:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Roland and all: You have raised a valid technical question. So, QSPEC also need to be independent of any QoS model. Again the question is this: Why does this QSPEC spec still deal with some "incomplete" extensions of Y.xxx and DSTE qos-specific models? BR/Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Roland Bless Sent: Tuesday, July 25, 2006 11:09 AM To: Kappler, Cornelia Cc: Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org; Ash, Gerald R ALABS Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Hi all, > I've been off-list for the last 10 days and may have difficulties > grasping the real point of the debate. Sorry, I missed the discussion, though we had some informal discussion in Dallas one morning at a roundtable :-) > I'd prefer some concrete suggestions to which parameters should not > be mandatory. Rather than blanket statements "List is too long" or > "List is too short" or "we should have N parameters". > > The question is not really whether it should be 2 or 8 or 20 > mandatory parameters. It is _which_ parameters are necessary to > _just_ accomodate the key ideas of typical QOSMs. Now I'll repeat what I already said in Dallas: I'd prefer to not prescribe any mandatory parameters for all QoS models. Thus I don't actually like the approach: "Mandatory parameters in the QSPEC must be meaningfully interpreted by all QNEs in the path, independent of which QOSM they support." I disagree, because we may have different QoS models that not even require these parameters or future QoS models that require even more mandatory parameters which are not covered by the QSPEC template anyway. But trying to be constructive: I would rather prefer to leave it up to each QoS model which parameters are mandatory and which are not, like defining a profile (e.g. similar to MPEG profiles). Furthermore, interworking between different QoS models can be defined that describes which parameters can mapped onto which in the other QoSM. I agree on this statement in the introduction: " A particular QOSM specifies a) a set of mandatory and optional QSPEC parameters, and b) how the QSPEC information is interpreted by the RMF with respect to the QoS description, resources desired, resources available, and control information." The value of the QSPEC is still retained, because a QoSM only needs to pick certain parameters of the QSPEC which are already defined therein. Just my two cents, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 25 12:05:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5PPR-0001Vl-OS; Tue, 25 Jul 2006 12:05:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5PPR-0001Vg-9H for nsis@ietf.org; Tue, 25 Jul 2006 12:05:25 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5PPP-0000z9-SW for nsis@ietf.org; Tue, 25 Jul 2006 12:05:25 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1153843334!10733367!51 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 19426 invoked from network); 25 Jul 2006 16:05:22 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-6.tower-120.messagelabs.com with SMTP; 25 Jul 2006 16:05:22 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 44C39E8500040F19; Tue, 25 Jul 2006 12:05:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Tue, 25 Jul 2006 11:05:21 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7B52@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44C6341F.2040508@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: Acav/FuJ5HAnJS7RRIKD+zMWJuR2rQAAvuag From: "Ash, Gerald R \(Jerry\), ALABS" To: "Roland Bless" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland, See below.=20 > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: Tuesday, July 25, 2006 11:09 AM > To: Kappler, Cornelia > Cc: Georgios Karagiannis; Bernd Schloer; Jukka MJ Manner;=20 > Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 > Hi all, >=20 > > I've been off-list for the last 10 days and may have difficulties > > grasping the real point of the debate. >=20 > Sorry, I missed the discussion, though we had some > informal discussion in Dallas one morning at a > roundtable :-) >=20 > > I'd prefer some concrete suggestions to which parameters should not > > be mandatory. Rather than blanket statements "List is too long" or > > "List is too short" or "we should have N parameters". > >=20 > > The question is not really whether it should be 2 or 8 or 20 > > mandatory parameters. It is _which_ parameters are necessary to > > _just_ accommodate the key ideas of typical QOSMs. > > Now I'll repeat what I already said in Dallas: Where/when did you say this, I don't recall hearing this comment in the NSIS meetings, but maybe I missed it? > I'd prefer to not prescribe any mandatory parameters for all > QoS models. Thus I don't actually like the approach: > "Mandatory parameters in the QSPEC must be > meaningfully interpreted by all QNEs in the path, independent of > which QOSM they support." I disagree, > because we may have different QoS models that not even > require these parameters or future QoS models that require > even more mandatory parameters which are not covered by > the QSPEC template anyway.=20 The concept is that a QNI initiates a reservation according to its QOSM. It may populate one or more mandatory parameters, and perhaps some optional parameters in its QSPEC object. Mandatory parameters only must be interpreted by downstream QNEs if populated by the QNI. =20 Right now there are only 3 mandatory QoS description parameters: , , and (see previous thread discussion on this topic). Several people agreed this is a minimal set of mandatory parameters. It seems to me that most QOSMs will want to support some version of these 3 parameters. They provide a common language for QOSMs, based on IntServ and DiffServ, as originally agreed in NSIS when the QSPEC was formulated. If a local domain supports a different QOSM than the QNI QOSM, it may remap (approximately interpret) the mandatory parameters that are populated, and may ignore the optional parameters, and flag those parameters it remaps or ignores. The QNI makes a decision on whether to accept or reject the reservation based on the RESPONSE. If for example the QNI populates and the local domain QNEs ignore (assuming that is not mandatory in the local QOSM, as you propose), the QNI is going to probably reject the reservation anyway. At best, the reservation will not be what is intended/desired by the QNI. > But trying to be constructive: > I would rather prefer to leave it up to each QoS model > which parameters are mandatory and which are not, like > defining a profile (e.g. similar to MPEG profiles). > Furthermore, interworking between different QoS models > can be defined that describes which parameters can > mapped onto which in the other QoSM. I don't agree with this approach, I think it would be overly complex for QOSMs to define all that detail for all 14 QSPEC parameters. A also don't think it would provide meaningful new functionality. E.g., if some QOSMs said is mandatory, and others said it was optional, what would be the difference anyway if a local QOSM didn't support the parameter as mandatory, if it was populated in the QNI-QSPEC? The local domain would merely respond that it ignored the parameter and the QNI would probably reject the reservation in any case. If we decide to not have the mandatory/optional parameter concept, I would prefer to just have all parameters be treated as 'optional', as currently defined in the QSPEC document. Thanks, Jerry > I agree on this statement in the introduction: > " A particular QOSM > specifies a) a set of mandatory and optional QSPEC parameters, and > b) how the QSPEC information is interpreted by the RMF with respect > to the QoS description, resources desired, resources available, and > control information." > The value of the QSPEC is still retained, because a QoSM only > needs to pick certain parameters of the QSPEC which are already > defined therein. >=20 > Just my two cents, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 05:21:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5fa8-0001vY-9o; Wed, 26 Jul 2006 05:21:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5fa7-0001vS-Mx for nsis@ietf.org; Wed, 26 Jul 2006 05:21:31 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5fa5-0005RG-15 for nsis@ietf.org; Wed, 26 Jul 2006 05:21:31 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6Q9L9Ql028271; Wed, 26 Jul 2006 10:21:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Wed, 26 Jul 2006 10:21:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: Acav/FuJ5HAnJS7RRIKD+zMWJuR2rQAAvuagACUVHuA= From: "Hancock, Robert" To: "Ash, Gerald R \(Jerry\), ALABS" , "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, just to add my two [small currency units]: i also still think that the mandatory/optional parameter concept is the right way to proceed. it was developed in order to guarantee some minimal level of interworking even if the flow path crosses some very disparate set of regions with different QoS management techniques without requiring a heavyweight implementation of all options in each of them; at the same time, it allows for more optimised QoS treatment in more homogeneous environments. we would have to=20 think very carefully before concluding that there are alternative solutions to that pair of problems. it may be that there are some QoS models which don't need some of the mandatory parameters. i don't see that as a problem; for=20 those models, the parameter mapping that the model has to define is just very simple (it is "ignore"). in other cases, they may natively use some different formulation than the QSPEC mandatory=20 parameters; in that case, the requirement to fit into the QSPEC is that the parametrisation should be re-formulated into=20 (existing mandatory parameter)+(new optional parameter). i think that is a fair constraint to impose - it's just to stop there developing 15 different ways of expressing the concept 'bandwidth' and so on. cheers, robert h. > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > Sent: 25 July 2006 17:05 > To: Roland Bless > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 >=20 > Hi Roland, >=20 > See below.=20 >=20 > > -----Original Message----- > > From: Roland Bless [mailto:bless@tm.uka.de]=20 > > Sent: Tuesday, July 25, 2006 11:09 AM > > To: Kappler, Cornelia > > Cc: Georgios Karagiannis; Bernd Schloer; Jukka MJ Manner;=20 > > Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > > parameter list? > >=20 > > Hi all, > >=20 > > > I've been off-list for the last 10 days and may have difficulties > > > grasping the real point of the debate. > >=20 > > Sorry, I missed the discussion, though we had some > > informal discussion in Dallas one morning at a > > roundtable :-) > >=20 > > > I'd prefer some concrete suggestions to which parameters=20 > should not > > > be mandatory. Rather than blanket statements "List is too long" or > > > "List is too short" or "we should have N parameters". > > >=20 > > > The question is not really whether it should be 2 or 8 or 20 > > > mandatory parameters. It is _which_ parameters are necessary to > > > _just_ accommodate the key ideas of typical QOSMs. > > > > Now I'll repeat what I already said in Dallas: >=20 > Where/when did you say this, I don't recall hearing this=20 > comment in the > NSIS meetings, but maybe I missed it? >=20 > > I'd prefer to not prescribe any mandatory parameters for all > > QoS models. Thus I don't actually like the approach: > > "Mandatory parameters in the QSPEC must be > > meaningfully interpreted by all QNEs in the path, independent of > > which QOSM they support." I disagree, > > because we may have different QoS models that not even > > require these parameters or future QoS models that require > > even more mandatory parameters which are not covered by > > the QSPEC template anyway.=20 >=20 > The concept is that a QNI initiates a reservation according=20 > to its QOSM. > It may populate one or more mandatory parameters, and perhaps some > optional parameters in its QSPEC object. Mandatory=20 > parameters only must > be interpreted by downstream QNEs if populated by the QNI. =20 >=20 > Right now there are only 3 mandatory QoS description parameters: > , , and (see previous thread discussion > on this topic). Several people agreed this is a minimal set of > mandatory parameters. It seems to me that most QOSMs will want to > support some version of these 3 parameters. They provide a common > language for QOSMs, based on IntServ and DiffServ, as=20 > originally agreed > in NSIS when the QSPEC was formulated. >=20 > If a local domain supports a different QOSM than the QNI QOSM, it may > remap (approximately interpret) the mandatory parameters that are > populated, and may ignore the optional parameters, and flag those > parameters it remaps or ignores. The QNI makes a decision on=20 > whether to > accept or reject the reservation based on the RESPONSE. >=20 > If for example the QNI populates and the local domain QNEs > ignore (assuming that is not mandatory in=20 > the local > QOSM, as you propose), the QNI is going to probably reject the > reservation anyway. At best, the reservation will not be what is > intended/desired by the QNI. >=20 > > But trying to be constructive: > > I would rather prefer to leave it up to each QoS model > > which parameters are mandatory and which are not, like > > defining a profile (e.g. similar to MPEG profiles). > > Furthermore, interworking between different QoS models > > can be defined that describes which parameters can > > mapped onto which in the other QoSM. >=20 > I don't agree with this approach, I think it would be overly=20 > complex for > QOSMs to define all that detail for all 14 QSPEC parameters. A also > don't think it would provide meaningful new functionality. E.g., if > some QOSMs said is mandatory, and others said it=20 > was optional, > what would be the difference anyway if a local QOSM didn't support the > parameter as mandatory, if it was populated in the=20 > QNI-QSPEC? > The local domain would merely respond that it ignored the > parameter and the QNI would probably reject the reservation=20 > in any case. >=20 > If we decide to not have the mandatory/optional parameter concept, I > would prefer to just have all parameters be treated as 'optional', as > currently defined in the QSPEC document. >=20 > Thanks, > Jerry >=20 > > I agree on this statement in the introduction: > > " A particular QOSM > > specifies a) a set of mandatory and optional QSPEC=20 > parameters, and > > b) how the QSPEC information is interpreted by the RMF=20 > with respect > > to the QoS description, resources desired, resources=20 > available, and > > control information." > > The value of the QSPEC is still retained, because a QoSM only > > needs to pick certain parameters of the QSPEC which are already > > defined therein. > >=20 > > Just my two cents, > > Roland > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 08:02:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5i5t-00027b-Fs; Wed, 26 Jul 2006 08:02:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5i5s-00027W-BJ for nsis@ietf.org; Wed, 26 Jul 2006 08:02:28 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5i5p-0005k4-Li for nsis@ietf.org; Wed, 26 Jul 2006 08:02:28 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1G5i5Z-0003ZG-Uf; Wed, 26 Jul 2006 14:02:20 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id BF8A48703; Wed, 26 Jul 2006 14:02:09 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1G5i5Z-0004dc-C7; Wed, 26 Jul 2006 14:02:09 +0200 Message-ID: <44C759C0.5060204@tm.uka.de> Date: Wed, 26 Jul 2006 14:02:08 +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: "Ash, Gerald R (Jerry), ALABS" Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? References: <9473683187ADC049A855ED2DA739ABCA0DDC7B52@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7B52@KCCLUST06EVS1.ugd.att.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, maybe I'm a little confused about what the mandatory concept exactly means in the QSPEC document. I guess there are actually two different meanings of "mandatory" intermixed in the document (or only in my mind). a) mandatory to be supported by _all_ QOSMs (that's how I read phrases like "Mandatory and optional QSPEC parameters provide a common language for QOSM developers to build their QSPECs and are likely to be re-used in several QOSMs." or "This is because mandatory parameters have been defined as a common language. Therefore, a QNE MUST at least interpret all the mandatory parameters in a QSPEC even if it does not support the corresponding QOSM.") b) mandatory parameter with respect to a specific a QoS model. Maybe I have missed the point in the document which clearly or explicitly says a). Most of the time my understanding was b). It is perfectly fine to let a QOSM signal that a certain parameter is mandatory to support for itself. But I had concerns with this: Additional mandatory parameters may be defined in the future. However, since this requires an update of all QNEs, this should be considered carefully. The definition of new mandatory parameter requires standards action and an update of this document. Such an update also needs a new QSPEC version number. Furthermore, all QOSM definitions must be updated to include how the new mandatory parameter is to be interpreted in the respective QOSM. As far as I understand the spec now, it's like: 1) each QOSM specifies the required parameters (mandatory for this particular QOSM) so each QOSM implementation MUST understand and interpret these parameters. Some of these parameters may be mandatory in the QSPEC meaning and others are optional in the QSPEC meaning but all are required (mandatory) for the QOSM. 2) mandatory parameters are a means of interworking between QOSMs. 3) there is no concept of having additional (optional) parameters within a QOSM. See further comments inline. Ash, Gerald R (Jerry), ALABS wrote: >> -----Original Message----- >> From: Roland Bless [mailto:bless@tm.uka.de] >> Sent: Tuesday, July 25, 2006 11:09 AM >> To: Kappler, Cornelia >> Cc: Georgios Karagiannis; Bernd Schloer; Jukka MJ Manner; >> Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >> Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory >> parameter list? >> >> Hi all, >> >>> I've been off-list for the last 10 days and may have difficulties >>> grasping the real point of the debate. >> Sorry, I missed the discussion, though we had some >> informal discussion in Dallas one morning at a >> roundtable :-) >> >>> I'd prefer some concrete suggestions to which parameters should not >>> be mandatory. Rather than blanket statements "List is too long" or >>> "List is too short" or "we should have N parameters". >>> >>> The question is not really whether it should be 2 or 8 or 20 >>> mandatory parameters. It is _which_ parameters are necessary to >>> _just_ accommodate the key ideas of typical QOSMs. >> Now I'll repeat what I already said in Dallas: > > Where/when did you say this, I don't recall hearing this comment in the > NSIS meetings, but maybe I missed it? Not in the official NSIS meeting. We had an informal discussion one morning before the sessions began in the atrium. You were sitting directly next to me IIRC. Hannes actually brought up the question. >> I'd prefer to not prescribe any mandatory parameters for all >> QoS models. Thus I don't actually like the approach: >> "Mandatory parameters in the QSPEC must be >> meaningfully interpreted by all QNEs in the path, independent of >> which QOSM they support." I disagree, >> because we may have different QoS models that not even >> require these parameters or future QoS models that require >> even more mandatory parameters which are not covered by >> the QSPEC template anyway. > > The concept is that a QNI initiates a reservation according to its QOSM. > It may populate one or more mandatory parameters, and perhaps some > optional parameters in its QSPEC object. Mandatory parameters only must > be interpreted by downstream QNEs if populated by the QNI. That's ok. > Right now there are only 3 mandatory QoS description parameters: > , , and (see previous thread discussion > on this topic). Several people agreed this is a minimal set of > mandatory parameters. It seems to me that most QOSMs will want to > support some version of these 3 parameters. They provide a common > language for QOSMs, based on IntServ and DiffServ, as originally agreed > in NSIS when the QSPEC was formulated. That's fine. QSPEC should be a common language for QOSMs. So if I need a bandwidth parameter, I know how to specify that. But I simply don't want that the QSPEC states which of them are mandatory for QOSMs. That should be specified by each QOSM itself. IMHO it's useless to prescribe what should be mandatory in the QSPEC, because future QOSMs may have even more mandatory parameters which are not supported by older QOSMs anyway. But maybe I'm only confused by terminology, what mandatory actually means (see above). > If a local domain supports a different QOSM than the QNI QOSM, it may > remap (approximately interpret) the mandatory parameters that are > populated, and may ignore the optional parameters, and flag those > parameters it remaps or ignores. The QNI makes a decision on whether to > accept or reject the reservation based on the RESPONSE. Ok, so: if I populated a "mandatory by QSPEC" parameter, it must be "understood" by the QOSM which may also finally ignore it? > If for example the QNI populates and the local domain QNEs > ignore (assuming that is not mandatory in the local > QOSM, as you propose), the QNI is going to probably reject the > reservation anyway. At best, the reservation will not be what is > intended/desired by the QNI. My case was the other way around: If a future QOSM has a required (mandatory in meaning b)) parameter that is not supported by other QOSMs, the current mandatory parameter set by QSPEC doesn't help anyway. >> But trying to be constructive: >> I would rather prefer to leave it up to each QoS model >> which parameters are mandatory and which are not, like >> defining a profile (e.g. similar to MPEG profiles). >> Furthermore, interworking between different QoS models >> can be defined that describes which parameters can >> mapped onto which in the other QoSM. > > I don't agree with this approach, I think it would be overly complex for > QOSMs to define all that detail for all 14 QSPEC parameters. A also No, you only need to define what is actually mandatory or optional, you don't need to list parameters that are not used by the QOSM. > don't think it would provide meaningful new functionality. E.g., if > some QOSMs said is mandatory, and others said it was optional, > what would be the difference anyway if a local QOSM didn't support the > parameter as mandatory, if it was populated in the QNI-QSPEC? > The local domain would merely respond that it ignored the > parameter and the QNI would probably reject the reservation in any case. > > If we decide to not have the mandatory/optional parameter concept, I > would prefer to just have all parameters be treated as 'optional', as > currently defined in the QSPEC document. I guess it's fine to keep most of the stuff if that's the consensus. Maybe there could be clarifying text that "mandatory" actually means: mandatory to be understood and supported by all QOSMs and not mandatory within the QOSM itself. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 08:17:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5iKg-0002dA-B2; Wed, 26 Jul 2006 08:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5iKf-0002d5-Fb for nsis@ietf.org; Wed, 26 Jul 2006 08:17:45 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5iKa-0007qm-Qp for nsis@ietf.org; Wed, 26 Jul 2006 08:17:45 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6QCHD7n030369; Wed, 26 Jul 2006 13:17:13 +0100 Received: from [193.118.197.193] ([193.118.197.193]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 13:17:13 +0100 Message-ID: <44C75D49.3020108@roke.co.uk> Date: Wed, 26 Jul 2006 13:17:13 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: attila.bader@ericsson.com, karagian@cs.utwente.nl, nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2006 12:17:13.0660 (UTC) FILETIME=[6D529FC0:01C6B0AD] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [NSIS] WGLC review of RMD X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Attila, Georgios, all, Having just got back from a post-ietf holiday, I've finished reviewing the RMD draft. I've marked up comments on a copy of the draft. Since this is probably too big to post to the list, I've put it here: http://nsis.srmr.co.uk/~adm/draft-ietf-nsis-rmd-07_adm_comments.txt There are a couple of general comments (also contained in the marked-up version): The internal operation of GIST (e.g. C-mode and D-mode) is referred to a number of times in the draft. However, these details are not visible to the NSLP. In general, GIST interactions should probably be dicussed in terms of the API. There are a lot of places where something like: "This must be set to 42 (i.e. Some_Thing)" is said. It would be better just to say: "This must be set to Some_Thing" where the value for Some_Thing is defined once in a table somewhere (in many cases that is in the QoS NSLP document) Otherwise, someone needs to do a careful check through the document to make sure that these values are all correct in each instance (especially required given that changes have happened in the documents where some of these codes originate, e.g. QoS NSLP). In looking at how QSpec stacking is used by RMD, it seems it is used at the initial reservation when there are parallel end-to-end and intra-domain RESERVE messages to piggyback intra-domain QSpec information on to the RESPONSE. Also, it seems that sometimes there is a RESPONSE sent by the edge node (back to the other edge node) as part of the intra-domain session. Is it possible to summarise where the intra-domain RESPONSE is carried by the end-to-end session, and when a RESPONSE (or NOTIFY) is sent as part of the intra-domain session? regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 09:15:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jE3-0005Y8-3t; Wed, 26 Jul 2006 09:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jE2-0005Vd-HF for nsis@ietf.org; Wed, 26 Jul 2006 09:14:58 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5jE0-0000nP-JC for nsis@ietf.org; Wed, 26 Jul 2006 09:14:57 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1153919552!211401!44 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 32417 invoked from network); 26 Jul 2006 13:14:55 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-120.messagelabs.com with SMTP; 26 Jul 2006 13:14:55 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 44C39E8500062DFD; Wed, 26 Jul 2006 09:14:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Wed, 26 Jul 2006 08:14:53 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7B5D@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: Acav/FuJ5HAnJS7RRIKD+zMWJuR2rQAAvuagACUVHuAABuWrYA== From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hancock, Robert" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, I agree with most of what you said. See below for a couple of comments. > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > Sent: Wednesday, July 26, 2006 5:21 AM > To: Ash, Gerald R (Jerry), ALABS; Roland Bless > Cc: nsis@ietf.org > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 > hi, >=20 > just to add my two [small currency units]: i also still think > that the mandatory/optional parameter concept is the right way > to proceed. it was developed in order to guarantee some minimal > level of interworking even if the flow path crosses some very > disparate set of regions with different QoS management techniques > without requiring a heavyweight implementation of all options in > each of them; at the same time, it allows for more optimised QoS > treatment in more homogeneous environments. we would have to=20 > think very carefully before concluding that there are alternative > solutions to that pair of problems. >=20 > it may be that there are some QoS models which don't need some of > the mandatory parameters. i don't see that as a problem; for=20 > those models, the parameter mapping that the model has to define > is just very simple (it is "ignore").=20 Right now it's not allowed to 'ignore' a mandatory parameter. Section 4.2, 4th paragraph specifies: " Mandatory parameters provide a minimal subset of parameters. A QNE MUST either a) strictly interpret a mandatory parameter, or b) remap the parameter and raise the flag defined in Section 5.1, where the remapping MUST be specified in the QOSM specification. Here the terminology 'strictly interpret' means that the parameter is implemented according to the commonly accepted definition and/or as specified by references given for each QSPEC parameter. This means that in case a), a parameter must be strictly interpreted as a token bucket. However, in case b), a parameter may be remapped, perhaps to a parameter."=20 The above does not allow an option to 'ignore' a mandatory parameter. However, there may be cases perhaps where a mandatory parameter must be ignored by a QOSM. In that case your suggestion may be a way to go: if a mandatory QSPEC parameter must be ignored by a QOSM, that needs to be specified in the QOSM specification document. In that case the QOSM would be allowed to set the N-flag ('not supported' flag) for the mandatory parameter. In that scenario (mandatory parameter is ignored) the QNI most likely would reject the reservation anyway. > in other cases, they may > natively use some different formulation than the QSPEC mandatory=20 > parameters; in that case, the requirement to fit into the QSPEC > is that the parametrisation should be re-formulated into=20 > (existing mandatory parameter)+(new optional parameter).=20 Such a mapping isn't allowed right now. A mandatory parameter may be remapped (and the remapping must be specified in the QOSM specification document), but there is no such thing as remapping a mandatory parameter into an optional parameter. That sounds pretty complex IMO. Thanks, Jerry > i think > that is a fair constraint to impose - it's just to stop there > developing 15 different ways of expressing the concept 'bandwidth' > and so on. >=20 > cheers, >=20 > robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 09:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jiA-0004f6-1i; Wed, 26 Jul 2006 09:46:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ji8-0004ez-9z for nsis@ietf.org; Wed, 26 Jul 2006 09:46:04 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5ji7-0007Kq-R4 for nsis@ietf.org; Wed, 26 Jul 2006 09:46:04 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-11.tower-121.messagelabs.com!1153919925!9887694!6 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2081 invoked from network); 26 Jul 2006 13:19:22 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-11.tower-121.messagelabs.com with SMTP; 26 Jul 2006 13:19:22 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 44C39E85000631F0; Wed, 26 Jul 2006 09:19:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Wed, 26 Jul 2006 08:19:21 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7B5E@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44C759C0.5060204@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: Acawq2CrPpEIevGPRPytaAPQfRbJJAABeF/w From: "Ash, Gerald R \(Jerry\), ALABS" To: "Roland Bless" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland, See below.=20 > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: Wednesday, July 26, 2006 8:02 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: nsis@ietf.org > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 > Hi Jerry, >=20 > maybe I'm a little confused about what the mandatory concept > exactly means in the QSPEC document. I guess there are actually two > different meanings of "mandatory" intermixed in the document (or only > in my mind). > a) mandatory to be supported by _all_ QOSMs (that's how I read phrases > like > "Mandatory and optional QSPEC parameters provide a common > language for QOSM developers to build their QSPECs and are=20 > likely to > be re-used in several QOSMs." or > "This is because mandatory > parameters have been defined as a common language. =20 > Therefore, a QNE > MUST at least interpret all the mandatory parameters in a=20 > QSPEC even > if it does not support the corresponding QOSM.") > b) mandatory parameter with respect to a specific a QoS model. >=20 > Maybe I have missed the point in the document which clearly or > explicitly says a). Most of the time my understanding was b). > It is perfectly fine to let a QOSM signal that a certain parameter is > mandatory to support for itself. Yes, the document clearly is specifying (a). See, for example, Section 4.4.1, which pretty clearly defines mandatory and optional parameters. I don't think this at all implies interpretation (b). I don't know where in the document you see any hint of interpretation (b)? =20 > But I had concerns with this: >=20 > Additional mandatory parameters may be defined in the future. > However, since this requires an update of all QNEs, this should be > considered carefully. The definition of new mandatory parameter > requires standards action and an update of this document. Such an > update also needs a new QSPEC version number. =20 > Furthermore, all QOSM > definitions must be updated to include how the new mandatory > parameter is to be interpreted in the respective QOSM. >=20 > As far as I understand the spec now, it's like: > 1) each QOSM specifies the required parameters > (mandatory for this particular QOSM) so each QOSM > implementation MUST understand and interpret these > parameters. Some of these parameters may be mandatory > in the QSPEC meaning and others are optional in the > QSPEC meaning but all are required (mandatory) for the > QOSM. Again, this is not at all the definition in the document (see Section 4.4.1). Where in the document does it say anything like this? > 2) mandatory parameters are a means of interworking > between QOSMs. Right. > 3) there is no concept of having additional > (optional) parameters within a QOSM. What does this mean? There certainly is a concept of having additional optional parameters within a QOSM (and a QOSM specification can define additional optional parameters). =20 > See further comments inline. >=20 > Ash, Gerald R (Jerry), ALABS wrote: > >> -----Original Message----- > >> From: Roland Bless [mailto:bless@tm.uka.de]=20 > >> Sent: Tuesday, July 25, 2006 11:09 AM > >> To: Kappler, Cornelia > >> Cc: Georgios Karagiannis; Bernd Schloer; Jukka MJ Manner;=20 > >> Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > >> Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > >> parameter list? > >> > >> Hi all, > >> > >>> I've been off-list for the last 10 days and may have difficulties > >>> grasping the real point of the debate. > >> Sorry, I missed the discussion, though we had some > >> informal discussion in Dallas one morning at a > >> roundtable :-) > >> > >>> I'd prefer some concrete suggestions to which parameters=20 > >>> should not > >>> be mandatory. Rather than blanket statements "List is too long" or > >>> "List is too short" or "we should have N parameters". > >>> > >>> The question is not really whether it should be 2 or 8 or 20 > >>> mandatory parameters. It is _which_ parameters are necessary to > >>> _just_ accommodate the key ideas of typical QOSMs. > >> Now I'll repeat what I already said in Dallas: > >=20 > > Where/when did you say this, I don't recall hearing this=20 > > comment in the > > NSIS meetings, but maybe I missed it? >=20 > Not in the official NSIS meeting. We had an informal > discussion one morning before the sessions began in > the atrium. You were sitting directly next to me > IIRC. Hannes actually brought up the question. Roland, that meeting in the atrium was in Dallas (IETF-65). I do recall of course sitting next to you at that meeting, but I don't recall any discussion on the number of mandatory parameters (perhaps I missed it). However, I heard no discussion of this topic in Montreal (IETF-66). =20 > >> I'd prefer to not prescribe any mandatory parameters for all > >> QoS models. Thus I don't actually like the approach: > >> "Mandatory parameters in the QSPEC must be > >> meaningfully interpreted by all QNEs in the path, independent of > >> which QOSM they support." I disagree, > >> because we may have different QoS models that not even > >> require these parameters or future QoS models that require > >> even more mandatory parameters which are not covered by > >> the QSPEC template anyway.=20 > >=20 > > The concept is that a QNI initiates a reservation according=20 > > to its QOSM. > > It may populate one or more mandatory parameters, and perhaps some > > optional parameters in its QSPEC object. Mandatory=20 > > parameters only must > > be interpreted by downstream QNEs if populated by the QNI. =20 >=20 > That's ok. >=20 > > Right now there are only 3 mandatory QoS description parameters: > > , , and (see previous thread=20 > > discussion > > on this topic). Several people agreed this is a minimal set of > > mandatory parameters. It seems to me that most QOSMs will want to > > support some version of these 3 parameters. They provide a common > > language for QOSMs, based on IntServ and DiffServ, as=20 > > originally agreed > > in NSIS when the QSPEC was formulated. >=20 > That's fine. QSPEC should be a common language for QOSMs. > So if I need a bandwidth parameter, I know how to specify that. > But I simply don't want that the QSPEC states which of them > are mandatory for QOSMs. That should be specified by each QOSM > itself. IMHO it's useless to prescribe what should be mandatory > in the QSPEC, because future QOSMs may have even more mandatory > parameters which are not supported by older QOSMs anyway. > But maybe I'm only confused by terminology, what mandatory > actually means (see above). >=20 > > If a local domain supports a different QOSM than the QNI=20 > > QOSM, it may > > remap (approximately interpret) the mandatory parameters that are > > populated, and may ignore the optional parameters, and flag those > > parameters it remaps or ignores. The QNI makes a decision=20 > > on whether to > > accept or reject the reservation based on the RESPONSE. >=20 > Ok, so: > if I populated a "mandatory by QSPEC" parameter, > it must be "understood" by the QOSM which may also > finally ignore it? Right now it is not allowed to 'ignore' a mandatory QSPEC parameter, it MUST be interpreted. =20 > > If for example the QNI populates and the local domain QNEs > > ignore (assuming that is not mandatory=20 > > in the local > > QOSM, as you propose), the QNI is going to probably reject the > > reservation anyway. At best, the reservation will not be what is > > intended/desired by the QNI. >=20 > My case was the other way around: If a future QOSM has a required > (mandatory in meaning b)) parameter that is not supported by other > QOSMs, the current mandatory parameter set by QSPEC doesn't help > anyway. >=20 > >> But trying to be constructive: > >> I would rather prefer to leave it up to each QoS model > >> which parameters are mandatory and which are not, like > >> defining a profile (e.g. similar to MPEG profiles). > >> Furthermore, interworking between different QoS models > >> can be defined that describes which parameters can > >> mapped onto which in the other QoSM. > >=20 > > I don't agree with this approach, I think it would be=20 > > overly complex for > > QOSMs to define all that detail for all 14 QSPEC parameters. A also >=20 > No, you only need to define what is actually mandatory or optional, > you don't need to list parameters that are not used by the QOSM. >=20 > > don't think it would provide meaningful new functionality. E.g., if > > some QOSMs said is mandatory, and others said it=20 > > was optional, > > what would be the difference anyway if a local QOSM didn't=20 > > support the > > parameter as mandatory, if it was populated in=20 > > the QNI-QSPEC? > > The local domain would merely respond that it ignored the > > parameter and the QNI would probably reject the reservation=20 > > in any case. > >=20 > > If we decide to not have the mandatory/optional parameter concept, I > > would prefer to just have all parameters be treated as=20 > > 'optional', as > > currently defined in the QSPEC document. >=20 > I guess it's fine to keep most of the stuff if that's the > consensus. Maybe there could > be clarifying text that "mandatory" actually means: > mandatory to be understood and supported by all QOSMs > and not mandatory within the QOSM itself. We can try to clarify the text. Please let us know if you have suggested clarifying text (this would be especially helpful in the place(s) in the document where you have inferred interpretation (b)). Thanks, Regards, Jerry =20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 09:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jjN-0004r7-TY; Wed, 26 Jul 2006 09:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jjN-0004r2-36 for nsis@ietf.org; Wed, 26 Jul 2006 09:47:21 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5jjM-0007Yo-Eq for nsis@ietf.org; Wed, 26 Jul 2006 09:47:21 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1G5jjE-0004Ig-Fr; Wed, 26 Jul 2006 15:47:18 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 1CE77BED4; Wed, 26 Jul 2006 15:47:08 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1G5jj9-0004i9-Rw; Wed, 26 Jul 2006 15:47:07 +0200 Message-ID: <44C7725B.4040102@tm.uka.de> Date: Wed, 26 Jul 2006 15:47:07 +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: "Hancock, Robert" Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, > just to add my two [small currency units]: i also still think > that the mandatory/optional parameter concept is the right way > to proceed. it was developed in order to guarantee some minimal > level of interworking even if the flow path crosses some very > disparate set of regions with different QoS management techniques > without requiring a heavyweight implementation of all options in > each of them; at the same time, it allows for more optimised QoS > treatment in more homogeneous environments. we would have to > think very carefully before concluding that there are alternative > solutions to that pair of problems. My misunderstanding was actually the scope of the meaning of "mandatory". I thought it means mandatory for a QoS model, not mandatory for all QOSMs. > it may be that there are some QoS models which don't need some of > the mandatory parameters. i don't see that as a problem; for > those models, the parameter mapping that the model has to define > is just very simple (it is "ignore"). in other cases, they may So the mandatory parameters are ignored in this particular QOS...hmmm. > natively use some different formulation than the QSPEC mandatory > parameters; in that case, the requirement to fit into the QSPEC > is that the parametrisation should be re-formulated into > (existing mandatory parameter)+(new optional parameter). i think Ok, but then maybe new optional parameter means required for this particular QOSM (i.e. mandatory within the QOSM). I also can think of QOSMs that specify parameters as additional information which are then optional within the QOSM itself. This is, however, not explicitly expressed within the QSPEC syntax. > that is a fair constraint to impose - it's just to stop there > developing 15 different ways of expressing the concept 'bandwidth' > and so on. That's fine. Regards, Roland > > cheers, > > robert h. > >> -----Original Message----- >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >> Sent: 25 July 2006 17:05 >> To: Roland Bless >> Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >> Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory >> parameter list? >> >> >> Hi Roland, >> >> See below. >> >>> -----Original Message----- >>> From: Roland Bless [mailto:bless@tm.uka.de] >>> Sent: Tuesday, July 25, 2006 11:09 AM >>> To: Kappler, Cornelia >>> Cc: Georgios Karagiannis; Bernd Schloer; Jukka MJ Manner; >>> Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >>> Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory >>> parameter list? >>> >>> Hi all, >>> >>>> I've been off-list for the last 10 days and may have difficulties >>>> grasping the real point of the debate. >>> Sorry, I missed the discussion, though we had some >>> informal discussion in Dallas one morning at a >>> roundtable :-) >>> >>>> I'd prefer some concrete suggestions to which parameters >> should not >>>> be mandatory. Rather than blanket statements "List is too long" or >>>> "List is too short" or "we should have N parameters". >>>> >>>> The question is not really whether it should be 2 or 8 or 20 >>>> mandatory parameters. It is _which_ parameters are necessary to >>>> _just_ accommodate the key ideas of typical QOSMs. >>> Now I'll repeat what I already said in Dallas: >> Where/when did you say this, I don't recall hearing this >> comment in the >> NSIS meetings, but maybe I missed it? >> >>> I'd prefer to not prescribe any mandatory parameters for all >>> QoS models. Thus I don't actually like the approach: >>> "Mandatory parameters in the QSPEC must be >>> meaningfully interpreted by all QNEs in the path, independent of >>> which QOSM they support." I disagree, >>> because we may have different QoS models that not even >>> require these parameters or future QoS models that require >>> even more mandatory parameters which are not covered by >>> the QSPEC template anyway. >> The concept is that a QNI initiates a reservation according >> to its QOSM. >> It may populate one or more mandatory parameters, and perhaps some >> optional parameters in its QSPEC object. Mandatory >> parameters only must >> be interpreted by downstream QNEs if populated by the QNI. >> >> Right now there are only 3 mandatory QoS description parameters: >> , , and (see previous thread discussion >> on this topic). Several people agreed this is a minimal set of >> mandatory parameters. It seems to me that most QOSMs will want to >> support some version of these 3 parameters. They provide a common >> language for QOSMs, based on IntServ and DiffServ, as >> originally agreed >> in NSIS when the QSPEC was formulated. >> >> If a local domain supports a different QOSM than the QNI QOSM, it may >> remap (approximately interpret) the mandatory parameters that are >> populated, and may ignore the optional parameters, and flag those >> parameters it remaps or ignores. The QNI makes a decision on >> whether to >> accept or reject the reservation based on the RESPONSE. >> >> If for example the QNI populates and the local domain QNEs >> ignore (assuming that is not mandatory in >> the local >> QOSM, as you propose), the QNI is going to probably reject the >> reservation anyway. At best, the reservation will not be what is >> intended/desired by the QNI. >> >>> But trying to be constructive: >>> I would rather prefer to leave it up to each QoS model >>> which parameters are mandatory and which are not, like >>> defining a profile (e.g. similar to MPEG profiles). >>> Furthermore, interworking between different QoS models >>> can be defined that describes which parameters can >>> mapped onto which in the other QoSM. >> I don't agree with this approach, I think it would be overly >> complex for >> QOSMs to define all that detail for all 14 QSPEC parameters. A also >> don't think it would provide meaningful new functionality. E.g., if >> some QOSMs said is mandatory, and others said it >> was optional, >> what would be the difference anyway if a local QOSM didn't support the >> parameter as mandatory, if it was populated in the >> QNI-QSPEC? >> The local domain would merely respond that it ignored the >> parameter and the QNI would probably reject the reservation >> in any case. >> >> If we decide to not have the mandatory/optional parameter concept, I >> would prefer to just have all parameters be treated as 'optional', as >> currently defined in the QSPEC document. >> >> Thanks, >> Jerry >> >>> I agree on this statement in the introduction: >>> " A particular QOSM >>> specifies a) a set of mandatory and optional QSPEC >> parameters, and >>> b) how the QSPEC information is interpreted by the RMF >> with respect >>> to the QoS description, resources desired, resources >> available, and >>> control information." >>> The value of the QSPEC is still retained, because a QoSM only >>> needs to pick certain parameters of the QSPEC which are already >>> defined therein. >>> >>> Just my two cents, >>> Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 10:15:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5kAk-00048q-PC; Wed, 26 Jul 2006 10:15:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5kAj-00048f-KZ for nsis@ietf.org; Wed, 26 Jul 2006 10:15:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5jZQ-0004Qj-Aj for nsis@ietf.org; Wed, 26 Jul 2006 09:37:04 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5jOl-0008EE-Gc for nsis@ietf.org; Wed, 26 Jul 2006 09:26:07 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 356876E0002; Wed, 26 Jul 2006 15:25:56 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 15:25:55 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 15:25:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jul 2006 15:25:55 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D055DFEA7@esealmw116.eemea.ericsson.se> In-Reply-To: <44C75D49.3020108@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC review of RMD Thread-Index: AcawrX4MiNzLEPdMT0e5EJzSyABH8wACORAw From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Andrew McDonald" , , X-OriginalArrivalTime: 26 Jul 2006 13:25:55.0241 (UTC) FILETIME=[05F9F990:01C6B0B7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [NSIS] RE: WGLC review of RMD X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, thank you very much for reviewing the draft and for the = detailed comments. We try to include them in the next version, and come = back with answers, comments later.=20 Best regards, Attila > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk] > Sent: Wednesday, July 26, 2006 2:17 PM > To: Attila B=E1der (IJ/ETH); karagian@cs.utwente.nl; nsis@ietf.org > Subject: WGLC review of RMD >=20 >=20 > Hi Attila, Georgios, all, >=20 > Having just got back from a post-ietf holiday, I've finished reviewing > the RMD draft. I've marked up comments on a copy of the draft. Since > this is probably too big to post to the list, I've put it here: > http://nsis.srmr.co.uk/~adm/draft-ietf-nsis-rmd-07_adm_comments.txt >=20 > There are a couple of general comments (also contained in the=20 > marked-up > version): >=20 > The internal operation of GIST (e.g. C-mode and D-mode) is=20 > referred to a > number of times in the draft. However, these details are not=20 > visible to > the NSLP. In general, GIST interactions should probably be dicussed in > terms of the API. >=20 > There are a lot of places where something like: > "This must be set to 42 (i.e. Some_Thing)" > is said. It would be better just to say: > "This must be set to Some_Thing" > where the value for Some_Thing is defined once in a table=20 > somewhere (in=20 > many cases that is in the QoS NSLP document) > Otherwise, someone needs to do a careful check through the document to > make sure that these values are all correct in each instance=20 > (especially=20 > required given that changes have happened in the documents=20 > where some of=20 > these codes originate, e.g. QoS NSLP). >=20 > In looking at how QSpec stacking is used by RMD, it seems it=20 > is used at > the initial reservation when there are parallel end-to-end and > intra-domain RESERVE messages to piggyback intra-domain QSpec > information on to the RESPONSE. Also, it seems that sometimes=20 > there is a > RESPONSE sent by the edge node (back to the other edge node)=20 > as part of > the intra-domain session. Is it possible to summarise where the=20 > intra-domain RESPONSE is carried by the end-to-end session,=20 > and when a=20 > RESPONSE (or NOTIFY) is sent as part of the intra-domain session? >=20 > regards, > Andrew >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 11:49:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ld2-000324-EA; Wed, 26 Jul 2006 11:48:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ld0-00030l-SG for nsis@ietf.org; Wed, 26 Jul 2006 11:48:54 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5ld0-0005PR-5q for nsis@ietf.org; Wed, 26 Jul 2006 11:48:54 -0400 Received: (qmail invoked by alias); 26 Jul 2006 15:42:07 -0000 Received: from ip-80-226-224-137.vodafone-net.de (EHLO [10.226.73.250]) [80.226.224.137] by mail.gmx.net (mp027) with SMTP; 26 Jul 2006 17:42:07 +0200 X-Authenticated: #29516787 Message-ID: <44C78D3F.8090801@gmx.net> Date: Wed, 26 Jul 2006 17:41:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Bless Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? References: <44C7725B.4040102@tm.uka.de> In-Reply-To: <44C7725B.4040102@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, when I re-read the QSPEC template draft in detail this year again I was confused as well. Hence, we scheduled a breakfast meeting in Dallas to discuss various aspects. In many discussions a few things changed in the draft and I learned new things as well. Here is what I understand, which seems to be different to Roberts and Rolands understanding: * The QSPEC template draft defines mandatory QoS parameters. The meaning is that they must be understood by every QNE (not matter which QOSM they implement). It does not mean that every QOSM needs to carry all mandatory parameters. In fact it might not even carry a single one of them (I don't think that the QSPEC template draft talks about this aspect). Small note: In a previous mailing list discussion I argued that the wording for 'mandatory parameter' is strictly speaking not realistic and I gave the example of interior nodes in an RMD domain. Let us see whether something will change with the next draft update. I agree with Robert that the concept itself is very important. Defining mappings between different QOSMs is still useful (although not done today in NSIS). For example, there is no description of RMD to Y.1541 QOSM mapping. The choice of mandatory parameters is obviously extremely important to the usefulness of the entire concept. With the recent discussion it seems that the list of the mandatory parameters will become smaller. I am not sure we have already defined the minimum set of useful parameters. What is missing today in QOSMs is a mapping of mandatory parameters to the QOSM behavior. If you look at the QOSMs being standardized today then they do not necessarily use all mandatory parameters. It is, IMHO, important to specify what a node that implements a particular QOSM would do when it receives a message with a QSPEC object that contains an unknown QOSM. For example, what do all the currently specified mandatory parameters mean in the context of RMD? I have asked this question in the past already; I never saw an answer. * The optional parameters in the QSPEC template draft only serve the purpose of a "common language for QoS parameters". This is not really important since a QOSM might want to describe their parameters anyway even if they are available in the QSPEC. The same is true for the parameter format. Ciao Hannes Roland Bless wrote: > Hi Robert, > > >>just to add my two [small currency units]: i also still think >>that the mandatory/optional parameter concept is the right way >>to proceed. it was developed in order to guarantee some minimal >>level of interworking even if the flow path crosses some very >>disparate set of regions with different QoS management techniques >>without requiring a heavyweight implementation of all options in >>each of them; at the same time, it allows for more optimised QoS >>treatment in more homogeneous environments. we would have to >>think very carefully before concluding that there are alternative >>solutions to that pair of problems. > > > My misunderstanding was actually the scope of the > meaning of "mandatory". I thought it means mandatory for a > QoS model, not mandatory for all QOSMs. > > >>it may be that there are some QoS models which don't need some of >>the mandatory parameters. i don't see that as a problem; for >>those models, the parameter mapping that the model has to define >>is just very simple (it is "ignore"). in other cases, they may > > > So the mandatory parameters are ignored in this particular > QOS...hmmm. > > >>natively use some different formulation than the QSPEC mandatory >>parameters; in that case, the requirement to fit into the QSPEC >>is that the parametrisation should be re-formulated into >>(existing mandatory parameter)+(new optional parameter). i think > > > Ok, but then maybe new optional parameter means required for this > particular QOSM (i.e. mandatory within the QOSM). I also can think > of QOSMs that specify parameters as additional information which are > then optional within the QOSM itself. This is, however, not explicitly > expressed within the QSPEC syntax. > > >>that is a fair constraint to impose - it's just to stop there >>developing 15 different ways of expressing the concept 'bandwidth' >>and so on. > > > That's fine. > > Regards, > Roland > >>cheers, >> >>robert h. >> >> >>>-----Original Message----- >>>From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>>Sent: 25 July 2006 17:05 >>>To: Roland Bless >>>Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >>>Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory >>>parameter list? >>> >>> >>>Hi Roland, >>> >>>See below. >>> >>> >>>>-----Original Message----- >>>>From: Roland Bless [mailto:bless@tm.uka.de] >>>>Sent: Tuesday, July 25, 2006 11:09 AM >>>>To: Kappler, Cornelia >>>>Cc: Georgios Karagiannis; Bernd Schloer; Jukka MJ Manner; >>>>Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >>>>Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory >>>>parameter list? >>>> >>>>Hi all, >>>> >>>> >>>>>I've been off-list for the last 10 days and may have difficulties >>>>>grasping the real point of the debate. >>>> >>>>Sorry, I missed the discussion, though we had some >>>>informal discussion in Dallas one morning at a >>>>roundtable :-) >>>> >>>> >>>>>I'd prefer some concrete suggestions to which parameters >>> >>>should not >>> >>>>>be mandatory. Rather than blanket statements "List is too long" or >>>>>"List is too short" or "we should have N parameters". >>>>> >>>>>The question is not really whether it should be 2 or 8 or 20 >>>>>mandatory parameters. It is _which_ parameters are necessary to >>>>>_just_ accommodate the key ideas of typical QOSMs. >>>> >>>>Now I'll repeat what I already said in Dallas: >>> >>>Where/when did you say this, I don't recall hearing this >>>comment in the >>>NSIS meetings, but maybe I missed it? >>> >>> >>>>I'd prefer to not prescribe any mandatory parameters for all >>>>QoS models. Thus I don't actually like the approach: >>>>"Mandatory parameters in the QSPEC must be >>>>meaningfully interpreted by all QNEs in the path, independent of >>>>which QOSM they support." I disagree, >>>>because we may have different QoS models that not even >>>>require these parameters or future QoS models that require >>>>even more mandatory parameters which are not covered by >>>>the QSPEC template anyway. >>> >>>The concept is that a QNI initiates a reservation according >>>to its QOSM. >>>It may populate one or more mandatory parameters, and perhaps some >>>optional parameters in its QSPEC object. Mandatory >>>parameters only must >>>be interpreted by downstream QNEs if populated by the QNI. >>> >>>Right now there are only 3 mandatory QoS description parameters: >>>, , and (see previous thread discussion >>>on this topic). Several people agreed this is a minimal set of >>>mandatory parameters. It seems to me that most QOSMs will want to >>>support some version of these 3 parameters. They provide a common >>>language for QOSMs, based on IntServ and DiffServ, as >>>originally agreed >>>in NSIS when the QSPEC was formulated. >>> >>>If a local domain supports a different QOSM than the QNI QOSM, it may >>>remap (approximately interpret) the mandatory parameters that are >>>populated, and may ignore the optional parameters, and flag those >>>parameters it remaps or ignores. The QNI makes a decision on >>>whether to >>>accept or reject the reservation based on the RESPONSE. >>> >>>If for example the QNI populates and the local domain QNEs >>>ignore (assuming that is not mandatory in >>>the local >>>QOSM, as you propose), the QNI is going to probably reject the >>>reservation anyway. At best, the reservation will not be what is >>>intended/desired by the QNI. >>> >>> >>>>But trying to be constructive: >>>>I would rather prefer to leave it up to each QoS model >>>>which parameters are mandatory and which are not, like >>>>defining a profile (e.g. similar to MPEG profiles). >>>>Furthermore, interworking between different QoS models >>>>can be defined that describes which parameters can >>>>mapped onto which in the other QoSM. >>> >>>I don't agree with this approach, I think it would be overly >>>complex for >>>QOSMs to define all that detail for all 14 QSPEC parameters. A also >>>don't think it would provide meaningful new functionality. E.g., if >>>some QOSMs said is mandatory, and others said it >>>was optional, >>>what would be the difference anyway if a local QOSM didn't support the >>> parameter as mandatory, if it was populated in the >>>QNI-QSPEC? >>>The local domain would merely respond that it ignored the >>>parameter and the QNI would probably reject the reservation >>>in any case. >>> >>>If we decide to not have the mandatory/optional parameter concept, I >>>would prefer to just have all parameters be treated as 'optional', as >>>currently defined in the QSPEC document. >>> >>>Thanks, >>>Jerry >>> >>> >>>>I agree on this statement in the introduction: >>>>" A particular QOSM >>>> specifies a) a set of mandatory and optional QSPEC >>> >>>parameters, and >>> >>>> b) how the QSPEC information is interpreted by the RMF >>> >>>with respect >>> >>>> to the QoS description, resources desired, resources >>> >>>available, and >>> >>>> control information." >>>>The value of the QSPEC is still retained, because a QoSM only >>>>needs to pick certain parameters of the QSPEC which are already >>>>defined therein. >>>> >>>>Just my two cents, >>>> Roland > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 15:50:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5pOT-0007WW-Qq; Wed, 26 Jul 2006 15:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5pOM-0007Fc-UA; Wed, 26 Jul 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5pOM-0001ph-Fs; Wed, 26 Jul 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6QJo2p0006456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jul 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G5pOL-0001K8-VS; Wed, 26 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-10.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --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 : GIST: General Internet Signaling Transport Author(s) : H. Schulzrinne, R. Hancock Filename : draft-ietf-nsis-ntlp-10.txt Pages : 141 Date : 2006-7-26 This document specifies protocol stacks for the routing and transport of per-flow signaling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signaling Transport (GIST), which provides a universal service for diverse signaling applications. GIST does not handle signaling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signaling" framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-ntlp-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-ntlp-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-26133231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-26133231.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Jul 26 19:02:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sOC-0004Pr-U6; Wed, 26 Jul 2006 19:02:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sOB-0004PG-8R; Wed, 26 Jul 2006 19:02:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5pqw-0005RM-Og; Wed, 26 Jul 2006 16:19:34 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5pOM-0008FM-LL; Wed, 26 Jul 2006 15:50:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6QJo1p0006454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jul 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G5pOL-0001K2-U5; Wed, 26 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Jul 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ram-dhc-dhcpv6-aakey-00.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --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 : Authentication, Authorization and key management for DHCPv6 Author(s) : V. Ram, et al. Filename : draft-ram-dhc-dhcpv6-aakey-00.txt Pages : 16 Date : 2006-7-26 Dynamic Host Configuration Protocol version 6 (DHCPv6) authentication, as described in RFC3315, makes use of a model described in RFC3118. The DHCP threat model is described in RFC3118. However, RFC3118 does not discuss the distribution of keys to the server and the client. It assumes that the keys are transferred to the server and client using out of band mechanisms. This draft proposes to make use of the security association that the client shares with its home Authentication, Authorization and Accounting (AAA) servers. The security association between the client and server are established during DHCPv6 messaging. This document specifies options to DHCPv6 messages that can be used to create DHCPv6 Security Associations between the client and server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ram-dhc-dhcpv6-aakey-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ram-dhc-dhcpv6-aakey-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ram-dhc-dhcpv6-aakey-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-26133020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ram-dhc-dhcpv6-aakey-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ram-dhc-dhcpv6-aakey-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-26133020.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Jul 26 19:15:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5san-0002IZ-7i; Wed, 26 Jul 2006 19:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sal-0002Eb-Op for nsis@ietf.org; Wed, 26 Jul 2006 19:15:03 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5sak-00046C-8K for nsis@ietf.org; Wed, 26 Jul 2006 19:15:03 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6QNEni1014428; Thu, 27 Jul 2006 02:14:49 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 02:14:15 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 02:14:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Thu, 27 Jul 2006 02:14:14 +0300 Message-ID: In-Reply-To: <44C6341F.2040508@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: Acav/LcCghxuE3maTlGfy+CUEAgaOwBC/M8w From: To: , X-OriginalArrivalTime: 26 Jul 2006 23:14:14.0892 (UTC) FILETIME=[363542C0:01C6B109] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: gash@att.com, karagian@cs.utwente.nl, jmanner@cs.Helsinki.FI, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Just bumping up a bit. =20 Generally, QoS models will address specific QoS deployements (at least mostly currently defined by different SDOs). These QoS Models don't necessarily scale or are applicable Internet-wide. (this is a rough generalization). In order to ensure some level of interopation, the Qspec contain should contain some basic information understood by all QoSM's so that signaling between different QoS deployments is possible. =20 I don't (currently) think it is possible to define 1 universal QoSM - but the Qspec should define a basic template for signaling QoS across the Internet and different deployments. The Mandatory parameter SHOULD (well, MUST) be understood by the different QoSMs - enough so they can either accept or reject a certain QoS flow. John >-----Original Message----- >From: ext Roland Bless [mailto:bless@tm.uka.de]=20 >Sent: 25 July, 2006 11:09 >To: Kappler, Cornelia >Cc: Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org;=20 >Ash,Gerald R ALABS >Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 >parameter list? > >Hi all, > >> I've been off-list for the last 10 days and may have difficulties=20 >> grasping the real point of the debate. > >Sorry, I missed the discussion, though we had some informal=20 >discussion in Dallas one morning at a roundtable :-) > >> I'd prefer some concrete suggestions to which parameters=20 >should not be=20 >> mandatory. Rather than blanket statements "List is too long"=20 >or "List=20 >> is too short" or "we should have N parameters". >>=20 >> The question is not really whether it should be 2 or 8 or 20=20 >mandatory=20 >> parameters. It is _which_ parameters are necessary to _just_=20 >> accomodate the key ideas of typical QOSMs. > >Now I'll repeat what I already said in Dallas: >I'd prefer to not prescribe any mandatory parameters for all=20 >QoS models. Thus I don't actually like the approach: >"Mandatory parameters in the QSPEC must be meaningfully=20 >interpreted by all QNEs in the path, independent of which QOSM=20 >they support." I disagree, because we may have different QoS=20 >models that not even require these parameters or future QoS=20 >models that require even more mandatory parameters which are=20 >not covered by the QSPEC template anyway. But trying to be=20 >constructive: >I would rather prefer to leave it up to each QoS model which=20 >parameters are mandatory and which are not, like defining a=20 >profile (e.g. similar to MPEG profiles). >Furthermore, interworking between different QoS models can be=20 >defined that describes which parameters can mapped onto which=20 >in the other QoSM. >I agree on this statement in the introduction: >" A particular QOSM > specifies a) a set of mandatory and optional QSPEC parameters, and > b) how the QSPEC information is interpreted by the RMF with respect > to the QoS description, resources desired, resources available, and > control information." >The value of the QSPEC is still retained, because a QoSM only=20 >needs to pick certain parameters of the QSPEC which are=20 >already defined therein. > >Just my two cents, > Roland > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 19:18:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5se7-00067s-MI; Wed, 26 Jul 2006 19:18:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5se6-00067c-G1 for nsis@ietf.org; Wed, 26 Jul 2006 19:18:30 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5se5-0004Kq-0t for nsis@ietf.org; Wed, 26 Jul 2006 19:18:30 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6QNIRRP017869; Thu, 27 Jul 2006 02:18:27 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 02:18:01 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 02:18:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] NSIS next steps Date: Thu, 27 Jul 2006 02:18:00 +0300 Message-ID: In-Reply-To: <44B60BFB.2010704@docomolab-euro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] NSIS next steps Thread-Index: AcamXNW1ses8bmqZRM+jTBJvFnUIvAKrNEdQ From: To: X-OriginalArrivalTime: 26 Jul 2006 23:18:00.0712 (UTC) FILETIME=[BCCEA880:01C6B109] X-Spam-Score: 0.2 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: robert.hancock@roke.co.uk, nsis@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org OK, my advice for next steps would be to write this up in a draft - so interested parties should discuss this. John=20 >-----Original Message----- >From: ext mendes [mailto:mendes@docomolab-euro.com]=20 >Sent: 13 July, 2006 05:02 >To: Loughney John (Nokia-NRC/Helsinki) >Cc: hannes.tschofenig@siemens.com; nsis@ietf.org;=20 >robert.hancock@roke.co.uk >Subject: Re: AW: [NSIS] NSIS next steps > >Hi John > >I'll be very interested in contributing to describe a=20 >different type on interDomain-QoSM based on a pattern MRM. But=20 >before that I would like to see you else is interested in=20 >this. Moreover, all this work depends on the evolution of the=20 >pattern MRM itself. At this point in time, I would say that=20 >would be interesting to explore a Echo pattern to allow QoS=20 >controllers to locate other peers in its (network) vicinity. > >Paulo > >john.loughney@nokia.com wrote: >> Paulo, >> >> =20 >>> I would like to express interest on the MRM pattern (I had already=20 >>> done it in Dallas after Martin's presentation). >>> >>> As for Hannes question about applications that may make use of this=20 >>> MRM, I can mention one: a different type of interDomain-QoSM as the=20 >>> one that will be presented in Montreal >>> (draft-zhang-nsis-interdomain-qosm-02): >>> - the draft to be presented in Montreal makes use of the=20 >new off-path=20 >>> MRM to break the end-to-end QoS signaling into inter-domain and=20 >>> intra-domain. >>> - with the MRM pattern the inter-domain signaling may be done in a=20 >>> different way, starting by the QoS-controller that triggers the=20 >>> navigation pattern. For instance: >>> - one QoS-controller may explore/monitor the capacity of=20 >>> neighbour networks (QoS-controllers) with a TTL defined in=20 >the query=20 >>> message and use the returned information to dimension its network. >>> - one QoS-controller may announce its own capability to its=20 >>> neighbours with a TTL defined in the query, and to collect the=20 >>> interest of other networks to make use of that capability. >>> =20 >> >> Very interesting - I'd be very interested in seeing this written up. >> >> =20 >>> Another application may be to configuration over dispersed nodes,=20 >>> such as sensors, and to collect sensing information. >>> =20 >> >> That would be another use - though a bit more experimental ... >> >> John >> >> =20 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 19:33:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ssX-0007JI-Ex; Wed, 26 Jul 2006 19:33:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ssW-0007GT-4L for nsis@ietf.org; Wed, 26 Jul 2006 19:33:24 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ssU-0005mT-L0 for nsis@ietf.org; Wed, 26 Jul 2006 19:33:24 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6QMXJXR031275; Thu, 27 Jul 2006 01:33:21 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 02:32:59 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 02:32:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Proposal for implementing QoS NSLP Proxy Mode Date: Thu, 27 Jul 2006 02:32:58 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal for implementing QoS NSLP Proxy Mode Thread-Index: AcapIXcjV+XEwO+ETWaE6ZuTCQOWegH6k/qA From: To: , X-OriginalArrivalTime: 26 Jul 2006 23:32:58.0551 (UTC) FILETIME=[D3F60470:01C6B10B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This seems like a reasonable way forward, IMO. John=20 >-----Original Message----- >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 >Sent: 16 July, 2006 17:44 >To: nsis@ietf.org >Subject: [NSIS] Proposal for implementing QoS NSLP Proxy Mode > > >We had a good discussion with Robert about the QoS NSLP Proxy=20 >mode, and at the end we agreed that the QoS NSLP does not=20 >really need much. Actually, we only need a new scope (besides=20 >single link and e2e) called e.g.=20 >"proxy", and the domain admin must define manually, which QNE=20 >operates as proxy (Proxy-QNE, P-QNE). Here is how the fing works: > >[End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver or sender] > >For outgoing flows, the end host is the QNI, and sends a=20 >RESERVE with the new proxy-scope bit set. The P-QNE will=20 >receive the RESERVE and reply with a RESPONSE (if requested),=20 >and NOT forward the RESERVE further to the next peer. The=20 >receiver-oriented reservation works the same way (QUERY=20 >towards P-QNE, RESERVE back, then RESPONSE to P-QNE, all=20 >carrying the proxy-scope bit). > >For incoming flows, the end host is also the QNI, and it sends=20 >a RESERVE towards the data sender with the proxy-scope bit=20 >set. Here the end host sets the MRI so that it indicates the=20 >end host as the receiver of the data, and the D-flag is set.=20 >If there is only one P-QNE in the domain, GIST gets the=20 >RESERVE to the P-QNE. If there are more than one P-QNEs, GIST=20 >will do its best, but may reply with an error indicating=20 >destination unreachable. > >Jukka > >ps. I'll be out of emails for a couple of weeks now. I intend=20 >to finalize the QoS NSLP draft in August and we can then send=20 >it for AD review. > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 20:03:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tLx-00022E-5q; Wed, 26 Jul 2006 20:03:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tLw-000226-4v; Wed, 26 Jul 2006 20:03:48 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5tLu-0001HA-LV; Wed, 26 Jul 2006 20:03:48 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6R03jLg026889; Thu, 27 Jul 2006 03:03:45 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 03:03:45 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 03:03:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Late RMD comments Date: Thu, 27 Jul 2006 03:03:44 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Late RMD comments Thread-Index: AcatKNWC8AA4BGdKRq6BV6gggBlAEwD5yZVA From: To: , X-OriginalArrivalTime: 27 Jul 2006 00:03:44.0966 (UTC) FILETIME=[20829660:01C6B110] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I agree with David. I know for sure that his point (2) will generate a DISCUSS from the IESG, so I think you need to take his suggestions very seriously. thanks, John=20 >-----Original Message----- >From: ext nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 >Sent: 21 July, 2006 20:50 >To: nsis@ietf.org >Subject: [NSIS] Late RMD comments > >I realize that Last Call on this draft ended yesterday, but I=20 >have a couple of things to add: > >(1) The format in Section 4.1.1 has the same=20 >limitation as the corresponding format in the QSPEC draft. =20 >Both of them should be expanded to be capable of signaling=20 >everything defined in RFC 3140. >A set of PHBs would make sense if RMD were used to provide a=20 >reserved bandwidth path for an AF PHB set across a domain. > >(2) I'm still uncomfortable with the potential DSCP=20 >consumption for severe congestion handling. Section 4.6.1.6.2.1 says: > > It is RECOMMENDED that the total number of additional DSCPs needed=20 > for severe congestion handling within an RMD domain should=20 >be as low=20 > as possible and it should not exceed the limit of 16. > >DSCPs are a rather scarce resource - 16 is: >- 25% of the total number that exist >- 50% of the EXP/LU space (cf. RFC 2474) >- 100% of Pool 2, the EXP/LU space not subject to future=20 >standardization. > >It would be acceptable to me if the number 16 were changed to 8. >Another possibility would be to go through the traffic classes=20 >in draft-ietf-tsvwg-diffserv-service-classes-02.txt and=20 >explain which ones RMD congestion control is applicable to=20 >motivate the selected limit. > >Thanks, >--David >---------------------------------------------------- >David L. Black, Senior Technologist >EMC Corporation, 176 South St., Hopkinton, MA 01748 >+1 (508) 293-7953 FAX: +1 (508) 293-7786 >black_david@emc.com Mobile: +1 (978) 394-7754 >---------------------------------------------------- > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 26 20:05:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tNS-0002aQ-53; Wed, 26 Jul 2006 20:05:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tNQ-0002aH-Gj; Wed, 26 Jul 2006 20:05:20 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5tNP-0001LK-1X; Wed, 26 Jul 2006 20:05:20 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6QN5Fmm015629; Thu, 27 Jul 2006 02:05:18 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 03:04:47 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 03:04:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Late QSPEC comments Date: Thu, 27 Jul 2006 03:04:46 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Late QSPEC comments Thread-Index: AcatDNipimSrQcYkSpCDP209wwqfRgEA12/A From: To: , X-OriginalArrivalTime: 27 Jul 2006 00:04:46.0615 (UTC) FILETIME=[45417A70:01C6B110] X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org David, Good points - Jerry, can you clarify these? thanks, John=20 >-----Original Message----- >From: ext nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 >Sent: 21 July, 2006 17:30 >To: nsis@ietf.org >Subject: [NSIS] Late QSPEC comments > >I reviewed draft-ietf-nsis-qspec-10.txt, looking mostly for=20 >DiffServ issues. I found a couple of things: > >Section 7.2.2 > >I understand "drop" as a single value, but not "shape" or "remark". >Shape to what? Remark to what? > >Section 7.2.6.1 > >This format is a subset of RFC 3140. It's missing the "X" bit=20 >in bit 14 for a set of PHBs (e.g., AF), and fails to cover the=20 >Case 2 format on p.4 of RFC 3140, even though the registry for=20 >the codes used in Case 2 is currently empty. > >Thanks, >--David >---------------------------------------------------- >David L. Black, Senior Technologist >EMC Corporation, 176 South St., Hopkinton, MA 01748 >+1 (508) 293-7953 FAX: +1 (508) 293-7786 >black_david@emc.com Mobile: +1 (978) 394-7754 >---------------------------------------------------- > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 27 02:32:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zPU-0007XM-Ld; Thu, 27 Jul 2006 02:31:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zPS-0007XE-Th for nsis@ietf.org; Thu, 27 Jul 2006 02:31:50 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5zPR-0002it-E8 for nsis@ietf.org; Thu, 27 Jul 2006 02:31:50 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 27 Jul 2006 08:31:46 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jul 2006 08:31:46 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF7C3@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: Hannes.Tschofenig@gmx.net Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Thu, 27 Jul 2006 08:31:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hannes, you raise an important aspect here. |What is missing today in QOSMs is a mapping of mandatory parameters to = |the QOSM behavior. If you look at the QOSMs being standardized today=20 |then they do not necessarily use all mandatory parameters. It=20 |is, IMHO, important to specify what a node that implements a=20 |particular QOSM would do when it receives a message with a QSPEC=20 |object that contains an unknown QOSM. For example, what do all=20 |the currently specified mandatory parameters mean in the context of=20 |RMD? I have asked this question in the past already; I never=20 |saw an answer. The draft should at least say, that the reservation must be=20 released/refused if a node doesn't understand a QOSM. If a=20 different behaviour is operated, every implementor of a QOSM=20 may design own interworkings and if several different=20 implementations appear along a path, the (usually value added)=20 service may not behave in way as expected by the QNI. A reservation should only continue if there's a standardised=20 interworking between different QOSM's along a path. I don't=20 however favour a solution, where everey standardised QOSM=20 is obliged to interwork with every other standardised=20 QOSM. Standardisation of these interworkings should follow=20 the trends of the operational Internet to this regard.=20 Interworkings between a few popular QOSMs may be useful. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 27 04:20:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G616h-00068a-0l; Thu, 27 Jul 2006 04:20:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G616f-00068V-12 for nsis@ietf.org; Thu, 27 Jul 2006 04:20:33 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G616b-0006zO-9E for nsis@ietf.org; Thu, 27 Jul 2006 04:20:32 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7E08ADAC; Thu, 27 Jul 2006 10:20:24 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 10:20:23 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 10:20:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Late RMD comments Date: Thu, 27 Jul 2006 10:20:23 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D055DFEAA@esealmw116.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Late RMD comments Thread-Index: AcatKNWC8AA4BGdKRq6BV6gggBlAEwD5yZVAABE1o3A= From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: , , X-OriginalArrivalTime: 27 Jul 2006 08:20:23.0493 (UTC) FILETIME=[81D0F750:01C6B155] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, David,=20 Thank you for the commments. I do not see problems to change these in = the draft. Best regards, Attila > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, July 27, 2006 2:04 AM > To: nsis-bounces@ietf.org; nsis@ietf.org > Subject: RE: [NSIS] Late RMD comments >=20 >=20 > Hi all, >=20 > I agree with David. I know for sure that his point (2) will generate > a DISCUSS from the IESG, so I think you need to take his suggestions > very seriously. >=20 > thanks, > John=20 >=20 > >-----Original Message----- > >From: ext nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 > >Sent: 21 July, 2006 20:50 > >To: nsis@ietf.org > >Subject: [NSIS] Late RMD comments > > > >I realize that Last Call on this draft ended yesterday, but I=20 > >have a couple of things to add: > > > >(1) The format in Section 4.1.1 has the same=20 > >limitation as the corresponding format in the QSPEC draft. =20 > >Both of them should be expanded to be capable of signaling=20 > >everything defined in RFC 3140. > >A set of PHBs would make sense if RMD were used to provide a=20 > >reserved bandwidth path for an AF PHB set across a domain. > > > >(2) I'm still uncomfortable with the potential DSCP=20 > >consumption for severe congestion handling. Section=20 > 4.6.1.6.2.1 says: > > > > It is RECOMMENDED that the total number of additional=20 > DSCPs needed=20 > > for severe congestion handling within an RMD domain should=20 > >be as low=20 > > as possible and it should not exceed the limit of 16. > > > >DSCPs are a rather scarce resource - 16 is: > >- 25% of the total number that exist > >- 50% of the EXP/LU space (cf. RFC 2474) > >- 100% of Pool 2, the EXP/LU space not subject to future=20 > >standardization. > > > >It would be acceptable to me if the number 16 were changed to 8. > >Another possibility would be to go through the traffic classes=20 > >in draft-ietf-tsvwg-diffserv-service-classes-02.txt and=20 > >explain which ones RMD congestion control is applicable to=20 > >motivate the selected limit. > > > >Thanks, > >--David > >---------------------------------------------------- > >David L. Black, Senior Technologist > >EMC Corporation, 176 South St., Hopkinton, MA 01748 > >+1 (508) 293-7953 FAX: +1 (508) 293-7786 > >black_david@emc.com Mobile: +1 (978) 394-7754 > >---------------------------------------------------- > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 27 07:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G63g0-0006EH-GP; Thu, 27 Jul 2006 07:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G63fz-0006E7-V8 for nsis@ietf.org; Thu, 27 Jul 2006 07:05:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G61Qz-0008HM-Kk for nsis@ietf.org; Thu, 27 Jul 2006 04:41:33 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G61DX-0005Di-EL for nsis@ietf.org; Thu, 27 Jul 2006 04:27:42 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6R8RKra021485; Thu, 27 Jul 2006 09:27:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Thu, 27 Jul 2006 09:27:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: Acav/FuJ5HAnJS7RRIKD+zMWJuR2rQAAvuagACUVHuAABuWrYAAounpA From: "Hancock, Robert" To: "Ash, Gerald R \(Jerry\), ALABS" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org jerry, i think we are actually agreeing with each other, but I'm not expressing myself very clearly. let me try a different tack. 1. one terminology issue (which may a general source of=20 confusion) is that we tend to be a bit lax about saying what "thing" the mandatory/optional distinction applies to - QNIs, QNEs, QoSMs, reservations, whatever. IMHO in order to achieve the interoperability goal (which is the main point) the mandatory/optional wording applies to QNEs: in other words, QNEs MUST understand and do something sensible with the mandatory parameters whatever QoSM they support. I don't see that it makes so much sense to say that a parameter is mandatory or optional for a QoSM or for a QNI. (see further below.) whatever the actual resolution here, i think the Qspec could do with more explanation of what 'mandatory' means conceptually. and it may be that 'mandatory' is not a good word; perhaps=20 something like 'basic' or 'fundamental' would be better. 2. to go to the first of your points below, my suggestion is that QNEs MUST understand the mandatory parameters, but=20 QoSMs do not have to use them if they do not want to. To me, a QoSM is a document and a node is a piece of equipment; we should specify what the equipment MUST do. the underlying point here is: to what extent are we expecting to define QNE behaviour by stating which QoSMs it supports. I don't actually think this is entirely feasible. For example, imagine a node that supports QoSMs A and B receiving a reservation for QoSM C. It has to implement the reservation by using an interpretation of the mandatory parameters in C, but which one should it use? The one defined by A or the one defined by B? Does it matter which? The only information propagated in the reservation is that C was not supported, not which of A/B was used as the definition for the mandatory parameter treatment. So, all that matters here is that the QNE does something=20 sensible with the parameter (and that is implicitly defined in the Qspec itself). to make a semi-sensible example: suppose you wanted to use the QoS-NSLP to check for TCP QuickStart support along a=20 path. Probably one would do this by defining a QuickStart QoSM. Within that QoSM, none of the Qspec mandatory parameters have any useful meaning, since QuickStart (AFAIK) just cares about the existence of a traffic management mechanism. So, saying that the QoSM MUST define a mapping for the mandatory parameters does not seem reasonable. However, an actual node MUST still support the mandatory parameters, so it can=20 process a non-QuickStart reservation. 3. to go to the second point below, i think this is a matter of phraseology. what i was trying to get at is that it might be natural for a particular resource management mechanism to be described in terms of (say) parameters X, Y and Z. However, none of X/Y/Z relate directly to the existing=20 Qspec parameters. Then, isn't it the case that we would expect the QoSM authors to go back to the definitions of X, Y and Z and say "aha, really this is equivalent to a token bucket and a couple of other parameters P, Q" and to write the QoSM document that way rather than directly in terms of X/Y/Z.=20 in other words, the reformulation is a requirement on the authors of new QoSMs, not on the QoSM itself. sorry for such a long email, r. > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > Sent: 26 July 2006 14:15 > To: Hancock, Robert > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 >=20 > Hi Robert, >=20 > I agree with most of what you said. See below for a couple=20 > of comments. >=20 >=20 > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > > Sent: Wednesday, July 26, 2006 5:21 AM > > To: Ash, Gerald R (Jerry), ALABS; Roland Bless > > Cc: nsis@ietf.org > > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > > parameter list? > >=20 > > hi, > >=20 > > just to add my two [small currency units]: i also still think > > that the mandatory/optional parameter concept is the right way > > to proceed. it was developed in order to guarantee some minimal > > level of interworking even if the flow path crosses some very > > disparate set of regions with different QoS management techniques > > without requiring a heavyweight implementation of all options in > > each of them; at the same time, it allows for more optimised QoS > > treatment in more homogeneous environments. we would have to=20 > > think very carefully before concluding that there are alternative > > solutions to that pair of problems. > >=20 > > it may be that there are some QoS models which don't need some of > > the mandatory parameters. i don't see that as a problem; for=20 > > those models, the parameter mapping that the model has to define > > is just very simple (it is "ignore").=20 >=20 > Right now it's not allowed to 'ignore' a mandatory parameter. Section > 4.2, 4th paragraph specifies: >=20 > " Mandatory parameters provide a minimal subset of parameters. A > QNE MUST either a) strictly interpret a mandatory parameter, or > b) remap the parameter and raise the flag defined in > Section 5.1, where the remapping MUST be specified in the QOSM > specification. Here the terminology 'strictly interpret'=20 > means that > the parameter is implemented according to the commonly accepted > definition and/or as specified by references given for each QSPEC > parameter. This means that in case a), a parameter > must be strictly interpreted as a token bucket. However,=20 > in case b), > a parameter may be remapped, perhaps to a=20 > > parameter."=20 >=20 > The above does not allow an option to 'ignore' a mandatory parameter. > However, there may be cases perhaps where a mandatory=20 > parameter must be > ignored by a QOSM. In that case your suggestion may be a way=20 > to go: if > a mandatory QSPEC parameter must be ignored by a QOSM, that=20 > needs to be > specified in the QOSM specification document. In that case the QOSM > would be allowed to set the N-flag ('not supported' flag) for the > mandatory parameter. In that scenario (mandatory parameter=20 > is ignored) > the QNI most likely would reject the reservation anyway. >=20 > > in other cases, they may > > natively use some different formulation than the QSPEC mandatory=20 > > parameters; in that case, the requirement to fit into the QSPEC > > is that the parametrisation should be re-formulated into=20 > > (existing mandatory parameter)+(new optional parameter).=20 >=20 > Such a mapping isn't allowed right now. A mandatory parameter may be > remapped (and the remapping must be specified in the QOSM=20 > specification > document), but there is no such thing as remapping a=20 > mandatory parameter > into an optional parameter. That sounds pretty complex IMO. >=20 > Thanks, > Jerry >=20 > > i think > > that is a fair constraint to impose - it's just to stop there > > developing 15 different ways of expressing the concept 'bandwidth' > > and so on. > >=20 > > cheers, > >=20 > > robert h. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 27 10:33:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66vK-000445-4U; Thu, 27 Jul 2006 10:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66vI-0003zg-Eu for nsis@ietf.org; Thu, 27 Jul 2006 10:33:12 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G66vH-0000jq-1l for nsis@ietf.org; Thu, 27 Jul 2006 10:33:12 -0400 Received: (qmail invoked by alias); 27 Jul 2006 14:33:06 -0000 Received: from ip-80-226-252-80.vodafone-net.de (EHLO [10.226.214.60]) [80.226.252.80] by mail.gmx.net (mp033) with SMTP; 27 Jul 2006 16:33:06 +0200 X-Authenticated: #29516787 Message-ID: <44C8CE9D.4020004@gmx.net> Date: Thu, 27 Jul 2006 16:33:01 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? References: <6439282641581441A36F7F6F83ED2ED2CBF7C3@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF7C3@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ruediger, Geib, Ruediger wrote: > Hannes, > > you raise an important aspect here. > > |What is missing today in QOSMs is a mapping of mandatory parameters to > |the QOSM behavior. If you look at the QOSMs being standardized today > |then they do not necessarily use all mandatory parameters. It > |is, IMHO, important to specify what a node that implements a > |particular QOSM would do when it receives a message with a QSPEC > |object that contains an unknown QOSM. For example, what do all > |the currently specified mandatory parameters mean in the context of > |RMD? I have asked this question in the past already; I never > |saw an answer. > > The draft should at least say, that the reservation must be > released/refused if a node doesn't understand a QOSM. Well, that's not what a node should do. Instead it should try todo anything it can to produce a meaningful QoS reservation whereby the idea is that this 'meaningful' reservation can be accomplished by just looking at the mandatory QoS parameters of a QSPEC object (with the details of that particular QOSM being unknown). If a > different behaviour is operated, every implementor of a QOSM > may design own interworkings and if several different > implementations appear along a path, the (usually value added) > service may not behave in way as expected by the QNI. The QNI might still learn that there are some domains along the end to end path that did not support the QOSM it signaled. It might still accomplish some QoS treatment although it will not be the one it initially expected. This is our 'better than nothing QoS' (inline with the 'better than nothing security' approach). > > A reservation should only continue if there's a standardised > interworking between different QOSM's along a path. That's the place where the QSPEC template guys would disagree with you. If the group would only worry about this aspect then we wouldn't need the QSPEC template draft. I don't > however favour a solution, where everey standardised QOSM > is obliged to interwork with every other standardised > QOSM. Sure. That would put a massive burden on new QOSMs and it might not be feasible given that other SDOs can also define their QOSMs. Standardisation of these interworkings should follow > the trends of the operational Internet to this regard. > Interworkings between a few popular QOSMs may be useful. I agree with you. This is, however, largely independent of the 'mandatory' QoS parameter idea. Ciao Hannes > > Regards, > > Rüdiger > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 27 11:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67T1-0008Me-TE; Thu, 27 Jul 2006 11:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67T1-0008MV-5t; Thu, 27 Jul 2006 11:08:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G67Sz-0005Ps-UI; Thu, 27 Jul 2006 11:08:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6RF81p0017689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jul 2006 15:08:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G67Sz-0003qO-LN; Thu, 27 Jul 2006 11:08:01 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 27 Jul 2006 11:08:01 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: nsis@ietf.org Subject: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org The IESG has received a request from the Next Steps in Signaling WG to consider the following document: - 'GIST: General Internet Signaling Transport ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-10. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-10.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 28 03:13:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6MWw-0004mY-Nq; Fri, 28 Jul 2006 03:13:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6MWv-0004mT-Ne for nsis@ietf.org; Fri, 28 Jul 2006 03:13:05 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6MWt-0001kz-UB for nsis@ietf.org; Fri, 28 Jul 2006 03:13:05 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Fri, 28 Jul 2006 09:13:02 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jul 2006 09:13:02 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF7CB@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: Hannes.Tschofenig@gmx.net Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Fri, 28 Jul 2006 09:12:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hannes, thanks for the clarification. If the QOSM philosophy is=20 as you describe it below then it's probably not producuing=20 what I would regard as QoS. I think that it is not possible=20 to define the service you will get if parameter=20 interpretation starts to be a local matter instead of=20 a standardised e2e behaviour.=20 Regards, R=FCdiger |> you raise an important aspect here. |>=20 |> |What is missing today in QOSMs is a mapping of mandatory=20 |> |parameters to the QOSM behavior. If you look at the=20 |> |QOSMs being standardized today=20 |> |then they do not necessarily use all mandatory parameters. It=20 |> |is, IMHO, important to specify what a node that implements a=20 |> |particular QOSM would do when it receives a message with a QSPEC=20 |> |object that contains an unknown QOSM. For example, what do all=20 |> |the currently specified mandatory parameters mean in the context of = |> |RMD? I have asked this question in the past already; I never=20 |> |saw an answer. |>=20 |> The draft should at least say, that the reservation must be=20 |> released/refused if a node doesn't understand a QOSM. | |Well, that's not what a node should do. Instead it should try todo=20 |anything it can to produce a meaningful QoS reservation=20 |whereby the idea=20 |is that this 'meaningful' reservation can be accomplished by just=20 |looking at the mandatory QoS parameters of a QSPEC object (with the=20 |details of that particular QOSM being unknown). | | If a |> different behaviour is operated, every implementor of a QOSM=20 |> may design own interworkings and if several different=20 |> implementations appear along a path, the (usually value added)=20 |> service may not behave in way as expected by the QNI. | |The QNI might still learn that there are some domains along the end to = |end path that did not support the QOSM it signaled. It might still=20 |accomplish some QoS treatment although it will not be the one it=20 |initially expected. This is our 'better than nothing QoS' (inline with = |the 'better than nothing security' approach). | | |>=20 |> A reservation should only continue if there's a standardised=20 |> interworking between different QOSM's along a path. | |That's the place where the QSPEC template guys would disagree with = you. |If the group would only worry about this aspect then we wouldn't need=20 |the QSPEC template draft. | | I don't |> however favour a solution, where everey standardised QOSM=20 |> is obliged to interwork with every other standardised=20 |> QOSM. | |Sure. That would put a massive burden on new QOSMs and it might not be = |feasible given that other SDOs can also define their QOSMs. | | | Standardisation of these interworkings should follow |> the trends of the operational Internet to this regard.=20 |> Interworkings between a few popular QOSMs may be useful. |I agree with you. |This is, however, largely independent of the 'mandatory' QoS parameter = |idea. | |Ciao |Hannes | |>=20 |> Regards, |>=20 |> R=FCdiger |>=20 |>=20 | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 28 11:32:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6UJs-0000Aj-U2; Fri, 28 Jul 2006 11:32:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6UJr-0000Ab-Od for nsis@ietf.org; Fri, 28 Jul 2006 11:32:07 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6UJq-0006Fs-AR for nsis@ietf.org; Fri, 28 Jul 2006 11:32:07 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1G6UJb-0004y0-Ua; Fri, 28 Jul 2006 17:31:55 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id AFD50BF05; Fri, 28 Jul 2006 17:31:51 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1G6UJb-0008GR-9a; Fri, 28 Jul 2006 17:31:51 +0200 Message-ID: <44CA2DE6.2000506@tm.uka.de> Date: Fri, 28 Jul 2006 17:31:50 +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: "Hancock, Robert" Subject: Re: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Mark Doll , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, [while playing around with our implementation, I reread parts of the current NTLP draft after a long time...and I have two -- maybe very silly/basic questions]: A) Possibly I missed the part in the draft, but is there any clear specification where exactly the RESPONSE must be sent in D-Mode (no MA-reuse)? I found only the following statements which are IMHO not very explicit about the exact destination: "A Query always triggers a Response in the reverse direction as the second message of the handshake." "No Association: No MA exists. GN2 sends the Response in D-mode directly to GN1, identifying itself and agreeing to the association setup." "Query MUST elicit a Response. This is a normally encapsulated D-mode message with additional payloads." and the "best hint" is in sec. 5.2.2 / NLI: The interface-address must be routable, i.e. it MUST be usable as a destination IP address for packets to be sent back to the node generating the signaling message, whether in D-mode or C-mode. though it doesn't specify something about which destination address must be used for responses (and it would not be the appropriate section for this). The example in fig.11 shows that the NLI i/f address is used in the response. (The alternative to use the NLI address would be sending it back to the source in case of a set S-flag, but I guess that's not what the spec intends...) However, I would really like to see a clear statement like: GN2 sends the Response in D-mode directly to GN1, using the interface-address as destination addess as specified in the NLI of the query and the source port of the query as destination port of the response. B) if the response must be sent back to what is specified in the NLI, this possibly opens up reflection attacks. This should be mentioned in the security considerations section and I'm not quite sure whether any sanity checks are possible to prevent this. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 28 18:32:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6at8-00026b-4u; Fri, 28 Jul 2006 18:32:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6at7-00026W-0A for nsis@ietf.org; Fri, 28 Jul 2006 18:32:57 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6at6-0000EL-KI for nsis@ietf.org; Fri, 28 Jul 2006 18:32:56 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k6SMWr88016755; Fri, 28 Jul 2006 18:32:53 -0400 (EDT) In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7B5D@KCCLUST06EVS1.ugd.att.com> Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? To: "Ash, Gerald R \(Jerry\), ALABS" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Fri, 28 Jul 2006 18:32:50 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/28/2006 06:31:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I think that, if a QNE is allowed to "ignore" a Mandatory parameter, it ceases to be "Mandatory" (at least as defined here). It seems that the only two options for a QNE which receives a Mandatory parameter are to "act on it as originally intended/defined" or "map it to one of the other permitted values for that Mandatory parameter. The example given was mapping between "bandwidth" and "token bucket" for the "Traffic Description" mandatory parameter. This means that every QNE MUST support either "bandwidth" or "token bucket". That SEEMS reasonable to me. If you don't support one, the QNE should map it into the other, and then apply it. This sounds OK too. But "Priority" is also a Mandatory parameter, and the two possibilities are (Preemption Priority/Defending Priority ) and (Admission Priority (with or without RPH)). First of all, I don't think it is reasonable to assume that EVERY QNE supports either "Preemption/ Defending" or "Admission Priority". I think it is quite likely that there will need to be QNEs that support neither (possibly because of local laws or regulations). Secondly, I do not think it is a good idea to have QNEs mapping arbitrarily between the two cases. Apart from anything else, if you map from "preemption/defending" to "admission priority" in one local domain, and then back to "preemption/defending" in another local domain, it is going to be very difficult to ensure that you end up with the original "preemption" value, and the original "defending" value. If the preemption and defending values are the same, you might be able to carry it in the RPH. But if the defending value is different, I don't see how you would preserve it. Thanks 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. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- "Ash, Gerald R \(Jerry\), ALABS" wrote on 07/26/2006 09:14:53 AM: > Hi Robert, > > I agree with most of what you said. See below for a couple of comments. > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Wednesday, July 26, 2006 5:21 AM > > To: Ash, Gerald R (Jerry), ALABS; Roland Bless > > Cc: nsis@ietf.org > > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory > > parameter list? > > > > hi, > > > > just to add my two [small currency units]: i also still think > > that the mandatory/optional parameter concept is the right way > > to proceed. it was developed in order to guarantee some minimal > > level of interworking even if the flow path crosses some very > > disparate set of regions with different QoS management techniques > > without requiring a heavyweight implementation of all options in > > each of them; at the same time, it allows for more optimised QoS > > treatment in more homogeneous environments. we would have to > > think very carefully before concluding that there are alternative > > solutions to that pair of problems. > > > > it may be that there are some QoS models which don't need some of > > the mandatory parameters. i don't see that as a problem; for > > those models, the parameter mapping that the model has to define > > is just very simple (it is "ignore"). > > Right now it's not allowed to 'ignore' a mandatory parameter. Section > 4.2, 4th paragraph specifies: > > " Mandatory parameters provide a minimal subset of parameters. A > QNE MUST either a) strictly interpret a mandatory parameter, or > b) remap the parameter and raise the flag defined in > Section 5.1, where the remapping MUST be specified in the QOSM > specification. Here the terminology 'strictly interpret' means that > the parameter is implemented according to the commonly accepted > definition and/or as specified by references given for each QSPEC > parameter. This means that in case a), a parameter > must be strictly interpreted as a token bucket. However, in case b), > a parameter may be remapped, perhaps to a > parameter." > > The above does not allow an option to 'ignore' a mandatory parameter. > However, there may be cases perhaps where a mandatory parameter must be > ignored by a QOSM. In that case your suggestion may be a way to go: if > a mandatory QSPEC parameter must be ignored by a QOSM, that needs to be > specified in the QOSM specification document. In that case the QOSM > would be allowed to set the N-flag ('not supported' flag) for the > mandatory parameter. In that scenario (mandatory parameter is ignored) > the QNI most likely would reject the reservation anyway. > > > in other cases, they may > > natively use some different formulation than the QSPEC mandatory > > parameters; in that case, the requirement to fit into the QSPEC > > is that the parametrisation should be re-formulated into > > (existing mandatory parameter)+(new optional parameter). > > Such a mapping isn't allowed right now. A mandatory parameter may be > remapped (and the remapping must be specified in the QOSM specification > document), but there is no such thing as remapping a mandatory parameter > into an optional parameter. That sounds pretty complex IMO. > > Thanks, > Jerry > > > i think > > that is a fair constraint to impose - it's just to stop there > > developing 15 different ways of expressing the concept 'bandwidth' > > and so on. > > > > cheers, > > > > robert h. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 28 19:59:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6cEO-0002Fh-SV; Fri, 28 Jul 2006 19:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6cEN-0002Fc-EW for nsis@ietf.org; Fri, 28 Jul 2006 19:58:59 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6cEM-00063n-1b for nsis@ietf.org; Fri, 28 Jul 2006 19:58:59 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1154131136!10993446!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9873 invoked from network); 28 Jul 2006 23:58:57 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-120.messagelabs.com with SMTP; 28 Jul 2006 23:58:57 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 44C39E85000D9007; Fri, 28 Jul 2006 19:58:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Date: Fri, 28 Jul 2006 18:58:56 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7B80@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Thread-Index: Acaylc3ZUjPAU4OoTU+Qet53DwAZ5wACfceg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Janet P Gunn" X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Janet, See below.=20 > -----Original Message----- > From: Janet P Gunn [mailto:jgunn6@csc.com]=20 > Sent: Friday, July 28, 2006 6:33 PM > To: Ash, Gerald R (Jerry), ALABS > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org; Hancock,Robert > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter list? >=20 > I think that, if a QNE is allowed to "ignore" a Mandatory=20 > parameter, it > ceases to be "Mandatory" (at least as defined here). Agree. However, they may be circumstances where it is necessary to ignore a mandatory parameter (e.g., where preemption in illegal, see below). =20 > It seems that the only two options for a QNE which receives a=20 > Mandatory > parameter are to "act on it as originally intended/defined"=20 > or "map it to > one of the other permitted values for that Mandatory parameter. >=20 > The example given was mapping between "bandwidth" and "token=20 > bucket" for > the "Traffic Description" mandatory parameter. This means=20 > that every QNE > MUST support either "bandwidth" or "token bucket". That=20 > SEEMS reasonable > to me. If you don't support one, the QNE should map it into=20 > the other, > and then apply it. This sounds OK too. >=20 > But "Priority" is also a Mandatory parameter, and the two=20 > possibilities > are (Preemption Priority/Defending Priority ) and (Admission=20 > Priority (with > or without RPH)). >=20 > First of all, I don't think it is reasonable to assume that EVERY QNE > supports either "Preemption/ Defending" or "Admission=20 > Priority". I think > it is quite likely that there will need to be QNEs that=20 > support neither > (possibly because of local laws or regulations). >=20 > Secondly, I do not think it is a good idea to have QNEs=20 > mapping arbitrarily > between the two cases. Apart from anything else, if you map from > "preemption/defending" to "admission priority" in one local=20 > domain, and > then back to "preemption/defending" in another local domain, =20 > it is going > to be very difficult to ensure that you end up with the original > "preemption" value, and the original "defending" value. >=20 > If the preemption and defending values are the same, you=20 > might be able to > carry it in the RPH. But if the defending value is=20 > different, I don't see > how you would preserve it. A few comments on the above: 1. I don't think there should be any remapping of parameters between preemption/defending priority and admission/RPH priority. These are two different things IMO and don't map to each other directly. 2. If it is illegal to use preemption (e.g., in the US PSTN), that is probably sufficient reason to allow a QNE to ignore the parameter. 3. IMO should be mandatory. For one thing, IntServ/RSVP uses these parameters (preemption/defending; admission priority extension in progress in TSVWG), and the set of mandatory parameters is based on IntServ/DiffServ. Thanks, Jerry >=20 > Thanks >=20 > Janet >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 29 05:38:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6lGd-0001Sq-U1; Sat, 29 Jul 2006 05:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6lGd-0001Sl-7L for nsis@ietf.org; Sat, 29 Jul 2006 05:37:55 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6lGb-00049A-P5 for nsis@ietf.org; Sat, 29 Jul 2006 05:37:55 -0400 Received: (qmail invoked by alias); 29 Jul 2006 09:37:51 -0000 Received: from p54984FB3.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.79.179] by mail.gmx.net (mp039) with SMTP; 29 Jul 2006 11:37:51 +0200 X-Authenticated: #29516787 Message-ID: <44CB2C7C.5080507@gmx.net> Date: Sat, 29 Jul 2006 11:38:04 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? References: <6439282641581441A36F7F6F83ED2ED2CBF7CB@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF7CB@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ruediger, it might not be what you would ideally expect. But consider that we are dealing with a failure case here (in some sense) that might in fact happen quite frequently in a transition period where access networks implement some QoSMs but the core network does not process any QoS signaling messages. With a sender-initiated reservation the edge node of the access network of the data receiver may receive a QoS signaling message with a QSPEC object containing a QoSM used in the data sender's access network. Then, you still receive some QoS treatment although it is not as perfect as it could be -> better than nothing. Ciao Hannes Geib, Ruediger wrote: > Hannes, > > thanks for the clarification. If the QOSM philosophy is > as you describe it below then it's probably not producuing > what I would regard as QoS. I think that it is not possible > to define the service you will get if parameter > interpretation starts to be a local matter instead of > a standardised e2e behaviour. > > Regards, > > Rüdiger > > > |> you raise an important aspect here. > |> > |> |What is missing today in QOSMs is a mapping of mandatory > |> |parameters to the QOSM behavior. If you look at the > |> |QOSMs being standardized today > |> |then they do not necessarily use all mandatory parameters. It > |> |is, IMHO, important to specify what a node that implements a > |> |particular QOSM would do when it receives a message with a QSPEC > |> |object that contains an unknown QOSM. For example, what do all > |> |the currently specified mandatory parameters mean in the context of > |> |RMD? I have asked this question in the past already; I never > |> |saw an answer. > |> > |> The draft should at least say, that the reservation must be > |> released/refused if a node doesn't understand a QOSM. > | > |Well, that's not what a node should do. Instead it should try todo > |anything it can to produce a meaningful QoS reservation > |whereby the idea > |is that this 'meaningful' reservation can be accomplished by just > |looking at the mandatory QoS parameters of a QSPEC object (with the > |details of that particular QOSM being unknown). > | > | If a > |> different behaviour is operated, every implementor of a QOSM > |> may design own interworkings and if several different > |> implementations appear along a path, the (usually value added) > |> service may not behave in way as expected by the QNI. > | > |The QNI might still learn that there are some domains along the end to > |end path that did not support the QOSM it signaled. It might still > |accomplish some QoS treatment although it will not be the one it > |initially expected. This is our 'better than nothing QoS' (inline with > |the 'better than nothing security' approach). > | > | > |> > |> A reservation should only continue if there's a standardised > |> interworking between different QOSM's along a path. > | > |That's the place where the QSPEC template guys would disagree with you. > |If the group would only worry about this aspect then we wouldn't need > |the QSPEC template draft. > | > | I don't > |> however favour a solution, where everey standardised QOSM > |> is obliged to interwork with every other standardised > |> QOSM. > | > |Sure. That would put a massive burden on new QOSMs and it might not be > |feasible given that other SDOs can also define their QOSMs. > | > | > | Standardisation of these interworkings should follow > |> the trends of the operational Internet to this regard. > |> Interworkings between a few popular QOSMs may be useful. > |I agree with you. > |This is, however, largely independent of the 'mandatory' QoS parameter > |idea. > | > |Ciao > |Hannes > | > |> > |> Regards, > |> > |> Rüdiger > |> > |> > | > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 29 05:38:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6lHN-0001vq-Dq; Sat, 29 Jul 2006 05:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6lHM-0001tG-M9 for nsis@ietf.org; Sat, 29 Jul 2006 05:38:40 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6lHL-0004C9-W7 for nsis@ietf.org; Sat, 29 Jul 2006 05:38:40 -0400 Received: (qmail invoked by alias); 29 Jul 2006 09:38:38 -0000 Received: from p54984FB3.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.79.179] by mail.gmx.net (mp031) with SMTP; 29 Jul 2006 11:38:38 +0200 X-Authenticated: #29516787 Message-ID: <44CB2CAC.1070208@gmx.net> Date: Sat, 29 Jul 2006 11:38:52 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, a minor comment below: Hancock, Robert wrote: > jerry, > > i think we are actually agreeing with each other, but I'm not > expressing myself very clearly. let me try a different tack. > > 1. one terminology issue (which may a general source of > confusion) is that we tend to be a bit lax about saying > what "thing" the mandatory/optional distinction applies to - > QNIs, QNEs, QoSMs, reservations, whatever. IMHO in order to > achieve the interoperability goal (which is the main point) > the mandatory/optional wording applies to QNEs: in other > words, QNEs MUST understand and do something sensible with > the mandatory parameters whatever QoSM they support. I don't > see that it makes so much sense to say that a parameter is > mandatory or optional for a QoSM or for a QNI. (see further > below.) > > whatever the actual resolution here, i think the Qspec could > do with more explanation of what 'mandatory' means conceptually. > and it may be that 'mandatory' is not a good word; perhaps > something like 'basic' or 'fundamental' would be better. > > 2. to go to the first of your points below, my suggestion is > that QNEs MUST understand the mandatory parameters, but > QoSMs do not have to use them if they do not want to. To me, > a QoSM is a document and a node is a piece of equipment; > we should specify what the equipment MUST do. > > the underlying point here is: to what extent are we expecting > to define QNE behaviour by stating which QoSMs it supports. > I don't actually think this is entirely feasible. For example, > imagine a node that supports QoSMs A and B receiving a reservation > for QoSM C. It has to implement the reservation by using an > interpretation of the mandatory parameters in C, but which one > should it use? The one defined by A or the one defined by B? > Does it matter which? The only information propagated in the > reservation is that C was not supported, not which of A/B was > used as the definition for the mandatory parameter treatment. > So, all that matters here is that the QNE does something > sensible with the parameter (and that is implicitly defined > in the Qspec itself). > > to make a semi-sensible example: suppose you wanted to use > the QoS-NSLP to check for TCP QuickStart support along a > path. Probably one would do this by defining a QuickStart > QoSM. Within that QoSM, none of the Qspec mandatory parameters > have any useful meaning, since QuickStart (AFAIK) just cares > about the existence of a traffic management mechanism. So, > saying that the QoSM MUST define a mapping for the mandatory > parameters does not seem reasonable. However, an actual node > MUST still support the mandatory parameters, so it can > process a non-QuickStart reservation. This is somewhat a corner case given what I wrote in my previous mail. The QSPEC template draft needs to indicate that this case can happen and hence it does not make sense to interpret mandatory parameters if there aren't any. > > 3. to go to the second point below, i think this is a matter > of phraseology. what i was trying to get at is that it might > be natural for a particular resource management mechanism > to be described in terms of (say) parameters X, Y and Z. > However, none of X/Y/Z relate directly to the existing > Qspec parameters. Then, isn't it the case that we would expect > the QoSM authors to go back to the definitions of X, Y and > Z and say "aha, really this is equivalent to a token bucket > and a couple of other parameters P, Q" and to write the QoSM > document that way rather than directly in terms of X/Y/Z. > in other words, the reformulation is a requirement on the > authors of new QoSMs, not on the QoSM itself. Alternatively, a QoSM could define how their parameters can be mapped to the mandatory parameters instead of rewriting the document to use different parameters since in most cases it is not just the terminology that is different (e.g., the name of the bandwidth parameter) but the range of possible might, for example, be different. As an example: Every SDO uses some form of priority values. The name of the attribute is different and the number of possible priority values as well. Still, there might be a way to map them to the priority values defined in the QSPEC template. When I tried to map the IEEE 802.16e QoS parameters to the parameters in the QSPEC template I had a really hard time because they did not match 100%. Sure, you can attempt to use the QSPEC parmeters with some additional wording but try to convince folks in Wimax that this is a good approach. Ciao Hannes > > sorry for such a long email, > > r. > > >>-----Original Message----- >>From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>Sent: 26 July 2006 14:15 >>To: Hancock, Robert >>Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >>Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory >>parameter list? >> >> >>Hi Robert, >> >>I agree with most of what you said. See below for a couple >>of comments. >> >> >> >>>-----Original Message----- >>>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >>>Sent: Wednesday, July 26, 2006 5:21 AM >>>To: Ash, Gerald R (Jerry), ALABS; Roland Bless >>>Cc: nsis@ietf.org >>>Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory >>>parameter list? >>> >>>hi, >>> >>>just to add my two [small currency units]: i also still think >>>that the mandatory/optional parameter concept is the right way >>>to proceed. it was developed in order to guarantee some minimal >>>level of interworking even if the flow path crosses some very >>>disparate set of regions with different QoS management techniques >>>without requiring a heavyweight implementation of all options in >>>each of them; at the same time, it allows for more optimised QoS >>>treatment in more homogeneous environments. we would have to >>>think very carefully before concluding that there are alternative >>>solutions to that pair of problems. >>> >>>it may be that there are some QoS models which don't need some of >>>the mandatory parameters. i don't see that as a problem; for >>>those models, the parameter mapping that the model has to define >>>is just very simple (it is "ignore"). >> >>Right now it's not allowed to 'ignore' a mandatory parameter. Section >>4.2, 4th paragraph specifies: >> >>" Mandatory parameters provide a minimal subset of parameters. A >> QNE MUST either a) strictly interpret a mandatory parameter, or >> b) remap the parameter and raise the flag defined in >> Section 5.1, where the remapping MUST be specified in the QOSM >> specification. Here the terminology 'strictly interpret' >>means that >> the parameter is implemented according to the commonly accepted >> definition and/or as specified by references given for each QSPEC >> parameter. This means that in case a), a parameter >> must be strictly interpreted as a token bucket. However, >>in case b), >> a parameter may be remapped, perhaps to a >> >> parameter." >> >>The above does not allow an option to 'ignore' a mandatory parameter. >>However, there may be cases perhaps where a mandatory >>parameter must be >>ignored by a QOSM. In that case your suggestion may be a way >>to go: if >>a mandatory QSPEC parameter must be ignored by a QOSM, that >>needs to be >>specified in the QOSM specification document. In that case the QOSM >>would be allowed to set the N-flag ('not supported' flag) for the >>mandatory parameter. In that scenario (mandatory parameter >>is ignored) >>the QNI most likely would reject the reservation anyway. >> >> >>>in other cases, they may >>>natively use some different formulation than the QSPEC mandatory >>>parameters; in that case, the requirement to fit into the QSPEC >>>is that the parametrisation should be re-formulated into >>>(existing mandatory parameter)+(new optional parameter). >> >>Such a mapping isn't allowed right now. A mandatory parameter may be >>remapped (and the remapping must be specified in the QOSM >>specification >>document), but there is no such thing as remapping a >>mandatory parameter >>into an optional parameter. That sounds pretty complex IMO. >> >>Thanks, >>Jerry >> >> >>>i think >>>that is a fair constraint to impose - it's just to stop there >>>developing 15 different ways of expressing the concept 'bandwidth' >>>and so on. >>> >>>cheers, >>> >>>robert h. >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 29 16:10:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6v8n-0005Ep-6F; Sat, 29 Jul 2006 16:10:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6v8l-0005EJ-1F for nsis@ietf.org; Sat, 29 Jul 2006 16:10:27 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6v8i-0001B4-QF for nsis@ietf.org; Sat, 29 Jul 2006 16:10:27 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Sat, 29 Jul 2006 16:10:13 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006072916101029626 ; Sat, 29 Jul 2006 16:10:10 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Jul 2006 16:10:10 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209DC2@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes Tschofenig , "Hancock, Robert" Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Sat, 29 Jul 2006 16:10:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Hannes and Robert: Inline [RRR]. BR/Radhika _____ From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Sat 7/29/2006 5:38 AM To: Hancock, Robert Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? When I tried to map the IEEE 802.16e QoS parameters to the parameters in the QSPEC template I had a really hard time because they did not match 100%. Sure, you can attempt to use the QSPEC parmeters with some additional wording but try to convince folks in Wimax that this is a good approach. [RRR] Did you also try to map from the application (e.g., SIP/SDP) to QSPEC parameters as NSIS is trying to do so? For example, there is a SIP INVITE and SDP expresses G.711 audio? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 29 17:26:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6wKZ-0006oP-OY; Sat, 29 Jul 2006 17:26:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6wKX-0006oI-Rg for nsis@ietf.org; Sat, 29 Jul 2006 17:26:41 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6wKW-0000OQ-EC for nsis@ietf.org; Sat, 29 Jul 2006 17:26:41 -0400 Received: (qmail invoked by alias); 29 Jul 2006 21:26:39 -0000 Received: from p54987724.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.119.36] by mail.gmx.net (mp019) with SMTP; 29 Jul 2006 23:26:39 +0200 X-Authenticated: #29516787 Message-ID: <44CBD29A.4050508@gmx.net> Date: Sat, 29 Jul 2006 23:26:50 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? References: <62D92A9A02BCC845B202323D49A48426209DC2@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426209DC2@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org No, I did not try to map the SIP/SDP parameters to the QSPEC. If we ignore the codecs then the only relevant parameter carried in SDP is a bandwidth parameter. Ciao Hannes Roy, Radhika R. wrote: > Hi, Hannes and Robert: > > Inline [RRR]. > > BR/Radhika > > _____ > > From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Sat 7/29/2006 5:38 AM > To: Hancock, Robert > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter > list? > > > > When I tried to map the IEEE 802.16e QoS parameters to the parameters in > the QSPEC template I had a really hard time because they did not match > 100%. Sure, you can attempt to use the QSPEC parmeters with some > additional wording but try to convince folks in Wimax that this is a > good approach. > > [RRR] Did you also try to map from the application (e.g., SIP/SDP) to QSPEC > parameters as NSIS is trying to do so? For example, there is a SIP INVITE > and SDP expresses G.711 audio? > > Ciao > Hannes > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 29 23:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G71wr-0007Aa-6j; Sat, 29 Jul 2006 23:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G71wp-0007AV-SL for nsis@ietf.org; Sat, 29 Jul 2006 23:26:35 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G71wn-0005H3-IT for nsis@ietf.org; Sat, 29 Jul 2006 23:26:35 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Sat, 29 Jul 2006 23:26:19 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006072923261519031 ; Sat, 29 Jul 2006 23:26:16 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Jul 2006 23:26:14 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209DC3@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes Tschofenig Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Sat, 29 Jul 2006 23:26:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Then, we have fundamental problems to fulfill the objectives of NSIS QOS standards. If you look very carefully, NSIS QOS is tied to the applications in the first place for which it is being designed to meet the very needs of QOS. If NSIS QOS is de-coupled from the applications to meet the needs of QOS, why are we developing so many fancy performance parameters? In the end of the day what purpose will NSIS QOS serve to meet the QOS needs of the applications? Let me summarize the problems that NSIS QOS standards will create if it is decoupled from the application QOS: 1. If a call from the application (e.g., SIP INVITE with G.711 codec) is made, the application will not be able to map it QOS needs (e.g., Bandwidth, Delay, Delay Jitter, Packet Loss) to the NSIS QOS signaling protocol messages. 2. If any arbitrary QOS needs are signaled to the NSIS QOS parameters decoupling from the application QOS needs, these QOS needs will be just some kinds of arbitrary IP network/MAC layer/Physical layer-centric QOS parameters that are only understood by the network entities like IP routers, LANs, base stations, etc., not by applications. 3. At the end of all those, when NSIS QOS parameters are sent to the application (e.g., G.711), what will the G.711 codec do? 4. If one thinks that some kinds of mapping between so-called NSIS IP network/MAC layer/Physical layer-centric QOS parameters will be magically be transformed into QOS parameters that the application (e.g., G.711), what is that standard? Is that so-called Y.xxxx or DSTE QOS model? If not, why are the NSIS WG working so hard to push for all those "technically confusing and contradicting" things that no direct relevance to NSIS QOS? 5. If you thinks that SDP needs to indicate bandwidth, delay, jitter, and packet loss for G.711, it can be done very easily and, like bandwidth, it will be end-to-end codec-to-codec delay/jitter/packet loss. Again, it will constitute the needs from the application point of view, and the SIP call is between the end-users - more appropriately between the codes. 6. If you think that NSIS will focus only on end-to-end application QOS parameters, can we not simplify using only few specific performance parameters for NSIS and let the network centric QOS folks develop all those billions of "segmented" performance parameters and so-called QOS models specific to all networks decoupling from the applications? Would you please take a little pain to clarify the above to the WG members as you are doing great jobs for so many things in many WGs including NSIS? Best regards, Radhika _____ From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Sat 7/29/2006 5:26 PM To: Roy, Radhika R. Cc: nsis@ietf.org; Hancock, Robert Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? No, I did not try to map the SIP/SDP parameters to the QSPEC. If we ignore the codecs then the only relevant parameter carried in SDP is a bandwidth parameter. Ciao Hannes Roy, Radhika R. wrote: > Hi, Hannes and Robert: > > Inline [RRR]. > > BR/Radhika > > _____ > > From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Sat 7/29/2006 5:38 AM > To: Hancock, Robert > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter > list? > > > > When I tried to map the IEEE 802.16e QoS parameters to the parameters in > the QSPEC template I had a really hard time because they did not match > 100%. Sure, you can attempt to use the QSPEC parmeters with some > additional wording but try to convince folks in Wimax that this is a > good approach. > > [RRR] Did you also try to map from the application (e.g., SIP/SDP) to QSPEC > parameters as NSIS is trying to do so? For example, there is a SIP INVITE > and SDP expresses G.711 audio? > > Ciao > Hannes > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 30 13:44:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7FKs-0004lL-Mv; Sun, 30 Jul 2006 13:44:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7FKr-0004lF-Hn for nsis@ietf.org; Sun, 30 Jul 2006 13:44:17 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7FKq-0000Zd-VL for nsis@ietf.org; Sun, 30 Jul 2006 13:44:17 -0400 Received: (qmail invoked by alias); 30 Jul 2006 17:44:15 -0000 Received: from p54986C35.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.108.53] by mail.gmx.net (mp039) with SMTP; 30 Jul 2006 19:44:15 +0200 X-Authenticated: #29516787 Message-ID: <44CCEFFD.8020103@gmx.net> Date: Sun, 30 Jul 2006 19:44:29 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? References: <62D92A9A02BCC845B202323D49A48426209DC3@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426209DC3@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roy, Roy, Radhika R. wrote: > Then, we have fundamental problems to fulfill the objectives of NSIS QOS > standards. There is no reason to be concerned. Just because I haven't done anything by my own isn't alarming. I bet a number of folks have done the analysis in a great level of detail. > If you look very carefully, NSIS QOS is tied to the applications in the > first place for which it is being designed to meet the very needs of QOS. If > NSIS QOS is de-coupled from the applications to meet the needs of QOS, why > are we developing so many fancy performance parameters? In the end of the > day what purpose will NSIS QOS serve to meet the QOS needs of the > applications? It is true that the parameters at all layers need to fit together if the goal is to signal for per-flow application layer traffic. Note, that there are some other scenarios where this is not necessarily true. > > Let me summarize the problems that NSIS QOS standards will create if it is > decoupled from the application QOS: > > 1. If a call from the application (e.g., SIP INVITE with G.711 codec) is > made, the application will not be able to map it QOS needs (e.g., Bandwidth, > Delay, Delay Jitter, Packet Loss) to the NSIS QOS signaling protocol > messages. Do you currently have the impression that this is not possible? > > 2. If any arbitrary QOS needs are signaled to the NSIS QOS parameters > decoupling from the application QOS needs, these QOS needs will be just some > kinds of arbitrary IP network/MAC layer/Physical layer-centric QOS > parameters that are only understood by the network entities like IP routers, > LANs, base stations, etc., not by applications. If the goal is to signal for end-to-end application layer traffic and the parameters at the link, network and the application layers do not fit together then there is a problem. > > 3. At the end of all those, when NSIS QOS parameters are sent to the > application (e.g., G.711), what will the G.711 codec do? It should be the other way around. The application knows what it wants todo and then it initiates QoS signaling with parameters it feels comfortable with. > > 4. If one thinks that some kinds of mapping between so-called NSIS IP > network/MAC layer/Physical layer-centric QOS parameters will be magically be > transformed into QOS parameters that the application (e.g., G.711), what is > that standard? There shouldn't be magic, obviously. However, you will not find IETF documents that describe these types of things since they are mostly implementation specific. Is that so-called Y.xxxx or DSTE QOS model? If not, why are > the NSIS WG working so hard to push for all those "technically confusing and > contradicting" things that no direct relevance to NSIS QOS? I know that you are not particularly excited about the Y.1541 work. Some environments will use the QoS model they like. The IETF (and the NSIS working group) is not the QoS deployment police. Let folks write the QoS model they like. No big problem if the document is properly written. With respect to the 'mandatory' QoS parameters we obviously need to make sure that we get them right. That was the reason we had some many discussions over the past few months. > 5. If you thinks that SDP needs to indicate bandwidth, delay, jitter, and > packet loss for G.711, it can be done very easily and, like bandwidth, it > will be end-to-end codec-to-codec delay/jitter/packet loss. Again, it will > constitute the needs from the application point of view, and the SIP call is > between the end-users - more appropriately between the codes. I looked at the 3GPP specs what they do with regard to the Diameter QoS work. They use information from SDP (bandwidth) and then use information about the environment (i.e., 3G access network) and then they generate the parameters. > > 6. If you think that NSIS will focus only on end-to-end application QOS > parameters, can we not simplify using only few specific performance > parameters for NSIS and let the network centric QOS folks develop all those > billions of "segmented" performance parameters and so-called QOS models > specific to all networks decoupling from the applications? Why don't you like the concept of QoS models? It is a useful concept and does not cause harm. You might not agree with all QoS models, for sure, but nobody will ever do so. RFC 3726 states that we focus on various deployment models; not only on E2E QoS. Ciao Hannes > > Best regards, > Radhika > > _____ > > From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Sat 7/29/2006 5:26 PM > To: Roy, Radhika R. > Cc: nsis@ietf.org; Hancock, Robert > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li > st? > > > > No, I did not try to map the SIP/SDP parameters to the QSPEC. > If we ignore the codecs then the only relevant parameter carried in SDP > is a bandwidth parameter. > > Ciao > Hannes > > Roy, Radhika R. wrote: > >>Hi, Hannes and Robert: >> >>Inline [RRR]. >> >>BR/Radhika >> >> _____ >> >>From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig >>Sent: Sat 7/29/2006 5:38 AM >>To: Hancock, Robert >>Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >>Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter >>list? >> >> >> >>When I tried to map the IEEE 802.16e QoS parameters to the parameters in >>the QSPEC template I had a really hard time because they did not match >>100%. Sure, you can attempt to use the QSPEC parmeters with some >>additional wording but try to convince folks in Wimax that this is a >>good approach. >> >>[RRR] Did you also try to map from the application (e.g., SIP/SDP) to > > QSPEC > >>parameters as NSIS is trying to do so? For example, there is a SIP INVITE >>and SDP expresses G.711 audio? >> >>Ciao >>Hannes >> > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 30 19:17:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7KWo-00078e-QR; Sun, 30 Jul 2006 19:16:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7KWo-000783-2G for nsis@ietf.org; Sun, 30 Jul 2006 19:16:58 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7KWn-0001Ch-Me for nsis@ietf.org; Sun, 30 Jul 2006 19:16:58 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Sun, 30 Jul 2006 19:16:50 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006073019165003019 ; Sun, 30 Jul 2006 19:16:50 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Sun, 30 Jul 2006 19:16:50 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209DC4@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes Tschofenig Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Sun, 30 Jul 2006 19:16:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Hannes: Let me summarize again the basic technical "fine" points. It is precisely: a. application layer QOS parameters vs. b. network centric QOS parameters. No IETF RFCs that are related to QOS had the charter to define QOS signaling and hence QOS parameters for application layer QOS other than NSIS. NSIS QOS signaling standards are proceeding OK. However, the key technical points that have been missed are this: 1. Do the NSIS QOS parameters defined so far represent end-to-end application QOS parameters (e.g., audio/video codec-to-codec bandwidth/delay/jitter/packet loss)? 2. If so, how do we do this? If not, why not? Best regards, Radhika PS: i. I understand the value of so-called QOS models developed by many folks in many standard organizations and people are implementing a lot of other things. But none of them doing is doing above based on standards. ii. The whole debates in NSIS QOS parameters have turned into how to carry the QOS parameters that have been defined in so-called QOS models that are also network-centric as I explained earlier. iii. Above item ii has obscured the basic fact that NSIS has been chartered that it will deal with application layer QOS. The question is this: Who will deal with the application aspect of QOS parameter that are so simple? iv. If 3GPP and other organization could solve the application layer QOS as described using standards, please let us know. v. If NSIS wants to deviate from its charter that it will NOT define application layer QOS, let us make the NSIS charter clear. If you think that the mapping between the network centric QOS and application QOS is a matter of implementation, I would then suggest, let NSIS charter should be revised by saying that the network-centric QOS parameters will be defined in along the spirit of all available so-called QOS models and/or IP network/MAC/physical layer QOS specific QOS parameters. In this case, we all know what to focus on without being oscillated between the two extreme ends: Application QOS vs. Network QOS. _____ From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Sun 7/30/2006 1:44 PM To: Roy, Radhika R. Cc: nsis@ietf.org; Hancock, Robert Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Hi Roy, Roy, Radhika R. wrote: > Then, we have fundamental problems to fulfill the objectives of NSIS QOS > standards. There is no reason to be concerned. Just because I haven't done anything by my own isn't alarming. I bet a number of folks have done the analysis in a great level of detail. > If you look very carefully, NSIS QOS is tied to the applications in the > first place for which it is being designed to meet the very needs of QOS. If > NSIS QOS is de-coupled from the applications to meet the needs of QOS, why > are we developing so many fancy performance parameters? In the end of the > day what purpose will NSIS QOS serve to meet the QOS needs of the > applications? It is true that the parameters at all layers need to fit together if the goal is to signal for per-flow application layer traffic. Note, that there are some other scenarios where this is not necessarily true. > > Let me summarize the problems that NSIS QOS standards will create if it is > decoupled from the application QOS: > > 1. If a call from the application (e.g., SIP INVITE with G.711 codec) is > made, the application will not be able to map it QOS needs (e.g., Bandwidth, > Delay, Delay Jitter, Packet Loss) to the NSIS QOS signaling protocol > messages. Do you currently have the impression that this is not possible? > > 2. If any arbitrary QOS needs are signaled to the NSIS QOS parameters > decoupling from the application QOS needs, these QOS needs will be just some > kinds of arbitrary IP network/MAC layer/Physical layer-centric QOS > parameters that are only understood by the network entities like IP routers, > LANs, base stations, etc., not by applications. If the goal is to signal for end-to-end application layer traffic and the parameters at the link, network and the application layers do not fit together then there is a problem. > > 3. At the end of all those, when NSIS QOS parameters are sent to the > application (e.g., G.711), what will the G.711 codec do? It should be the other way around. The application knows what it wants todo and then it initiates QoS signaling with parameters it feels comfortable with. > > 4. If one thinks that some kinds of mapping between so-called NSIS IP > network/MAC layer/Physical layer-centric QOS parameters will be magically be > transformed into QOS parameters that the application (e.g., G.711), what is > that standard? There shouldn't be magic, obviously. However, you will not find IETF documents that describe these types of things since they are mostly implementation specific. Is that so-called Y.xxxx or DSTE QOS model? If not, why are > the NSIS WG working so hard to push for all those "technically confusing and > contradicting" things that no direct relevance to NSIS QOS? I know that you are not particularly excited about the Y.1541 work. Some environments will use the QoS model they like. The IETF (and the NSIS working group) is not the QoS deployment police. Let folks write the QoS model they like. No big problem if the document is properly written. With respect to the 'mandatory' QoS parameters we obviously need to make sure that we get them right. That was the reason we had some many discussions over the past few months. > 5. If you thinks that SDP needs to indicate bandwidth, delay, jitter, and > packet loss for G.711, it can be done very easily and, like bandwidth, it > will be end-to-end codec-to-codec delay/jitter/packet loss. Again, it will > constitute the needs from the application point of view, and the SIP call is > between the end-users - more appropriately between the codes. I looked at the 3GPP specs what they do with regard to the Diameter QoS work. They use information from SDP (bandwidth) and then use information about the environment (i.e., 3G access network) and then they generate the parameters. > > 6. If you think that NSIS will focus only on end-to-end application QOS > parameters, can we not simplify using only few specific performance > parameters for NSIS and let the network centric QOS folks develop all those > billions of "segmented" performance parameters and so-called QOS models > specific to all networks decoupling from the applications? Why don't you like the concept of QoS models? It is a useful concept and does not cause harm. You might not agree with all QoS models, for sure, but nobody will ever do so. RFC 3726 states that we focus on various deployment models; not only on E2E QoS. Ciao Hannes > > Best regards, > Radhika > > _____ > > From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Sat 7/29/2006 5:26 PM > To: Roy, Radhika R. > Cc: nsis@ietf.org; Hancock, Robert > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li > st? > > > > No, I did not try to map the SIP/SDP parameters to the QSPEC. > If we ignore the codecs then the only relevant parameter carried in SDP > is a bandwidth parameter. > > Ciao > Hannes > > Roy, Radhika R. wrote: > >>Hi, Hannes and Robert: >> >>Inline [RRR]. >> >>BR/Radhika >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 05:00:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7TdM-00068M-8X; Mon, 31 Jul 2006 05:00:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7TdL-00068H-2N for nsis@ietf.org; Mon, 31 Jul 2006 05:00:19 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7TdK-0005v6-Ck for nsis@ietf.org; Mon, 31 Jul 2006 05:00:19 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6V903xw026875; Mon, 31 Jul 2006 10:00:03 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Mon, 31 Jul 2006 10:00:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Thread-Index: Aca0LwRtQYTWFp/3QpGbfdZtOFnd1wAT9lyw From: "Hancock, Robert" To: , "Hannes Tschofenig" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org roy, my views: > -----Original Message----- > From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com]=20 > Sent: 31 July 2006 00:17 > To: Hannes Tschofenig > Cc: nsis@ietf.org; Hancock, Robert > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter li st? >=20 >=20 > Hi, Hannes: > =20 > Let me summarize again the basic technical "fine" points. > =20 > It is precisely: a. application layer QOS parameters vs. b.=20 > network centric QOS parameters. i would say 'parameters that need to be implemented in the network infrastructure' rather than 'network centric' but this is probably just a terminology issue. > =20 > No IETF RFCs that are related to QOS had the charter to=20 > define QOS signaling > and hence QOS parameters for application layer QOS other than NSIS. i can't fully comment on this, not being sufficiently familiar=20 with all the other ietf WGs. but do you say this is outside (for example) mmusic? > =20 > NSIS QOS signaling standards are proceeding OK. i am glad we all agree on this :-D > =20 > However, the key technical points that have been missed are this: > =20 > 1. Do the NSIS QOS parameters defined so far represent end-to-end > application QOS parameters (e.g., audio/video codec-to-codec > bandwidth/delay/jitter/packet loss)? only in so far as they need to be understood and implemented in the network infrastructure. so, for example, codec issues would IMHO be entirely out of scope. > =20 > 2. If so, how do we do this? If not, why not? we don't because it is not our job to do so? at least, that is my interpretation. but that is more a question for John and=20 the IESG, I think. robert h. > =20 > Best regards, > Radhika > =20 > PS:=20 > =20 > i. I understand the value of so-called QOS models developed=20 > by many folks in > many standard organizations and people are implementing a lot of other > things. But none of them doing is doing above based on standards. > =20 > ii. The whole debates in NSIS QOS parameters have turned into=20 > how to carry > the QOS parameters that have been defined in so-called QOS=20 > models that are > also network-centric as I explained earlier. > =20 > iii. Above item ii has obscured the basic fact that NSIS has=20 > been chartered > that it will deal with application layer QOS. The question is=20 > this: Who will > deal with the application aspect of QOS parameter that are so simple? > =20 > iv. If 3GPP and other organization could solve the=20 > application layer QOS as > described using standards, please let us know. > =20 > v. If NSIS wants to deviate from its charter that it will NOT define > application layer QOS, let us make the NSIS charter clear. If=20 > you think that > the mapping between the network centric QOS and application=20 > QOS is a matter > of implementation, I would then suggest, let NSIS charter=20 > should be revised > by saying that the network-centric QOS parameters will be=20 > defined in along > the spirit of all available so-called QOS models and/or IP > network/MAC/physical layer QOS specific QOS parameters. In=20 > this case, we all > know what to focus on without being oscillated between the=20 > two extreme ends: > Application QOS vs. Network QOS. >=20 > _____ =20 >=20 > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sun 7/30/2006 1:44 PM > To: Roy, Radhika R. > Cc: nsis@ietf.org; Hancock, Robert > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 > parameter li > st? >=20 >=20 >=20 > Hi Roy, >=20 > Roy, Radhika R. wrote: > > Then, we have fundamental problems to fulfill the=20 > objectives of NSIS QOS > > standards. >=20 > There is no reason to be concerned. Just because I haven't=20 > done anything > by my own isn't alarming. I bet a number of folks have done the > analysis in a great level of detail. >=20 > > If you look very carefully, NSIS QOS is tied to the=20 > applications in the > > first place for which it is being designed to meet the very=20 > needs of QOS. > If > > NSIS QOS is de-coupled from the applications to meet the=20 > needs of QOS, why > > are we developing so many fancy performance parameters? In=20 > the end of the > > day what purpose will NSIS QOS serve to meet the QOS needs of the > > applications? >=20 > It is true that the parameters at all layers need to fit=20 > together if the > goal is to signal for per-flow application layer traffic. Note, that > there are some other scenarios where this is not necessarily true. >=20 > >=20 > > Let me summarize the problems that NSIS QOS standards will=20 > create if it is > > decoupled from the application QOS: > >=20 > > 1. If a call from the application (e.g., SIP INVITE with=20 > G.711 codec) is > > made, the application will not be able to map it QOS needs (e.g., > Bandwidth, > > Delay, Delay Jitter, Packet Loss) to the NSIS QOS signaling protocol > > messages. >=20 > Do you currently have the impression that this is not possible? >=20 > >=20 > > 2. If any arbitrary QOS needs are signaled to the NSIS QOS=20 > parameters > > decoupling from the application QOS needs, these QOS needs=20 > will be just > some > > kinds of arbitrary IP network/MAC layer/Physical layer-centric QOS > > parameters that are only understood by the network entities like IP > routers, > > LANs, base stations, etc., not by applications. >=20 > If the goal is to signal for end-to-end application layer traffic and > the parameters at the link, network and the application layers do not > fit together then there is a problem. >=20 > >=20 > > 3. At the end of all those, when NSIS QOS parameters are sent to the > > application (e.g., G.711), what will the G.711 codec do? >=20 > It should be the other way around. The application knows what it wants > todo and then it initiates QoS signaling with parameters it feels > comfortable with. >=20 > >=20 > > 4. If one thinks that some kinds of mapping between=20 > so-called NSIS IP > > network/MAC layer/Physical layer-centric QOS parameters=20 > will be magically > be > > transformed into QOS parameters that the application (e.g.,=20 > G.711), what > is > > that standard? >=20 > There shouldn't be magic, obviously. However, you will not find IETF > documents that describe these types of things since they are mostly > implementation specific. >=20 > Is that so-called Y.xxxx or DSTE QOS model? If not, why are > > the NSIS WG working so hard to push for all those=20 > "technically confusing > and > > contradicting" things that no direct relevance to NSIS QOS? >=20 > I know that you are not particularly excited about the Y.1541 work. >=20 > Some environments will use the QoS model they like. The IETF (and the > NSIS working group) is not the QoS deployment police. >=20 > Let folks write the QoS model they like. No big problem if=20 > the document > is properly written. >=20 > With respect to the 'mandatory' QoS parameters we obviously=20 > need to make > sure that we get them right. That was the reason we had some many > discussions over the past few months. >=20 >=20 > > 5. If you thinks that SDP needs to indicate bandwidth,=20 > delay, jitter, and > > packet loss for G.711, it can be done very easily and, like=20 > bandwidth, it > > will be end-to-end codec-to-codec delay/jitter/packet loss.=20 > Again, it will > > constitute the needs from the application point of view,=20 > and the SIP call > is > > between the end-users - more appropriately between the codes. >=20 > I looked at the 3GPP specs what they do with regard to the=20 > Diameter QoS > work. They use information from SDP (bandwidth) and then use=20 > information > about the environment (i.e., 3G access network) and then they generate > the parameters. >=20 >=20 > >=20 > > 6. If you think that NSIS will focus only on end-to-end=20 > application QOS > > parameters, can we not simplify using only few specific performance > > parameters for NSIS and let the network centric QOS folks=20 > develop all > those > > billions of "segmented" performance parameters and=20 > so-called QOS models > > specific to all networks decoupling from the applications? >=20 > Why don't you like the concept of QoS models? It is a useful=20 > concept and > does not cause harm. You might not agree with all QoS models,=20 > for sure, > but nobody will ever do so. >=20 > RFC 3726 states that we focus on various deployment models;=20 > not only on > E2E QoS. >=20 > Ciao > Hannes >=20 > >=20 > > Best regards, > > Radhika > > > > _____=20 > > > > From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig > > Sent: Sat 7/29/2006 5:26 PM > > To: Roy, Radhika R. > > Cc: nsis@ietf.org; Hancock, Robert > > Subject: Re: AW: [NSIS] Any resolution to the QSPEC=20 > mandatory parameter li > > st? > > > > > > > > No, I did not try to map the SIP/SDP parameters to the QSPEC. > > If we ignore the codecs then the only relevant parameter=20 > carried in SDP > > is a bandwidth parameter. > > > > Ciao > > Hannes > > > > Roy, Radhika R. wrote: > > > >>Hi, Hannes and Robert: > >> > >>Inline [RRR]. > >> > >>BR/Radhika > >> >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 05:34:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7U9w-00089q-EK; Mon, 31 Jul 2006 05:34:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7U9v-00089l-J4 for nsis@ietf.org; Mon, 31 Jul 2006 05:33:59 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7U9u-0002b3-3n for nsis@ietf.org; Mon, 31 Jul 2006 05:33:59 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E21A11BAC4D; Mon, 31 Jul 2006 11:17:22 +0200 (CEST) In-Reply-To: <20060712163212.GA8050@mafr.de> References: <20060712163212.GA8050@mafr.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <778F8072-E72D-461D-80B0-74ED876772C0@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NATFW: LE-MRM and NATFW_DTINFO_IPv4/IPv6 Date: Mon, 31 Jul 2006 11:33:52 +0200 To: Matthias Friedrich X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Matthias, Am 12.07.2006 um 18:32 schrieb Matthias Friedrich: > Hi, > > I'm wondering why there is no NATFW_DTINFO_IPv6 object in the current > draft revision (draft-ietf-nsis-nslp-natfw-12). A very brief answer ahead: Because there is no IPv6 NAT and the DTINFO* objects are used for NAT traversal. More further down this email. > > Suppose an NI+ is behind a firewall (no other firewalls, no NATs) and > wants to send a REA message upstream to block traffic from a range of > addresses. Then there is no known sender address, and it would IMHO > make > sense to use the LE-MRM with an appropriate SDA. At least that's > what I > think the LE-MRM was designed for. In the IPv6 case, a > NATFW_DTINFO_IPv6 > or a generalized NATFW_DTINFO object would be needed. > > According to section 3.7.2, in this case the PC-MRM should be used > with > the "data flow source IP address set to wildcard". I must admit I'm a > bit lost here, the "two different signaling scenarios" on page 36 are > difficult to read. Splitting the text into more paragraphs with some > more explanations would probably help. The LE-MRM has been just defined for the NAT usage and is not intended for pure firewall usage. The main difference between LE-MRM and the PC-MRM in the NAT case is: The message can probably not be forwarded when the receiver is behind a NAT and it is using the PC- MRM with a wildcarded sender IP address. When there are multiple NATs in parallel to the Internet, GIST may have the issue of not knowing which route to take. In this case GIST would return an error message. By using the LE-MRM, GIST is always able to route the message upstream to "a" NAT. In the first place it is not necessary to hit the best NAT, i.e., closest to the data sender but to get a public reachable IP address. By choosing different SDAs, one may get a better or worse located NAT. Therefore, there is a difference between using the LE-MRM and the PC- MRM if the data receiver is behind a NAT. For the case with firewalls only, as you have described, LE-MRM is not an option, but PC-MRM is. LE-MRM cannot be used, because GIST would route the signaling message towards the SDA and end up at firewall X. However, the real data traffic would hit another firewall Y. When there are multiple firewalls in parallel, this is probably going to be the wrong firewall and GIST has not the chance of returning an error, which tells "there are multiple routes and I cannot forward your message". By using the PC-MRM GIST can route the signaling message upstream and if there are multiple inbound routes, stop the forwarding and return an error message. In the firewall case it is not useful to hit any firewall, because firewalls do not do any route pinning as opposed to NATs. > > What I don't understand is: If the PC-MRM may be used when the data > sender is unknown, why do we need the LE-MRM at all? Witout it, we > would > get rid of the NATFW_DTINFO object(s) altogether. It is not that easy, because LE-MRM gives more power to hosts behind NATs. LE-MRM will definitely find an edge-NAT while PC-MRM can easily fail if there are multiple NATs in parallel. However, it is time to rework the section(s) on the LE-MRM/PC-MRM usage (plus DTINFO) for getting it all clear. I see the issue of having the information about the MRM usage spread too much over the document and lack of some good introductory text. There will be an updated text in the next version clarifying this. I hope to get you as a review! :-) > > > One last thing, I heard that the REA message is going to be renamed. > It's not very creative, but why don't you rename CREATE to SCREATE > (Sender/Source CREATE) or ICREATE (Initiator CREATE), and REA to > RCREATE > (Receiver/Responder CREATE)? Maybe the whole NI+/NR+ terminology could > be dropped, too. Good proposals. I've just seen you posting to the list and the suggestions will taken to the list. Thanks, Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 05:50:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7UQC-0003Ln-5J; Mon, 31 Jul 2006 05:50:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7UQB-0003Lh-3J for nsis@ietf.org; Mon, 31 Jul 2006 05:50:47 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7UQ9-0003qI-DL for nsis@ietf.org; Mon, 31 Jul 2006 05:50:47 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2AFED1BAC4D; Mon, 31 Jul 2006 11:34:10 +0200 (CEST) In-Reply-To: <84CA64E50179964E8EF67403019ABB940230D470@sdebe101.NOE.Nokia.com> References: <84CA64E50179964E8EF67403019ABB940230D470@sdebe101.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20B751D1-B433-472C-937E-2D61A14973B2@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt Date: Mon, 31 Jul 2006 11:49:24 +0200 To: X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: fu@cs.uni-goettingen.de, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Gabor, Am 13.07.2006 um 19:16 schrieb : > Hi Martin, > > >> -----Original Message----- >> From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: Wednesday, July 12, 2006 10:17 AM >> To: Xiaoming Fu >> Cc: nsis@ietf.org >> Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt >> >>> - alternatively, MN can issue a DETECT (no matter it is called) >>> message towards the HA to collect all firewall information, if any, >>> and RESPONSE from the HA gives the response to MN. This is >> similar to >>> what diagnostics function covers. >>> >>> This feature could provide the NI some freedom e.g., >> choosing multiple >>> rules in a single signaling message exchange, or even no NAT/FW >>> signaling is needed (if it is clear that no firewall is >> encountered in >>> the data path). >> >> This is talking about two different things here. First, the a >> detection message exchange and aggregation of policy rules >> into a signalling message. >> >> There is basically no need for having a separated detection >> mechanisms, since you run one message exchange just for >> nothing. You suggest to run the detection mechanisms to find >> out if there is any firewall/NAT and afterwards to signal for >> the desired rules. Isn't it better to directly signal for the >> desired rules? If there is any firewall/NAT en route, it is >> automatically configured as requested. >> Adding a detection mechanism will require another round trip >> and is not saving anything. > > The MN may want to know if there is any firewall on the path > between the > MN's new CoA and the HA and the CN, respectively. If there is no > firewall, then there is no reason using NSLP. Not using NSLP would > save > one round trip for each mipv6 signalling and also data connection > setup > for each pair of (CoA, HA) and (CoA, CN) connections. Ok, I see, there is space for some signalling cost saving. > > It would probably be preferable to have a firewall detection mechanism > inbuilt into MIPv6, instead of NSLP. I'm fine if MIPv6 is providing this or any other mean. Any other mean, could include the NATFW NSLP, would very likely involve one round trip to get the information whether there are firewalls or not. Using, for instance, some probing mechanisms, will eat some round trips too. If MIPv6 is not providing such information, sending a probe request of the NATFW NSLP could be a good idea. Either there is are firewalls in between and they are configured accordingly or there are no firewalls and the signalling messages just runs through. Martin > > Gabor > > >> Second, the aggregation of policy rules into a signalling message. >> This is not supported by the NATFW NSLP. You can signal for a >> specific flow (which in turn can be quite unspecific) and say >> it is running from A to B with IPv6. This would cover packets >> of this flow out of mobile IP and the latter data traffic. >> >> Martin >> >>> >>> Xiaoming >>> >>> Martin Stiemerling wrote: >>>> Hi Xiaoming, >>>> What do exactly refer as "detection of middlebox presence"? >>>> Basically, the NATFW NSLP, to be precise GIST, is already >> detecting >>>> the presence of NATFW NSLP enabled middleboxes. >>>> Martin >>>> Am 10.07.2006 um 08:21 schrieb Xiaoming Fu: >>>>> Hi Martin, all, >>>>> >>>>> Is it possible for NAT/FW NSIS NSLP to support detection of >>>>> middlebox presence? We find out this feature will be useful in >>>>> MIP6 FW traversal scenarios, as depicted in http://www.ietf.org/ >>>>> internet- drafts/draft-thiruvengadam-nsis-mip6-fw-04.txt >>>>> This could save additional signaling message flows, especially if >>>>> one expects to install multiple rules in a firewall -- if >> exists -- >>>>> in a particular IP path, e.g., rules for allowing both BU >> and HoTI >>>>> messages to traverse between the MN and the HA. >>>>> >>>>> Cheers, >>>>> Xiaoming >>>>> >>>>> Internet-Drafts@ietf.org wrote: >>>>> >>>>>> 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 : NAT/Firewall NSIS Signaling Layer Protocol >>>>>> (NSLP) >>>>>> Author(s) : M. Stiemerling, et al. >>>>>> Filename : draft-ietf-nsis-nslp-natfw-12.txt >>>>>> Pages : 101 >>>>>> Date : 2006-6-29 >>>>>> This memo defines the NSIS Signaling Layer Protocol (NSLP) >>>>>> for >>>>>> Network Address Translators (NATs) and firewalls. This NSLP >>>>>> allows >>>>>> hosts to signal on the data path for NATs and firewalls to be >>>>>> configured according to the needs of the application data >>>>>> flows. It >>>>>> enables hosts behind NATs to obtain a public reachable address >>>>>> and >>>>>> hosts behind firewalls to receive data traffic. The overall >>>>>> architecture is given by the framework and >> requirements defined >>>>>> by >>>>>> the Next Steps in Signaling (NSIS) working group. The network >>>>>> scenarios, the protocol itself, and examples for path-coupled >>>>>> signaling are given in this memo. >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp- >>>>>> natfw-12.txt >>>>>> To remove yourself from the I-D Announcement list, send a >> message >>>>>> to i-d-announce-request@ietf.org with the word >> unsubscribe in the >>>>>> body of the message. You can also visit https://www1.ietf.org/ >>>>>> mailman/listinfo/I-D-announce to change your subscription >> settings. >>>>>> Internet-Drafts are also available by anonymous FTP. Login with >>>>>> the username >>>>>> "anonymous" and a password of your e-mail address. After logging >>>>>> in, type "cd internet-drafts" and then >>>>>> "get draft-ietf-nsis-nslp-natfw-12.txt". >>>>>> A list of Internet-Drafts directories can be found in >>>>>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/ >>>>>> 1shadow- sites.txt >>>>>> Internet-Drafts can also be obtained by e-mail. >>>>>> Send a message to: >>>>>> mailserv@ietf.org. >>>>>> In the body type: >>>>>> "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt". >>>>>> NOTE: The mail server at ietf.org can return the >> document in >>>>>> MIME-encoded form by using the "mpack" utility. To use this >>>>>> feature, insert the command "ENCODING mime" before the "FILE" >>>>>> command. To decode the response(s), you will need >> "munpack" or >>>>>> a MIME-compliant mail reader. Different MIME-compliant mail >>>>>> readers >>>>>> exhibit different behavior, especially when dealing with >>>>>> "multipart" MIME messages (i.e. documents which have >> been split >>>>>> up into multiple messages), so check your local documentation >>>>>> on >>>>>> how to manipulate these messages. >>>>>> Below is the data which will enable a MIME >> compliant >>>>>> mail reader implementation to automatically retrieve the ASCII >>>>>> version of the Internet-Draft. >>>>>> >> ------------------------------------------------------------------- >>>>>> -- --- >>>>>> _______________________________________________ >>>>>> nsis mailing list >>>>>> nsis@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>>> >>>>> >>>>> _______________________________________________ >>>>> nsis mailing list >>>>> nsis@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 05:59:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7UYN-0005Py-1e; Mon, 31 Jul 2006 05:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7UYL-0005Pt-Pw for nsis@ietf.org; Mon, 31 Jul 2006 05:59:13 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7UYK-0004dw-Bh for nsis@ietf.org; Mon, 31 Jul 2006 05:59:13 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 252B31BAC4D; Mon, 31 Jul 2006 11:42:37 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] Proposal for implementing QoS NSLP Proxy Mode Date: Mon, 31 Jul 2006 11:59:06 +0200 To: Jukka MJ Manner X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, all, Sounds as a reasonable way forward! Martin Am 16.07.2006 um 23:43 schrieb Jukka MJ Manner: > > We had a good discussion with Robert about the QoS NSLP Proxy mode, > and at > the end we agreed that the QoS NSLP does not really need much. > Actually, > we only need a new scope (besides single link and e2e) called e.g. > "proxy", and the domain admin must define manually, which QNE > operates as > proxy (Proxy-QNE, P-QNE). Here is how the fing works: > > [End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver or sender] > > For outgoing flows, the end host is the QNI, and sends a RESERVE > with the > new proxy-scope bit set. The P-QNE will receive the RESERVE and > reply with > a RESPONSE (if requested), and NOT forward the RESERVE further to > the next > peer. The receiver-oriented reservation works the same way (QUERY > towards > P-QNE, RESERVE back, then RESPONSE to P-QNE, all carrying the proxy- > scope > bit). > > For incoming flows, the end host is also the QNI, and it sends a > RESERVE > towards the data sender with the proxy-scope bit set. Here the end > host > sets the MRI so that it indicates the end host as the receiver of the > data, and the D-flag is set. If there is only one P-QNE in the domain, > GIST gets the RESERVE to the P-QNE. If there are more than one P-QNEs, > GIST will do its best, but may reply with an error indicating > destination > unreachable. > > Jukka > > ps. I'll be out of emails for a couple of weeks now. I intend to > finalize > the QoS NSLP draft in August and we can then send it for AD review. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 09:24:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Xl2-0003sT-Pu; Mon, 31 Jul 2006 09:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Xl2-0003sH-7Z for nsis@ietf.org; Mon, 31 Jul 2006 09:24:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Ww4-0001FU-KR for nsis@ietf.org; Mon, 31 Jul 2006 08:31:52 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7Wls-0005PX-5a for nsis@ietf.org; Mon, 31 Jul 2006 08:21:21 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6VCKn2d000663; Mon, 31 Jul 2006 13:20:49 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) Date: Mon, 31 Jul 2006 13:20:49 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) Thread-Index: AcayWw3x8hbLUJEASQaTZYEExu/AqwCPxuWA From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Mark Doll , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi roland, > Hi Robert, >=20 > [while playing around with our implementation, I reread > parts of the current NTLP draft after a long time...and I have > two -- maybe very silly/basic questions]: > A) > Possibly I missed the part in the draft, but is there any clear > specification where exactly the RESPONSE must be sent in D-Mode > (no MA-reuse)? I found only the following statements which > are IMHO not very explicit about the exact destination: >=20 > "A Query always triggers a Response in > the reverse direction as the second message of the handshake." >=20 > "No Association: No MA exists. GN2 sends the Response in D-mode > directly to GN1, identifying itself and agreeing to the > association setup." >=20 > "Query MUST elicit a Response. This is a normally encapsulated D-mode > message with additional payloads." >=20 > and the "best hint" is in sec. 5.2.2 / NLI: >=20 > The interface-address must be routable, i.e. it MUST be usable as > a destination IP address for packets to be sent back to the node > generating the signaling message, whether in D-mode or C-mode. >=20 > though it doesn't specify something about which destination > address must be used for responses (and it would not be the > appropriate section for this). >=20 > The example in fig.11 shows that the NLI i/f address > is used in the response. >=20 > (The alternative to use the NLI address would be > sending it back to the source in case of a set S-flag, > but I guess that's not what the spec intends...) >=20 > However, I would really like to see a clear statement like: > GN2 sends the Response in D-mode directly to GN1, using > the interface-address as destination addess as specified > in the NLI of the query and the source port of the query > as destination port of the response. there are three parts to the answer here: 1) the underlying requirement is to get the message to the right node; apart from this, the encapsulation doesn't matter. 2) for the scenarios which are in scope of the spec (i.e. no legacy NATs) the correct (or at least intended) behaviour is=20 as you put it above. 3) it is not impossible that some approach to traversal of legacy NATs would require sending the Response back to the=20 Query source. those approaches are not worked out in this draft, but it is the basis of the approach described in draft-pashalidis-ietf-nsis-gist-legacynats-00 for example (see section 5). so i can imagine writing something more explicit, but i wouldn't want to pin it down to the extent of ruling out the flexibility required by (3), expecially given the overall criterion (1) - that it shouldn't matter provided it works. more text suggestions welcome ;-) >=20 > B) > if the response must be sent back to what is specified in the > NLI, this possibly opens up reflection attacks. This should be > mentioned in the security considerations section and I'm not quite > sure whether any sanity checks are possible to prevent this. this is the intention (one of the intentions) of the 3rd requirement on the Q-cookie in section 8.5 (easily validated ... to discard responses to spoofed queries). i don't see what other sanity=20 checks are possible to prevent this. cheers, robert h. >=20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 10:02:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YM5-0002oA-UJ; Mon, 31 Jul 2006 10:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YM4-0002lw-B9 for nsis@ietf.org; Mon, 31 Jul 2006 10:02:48 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7YM1-0005wW-ID for nsis@ietf.org; Mon, 31 Jul 2006 10:02:48 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6VE2fc3005960 for ; Mon, 31 Jul 2006 16:02:41 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6VE2fvb000731 for ; Mon, 31 Jul 2006 16:02:41 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6VE2f816529; Mon, 31 Jul 2006 16:02:41 +0200 (MEST) Date: Mon, 31 Jul 2006 16:02:41 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nsis@ietf.org Subject: Re: [NSIS] agreement on QSPEC template draft? Received: from 83.235.185.54 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 31 Jul 2006 14:02:40 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.739 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 31 Jul 2006 16:02:42 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Cornelia, Attila At the moment I am on holidays! Some time ago I have sent the below e-mail, but I have not received any reply! Please comment on the below e-mail! Best Regards, Georgios On 7/17/2006, "Georgios Karagiannis" wrote: > >Hi all > >If we include an additional flag into the QOS-NSLP draft to show that a >non QoS-NSLP Hop, say "Non QoS-NSLP Hop", has been passed during the >end-to-end path followed by a RESERVE, then regarding the QSpec >template, I agree to: > >* add the R bit flag proposed by Jerry, where each parameter will carry >such a flag and it will be used in the situation that a parameter, >mandatory or optional is downgraded. >* use the "Non QOSM Hop" flag as currently used! >* use the T flag as currently used >* use of N flag as currently used >* use of E flag as currently used >* try to use as less as possible mandatory parameters > >Best Regards, >Georgios > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 10:35:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Yro-0001cG-Q4; Mon, 31 Jul 2006 10:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Yrn-0001cB-Qn for nsis@ietf.org; Mon, 31 Jul 2006 10:35:35 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Yrm-0000WR-AD for nsis@ietf.org; Mon, 31 Jul 2006 10:35:35 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k6VEZRfl008502; Mon, 31 Jul 2006 16:35:27 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k6VEZQvb003630; Mon, 31 Jul 2006 16:35:27 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k6VEZMu23953; Mon, 31 Jul 2006 16:35:22 +0200 (MEST) Date: Mon, 31 Jul 2006 16:35:22 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: john.loughney@nokia.com, bless@tm.uka.de, cornelia.kappler@siemens.com Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list? Received: from 83.235.185.54 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 31 Jul 2006 14:35:20 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.257 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 31 Jul 2006 16:35:29 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: "gash@att.com" , "jmanner@cs.Helsinki.FI" , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John Actually I agree with the comment of Roland, however, if it is to use the concept of understanding the basic information, then IMHO the basic information should be as much as basic as possible, i.e., Token Bucket, Bandwidth, Non QOSM Hop. In addition by using the additional flags proposed by Jerry, including the R (remapping bit) the QNI that initiated the end to end reservation can detect which of the mandatory/optional parameters where tunneled, remapped or not interpreted at all! Best Regards, Georgios On 7/26/2006, "john.loughney@nokia.com" wrote: >Hi all, > >Just bumping up a bit. > >Generally, QoS models will address specific QoS deployements (at least >mostly currently defined by different SDOs). These QoS Models don't >necessarily scale or are applicable Internet-wide. (this is a rough >generalization). > >In order to ensure some level of interopation, the Qspec contain should >contain some basic information understood by all QoSM's so that >signaling between different QoS deployments is possible. > >I don't (currently) think it is possible to define 1 universal QoSM - >but the Qspec should define a basic template for signaling QoS across >the Internet and different deployments. > >The Mandatory parameter SHOULD (well, MUST) be understood by the >different QoSMs - enough so they can either accept or reject a certain >QoS flow. > >John > >>-----Original Message----- >>From: ext Roland Bless [mailto:bless@tm.uka.de] >>Sent: 25 July, 2006 11:09 >>To: Kappler, Cornelia >>Cc: Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org; >>Ash,Gerald R ALABS >>Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory >>parameter list? >> >>Hi all, >> >>> I've been off-list for the last 10 days and may have difficulties >>> grasping the real point of the debate. >> >>Sorry, I missed the discussion, though we had some informal >>discussion in Dallas one morning at a roundtable :-) >> >>> I'd prefer some concrete suggestions to which parameters >>should not be >>> mandatory. Rather than blanket statements "List is too long" >>or "List >>> is too short" or "we should have N parameters". >>> >>> The question is not really whether it should be 2 or 8 or 20 >>mandatory >>> parameters. It is _which_ parameters are necessary to _just_ >>> accomodate the key ideas of typical QOSMs. >> >>Now I'll repeat what I already said in Dallas: >>I'd prefer to not prescribe any mandatory parameters for all >>QoS models. Thus I don't actually like the approach: >>"Mandatory parameters in the QSPEC must be meaningfully >>interpreted by all QNEs in the path, independent of which QOSM >>they support." I disagree, because we may have different QoS >>models that not even require these parameters or future QoS >>models that require even more mandatory parameters which are >>not covered by the QSPEC template anyway. But trying to be >>constructive: >>I would rather prefer to leave it up to each QoS model which >>parameters are mandatory and which are not, like defining a >>profile (e.g. similar to MPEG profiles). >>Furthermore, interworking between different QoS models can be >>defined that describes which parameters can mapped onto which >>in the other QoSM. >>I agree on this statement in the introduction: >>" A particular QOSM >> specifies a) a set of mandatory and optional QSPEC parameters, and >> b) how the QSPEC information is interpreted by the RMF with respect >> to the QoS description, resources desired, resources available, and >> control information." >>The value of the QSPEC is still retained, because a QoSM only >>needs to pick certain parameters of the QSPEC which are >>already defined therein. >> >>Just my two cents, >> Roland >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 11:33:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZlI-00072m-QU; Mon, 31 Jul 2006 11:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZlI-00072h-BY for nsis@ietf.org; Mon, 31 Jul 2006 11:32:56 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ZlG-00057s-MQ for nsis@ietf.org; Mon, 31 Jul 2006 11:32:56 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k6VFWq9r030124; Mon, 31 Jul 2006 17:32:52 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k6VFWqTV017097; Mon, 31 Jul 2006 17:32:52 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 17:32:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Mon, 31 Jul 2006 17:32:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? thread-index: AcazSxwWnY+kn2m6T26CLaQKAwysAABax2fw From: "Tschofenig, Hannes" To: "Roy, Radhika R." , "Hannes Tschofenig" , "Hancock, Robert" X-OriginalArrivalTime: 31 Jul 2006 15:32:52.0267 (UTC) FILETIME=[9624A7B0:01C6B4B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roy,=20 from the discussion so far it seems that you have looked at the application layer to NSIS QoS mapping in more detail.=20 What was the conclusion? Are the work-in-progress QoS models support what you want?=20 Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 12:35:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ak9-00082E-Om; Mon, 31 Jul 2006 12:35:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ak8-0007wb-J5 for nsis@ietf.org; Mon, 31 Jul 2006 12:35:48 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ak6-0000Sr-91 for nsis@ietf.org; Mon, 31 Jul 2006 12:35:48 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 31 Jul 2006 12:35:38 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006073112353521228 ; Mon, 31 Jul 2006 12:35:36 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jul 2006 12:35:35 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209DC5@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: "Tschofenig, Hannes" Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Mon, 31 Jul 2006 12:35:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Hannes: The most important conclusion is this: We do not need any QOS model. Period. All we want in NSIS is this: Like NSIS QOS signaling messages, we just need to express the end-to-end QOS parameters of the applications as follows: Bandwidth, Delay, Jitter, and Packet Loss. For non-real-time data application, "jitter" may or may not be required, but for real-time/near-real-time audio/video application, the above 4 parameters are needed. The application will express those values on end-to-end basis, "independent" of any transport networking that may consist of one or many networks while transporting the application messages/payload on end-to-end basis. By the way, NSIS's charter is not to standardize or specify any "value" for those performance parameters. It is so simple. How to deal with the network QOS, it is not NSIS's problems. NSIS's charter is to "signal" the QOS parameters on end-to-end basis between the applications. By the way, the end-to-end QOS requirements for applications will remain the "same" because it is based on the "inherent" characteristics of the system (e.g., MOS of audio/video application, response time requirements for data application depending on human or automa). Best regards, Radhika PS: 1. Now, 3G may solve their part of the network QOS. For example, they provide the access wireless network. 2. IEEE may solve the access LAN QOS problems. 3. IETF may solve the problems of public Internet backbone network QOS (e.g., DiffServ, DSTE), access IP network QOS (e.g., IntServ) or end-to-end IP (access + backbone). 4. An implementer (say, service provider) that wants to provide end-to-end VoIP/SIP service will take NSIS QOS as the fundamental reference for addressing the end-to-end QOS for the application. They now need to choose what type of networks they will use on the end-to-end path. Accordingly, they will divide the NSIS's end-to-end QOS that has been signaled by the application into individual networks. The beauty of this is this: NSIS QOS signaling protocol still be used on end-to-end basis between the applications. 5. If NSIS needs to address item 4, it needs to change its charter. It is a huge problem to solve. I am extremely worried that NSIS focus might have distorted due to unnecessarily mixing of items 1, 2, 3, and 4 while they started discussing the QOS parameters. _____ From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes Sent: Mon 7/31/2006 11:32 AM To: Roy, Radhika R.; Hannes Tschofenig; Hancock, Robert Cc: nsis@ietf.org Subject: AW: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Hi Roy, from the discussion so far it seems that you have looked at the application layer to NSIS QoS mapping in more detail. What was the conclusion? Are the work-in-progress QoS models support what you want? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 12:48:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7awS-0002tL-Mv; Mon, 31 Jul 2006 12:48:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7awR-0002tB-At for nsis@ietf.org; Mon, 31 Jul 2006 12:48:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7XB8-0003HK-MY for nsis@ietf.org; Mon, 31 Jul 2006 08:47:26 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7X2Y-00062k-46 for nsis@ietf.org; Mon, 31 Jul 2006 08:38:37 -0400 Received: from [84.163.6.174] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1G7X2Q11mE-0005uo; Mon, 31 Jul 2006 14:38:26 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id F0DCC5E81F6; Mon, 31 Jul 2006 14:38:14 +0200 (CEST) Date: Mon, 31 Jul 2006 14:38:14 +0200 From: Matthias Friedrich To: Martin Stiemerling Subject: Re: [NSIS] NATFW: LE-MRM and NATFW_DTINFO_IPv4/IPv6 Message-ID: <20060731123814.GA7694@mafr.de> Mail-Followup-To: Martin Stiemerling , nsis@ietf.org References: <20060712163212.GA8050@mafr.de> <778F8072-E72D-461D-80B0-74ED876772C0@netlab.nec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <778F8072-E72D-461D-80B0-74ED876772C0@netlab.nec.de> User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: -2.6 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, On Monday, 2006-07-31, Martin Stiemerling wrote: [ LE-MRM vs. PC-MRM etc. ] Thanks a lot for your detailed response. I think I understand now why the LE-MRM has been chosen, however, I'm a bit unhappy about the special cases that have to be handled in NATFW-implementations. Things are more tricky than I initially thought, but maybe I can work out an alternative that reduces complexity a bit and post it to the list in the next couple of weeks. Cheers, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 15:34:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7dWX-0004uW-Ne; Mon, 31 Jul 2006 15:33:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7dWV-0004uG-OB for nsis@ietf.org; Mon, 31 Jul 2006 15:33:55 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7dWU-0001ZH-8m for nsis@ietf.org; Mon, 31 Jul 2006 15:33:55 -0400 Received: (qmail invoked by alias); 31 Jul 2006 19:33:50 -0000 Received: from p549849DF.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.73.223] by mail.gmx.net (mp022) with SMTP; 31 Jul 2006 21:33:50 +0200 X-Authenticated: #29516787 Message-ID: <44CE5B2B.9060403@gmx.net> Date: Mon, 31 Jul 2006 21:34:03 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? References: <62D92A9A02BCC845B202323D49A48426209DC5@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426209DC5@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: "Hancock, Robert" , nsis@ietf.org, "Tschofenig, Hannes" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roy, I strongly believe that we need the QoS model concept. I also think that there will never be a single QoS model that everyone can agree with. You will always find deployment environments that are a bit different that others. We already see this happening today. NSIS is about signaling QoS information obtained from the application to the network, in one of the envisioned usage scenarios. But there are others as well that are important. You just need to think about the transition time where an E2E solution cannot be deployed. Ciao Hannes Roy, Radhika R. wrote: > Hi, Hannes: > > The most important conclusion is this: We do not need any QOS model. Period. > > All we want in NSIS is this: Like NSIS QOS signaling messages, we just need > to express the end-to-end QOS parameters of the applications as follows: > Bandwidth, Delay, Jitter, and Packet Loss. > > For non-real-time data application, "jitter" may or may not be required, but > for real-time/near-real-time audio/video application, the above 4 parameters > are needed. > > The application will express those values on end-to-end basis, "independent" > of any transport networking that may consist of one or many networks while > transporting the application messages/payload on end-to-end basis. > > By the way, NSIS's charter is not to standardize or specify any "value" for > those performance parameters. > > It is so simple. > > How to deal with the network QOS, it is not NSIS's problems. NSIS's charter > is to "signal" the QOS parameters on end-to-end basis between the > applications. By the way, the end-to-end QOS requirements for applications > will remain the "same" because it is based on the "inherent" characteristics > of the system (e.g., MOS of audio/video application, response time > requirements for data application depending on human or automa). > > Best regards, > Radhika > > PS: > > 1. Now, 3G may solve their part of the network QOS. For example, they > provide the access wireless network. > > 2. IEEE may solve the access LAN QOS problems. > > 3. IETF may solve the problems of public Internet backbone network QOS > (e.g., DiffServ, DSTE), access IP network QOS (e.g., IntServ) or end-to-end > IP (access + backbone). > > 4. An implementer (say, service provider) that wants to provide end-to-end > VoIP/SIP service will take NSIS QOS as the fundamental reference for > addressing the end-to-end QOS for the application. They now need to choose > what type of networks they will use on the end-to-end path. Accordingly, > they will divide the NSIS's end-to-end QOS that has been signaled by the > application into individual networks. The beauty of this is this: NSIS QOS > signaling protocol still be used on end-to-end basis between the > applications. > > 5. If NSIS needs to address item 4, it needs to change its charter. It is a > huge problem to solve. I am extremely worried that NSIS focus might have > distorted due to unnecessarily mixing of items 1, 2, 3, and 4 while they > started discussing the QOS parameters. > > _____ > > From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes > Sent: Mon 7/31/2006 11:32 AM > To: Roy, Radhika R.; Hannes Tschofenig; Hancock, Robert > Cc: nsis@ietf.org > Subject: AW: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li > st? > > > > Hi Roy, > > from the discussion so far it seems that you have looked at the > application layer to NSIS QoS mapping in more detail. > What was the conclusion? > Are the work-in-progress QoS models support what you want? > > Ciao > Hannes > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 16:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7e7v-0005u9-1C; Mon, 31 Jul 2006 16:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7e7t-0005sC-Kj for nsis@ietf.org; Mon, 31 Jul 2006 16:12:33 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7e7s-00010w-Vv for nsis@ietf.org; Mon, 31 Jul 2006 16:12:33 -0400 Received: (qmail invoked by alias); 31 Jul 2006 20:12:31 -0000 Received: from p549849DF.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.73.223] by mail.gmx.net (mp043) with SMTP; 31 Jul 2006 22:12:31 +0200 X-Authenticated: #29516787 Message-ID: <44CE643C.9020403@gmx.net> Date: Mon, 31 Jul 2006 22:12:44 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? References: <62D92A9A02BCC845B202323D49A48426209DC4@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426209DC4@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roy, Roy, Radhika R. wrote: > Hi, Hannes: > > Let me summarize again the basic technical "fine" points. > > It is precisely: a. application layer QOS parameters vs. b. network centric > QOS parameters. I don't see them as two distinct parameter sets. > > No IETF RFCs that are related to QOS had the charter to define QOS signaling > and hence QOS parameters for application layer QOS other than NSIS. I am not sure what you mean. What about the work done in the SIP environment? What about the work in the transport working group? > > NSIS QOS signaling standards are proceeding OK. > > However, the key technical points that have been missed are this: > > 1. Do the NSIS QOS parameters defined so far represent end-to-end > application QOS parameters (e.g., audio/video codec-to-codec > bandwidth/delay/jitter/packet loss)? > > 2. If so, how do we do this? If not, why not? > please see my comment below: > Best regards, > Radhika > > PS: > > i. I understand the value of so-called QOS models developed by many folks in > many standard organizations and people are implementing a lot of other > things. But none of them doing is doing above based on standards. > > ii. The whole debates in NSIS QOS parameters have turned into how to carry > the QOS parameters that have been defined in so-called QOS models that are > also network-centric as I explained earlier. > > iii. Above item ii has obscured the basic fact that NSIS has been chartered > that it will deal with application layer QOS. The question is this: Who will > deal with the application aspect of QOS parameter that are so simple? > > iv. If 3GPP and other organization could solve the application layer QOS as > described using standards, please let us know. > > v. If NSIS wants to deviate from its charter that it will NOT define > application layer QOS, let us make the NSIS charter clear. If you think that > the mapping between the network centric QOS and application QOS is a matter > of implementation, I would then suggest, let NSIS charter should be revised > by saying that the network-centric QOS parameters will be defined in along > the spirit of all available so-called QOS models and/or IP > network/MAC/physical layer QOS specific QOS parameters. In this case, we all > know what to focus on without being oscillated between the two extreme ends: > Application QOS vs. Network QOS. > I am not sure why you stick so much to the parameter discussion. What parameters would you like to see being used? What QoS model do you think is the one that would satisfy your needs? Why don't you write a QoS model draft that contains the parameters that you would like to see. The work is contribution driven and there are already a number of QOSMs out there that fulfill the needs in certain deployment environments. There is nothing to stop us from working on new documents. Ciao Hannes > _____ > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sun 7/30/2006 1:44 PM > To: Roy, Radhika R. > Cc: nsis@ietf.org; Hancock, Robert > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li > st? > > > > Hi Roy, > > Roy, Radhika R. wrote: > >>Then, we have fundamental problems to fulfill the objectives of NSIS QOS >>standards. > > > There is no reason to be concerned. Just because I haven't done anything > by my own isn't alarming. I bet a number of folks have done the > analysis in a great level of detail. > > >>If you look very carefully, NSIS QOS is tied to the applications in the >>first place for which it is being designed to meet the very needs of QOS. > > If > >>NSIS QOS is de-coupled from the applications to meet the needs of QOS, why >>are we developing so many fancy performance parameters? In the end of the >>day what purpose will NSIS QOS serve to meet the QOS needs of the >>applications? > > > It is true that the parameters at all layers need to fit together if the > goal is to signal for per-flow application layer traffic. Note, that > there are some other scenarios where this is not necessarily true. > > >>Let me summarize the problems that NSIS QOS standards will create if it is >>decoupled from the application QOS: >> >>1. If a call from the application (e.g., SIP INVITE with G.711 codec) is >>made, the application will not be able to map it QOS needs (e.g., > > Bandwidth, > >>Delay, Delay Jitter, Packet Loss) to the NSIS QOS signaling protocol >>messages. > > > Do you currently have the impression that this is not possible? > > >>2. If any arbitrary QOS needs are signaled to the NSIS QOS parameters >>decoupling from the application QOS needs, these QOS needs will be just > > some > >>kinds of arbitrary IP network/MAC layer/Physical layer-centric QOS >>parameters that are only understood by the network entities like IP > > routers, > >>LANs, base stations, etc., not by applications. > > > If the goal is to signal for end-to-end application layer traffic and > the parameters at the link, network and the application layers do not > fit together then there is a problem. > > >>3. At the end of all those, when NSIS QOS parameters are sent to the >>application (e.g., G.711), what will the G.711 codec do? > > > It should be the other way around. The application knows what it wants > todo and then it initiates QoS signaling with parameters it feels > comfortable with. > > >>4. If one thinks that some kinds of mapping between so-called NSIS IP >>network/MAC layer/Physical layer-centric QOS parameters will be magically > > be > >>transformed into QOS parameters that the application (e.g., G.711), what > > is > >>that standard? > > > There shouldn't be magic, obviously. However, you will not find IETF > documents that describe these types of things since they are mostly > implementation specific. > > Is that so-called Y.xxxx or DSTE QOS model? If not, why are > >>the NSIS WG working so hard to push for all those "technically confusing > > and > >>contradicting" things that no direct relevance to NSIS QOS? > > > I know that you are not particularly excited about the Y.1541 work. > > Some environments will use the QoS model they like. The IETF (and the > NSIS working group) is not the QoS deployment police. > > Let folks write the QoS model they like. No big problem if the document > is properly written. > > With respect to the 'mandatory' QoS parameters we obviously need to make > sure that we get them right. That was the reason we had some many > discussions over the past few months. > > > >>5. If you thinks that SDP needs to indicate bandwidth, delay, jitter, and >>packet loss for G.711, it can be done very easily and, like bandwidth, it >>will be end-to-end codec-to-codec delay/jitter/packet loss. Again, it will >>constitute the needs from the application point of view, and the SIP call > > is > >>between the end-users - more appropriately between the codes. > > > I looked at the 3GPP specs what they do with regard to the Diameter QoS > work. They use information from SDP (bandwidth) and then use information > about the environment (i.e., 3G access network) and then they generate > the parameters. > > > >>6. If you think that NSIS will focus only on end-to-end application QOS >>parameters, can we not simplify using only few specific performance >>parameters for NSIS and let the network centric QOS folks develop all > > those > >>billions of "segmented" performance parameters and so-called QOS models >>specific to all networks decoupling from the applications? > > > Why don't you like the concept of QoS models? It is a useful concept and > does not cause harm. You might not agree with all QoS models, for sure, > but nobody will ever do so. > > RFC 3726 states that we focus on various deployment models; not only on > E2E QoS. > > Ciao > Hannes > > >>Best regards, >>Radhika >> >> _____ >> >>From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig >>Sent: Sat 7/29/2006 5:26 PM >>To: Roy, Radhika R. >>Cc: nsis@ietf.org; Hancock, Robert >>Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li >>st? >> >> >> >>No, I did not try to map the SIP/SDP parameters to the QSPEC. >>If we ignore the codecs then the only relevant parameter carried in SDP >>is a bandwidth parameter. >> >>Ciao >>Hannes >> >>Roy, Radhika R. wrote: >> >> >>>Hi, Hannes and Robert: >>> >>>Inline [RRR]. >>> >>>BR/Radhika >>> > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 17:34:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7fPE-0005Fx-VX; Mon, 31 Jul 2006 17:34:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7fPD-0005Fj-5k for nsis@ietf.org; Mon, 31 Jul 2006 17:34:31 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7fPA-00072k-Pz for nsis@ietf.org; Mon, 31 Jul 2006 17:34:31 -0400 Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-green.research.att.com (Postfix) with ESMTP id 7DB0686C8 for ; Mon, 31 Jul 2006 17:34:28 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Mon, 31 Jul 2006 17:34:28 -0400 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1029F7649@NJFPSRVEXG2KCL.research.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Thread-Index: Aca02EsXuctL8RfsQGmTeBXTSQ1UKAABL0DQ From: To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I don't usually post here, but I want to chime in, having been active in QoS and QoE (experience) in other arenas over the years (ITU, ATIS, IEEE,...). Many years ago, e2e QoS experts around the globe agreed that it was NOT a good idea to leave the assignment and allocation of individual performance parameters up to the user/application. Having even an educated user try to negotiate an infinite combination of levels of loss, delay, jitter, etc., was not seen as feasible. Moreover it was seen as unnecessary because most all applications fall into one of a finite set ( < 10) classes. That is why we came up with the QoS classes in Y.1541, which takes the full range of common applications into account--voice, data, IPTV, large frame TCP, best effort, whatever. Regarding QoS, all the application need signal is which of the eight classes is needed. The network can indicate whether the objectives of that class can be met, or possibly offer another class.=20 We appreciate that not everyone may buy in to this approach, and we are not forcing this approach on everyone. However, there is sufficient critical mass for this "QoS model" to justify it; indeed Y.1541 is *the* basis for "network QoS" in other forums, and we see NSIS as also usefully supporting it. So in like kind, we ask that no one force their solution on us! Respectfully Chuck Dvorak AT&T Labs -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Monday, July 31, 2006 3:34 PM To: Roy, Radhika R. Cc: Hancock, Robert; nsis@ietf.org; Tschofenig, Hannes Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Hi Roy, I strongly believe that we need the QoS model concept. I also think that there will never be a single QoS model that everyone can agree with. You will always find deployment environments that are a bit different that=20 others. We already see this happening today. NSIS is about signaling QoS information obtained from the application to the network, in one of the envisioned usage scenarios. But there are=20 others as well that are important. You just need to think about the=20 transition time where an E2E solution cannot be deployed. Ciao Hannes Roy, Radhika R. wrote: > Hi, Hannes: > =20 > The most important conclusion is this: We do not need any QOS model. Period. > =20 > All we want in NSIS is this: Like NSIS QOS signaling messages, we just need > to express the end-to-end QOS parameters of the applications as follows: > Bandwidth, Delay, Jitter, and Packet Loss. > =20 > For non-real-time data application, "jitter" may or may not be required, but > for real-time/near-real-time audio/video application, the above 4 parameters > are needed. > =20 > The application will express those values on end-to-end basis, "independent" > of any transport networking that may consist of one or many networks while > transporting the application messages/payload on end-to-end basis. > =20 > By the way, NSIS's charter is not to standardize or specify any "value" for > those performance parameters. > =20 > It is so simple. > =20 > How to deal with the network QOS, it is not NSIS's problems. NSIS's charter > is to "signal" the QOS parameters on end-to-end basis between the > applications. By the way, the end-to-end QOS requirements for applications > will remain the "same" because it is based on the "inherent" characteristics > of the system (e.g., MOS of audio/video application, response time > requirements for data application depending on human or automa).=20 > =20 > Best regards, > Radhika > =20 > PS: > =20 > 1. Now, 3G may solve their part of the network QOS. For example, they > provide the access wireless network. > =20 > 2. IEEE may solve the access LAN QOS problems. > =20 > 3. IETF may solve the problems of public Internet backbone network QOS > (e.g., DiffServ, DSTE), access IP network QOS (e.g., IntServ) or end-to-end > IP (access + backbone). > =20 > 4. An implementer (say, service provider) that wants to provide end-to-end > VoIP/SIP service will take NSIS QOS as the fundamental reference for > addressing the end-to-end QOS for the application. They now need to choose > what type of networks they will use on the end-to-end path. Accordingly, > they will divide the NSIS's end-to-end QOS that has been signaled by the > application into individual networks. The beauty of this is this: NSIS QOS > signaling protocol still be used on end-to-end basis between the > applications. > =20 > 5. If NSIS needs to address item 4, it needs to change its charter. It is a > huge problem to solve. I am extremely worried that NSIS focus might have > distorted due to unnecessarily mixing of items 1, 2, 3, and 4 while they > started discussing the QOS parameters. >=20 > _____ =20 >=20 > From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes > Sent: Mon 7/31/2006 11:32 AM > To: Roy, Radhika R.; Hannes Tschofenig; Hancock, Robert > Cc: nsis@ietf.org > Subject: AW: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li > st? >=20 >=20 >=20 > Hi Roy, >=20 > from the discussion so far it seems that you have looked at the > application layer to NSIS QoS mapping in more detail. > What was the conclusion? > Are the work-in-progress QoS models support what you want? >=20 > Ciao > Hannes >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > =20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 31 22:49:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7kK2-0007EV-5g; Mon, 31 Jul 2006 22:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7kK0-0007BB-4x for nsis@ietf.org; Mon, 31 Jul 2006 22:49:28 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7kJz-0000iH-Po for nsis@ietf.org; Mon, 31 Jul 2006 22:49:28 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 31 Jul 2006 22:49:15 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006073122491523250 ; Mon, 31 Jul 2006 22:49:15 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jul 2006 22:49:15 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209DC7@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes Tschofenig Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Mon, 31 Jul 2006 22:49:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Hannes: It is very interesting that NSIS wants QOS model concept for signaling. The question is this: Which QOS model? More inline [RRR]. BR/Radhika _____ From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Mon 7/31/2006 3:34 PM To: Roy, Radhika R. Cc: Hancock, Robert; nsis@ietf.org; Tschofenig, Hannes Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Hi Roy, I strongly believe that we need the QoS model concept. [RRR] Which QOS model? I also think that there will never be a single QoS model that everyone can agree with. [RRR] Again, which QOS model that NSIS needs to agree with? You will always find deployment environments that are a bit different that others. We already see this happening today. [RRR] Agreed. NSIS is not standardizing any specific implemention or deployment. NSIS is about signaling QoS information obtained from the application to the network, in one of the envisioned usage scenarios. [RRR] Agreed. One of the important real-time multimedia applications is SIP. If its needs are not met, which applications that NSIS is shooting for? Could you please provide a scenario how the SIP application will use NSIS QOS parameters that will have no knowledge of any underlying transport networks or network-specific QOS models other than its own codecs per se? I would appreciate your help. But there are others as well that are important. [RRR] I would think so. Could you please be more specifc with a given example instead of being abstract? You just need to think about the transition time where an E2E solution cannot be deployed. [RRR] Good. Let us understand what is the transitional QOS model where e2e QOS solution cannot be deployed. No one in NSIS has yet written a requirement that NSIS will develop a QOS signaling standard that will deal with a transitional case before the e2e QOS solution is deployed. If so, let us make it very specific what is the scope of this transitional QOS solution. If we know this, definitely we all will work to this end. Let us write a requirement document on this instead of being abstract. [RRR] We thought that NSIS will do in two steps: a. Simple one with e2e application QOS and b. Network-specific e2e QOS while complementing the e2e application QOS as the fundamental reference. Case a will always remain the same as SIP will always use its QOS reference to its codecs while case b will have numerous soultions/implementations, and NSIS may work for a long time on item b. Ciao Hannes Roy, Radhika R. wrote: > Hi, Hannes: > > The most important conclusion is this: We do not need any QOS model. Period. > > All we want in NSIS is this: Like NSIS QOS signaling messages, we just need > to express the end-to-end QOS parameters of the applications as follows: > Bandwidth, Delay, Jitter, and Packet Loss. > > For non-real-time data application, "jitter" may or may not be required, but > for real-time/near-real-time audio/video application, the above 4 parameters > are needed. > > The application will express those values on end-to-end basis, "independent" > of any transport networking that may consist of one or many networks while > transporting the application messages/payload on end-to-end basis. > > By the way, NSIS's charter is not to standardize or specify any "value" for > those performance parameters. > > It is so simple. > > How to deal with the network QOS, it is not NSIS's problems. NSIS's charter > is to "signal" the QOS parameters on end-to-end basis between the > applications. By the way, the end-to-end QOS requirements for applications > will remain the "same" because it is based on the "inherent" characteristics > of the system (e.g., MOS of audio/video application, response time > requirements for data application depending on human or automa). > > Best regards, > Radhika > > PS: > > 1. Now, 3G may solve their part of the network QOS. For example, they > provide the access wireless network. > > 2. IEEE may solve the access LAN QOS problems. > > 3. IETF may solve the problems of public Internet backbone network QOS > (e.g., DiffServ, DSTE), access IP network QOS (e.g., IntServ) or end-to-end > IP (access + backbone). > > 4. An implementer (say, service provider) that wants to provide end-to-end > VoIP/SIP service will take NSIS QOS as the fundamental reference for > addressing the end-to-end QOS for the application. They now need to choose > what type of networks they will use on the end-to-end path. Accordingly, > they will divide the NSIS's end-to-end QOS that has been signaled by the > application into individual networks. The beauty of this is this: NSIS QOS > signaling protocol still be used on end-to-end basis between the > applications. > > 5. If NSIS needs to address item 4, it needs to change its charter. It is a > huge problem to solve. I am extremely worried that NSIS focus might have > distorted due to unnecessarily mixing of items 1, 2, 3, and 4 while they > started discussing the QOS parameters. > > _____ > > From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes > Sent: Mon 7/31/2006 11:32 AM > To: Roy, Radhika R.; Hannes Tschofenig; Hancock, Robert > Cc: nsis@ietf.org > Subject: AW: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li > st? > > > > Hi Roy, > > from the discussion so far it seems that you have looked at the > application layer to NSIS QoS mapping in more detail. > What was the conclusion? > Are the work-in-progress QoS models support what you want? > > Ciao > Hannes > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis