From nsis-bounces@ietf.org Tue Jan 02 07:39:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ivI-0003wz-P3; Tue, 02 Jan 2007 07:39:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ivH-0003wa-RH for nsis@ietf.org; Tue, 02 Jan 2007 07:39:19 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1ivG-0006pq-Cr for nsis@ietf.org; Tue, 02 Jan 2007 07:39:19 -0500 Received: (qmail invoked by alias); 02 Jan 2007 11:39:16 -0000 Received: from p549858DF.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.88.223] by mail.gmx.net (mp053) with SMTP; 02 Jan 2007 12:39:16 +0100 X-Authenticated: #29516787 Message-ID: <459A4477.80407@gmx.net> Date: Tue, 02 Jan 2007 12:39:35 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: nsis@ietf.org 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: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [NSIS] QSPEC Template Draft 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, as a short summary: The draft now provides QoS parameters (Traffic Model Parameters, Constraint Parameters, Traffic Handling Directives, Traffic Classifiers) and informative processing descriptions related to the QSPEC usage tied to the QoS NSLP. Regarding QoS parameters: The goal of defining a "global" QoS model seems to be gone. Instead, the M-flag is now used to indicate whether a particular parameter has to be understood. I was always a bit skeptical with the inclusion of Y.1541 and DSTE parameters as mandatory-to-implement in the past (the Y.1541 QoS Class parameter is just a "compressed" version of the path latency, path jitter, and path packet loss ratio parameter of the constraint parameters and the DSTE parameter is useful only for a local QoS model). BUT: with the most recent draft version this is not the case anymore since a domain can just decide to implement a specific QoS model or a small number of QoSMs. Nobody implements the QSPEC as such; instead they implement a QoSM that makes use of some QoS parameters and may define a few more. With this respect the document, is truly a template for QoS parameters. At least that's my reading. Is it true? With this respect, the abstract and Section 5.4 regarding extensibility have to be updated. Usage of RFC 2119 language is a bit challenging in this document given that it means "If a QoSM decides to use a certain parameter then it must implement the parameter as mentioned in this document.". Do you need to a normative reference since it is just a template of QoS parameters? Regarding processing description: I never understood why the processing description is also provided in this document. I provided this comment already in the past but obviously the authors didn't like it too much. Not a big deal though. In some sense it is largely a matter of taste anyway. Instead of reducing the processing description it was actually enhanced; I was surprised to find a QSPEC encapsulation technique in Section 5.1. I always thought that this is a QoS NSLP draft aspect. This is probably a document writing style and a matter of worksplit between the QoS NSLP and the QSPEC document authors. A deployable solution requires GIST, the QoS NSLP, the QSPEC and a QoSM (and the AAA part) and a reader might want to read all these documents anyway. Section 5.3 should be informative only; no RFC 2119 language since the current text just outlines all possible combinations. Currently, one can sometimes find RFC 2119 language in some subsections. The QoSMs provide the normative text and may restrict the available combinations. [[Note that this might raise interesting problems given that different QoSMs implement a different signaling behavior and interworking between different QoSMs might be really challenging. For example, what happens if a receiver-initiated reservation meets a domain with a QoS model that only supports sender-initiated reservations.]] That's it for now. I will provide more detailed comments later. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 02 08:47:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1jzK-0001iL-AH; Tue, 02 Jan 2007 08:47:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1jzI-0001iF-Vv for nsis@ietf.org; Tue, 02 Jan 2007 08:47:32 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1jzH-0005Nl-CJ for nsis@ietf.org; Tue, 02 Jan 2007 08:47:32 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Jan 2007 05:47:30 -0800 X-IronPort-AV: i="4.12,226,1165219200"; d="scan'208"; a="97191656:sNHT63612297" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l02DlUvd026113; Tue, 2 Jan 2007 05:47:30 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l02DlUnc002532; Tue, 2 Jan 2007 05:47:30 -0800 (PST) Received: from [10.32.245.152] ([10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l02DUmMY001485; Tue, 2 Jan 2007 05:30:48 -0800 In-Reply-To: <459A4477.80407@gmx.net> References: <459A4477.80407@gmx.net> 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: David R Oran Subject: Re: [NSIS] QSPEC Template Draft Review Date: Tue, 2 Jan 2007 08:47:25 -0500 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5104; t=1167745650; x=1168609650; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20QSPEC=20Template=20Draft=20Review |Sender:=20; bh=Yl6Ycr9pbsbiKkyi0mGCQWSb7OKLDN94Qd6ThCidAcc=; b=ajZlek5Te+uHfma/3YIeIgCDeSXPMPPMT/DLuFwW+ymen61igPrA4udF7afh9rbTjKkWdVIy Ie9oyMlGMihz35P+ycJLYZMPZgX+jN9Pj1wZMXikLNL0cgiiHMWq0Tti; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5104; t=1167744648; x=1168608648; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20QSPEC=20Template=20Draft=20Review |Sender:=20 |To:=20Hannes=20Tschofenig=20; bh=Yl6Ycr9pbsbiKkyi0mGCQWSb7OKLDN94Qd6ThCidAcc=; b=pVuQPBVkbP0+rgZMOX4TFH31mAVYxTsuR4nNpf7G4WlwVSO9FiMHWgoUQUTfwZmg41UfRs+7 +u1wmiy9lW58jTaA0OaLddbHEQemb2tQA7U2vVFPv0yDNQJoBjfGdyzx; Authentication-Results: sj-dkim-3; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote: > Hi all, > > as a short summary: The draft now provides QoS parameters (Traffic > Model Parameters, Constraint Parameters, Traffic Handling > Directives, Traffic Classifiers) and informative processing > descriptions related to the QSPEC usage tied to the QoS NSLP. > > Regarding QoS parameters: > > The goal of defining a "global" QoS model seems to be gone. > Instead, the M-flag is now used to indicate whether a particular > parameter has to be understood. > I was always a bit skeptical with the inclusion of Y.1541 and DSTE > parameters as mandatory-to-implement in the past (the Y.1541 QoS > Class parameter is just a "compressed" version of the path latency, > path jitter, and path packet loss ratio parameter of the constraint > parameters and the DSTE parameter is useful only for a local QoS > model). BUT: with the most recent draft version this is not the > case anymore since a domain can just decide to implement a specific > QoS model or a small number of QoSMs. Nobody implements the QSPEC > as such; instead they implement a QoSM that makes use of some QoS > parameters and may define a few more. With this respect the > document, is truly a template for QoS parameters. At least that's > my reading. Is it true? > That's a good summary of what the authors and I were trying to achieve with the re-write. We wanted to make QSPECs a way of expressing traffic sources (via the TMOD parameters), QoS requirements for admission (the constraint parameters), and parameters which further describe the handling/interpretation of traffic(the handling directives). This seems a much better approach than the prior way of bundling things in the QoSMs which introduce all sorts of interoperability and cross-domain issues. > With this respect, the abstract and Section 5.4 regarding > extensibility have to be updated. > > Usage of RFC 2119 language is a bit challenging in this document > given that it means "If a QoSM decides to use a certain parameter > then it must implement the parameter as mentioned in this > document.". Do you need to a normative reference since it is just a > template of QoS parameters? > I think so, at least in the sense that the parameters have well defined semantics that are not dependent of any local QoSM's whim to redefine. If a given QNI says "I want delay variance under 200ms and if you can't give it to me I don't want my traffic admitted" then the QoSM can't just ignore that or decide that it means something else. For example if an RMF in one of the nodes allows an EF queue for other traffic with a maximum depth more than 200ms then there's no way it can admit the traffic needing a delay variance under 200ms. > Regarding processing description: > > I never understood why the processing description is also provided > in this document. I provided this comment already in the past but > obviously the authors didn't like it too much. Not a big deal > though. In some sense it is largely a matter of taste anyway. > Instead of reducing the processing description it was actually > enhanced; I was surprised to find a QSPEC encapsulation technique > in Section 5.1. I always thought that this is a QoS NSLP draft aspect. Well, this was the subject of a spirited debate among some of the WG participants. I didn't particularly like the way it turned out, but there seems to be rough consensus that QSPEC encapsulation should be part of other QSPEC itself. > This is probably a document writing style and a matter of > worksplit between the QoS NSLP and the QSPEC document authors. A > deployable solution requires GIST, the QoS NSLP, the QSPEC and a > QoSM (and the AAA part) and a reader might want to read all these > documents anyway. > > Section 5.3 should be informative only; no RFC 2119 language since > the current text just outlines all possible combinations. > Currently, one can sometimes find RFC 2119 language in some > subsections. The QoSMs provide the normative text and may restrict > the available combinations. [[Note that this might raise > interesting problems given that different QoSMs implement a > different signaling behavior and interworking between different > QoSMs might be really challenging. This was one of the reasons I proposed restricting the variability among QOSMs to be in the RMF only and not to allow different signaling semantics. I lost that one. > For example, what happens if a receiver-initiated reservation meets > a domain with a QoS model that only supports sender-initiated > reservations.]] > In order to make this work I think you have to have recursive signaling at the edge of the domain. > That's it for now. I will provide more detailed comments later. > > 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 Wed Jan 03 06:16:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H246X-0004Dl-HK; Wed, 03 Jan 2007 06:16:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H246V-0004Dg-Uu for nsis@ietf.org; Wed, 03 Jan 2007 06:16:19 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H246U-0003R7-Ar for nsis@ietf.org; Wed, 03 Jan 2007 06:16:19 -0500 Received: (qmail invoked by alias); 03 Jan 2007 11:16:17 -0000 Received: from p5498684F.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.104.79] by mail.gmx.net (mp049) with SMTP; 03 Jan 2007 12:16:17 +0100 X-Authenticated: #29516787 Message-ID: <459B9094.1050901@gmx.net> Date: Wed, 03 Jan 2007 12:16:36 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: David R Oran Subject: Re: [NSIS] QSPEC Template Draft Review References: <459A4477.80407@gmx.net> 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: 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 David, David R Oran wrote: > > On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote: > >> Hi all, >> >> as a short summary: The draft now provides QoS parameters (Traffic >> Model Parameters, Constraint Parameters, Traffic Handling Directives, >> Traffic Classifiers) and informative processing descriptions related >> to the QSPEC usage tied to the QoS NSLP. >> >> Regarding QoS parameters: >> >> The goal of defining a "global" QoS model seems to be gone. Instead, >> the M-flag is now used to indicate whether a particular parameter has >> to be understood. >> I was always a bit skeptical with the inclusion of Y.1541 and DSTE >> parameters as mandatory-to-implement in the past (the Y.1541 QoS >> Class parameter is just a "compressed" version of the path latency, >> path jitter, and path packet loss ratio parameter of the constraint >> parameters and the DSTE parameter is useful only for a local QoS >> model). BUT: with the most recent draft version this is not the case >> anymore since a domain can just decide to implement a specific QoS >> model or a small number of QoSMs. Nobody implements the QSPEC as >> such; instead they implement a QoSM that makes use of some QoS >> parameters and may define a few more. With this respect the document, >> is truly a template for QoS parameters. At least that's my reading. >> Is it true? >> > That's a good summary of what the authors and I were trying to achieve > with the re-write. We wanted to make QSPECs a way of expressing > traffic sources (via the TMOD parameters), QoS requirements for > admission (the constraint parameters), and parameters which further > describe the handling/interpretation of traffic(the handling > directives). This seems a much better approach than the prior way of > bundling things in the QoSMs which introduce all sorts of > interoperability and cross-domain issues. I agree that it is better to separate topics to improve readability. > >> With this respect, the abstract and Section 5.4 regarding >> extensibility have to be updated. >> >> Usage of RFC 2119 language is a bit challenging in this document >> given that it means "If a QoSM decides to use a certain parameter >> then it must implement the parameter as mentioned in this document.". >> Do you need to a normative reference since it is just a template of >> QoS parameters? >> > I think so, at least in the sense that the parameters have well > defined semantics that are not dependent of any local QoSM's whim to > redefine. If a given QNI says "I want delay variance under 200ms and > if you can't give it to me I don't want my traffic admitted" then the > QoSM can't just ignore that or decide that it means something else. > For example if an RMF in one of the nodes allows an EF queue for other > traffic with a maximum depth more than 200ms then there's no way it > can admit the traffic needing a delay variance under 200ms. I see it differently. The current collection of parameters are available to a QoSM designer. They can decide whether to use it or define something new. Every QoSM is allowed to define whatever they want. If I want to define a IEEE 802.16e QoSM then nobody should prevent me from doing so. I would want to use the parameters that are available in the IEEE spec. For example, when I tried to map the existing QSPEC parameters to the existing IEEE 802.16e parameters then I noticed that they are similar but not exactly the same. Hence, even if they look similar I would like to define my own based on .16e rather than reusing the QSPEC parameters. The idea of a template is to offer a set of parameters that might be used when building QoSMs. With a specific QoSM some of these QSPEC parameters are hopefully implemented. The question with the parameter selection is therefore: Are these useful parameters that might be reused by a number of QoSMs? > >> Regarding processing description: >> >> I never understood why the processing description is also provided in >> this document. I provided this comment already in the past but >> obviously the authors didn't like it too much. Not a big deal though. >> In some sense it is largely a matter of taste anyway. Instead of >> reducing the processing description it was actually enhanced; I was >> surprised to find a QSPEC encapsulation technique in Section 5.1. I >> always thought that this is a QoS NSLP draft aspect. > Well, this was the subject of a spirited debate among some of the WG > participants. I didn't particularly like the way it turned out, but > there seems to be rough consensus that QSPEC encapsulation should be > part of other QSPEC itself. I must have missed this discussion. If people like it that way then it should be fine. > >> This is probably a document writing style and a matter of worksplit >> between the QoS NSLP and the QSPEC document authors. A deployable >> solution requires GIST, the QoS NSLP, the QSPEC and a QoSM (and the >> AAA part) and a reader might want to read all these documents anyway. >> >> Section 5.3 should be informative only; no RFC 2119 language since >> the current text just outlines all possible combinations. Currently, >> one can sometimes find RFC 2119 language in some subsections. The >> QoSMs provide the normative text and may restrict the available >> combinations. [[Note that this might raise interesting problems given >> that different QoSMs implement a different signaling behavior and >> interworking between different QoSMs might be really challenging. > This was one of the reasons I proposed restricting the variability > among QOSMs to be in the RMF only and not to allow different signaling > semantics. I lost that one. Another alternative is that the QSPEC document demands that QoSM documents define all possible signaling behaviors. Then it would be fine as well. It would make the QoSMs more complicated. I, btw, was never in favor of receiver-initiated signaling behavior since the authorization story is really mood. Do you agree with me that RFC 2119 language shouldn't be used in Section 5.3? > >> For example, what happens if a receiver-initiated reservation meets a >> domain with a QoS model that only supports sender-initiated >> reservations.]] >> > In order to make this work I think you have to have recursive > signaling at the edge of the domain. Correct. As an example, in RMD these different cases got considered. If you only assume that sender-initiated reservations exist then documents are simpler since they obviously don't need to consider all the different cases. We noticed this problem already with the mobility document where the receiver-initiated reservations are just painful. > >> That's it for now. I will provide more detailed comments later. >> >> Ciao >> Hannes >> >> 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 Wed Jan 03 08:52:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26XE-00012Y-0b; Wed, 03 Jan 2007 08:52:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26XC-00012K-KC for nsis@ietf.org; Wed, 03 Jan 2007 08:52:02 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H26XB-000213-Vs for nsis@ietf.org; Wed, 03 Jan 2007 08:52:02 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 03 Jan 2007 05:52:01 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l03Dq1xU016133; Wed, 3 Jan 2007 05:52:01 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l03Dq1Il019397; Wed, 3 Jan 2007 05:52:01 -0800 (PST) Received: from [10.32.245.152] ([10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l03DZDo4026159; Wed, 3 Jan 2007 05:35:13 -0800 In-Reply-To: <459B9094.1050901@gmx.net> References: <459A4477.80407@gmx.net> <459B9094.1050901@gmx.net> 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: David R Oran Subject: Re: [NSIS] QSPEC Template Draft Review Date: Wed, 3 Jan 2007 08:51:54 -0500 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9366; t=1167832321; x=1168696321; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20QSPEC=20Template=20Draft=20Review |Sender:=20; bh=YY3rcqb5k36yxtVgdRlyI77qoL09HW/ZChRenqnWofc=; b=QXpUHxLBumRGI5j63fVfIyc4Ei9gWUwbfRwcPzLfbImyIQrx4P8SegAy5NMLwmzMuk/+zCSE piHxHkN75/yxcZMJxsdyccNS/zLrFbaL4u7EQpjz+LcdWB4GzLFZtKG5; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9366; t=1167831314; x=1168695314; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20QSPEC=20Template=20Draft=20Review |Sender:=20 |To:=20Hannes=20Tschofenig=20; bh=YY3rcqb5k36yxtVgdRlyI77qoL09HW/ZChRenqnWofc=; b=l8hb+vTOCwH1J7wImhHu4ubiDkGi/vI2twW277td76BU2DNYJO66asU53HZrjqLDnyb3upUx UvzLYIULQbgypxAI3eNYJfoX0CSIFUqQ4MqbQjg2YBzbAFIiW1H5KWaP; Authentication-Results: sj-dkim-7; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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 On Jan 3, 2007, at 6:16 AM, Hannes Tschofenig wrote: > Hi David, > > David R Oran wrote: >> >> On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote: >> [snip] >>> With this respect, the abstract and Section 5.4 regarding >>> extensibility have to be updated. >>> >>> Usage of RFC 2119 language is a bit challenging in this document >>> given that it means "If a QoSM decides to use a certain parameter >>> then it must implement the parameter as mentioned in this >>> document.". Do you need to a normative reference since it is just >>> a template of QoS parameters? >>> >> I think so, at least in the sense that the parameters have well >> defined semantics that are not dependent of any local QoSM's whim >> to redefine. If a given QNI says "I want delay variance under >> 200ms and if you can't give it to me I don't want my traffic >> admitted" then the QoSM can't just ignore that or decide that it >> means something else. For example if an RMF in one of the nodes >> allows an EF queue for other traffic with a maximum depth more >> than 200ms then there's no way it can admit the traffic needing a >> delay variance under 200ms. > > I see it differently. The current collection of parameters are > available to a QoSM designer. They can decide whether to use it or > define something new. Every QoSM is allowed to define whatever they > want. If I want to define a IEEE 802.16e QoSM then nobody should > prevent me from doing so. I would want to use the parameters that > are available in the IEEE spec. For example, when I tried to map > the existing QSPEC parameters to the existing IEEE 802.16e > parameters then I noticed that they are similar but not exactly the > same. Hence, even if they look similar I would like to define my > own based on .16e rather than reusing the QSPEC parameters. > And herein lies the core of the issue that has bedeviled the working group lately (and perhaps since inception, I don't know since my participation has been sporadic). I see the purpose of NSIS to define a signaling scheme which works end-to-end on the Internet, rather than just an architecture and template for defining a set of non- interoperable custom, per-network QoS signaling and description schemes. To do this there have to be a core set of QoS parameters which are universally understood from which you can build the vast majority of QoS schemes. Let's face it, the number of feasible data plane queueing/scheduling/policing/shaping algorithms is in fact not that large. I think it has yet to be demonstrated that the network- specific QoS parameter cannot in all but some corner cases be represented using the parameters we have come up with. Most of the argument has been based on RMFs that wish to be "simpler" than the general case in which the exact constraints and traffic model parameters of the source are enforced. This is fine, but it does NOT mean that we need a free-for-all in terms of parameter space. It is in fact why we restructured the Qspec parameters so that the user could be explicit and control what is advisory and what is mandatory for admission. Even more important, we don't need a free-for-all in the operation of QoS NSLP. The idea that the QoSM can change the signaling state machines for the NSLP is quite scary to me, which is why I suggested the language which said a QOSM isn't permitted to redefine the way QOS NSLP works. It's pretty clear that a number of people on the WG disagree with this position. That's fine - I said I'd shut up if the WG consensus went a different way. However, I do detect the weight of opinion being closer to what I wrote above. I'll leave it to the WG chair to assess this. > The idea of a template is to offer a set of parameters that might > be used when building QoSMs. With a specific QoSM some of these > QSPEC parameters are hopefully implemented. > If the QSPEC specification is viewed as just a template/base schema, then I think we will have failed pretty miserably. We will have the illusion of interoperability and not real interoperability. > The question with the parameter selection is therefore: Are these > useful parameters that might be reused by a number of QoSMs? > I'd turn it around and say "given that end-to-end QoS interoperability is a main goal of NSIS, does the particular QoSM achieve this well enough to admit the traffic as requested by the QNI". If the QoSM can't do what the user asked then it's the job of the QSPEC semantics and the QOS NSLP signaling machinery to not admit the traffic, and tell the user why. It's up to the user/QNI to formulate QoS requests that are adequate to the needs of the application but which have high probability of being admitted under conditions where there are adequate resources. QoS NSLP and Qspecs (as we have them in the current drafts) give us the tools to accomplish this. If we treat the Qspec parameters just as "useful suggestions" I think we will have pretty definitely sacrificed this goal for the Internet, which is what NSIS exists for. >> >>> Regarding processing description: >>> >>> I never understood why the processing description is also >>> provided in this document. I provided this comment already in the >>> past but obviously the authors didn't like it too much. Not a big >>> deal though. In some sense it is largely a matter of taste >>> anyway. Instead of reducing the processing description it was >>> actually enhanced; I was surprised to find a QSPEC encapsulation >>> technique in Section 5.1. I always thought that this is a QoS >>> NSLP draft aspect. >> Well, this was the subject of a spirited debate among some of the >> WG participants. I didn't particularly like the way it turned out, >> but there seems to be rough consensus that QSPEC encapsulation >> should be part of other QSPEC itself. > > I must have missed this discussion. If people like it that way then > it should be fine. > >> >>> This is probably a document writing style and a matter of >>> worksplit between the QoS NSLP and the QSPEC document authors. A >>> deployable solution requires GIST, the QoS NSLP, the QSPEC and a >>> QoSM (and the AAA part) and a reader might want to read all >>> these documents anyway. >>> >>> Section 5.3 should be informative only; no RFC 2119 language >>> since the current text just outlines all possible combinations. >>> Currently, one can sometimes find RFC 2119 language in some >>> subsections. The QoSMs provide the normative text and may >>> restrict the available combinations. [[Note that this might raise >>> interesting problems given that different QoSMs implement a >>> different signaling behavior and interworking between different >>> QoSMs might be really challenging. >> This was one of the reasons I proposed restricting the variability >> among QOSMs to be in the RMF only and not to allow different >> signaling semantics. I lost that one. > > Another alternative is that the QSPEC document demands that QoSM > documents define all possible signaling behaviors. Then it would be > fine as well. It would make the QoSMs more complicated. I, btw, was > never in favor of receiver-initiated signaling behavior since the > authorization story is really mood. > > > Do you agree with me that RFC 2119 language shouldn't be used in > Section 5.3? > I see no problem with the (quite limited) use of RFC2119 language in the places in section 5.3 where it appears. It seems quite appropriate to me,. >> >>> For example, what happens if a receiver-initiated reservation >>> meets a domain with a QoS model that only supports sender- >>> initiated reservations.]] >>> >> In order to make this work I think you have to have recursive >> signaling at the edge of the domain. > Correct. > > As an example, in RMD these different cases got considered. > > If you only assume that sender-initiated reservations exist then > documents are simpler since they obviously don't need to consider > all the different cases. > We noticed this problem already with the mobility document where > the receiver-initiated reservations are just painful. > But this is up to the applications which is more useful/natural, no? If you are saying that receiver-initiated is harder to achieve under some circumstances, then sure. Applications should be cognizant of that and use receiver-initiated only when they can't conveniently use sender-initiated. Conversely, some applications (e.g. multicast and multi-unicast) can get all tied up in knots with sender-initiated reservations. But to say that interoperability fails because some QoSM decides receiver-initiated reservations are a pain and redefines QOS NSLP to eliminate them over its domain strikes me as a very poor tradeoff. Cheers, Dave. > >> >>> That's it for now. I will provide more detailed comments later. >>> >>> Ciao >>> Hannes >>> >>> > 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 Wed Jan 03 09:11:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26pC-0004Fv-Ht; Wed, 03 Jan 2007 09:10:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26pA-0004Fp-U8 for nsis@ietf.org; Wed, 03 Jan 2007 09:10:36 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H26p9-0006Pb-0s for nsis@ietf.org; Wed, 03 Jan 2007 09:10:36 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l03EAFhI021178; Wed, 3 Jan 2007 15:10:23 +0100 (MET) From: "Georgios Karagiannis" To: "'David R Oran'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] QSPEC Template Draft Review Date: Wed, 3 Jan 2007 15:10:17 +0100 Message-ID: <001501c72f40$e8cd9cb0$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.3028 Thread-Index: AccvPqQKhCF9/IMjRbaDejRmRB8Y/AAAYN8Q In-Reply-To: X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 03 Jan 2007 15:10:25 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df 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 Dave > It's pretty clear that a number of people on the WG disagree > with this position. That's fine - I said I'd shut up if the > WG consensus went a different way. However, I do detect the > weight of opinion being closer to what I wrote above. I'll > leave it to the WG chair to assess this. It is obvious that you try very hard to change certain QOSM concepts that have been decided 4 years ago by the NSIS WG. Reading the comments of Hannes I can see that also Hannes disagrees with you! Best Regards, Georgios > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: woensdag 3 januari 2007 14:52 > To: Hannes Tschofenig > Cc: nsis@ietf.org > Subject: Re: [NSIS] QSPEC Template Draft Review > > > On Jan 3, 2007, at 6:16 AM, Hannes Tschofenig wrote: > > > Hi David, > > > > David R Oran wrote: > >> > >> On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote: > >> > [snip] > >>> With this respect, the abstract and Section 5.4 regarding > >>> extensibility have to be updated. > >>> > >>> Usage of RFC 2119 language is a bit challenging in this document > >>> given that it means "If a QoSM decides to use a certain parameter > >>> then it must implement the parameter as mentioned in this > >>> document.". Do you need to a normative reference since it > is just a > >>> template of QoS parameters? > >>> > >> I think so, at least in the sense that the parameters have well > >> defined semantics that are not dependent of any local > QoSM's whim to > >> redefine. If a given QNI says "I want delay variance under > 200ms and > >> if you can't give it to me I don't want my traffic > admitted" then the > >> QoSM can't just ignore that or decide that it means > something else. > >> For example if an RMF in one of the nodes allows an EF queue for > >> other traffic with a maximum depth more than 200ms then there's no > >> way it can admit the traffic needing a delay variance under 200ms. > > > > I see it differently. The current collection of parameters are > > available to a QoSM designer. They can decide whether to use it or > > define something new. Every QoSM is allowed to define whatever they > > want. If I want to define a IEEE 802.16e QoSM then nobody should > > prevent me from doing so. I would want to use the > parameters that are > > available in the IEEE spec. For example, when I tried to map the > > existing QSPEC parameters to the existing IEEE 802.16e > parameters then > > I noticed that they are similar but not exactly the same. > Hence, even > > if they look similar I would like to define my own based on .16e > > rather than reusing the QSPEC parameters. > > > And herein lies the core of the issue that has bedeviled the > working group lately (and perhaps since inception, I don't > know since my participation has been sporadic). I see the > purpose of NSIS to define a signaling scheme which works > end-to-end on the Internet, rather than just an architecture > and template for defining a set of non- interoperable custom, > per-network QoS signaling and description schemes. To do this > there have to be a core set of QoS parameters which are > universally understood from which you can build the vast > majority of QoS schemes. Let's face it, the number of > feasible data plane queueing/scheduling/policing/shaping > algorithms is in fact not that large. I think it has yet to > be demonstrated that the network- specific QoS parameter > cannot in all but some corner cases be represented using the > parameters we have come up with. Most of the argument has > been based on RMFs that wish to be "simpler" than the general > case in which the exact constraints and traffic model > parameters of the source are enforced. This is fine, but it > does NOT mean that we need a free-for-all in terms of > parameter space. It is in fact why we restructured the Qspec > parameters so that the user could be explicit and control > what is advisory and what is mandatory for admission. > > Even more important, we don't need a free-for-all in the > operation of QoS NSLP. The idea that the QoSM can change the > signaling state machines for the NSLP is quite scary to me, > which is why I suggested the language which said a QOSM isn't > permitted to redefine the way QOS NSLP works. > > It's pretty clear that a number of people on the WG disagree > with this position. That's fine - I said I'd shut up if the > WG consensus went a different way. However, I do detect the > weight of opinion being closer to what I wrote above. I'll > leave it to the WG chair to assess this. > > > The idea of a template is to offer a set of parameters that > might be > > used when building QoSMs. With a specific QoSM some of these QSPEC > > parameters are hopefully implemented. > > > If the QSPEC specification is viewed as just a template/base > schema, then I think we will have failed pretty miserably. We > will have the illusion of interoperability and not real > interoperability. > > > The question with the parameter selection is therefore: Are these > > useful parameters that might be reused by a number of QoSMs? > > > I'd turn it around and say "given that end-to-end QoS > interoperability is a main goal of NSIS, does the particular > QoSM achieve this well enough to admit the traffic as > requested by the QNI". If the QoSM can't do what the user > asked then it's the job of the QSPEC semantics and the QOS > NSLP signaling machinery to not admit the traffic, and tell > the user why. It's up to the user/QNI to formulate QoS > requests that are adequate to the needs of the application > but which have high probability of being admitted under > conditions where there are adequate resources. QoS NSLP and > Qspecs (as we have them in the current drafts) give us the > tools to accomplish this. If we treat the Qspec parameters > just as "useful suggestions" I think we will have pretty > definitely sacrificed this goal for the Internet, which is > what NSIS exists for. > > >> > >>> Regarding processing description: > >>> > >>> I never understood why the processing description is also > provided > >>> in this document. I provided this comment already in the past but > >>> obviously the authors didn't like it too much. Not a big deal > >>> though. In some sense it is largely a matter of taste anyway. > >>> Instead of reducing the processing description it was actually > >>> enhanced; I was surprised to find a QSPEC encapsulation > technique in > >>> Section 5.1. I always thought that this is a QoS NSLP > draft aspect. > >> Well, this was the subject of a spirited debate among some > of the WG > >> participants. I didn't particularly like the way it turned > out, but > >> there seems to be rough consensus that QSPEC encapsulation > should be > >> part of other QSPEC itself. > > > > I must have missed this discussion. If people like it that > way then it > > should be fine. > > > >> > >>> This is probably a document writing style and a matter > of worksplit > >>> between the QoS NSLP and the QSPEC document authors. A deployable > >>> solution requires GIST, the QoS NSLP, the QSPEC and a > QoSM (and the > >>> AAA part) and a reader might want to read all these documents > >>> anyway. > >>> > >>> Section 5.3 should be informative only; no RFC 2119 > language since > >>> the current text just outlines all possible combinations. > >>> Currently, one can sometimes find RFC 2119 language in some > >>> subsections. The QoSMs provide the normative text and may > restrict > >>> the available combinations. [[Note that this might raise > interesting > >>> problems given that different QoSMs implement a different > signaling > >>> behavior and interworking between different QoSMs might be really > >>> challenging. > >> This was one of the reasons I proposed restricting the variability > >> among QOSMs to be in the RMF only and not to allow different > >> signaling semantics. I lost that one. > > > > Another alternative is that the QSPEC document demands that QoSM > > documents define all possible signaling behaviors. Then it would be > > fine as well. It would make the QoSMs more complicated. I, btw, was > > never in favor of receiver-initiated signaling behavior since the > > authorization story is really mood. > > > > > > Do you agree with me that RFC 2119 language shouldn't be used in > > Section 5.3? > > > I see no problem with the (quite limited) use of RFC2119 > language in the places in section 5.3 where it appears. It > seems quite appropriate to me,. > > >> > >>> For example, what happens if a receiver-initiated > reservation meets > >>> a domain with a QoS model that only supports sender- initiated > >>> reservations.]] > >>> > >> In order to make this work I think you have to have recursive > >> signaling at the edge of the domain. > > Correct. > > > > As an example, in RMD these different cases got considered. > > > > If you only assume that sender-initiated reservations exist then > > documents are simpler since they obviously don't need to > consider all > > the different cases. > > We noticed this problem already with the mobility document > where the > > receiver-initiated reservations are just painful. > > > But this is up to the applications which is more useful/natural, no? > If you are saying that receiver-initiated is harder to > achieve under some circumstances, then sure. Applications > should be cognizant of that and use receiver-initiated only > when they can't conveniently use sender-initiated. > Conversely, some applications (e.g. multicast and > multi-unicast) can get all tied up in knots with > sender-initiated reservations. But to say that > interoperability fails because some QoSM decides > receiver-initiated reservations are a pain and redefines QOS > NSLP to eliminate them over its domain strikes me as a very > poor tradeoff. > > Cheers, Dave. > > > > >> > >>> That's it for now. I will provide more detailed comments later. > >>> > >>> Ciao > >>> Hannes > >>> > >>> > > 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 Wed Jan 03 09:28:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H276c-0007qO-5I; Wed, 03 Jan 2007 09:28:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H276a-0007pq-6I for nsis@ietf.org; Wed, 03 Jan 2007 09:28:36 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H276Y-0001df-GN for nsis@ietf.org; Wed, 03 Jan 2007 09:28:36 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Jan 2007 06:28:34 -0800 X-IronPort-AV: i="4.12,232,1165219200"; d="scan'208"; a="757985538:sNHT66405440" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l03ESXlL007306 for ; Wed, 3 Jan 2007 06:28:33 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l03ESWZH014455 for ; Wed, 3 Jan 2007 06:28:32 -0800 (PST) Received: from [10.32.245.152] ([10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l03EBlZP027625 for ; Wed, 3 Jan 2007 06:11:47 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <001501c72f40$e8cd9cb0$4c0d5982@dynamic.ewi.utwente.nl> References: <001501c72f40$e8cd9cb0$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3CDC619D-3420-4102-B6E7-1932601F873C@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] QSPEC Template Draft Review Date: Wed, 3 Jan 2007 09:28:27 -0500 To: NSIS Group X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11551; t=1167834513; x=1168698513; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20QSPEC=20Template=20Draft=20Review |Sender:=20; bh=8rgwIoNt2PvPLlWiFXjBVaOSimaVKxh58NQ7tlZoK1s=; b=miV2fxD7g1frUZMrt6aHNrqVLBCWMLUtdTk8Jdm/sQ8paySamFiDx5L36Y0zcsgw1ox+6NuD C9aBk2hPM4uvqHdii0YdrOlSKo5ZfZ+DRrJl3H/Lw0M/tJdbv00UDr8G; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11551; t=1167833507; x=1168697507; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20QSPEC=20Template=20Draft=20Review |Sender:=20 |To:=20NSIS=20Group=20; bh=8rgwIoNt2PvPLlWiFXjBVaOSimaVKxh58NQ7tlZoK1s=; b=NwMbikTpzBAKr2SByodFYF5OgKqBWqMKaTIaDAhKLI0U0k0U6BI2A6JU4N9MiO/JcatB3wDQ sgNOxN9/SmfqD0RXWhlKd+nJutzR5hWl/EzjNuvd1iVp2kUW165yukoa; Authentication-Results: sj-dkim-2; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb 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 Jan 3, 2007, at 9:10 AM, Georgios Karagiannis wrote: > Hi Dave > >> It's pretty clear that a number of people on the WG disagree >> with this position. That's fine - I said I'd shut up if the >> WG consensus went a different way. However, I do detect the >> weight of opinion being closer to what I wrote above. I'll >> leave it to the WG chair to assess this. > > It is obvious that you try very hard to change certain QOSM concepts > that have been decided 4 years ago by the NSIS WG. > Reading the comments of Hannes I can see that also > Hannes disagrees with you! > If those were in fact "decisions" and if their implications were understood then you are correct in characterizing my position as a change from prior WG direction. In my defense I'll say that this change (or proposal for change) came up as an attempt to break a kind of deadlock over the technical content of the qspec specification. If the conditions that led to that no longer exist, and the WG is happy to go back to treating qspecs as templates and QoSMs as being the first-class architectural elements then, if the WG chair agrees that's the consensus, I'll shut up. It might be worth asking the transport area directors their opinions on this though, since it is in no one's interest to just postpone a set of issues that the IESG would wind up raising during the approval cycle. Best, Dave. > Best Regards, > Georgios > > >> -----Original Message----- >> From: David R Oran [mailto:oran@cisco.com] >> Sent: woensdag 3 januari 2007 14:52 >> To: Hannes Tschofenig >> Cc: nsis@ietf.org >> Subject: Re: [NSIS] QSPEC Template Draft Review >> >> >> On Jan 3, 2007, at 6:16 AM, Hannes Tschofenig wrote: >> >>> Hi David, >>> >>> David R Oran wrote: >>>> >>>> On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote: >>>> >> [snip] >>>>> With this respect, the abstract and Section 5.4 regarding >>>>> extensibility have to be updated. >>>>> >>>>> Usage of RFC 2119 language is a bit challenging in this document >>>>> given that it means "If a QoSM decides to use a certain parameter >>>>> then it must implement the parameter as mentioned in this >>>>> document.". Do you need to a normative reference since it >> is just a >>>>> template of QoS parameters? >>>>> >>>> I think so, at least in the sense that the parameters have well >>>> defined semantics that are not dependent of any local >> QoSM's whim to >>>> redefine. If a given QNI says "I want delay variance under >> 200ms and >>>> if you can't give it to me I don't want my traffic >> admitted" then the >>>> QoSM can't just ignore that or decide that it means >> something else. >>>> For example if an RMF in one of the nodes allows an EF queue for >>>> other traffic with a maximum depth more than 200ms then there's no >>>> way it can admit the traffic needing a delay variance under 200ms. >>> >>> I see it differently. The current collection of parameters are >>> available to a QoSM designer. They can decide whether to use it or >>> define something new. Every QoSM is allowed to define whatever they >>> want. If I want to define a IEEE 802.16e QoSM then nobody should >>> prevent me from doing so. I would want to use the >> parameters that are >>> available in the IEEE spec. For example, when I tried to map the >>> existing QSPEC parameters to the existing IEEE 802.16e >> parameters then >>> I noticed that they are similar but not exactly the same. >> Hence, even >>> if they look similar I would like to define my own based on .16e >>> rather than reusing the QSPEC parameters. >>> >> And herein lies the core of the issue that has bedeviled the >> working group lately (and perhaps since inception, I don't >> know since my participation has been sporadic). I see the >> purpose of NSIS to define a signaling scheme which works >> end-to-end on the Internet, rather than just an architecture >> and template for defining a set of non- interoperable custom, >> per-network QoS signaling and description schemes. To do this >> there have to be a core set of QoS parameters which are >> universally understood from which you can build the vast >> majority of QoS schemes. Let's face it, the number of >> feasible data plane queueing/scheduling/policing/shaping >> algorithms is in fact not that large. I think it has yet to >> be demonstrated that the network- specific QoS parameter >> cannot in all but some corner cases be represented using the >> parameters we have come up with. Most of the argument has >> been based on RMFs that wish to be "simpler" than the general >> case in which the exact constraints and traffic model >> parameters of the source are enforced. This is fine, but it >> does NOT mean that we need a free-for-all in terms of >> parameter space. It is in fact why we restructured the Qspec >> parameters so that the user could be explicit and control >> what is advisory and what is mandatory for admission. >> >> Even more important, we don't need a free-for-all in the >> operation of QoS NSLP. The idea that the QoSM can change the >> signaling state machines for the NSLP is quite scary to me, >> which is why I suggested the language which said a QOSM isn't >> permitted to redefine the way QOS NSLP works. >> >> It's pretty clear that a number of people on the WG disagree >> with this position. That's fine - I said I'd shut up if the >> WG consensus went a different way. However, I do detect the >> weight of opinion being closer to what I wrote above. I'll >> leave it to the WG chair to assess this. >> >>> The idea of a template is to offer a set of parameters that >> might be >>> used when building QoSMs. With a specific QoSM some of these QSPEC >>> parameters are hopefully implemented. >>> >> If the QSPEC specification is viewed as just a template/base >> schema, then I think we will have failed pretty miserably. We >> will have the illusion of interoperability and not real >> interoperability. >> >>> The question with the parameter selection is therefore: Are these >>> useful parameters that might be reused by a number of QoSMs? >>> >> I'd turn it around and say "given that end-to-end QoS >> interoperability is a main goal of NSIS, does the particular >> QoSM achieve this well enough to admit the traffic as >> requested by the QNI". If the QoSM can't do what the user >> asked then it's the job of the QSPEC semantics and the QOS >> NSLP signaling machinery to not admit the traffic, and tell >> the user why. It's up to the user/QNI to formulate QoS >> requests that are adequate to the needs of the application >> but which have high probability of being admitted under >> conditions where there are adequate resources. QoS NSLP and >> Qspecs (as we have them in the current drafts) give us the >> tools to accomplish this. If we treat the Qspec parameters >> just as "useful suggestions" I think we will have pretty >> definitely sacrificed this goal for the Internet, which is >> what NSIS exists for. >> >>>> >>>>> Regarding processing description: >>>>> >>>>> I never understood why the processing description is also >> provided >>>>> in this document. I provided this comment already in the past but >>>>> obviously the authors didn't like it too much. Not a big deal >>>>> though. In some sense it is largely a matter of taste anyway. >>>>> Instead of reducing the processing description it was actually >>>>> enhanced; I was surprised to find a QSPEC encapsulation >> technique in >>>>> Section 5.1. I always thought that this is a QoS NSLP >> draft aspect. >>>> Well, this was the subject of a spirited debate among some >> of the WG >>>> participants. I didn't particularly like the way it turned >> out, but >>>> there seems to be rough consensus that QSPEC encapsulation >> should be >>>> part of other QSPEC itself. >>> >>> I must have missed this discussion. If people like it that >> way then it >>> should be fine. >>> >>>> >>>>> This is probably a document writing style and a matter >> of worksplit >>>>> between the QoS NSLP and the QSPEC document authors. A deployable >>>>> solution requires GIST, the QoS NSLP, the QSPEC and a >> QoSM (and the >>>>> AAA part) and a reader might want to read all these documents >>>>> anyway. >>>>> >>>>> Section 5.3 should be informative only; no RFC 2119 >> language since >>>>> the current text just outlines all possible combinations. >>>>> Currently, one can sometimes find RFC 2119 language in some >>>>> subsections. The QoSMs provide the normative text and may >> restrict >>>>> the available combinations. [[Note that this might raise >> interesting >>>>> problems given that different QoSMs implement a different >> signaling >>>>> behavior and interworking between different QoSMs might be really >>>>> challenging. >>>> This was one of the reasons I proposed restricting the variability >>>> among QOSMs to be in the RMF only and not to allow different >>>> signaling semantics. I lost that one. >>> >>> Another alternative is that the QSPEC document demands that QoSM >>> documents define all possible signaling behaviors. Then it would be >>> fine as well. It would make the QoSMs more complicated. I, btw, was >>> never in favor of receiver-initiated signaling behavior since the >>> authorization story is really mood. >>> >>> >>> Do you agree with me that RFC 2119 language shouldn't be used in >>> Section 5.3? >>> >> I see no problem with the (quite limited) use of RFC2119 >> language in the places in section 5.3 where it appears. It >> seems quite appropriate to me,. >> >>>> >>>>> For example, what happens if a receiver-initiated >> reservation meets >>>>> a domain with a QoS model that only supports sender- initiated >>>>> reservations.]] >>>>> >>>> In order to make this work I think you have to have recursive >>>> signaling at the edge of the domain. >>> Correct. >>> >>> As an example, in RMD these different cases got considered. >>> >>> If you only assume that sender-initiated reservations exist then >>> documents are simpler since they obviously don't need to >> consider all >>> the different cases. >>> We noticed this problem already with the mobility document >> where the >>> receiver-initiated reservations are just painful. >>> >> But this is up to the applications which is more useful/natural, no? >> If you are saying that receiver-initiated is harder to >> achieve under some circumstances, then sure. Applications >> should be cognizant of that and use receiver-initiated only >> when they can't conveniently use sender-initiated. >> Conversely, some applications (e.g. multicast and >> multi-unicast) can get all tied up in knots with >> sender-initiated reservations. But to say that >> interoperability fails because some QoSM decides >> receiver-initiated reservations are a pain and redefines QOS >> NSLP to eliminate them over its domain strikes me as a very >> poor tradeoff. >> >> Cheers, Dave. >> >>> >>>> >>>>> That's it for now. I will provide more detailed comments later. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>> 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 Wed Jan 03 16:22:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DYQ-0005ib-Fi; Wed, 03 Jan 2007 16:21:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DYP-0005hj-KS for nsis@ietf.org; Wed, 03 Jan 2007 16:21:45 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2DYK-0002kh-M6 for nsis@ietf.org; Wed, 03 Jan 2007 16:21:45 -0500 Received: (qmail invoked by alias); 03 Jan 2007 21:21:38 -0000 Received: from p549879CC.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.121.204] by mail.gmx.net (mp001) with SMTP; 03 Jan 2007 22:21:38 +0100 X-Authenticated: #29516787 Message-ID: <459C1E6B.20700@gmx.net> Date: Wed, 03 Jan 2007 22:21:47 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: David R Oran Subject: Re: [NSIS] QSPEC Template Draft Review References: <459A4477.80407@gmx.net> <459B9094.1050901@gmx.net> 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: f5932bfc8385127f631fc458a872feb1 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 Dave, thanks for your quick response. David R Oran wrote: > > On Jan 3, 2007, at 6:16 AM, Hannes Tschofenig wrote: > >> Hi David, >> >> David R Oran wrote: >>> >>> On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote: >>> > [snip] >>>> With this respect, the abstract and Section 5.4 regarding >>>> extensibility have to be updated. >>>> >>>> Usage of RFC 2119 language is a bit challenging in this document >>>> given that it means "If a QoSM decides to use a certain parameter >>>> then it must implement the parameter as mentioned in this >>>> document.". Do you need to a normative reference since it is just a >>>> template of QoS parameters? >>>> >>> I think so, at least in the sense that the parameters have well >>> defined semantics that are not dependent of any local QoSM's whim to >>> redefine. If a given QNI says "I want delay variance under 200ms and >>> if you can't give it to me I don't want my traffic admitted" then >>> the QoSM can't just ignore that or decide that it means something >>> else. For example if an RMF in one of the nodes allows an EF queue >>> for other traffic with a maximum depth more than 200ms then there's >>> no way it can admit the traffic needing a delay variance under 200ms. >> >> I see it differently. The current collection of parameters are >> available to a QoSM designer. They can decide whether to use it or >> define something new. Every QoSM is allowed to define whatever they >> want. If I want to define a IEEE 802.16e QoSM then nobody should >> prevent me from doing so. I would want to use the parameters that are >> available in the IEEE spec. For example, when I tried to map the >> existing QSPEC parameters to the existing IEEE 802.16e parameters >> then I noticed that they are similar but not exactly the same. Hence, >> even if they look similar I would like to define my own based on .16e >> rather than reusing the QSPEC parameters. >> > And herein lies the core of the issue that has bedeviled the working > group lately (and perhaps since inception, I don't know since my > participation has been sporadic). I see the purpose of NSIS to define > a signaling scheme which works end-to-end on the Internet, rather than > just an architecture and template for defining a set of > non-interoperable custom, per-network QoS signaling and description > schemes. To do this there have to be a core set of QoS parameters > which are universally understood from which you can build the vast > majority of QoS schemes. Let's face it, the number of feasible data > plane queueing/scheduling/policing/shaping algorithms is in fact not > that large. > I think it has yet to be demonstrated that the network-specific QoS > parameter cannot in all but some corner cases be represented using the > parameters we have come up with. Most of the argument has been based > on RMFs that wish to be "simpler" than the general case in which the > exact constraints and traffic model parameters of the source are > enforced. This is fine, but it does NOT mean that we need a > free-for-all in terms of parameter space. It is in fact why we > restructured the Qspec parameters so that the user could be explicit > and control what is advisory and what is mandatory for admission. > > Even more important, we don't need a free-for-all in the operation of > QoS NSLP. The idea that the QoSM can change the signaling state > machines for the NSLP is quite scary to me, which is why I suggested > the language which said a QOSM isn't permitted to redefine the way QOS > NSLP works. > > It's pretty clear that a number of people on the WG disagree with this > position. That's fine - I said I'd shut up if the WG consensus went a > different way. However, I do detect the weight of opinion being closer > to what I wrote above. I'll leave it to the WG chair to assess this. There are a few aspects that need to be discussed here. I read the QSPEC draft many, many times already (and different versions). Whenever I read through the abstract and the introduction I had the impression that I understood what the rest of the document is going to contain. I was always wrong. This time I was wrong as well. It shouldn't be too difficult to tell the reader what the document wants to accomplish. If I don't understand it then how should someone else (slightly ignoring the fact that everyone else might be smarter)? Let us separate the signaling from the QoS parameter story since they are largely a different subject. Let us try to understand what interoperability means. * Signaling Different QoSMs can nicely interwork if a) the QoS NSLP or the QSPEC document mandates a single signaling mode b) all QoSMs "support" all signaling modes. By support I mean that they describe what needs to be done in the different cases. Returning a failure might also be a possible option. While all possible signaling modes are described in the QSPEC document I couldn't see a mandate for a QoSM document to also describe what todo for all the signaling modes. [[ I call the signaling exchanges and respective message processing rules in this context "signaling modes" lacking a better term.]] * QoS Parameters From an interoperability point of view it would be ideal to have a single QoSM that is understood by everyone. I got the impression that this was the initial goal of the QSPEC document. Having a core set of parameters that are understood by everyone and a few optional parameters was an interesting idea, I thought. [[ I was never really 100 % convinced that it can actually work but that's another story. I personally was just unhappy about the choice of mandatory parameters. ]] Another alternative is to define mappings from one QoSM to another one.This is done today already but there are no procedures and documents in the NSIS working group for defining these mappings. With this approach every QoSM can essentially define whatever they want if a reasonable mapping exists. Having a mapping is obviously better than just looking at mandatory-to-understand parameters (and ignoring the optional parameters). From your description it seems that the QSPEC contains a number of parameters that are supposed to be complete and MUST be used by future QoSMs. To avoid interoperability problems QoSMs ideally must never not introduce parameters. Since some of QSPEC authors are also QoSM authors they ensured that their QoSM is nicely supported. To allow the end-to-end story to work it is necessary to consider today's access networks and the QoS parameters that are being used there. Is someone ever wants to use a path-coupled signaling solution then two approaches are possible a) the end host already uses a QoS signaling protocol like RSVP or NSIS b) the end host uses a link layer protocol (with QoS extensions) towards the access network and the network triggers the NSIS signaling exchange [A combination of the two is also possible.] In any case I guess you have to deal with the QoS parameters of the specific link layer. I wonder whether someone has looked at these issues already and whether the QSPEC QoS parameter and local QoSM model supports this extensibility. As an example, the Traffic Priority as defined in IEEE802.16e has 8 priority levels. What would I do? This parameter does not correspond to anything in the QSPEC document at the moment. The typical question I have is: I want to implement QoSM X. What do I have to implement from the QSPEC draft? [ A minor technical issue: Are there problems (in the IETF document processing) if normative references point to documents that are non-IETF documents? ] I am not sure I understood your comment regarding " The idea that the QoSM can change the signaling state machines for the NSLP is quite scary to me, which is why I suggested the language which said a QOSM isn't permitted to redefine the way QOS NSLP works. " > >> The idea of a template is to offer a set of parameters that might be >> used when building QoSMs. With a specific QoSM some of these QSPEC >> parameters are hopefully implemented. >> > If the QSPEC specification is viewed as just a template/base schema, > then I think we will have failed pretty miserably. We will have the > illusion of interoperability and not real interoperability. This is what I read from the abstract and the introduction. Maybe it would be appropriate to delete the term "template" from the document. > >> The question with the parameter selection is therefore: Are these >> useful parameters that might be reused by a number of QoSMs? >> > I'd turn it around and say "given that end-to-end QoS interoperability > is a main goal of NSIS, does the particular QoSM achieve this well > enough to admit the traffic as requested by the QNI". If the QoSM > can't do what the user asked then it's the job of the QSPEC semantics > and the QOS NSLP signaling machinery to not admit the traffic, and > tell the user why. It's up to the user/QNI to formulate QoS requests > that are adequate to the needs of the application but which have high > probability of being admitted under conditions where there are > adequate resources. QoS NSLP and Qspecs (as we have them in the > current drafts) give us the tools to accomplish this. If we treat the > Qspec parameters just as "useful suggestions" I think we will have > pretty definitely sacrificed this goal for the Internet, which is what > NSIS exists for. This sounds like a very nice. When it comes to the details things get a bit more difficult. > >>> >>>> Regarding processing description: >>>> >>>> I never understood why the processing description is also provided >>>> in this document. I provided this comment already in the past but >>>> obviously the authors didn't like it too much. Not a big deal >>>> though. In some sense it is largely a matter of taste anyway. >>>> Instead of reducing the processing description it was actually >>>> enhanced; I was surprised to find a QSPEC encapsulation technique >>>> in Section 5.1. I always thought that this is a QoS NSLP draft aspect. >>> Well, this was the subject of a spirited debate among some of the WG >>> participants. I didn't particularly like the way it turned out, but >>> there seems to be rough consensus that QSPEC encapsulation should be >>> part of other QSPEC itself. >> >> I must have missed this discussion. If people like it that way then >> it should be fine. >> >>> >>>> This is probably a document writing style and a matter of >>>> worksplit between the QoS NSLP and the QSPEC document authors. A >>>> deployable solution requires GIST, the QoS NSLP, the QSPEC and a >>>> QoSM (and the AAA part) and a reader might want to read all these >>>> documents anyway. >>>> >>>> Section 5.3 should be informative only; no RFC 2119 language since >>>> the current text just outlines all possible combinations. >>>> Currently, one can sometimes find RFC 2119 language in some >>>> subsections. The QoSMs provide the normative text and may restrict >>>> the available combinations. [[Note that this might raise >>>> interesting problems given that different QoSMs implement a >>>> different signaling behavior and interworking between different >>>> QoSMs might be really challenging. >>> This was one of the reasons I proposed restricting the variability >>> among QOSMs to be in the RMF only and not to allow different >>> signaling semantics. I lost that one. >> >> Another alternative is that the QSPEC document demands that QoSM >> documents define all possible signaling behaviors. Then it would be >> fine as well. It would make the QoSMs more complicated. I, btw, was >> never in favor of receiver-initiated signaling behavior since the >> authorization story is really mood. >> >> >> Do you agree with me that RFC 2119 language shouldn't be used in >> Section 5.3? >> > I see no problem with the (quite limited) use of RFC2119 language in > the places in section 5.3 where it appears. It seems quite appropriate > to me,. > I need to read through each paragraph to determine what the implications are. >>> >>>> For example, what happens if a receiver-initiated reservation meets >>>> a domain with a QoS model that only supports sender-initiated >>>> reservations.]] >>>> >>> In order to make this work I think you have to have recursive >>> signaling at the edge of the domain. >> Correct. >> >> As an example, in RMD these different cases got considered. >> >> If you only assume that sender-initiated reservations exist then >> documents are simpler since they obviously don't need to consider all >> the different cases. >> We noticed this problem already with the mobility document where the >> receiver-initiated reservations are just painful. >> > But this is up to the applications which is more useful/natural, no? > If you are saying that receiver-initiated is harder to achieve under > some circumstances, then sure. Applications should be cognizant of > that and use receiver-initiated only when they can't conveniently use > sender-initiated. Conversely, some applications (e.g. multicast and > multi-unicast) can get all tied up in knots with sender-initiated > reservations. But to say that interoperability fails because some QoSM > decides receiver-initiated reservations are a pain and redefines QOS > NSLP to eliminate them over its domain strikes me as a very poor > tradeoff. I agree with your statement about multicast QoS reservations. I wonder whether someone wants to use path-coupled QoS signaling for multicast communication. Ciao Hannes > Cheers, Dave. > >> >>> >>>> That's it for now. I will provide more detailed comments later. >>>> >>>> Ciao >>>> Hannes >>>> >>>> >> 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 Thu Jan 04 03:49:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2OHV-0000Ra-5E; Thu, 04 Jan 2007 03:49:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2OHT-0000RD-My for nsis@ietf.org; Thu, 04 Jan 2007 03:48:59 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2OHS-0008VF-Tb for nsis@ietf.org; Thu, 04 Jan 2007 03:48:59 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l048mRbS027256; Thu, 4 Jan 2007 09:48:40 +0100 (MET) From: "Georgios Karagiannis" To: "'Hannes Tschofenig'" , "'David R Oran'" Subject: RE: [NSIS] QSPEC Template Draft Review Date: Thu, 4 Jan 2007 09:48:33 +0100 Message-ID: <000301c72fdd$23903640$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.3028 Thread-Index: AccvfU86n0A3fwcQTUOCAObYRyIC1AAXykyg In-Reply-To: <459C1E6B.20700@gmx.net> X-Spam-Score: 0.255 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 04 Jan 2007 09:48:42 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d 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 Regarding the following point: >> * Signaling >> Different QoSMs can nicely interwork if >> a) the QoS NSLP or the QSPEC document mandates a single signaling mode >> b) all QoSMs "support" all signaling modes. >> By support I mean that they describe what needs to be done in the different cases. >> Returning a failure might also be a possible option. >> While all possible signaling modes are described in the QSPEC document >> I couldn't see a mandate for a QoSM document to also describe what todo for all the signaling modes. >> [[ I call the signaling exchanges and respective message processing >> rules in this context "signaling modes" lacking a better term.]] Regarding signaling the NSIS WG introduced the concept of QOSM to be able to support your b) option: >> b) all QoSMs "support" all signaling modes. >> By support I mean that they describe what needs to be done in the different cases. >> Returning a failure might also be a possible option. Best Regards, Georgios > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: woensdag 3 januari 2007 22:22 > To: David R Oran > Cc: nsis@ietf.org > Subject: Re: [NSIS] QSPEC Template Draft Review > > Hi Dave, > > thanks for your quick response. > > David R Oran wrote: > > > > On Jan 3, 2007, at 6:16 AM, Hannes Tschofenig wrote: > > > >> Hi David, > >> > >> David R Oran wrote: > >>> > >>> On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote: > >>> > > [snip] > >>>> With this respect, the abstract and Section 5.4 regarding > >>>> extensibility have to be updated. > >>>> > >>>> Usage of RFC 2119 language is a bit challenging in this document > >>>> given that it means "If a QoSM decides to use a certain > parameter > >>>> then it must implement the parameter as mentioned in this > >>>> document.". Do you need to a normative reference since > it is just a > >>>> template of QoS parameters? > >>>> > >>> I think so, at least in the sense that the parameters have well > >>> defined semantics that are not dependent of any local > QoSM's whim to > >>> redefine. If a given QNI says "I want delay variance > under 200ms and > >>> if you can't give it to me I don't want my traffic admitted" then > >>> the QoSM can't just ignore that or decide that it means something > >>> else. For example if an RMF in one of the nodes allows an > EF queue > >>> for other traffic with a maximum depth more than 200ms > then there's > >>> no way it can admit the traffic needing a delay variance > under 200ms. > >> > >> I see it differently. The current collection of parameters are > >> available to a QoSM designer. They can decide whether to use it or > >> define something new. Every QoSM is allowed to define > whatever they > >> want. If I want to define a IEEE 802.16e QoSM then nobody should > >> prevent me from doing so. I would want to use the > parameters that are > >> available in the IEEE spec. For example, when I tried to map the > >> existing QSPEC parameters to the existing IEEE 802.16e parameters > >> then I noticed that they are similar but not exactly the > same. Hence, > >> even if they look similar I would like to define my own > based on .16e > >> rather than reusing the QSPEC parameters. > >> > > And herein lies the core of the issue that has bedeviled > the working > > group lately (and perhaps since inception, I don't know since my > > participation has been sporadic). I see the purpose of NSIS > to define > > a signaling scheme which works end-to-end on the Internet, > rather than > > just an architecture and template for defining a set of > > non-interoperable custom, per-network QoS signaling and description > > schemes. To do this there have to be a core set of QoS parameters > > which are universally understood from which you can build the vast > > majority of QoS schemes. Let's face it, the number of feasible data > > plane queueing/scheduling/policing/shaping algorithms is in > fact not > > that large. > > I think it has yet to be demonstrated that the network-specific QoS > > parameter cannot in all but some corner cases be > represented using the > > parameters we have come up with. Most of the argument has > been based > > on RMFs that wish to be "simpler" than the general case in > which the > > exact constraints and traffic model parameters of the source are > > enforced. This is fine, but it does NOT mean that we need a > > free-for-all in terms of parameter space. It is in fact why we > > restructured the Qspec parameters so that the user could be > explicit > > and control what is advisory and what is mandatory for admission. > > > > Even more important, we don't need a free-for-all in the > operation of > > QoS NSLP. The idea that the QoSM can change the signaling state > > machines for the NSLP is quite scary to me, which is why I > suggested > > the language which said a QOSM isn't permitted to redefine > the way QOS > > NSLP works. > > > > It's pretty clear that a number of people on the WG > disagree with this > > position. That's fine - I said I'd shut up if the WG > consensus went a > > different way. However, I do detect the weight of opinion > being closer > > to what I wrote above. I'll leave it to the WG chair to assess this. > > There are a few aspects that need to be discussed here. > > I read the QSPEC draft many, many times already (and > different versions). Whenever I read through the abstract and > the introduction I had the impression that I understood what > the rest of the document is going to contain. I was always > wrong. This time I was wrong as well. > > It shouldn't be too difficult to tell the reader what the > document wants to accomplish. If I don't understand it then > how should someone else (slightly ignoring the fact that > everyone else might be smarter)? > > Let us separate the signaling from the QoS parameter story > since they are largely a different subject. Let us try to > understand what interoperability means. > > * Signaling > > Different QoSMs can nicely interwork if > a) the QoS NSLP or the QSPEC document mandates a single signaling mode > b) all QoSMs "support" all signaling modes. > By support I mean that they describe what needs to be done in > the different cases. Returning a failure might also be a > possible option. > > While all possible signaling modes are described in the QSPEC > document I couldn't see a mandate for a QoSM document to also > describe what todo for all the signaling modes. > > [[ I call the signaling exchanges and respective message > processing rules in this context "signaling modes" lacking a > better term.]] > > * QoS Parameters > > From an interoperability point of view it would be ideal to > have a single QoSM that is understood by everyone. I got the > impression that this was the initial goal of the QSPEC > document. Having a core set of parameters that are understood > by everyone and a few optional parameters was an interesting > idea, I thought. [[ I was never really 100 % convinced that > it can actually work but that's another story. I personally > was just unhappy about the choice of mandatory parameters. ]] > > Another alternative is to define mappings from one QoSM to > another one.This is done today already but there are no > procedures and documents in the NSIS working group for > defining these mappings. With this approach every QoSM can > essentially define whatever they want if a reasonable mapping exists. > > Having a mapping is obviously better than just looking at > mandatory-to-understand parameters (and ignoring the optional > parameters). > > From your description it seems that the QSPEC contains a > number of parameters that are supposed to be complete and > MUST be used by future QoSMs. To avoid interoperability > problems QoSMs ideally must never not introduce parameters. > Since some of QSPEC authors are also QoSM authors they > ensured that their QoSM is nicely supported. To allow the > end-to-end story to work it is necessary to consider today's > access networks and the QoS parameters that are being used > there. Is someone ever wants to use a path-coupled signaling > solution then two approaches are possible > a) the end host already uses a QoS signaling protocol like > RSVP or NSIS > b) the end host uses a link layer protocol (with QoS > extensions) towards the access network and the network > triggers the NSIS signaling exchange [A combination of the > two is also possible.] > > In any case I guess you have to deal with the QoS parameters > of the specific link layer. I wonder whether someone has > looked at these issues already and whether the QSPEC QoS > parameter and local QoSM model supports this extensibility. > > As an example, the Traffic Priority as defined in IEEE802.16e > has 8 priority levels. What would I do? This parameter does > not correspond to anything in the QSPEC document at the moment. > > The typical question I have is: I want to implement QoSM X. > What do I have to implement from the QSPEC draft? > > [ A minor technical issue: Are there problems (in the IETF document > processing) if normative references point to documents that > are non-IETF documents? ] > > I am not sure I understood your comment regarding " > The idea that the QoSM can change the signaling state > machines for the NSLP is quite scary to me, which is why I > suggested the language which said a QOSM isn't permitted to > redefine the way QOS NSLP works. > " > > > > >> The idea of a template is to offer a set of parameters > that might be > >> used when building QoSMs. With a specific QoSM some of these QSPEC > >> parameters are hopefully implemented. > >> > > If the QSPEC specification is viewed as just a > template/base schema, > > then I think we will have failed pretty miserably. We will have the > > illusion of interoperability and not real interoperability. > > This is what I read from the abstract and the introduction. Maybe it > would be appropriate to delete the term "template" from the document. > > > > > >> The question with the parameter selection is therefore: Are these > >> useful parameters that might be reused by a number of QoSMs? > >> > > I'd turn it around and say "given that end-to-end QoS > interoperability > > is a main goal of NSIS, does the particular QoSM achieve this well > > enough to admit the traffic as requested by the QNI". If the QoSM > > can't do what the user asked then it's the job of the QSPEC > semantics > > and the QOS NSLP signaling machinery to not admit the traffic, and > > tell the user why. It's up to the user/QNI to formulate QoS > requests > > that are adequate to the needs of the application but which > have high > > probability of being admitted under conditions where there are > > adequate resources. QoS NSLP and Qspecs (as we have them in the > > current drafts) give us the tools to accomplish this. If we > treat the > > Qspec parameters just as "useful suggestions" I think we will have > > pretty definitely sacrificed this goal for the Internet, > which is what > > NSIS exists for. > > This sounds like a very nice. When it comes to the details > things get a > bit more difficult. > > > > >>> > >>>> Regarding processing description: > >>>> > >>>> I never understood why the processing description is > also provided > >>>> in this document. I provided this comment already in the > past but > >>>> obviously the authors didn't like it too much. Not a big deal > >>>> though. In some sense it is largely a matter of taste anyway. > >>>> Instead of reducing the processing description it was actually > >>>> enhanced; I was surprised to find a QSPEC encapsulation > technique > >>>> in Section 5.1. I always thought that this is a QoS NSLP > draft aspect. > >>> Well, this was the subject of a spirited debate among > some of the WG > >>> participants. I didn't particularly like the way it > turned out, but > >>> there seems to be rough consensus that QSPEC > encapsulation should be > >>> part of other QSPEC itself. > >> > >> I must have missed this discussion. If people like it that > way then > >> it should be fine. > >> > >>> > >>>> This is probably a document writing style and a matter of > >>>> worksplit between the QoS NSLP and the QSPEC document authors. A > >>>> deployable solution requires GIST, the QoS NSLP, the QSPEC and a > >>>> QoSM (and the AAA part) and a reader might want to read > all these > >>>> documents anyway. > >>>> > >>>> Section 5.3 should be informative only; no RFC 2119 > language since > >>>> the current text just outlines all possible combinations. > >>>> Currently, one can sometimes find RFC 2119 language in some > >>>> subsections. The QoSMs provide the normative text and > may restrict > >>>> the available combinations. [[Note that this might raise > >>>> interesting problems given that different QoSMs implement a > >>>> different signaling behavior and interworking between different > >>>> QoSMs might be really challenging. > >>> This was one of the reasons I proposed restricting the > variability > >>> among QOSMs to be in the RMF only and not to allow different > >>> signaling semantics. I lost that one. > >> > >> Another alternative is that the QSPEC document demands that QoSM > >> documents define all possible signaling behaviors. Then it > would be > >> fine as well. It would make the QoSMs more complicated. I, > btw, was > >> never in favor of receiver-initiated signaling behavior since the > >> authorization story is really mood. > >> > >> > >> Do you agree with me that RFC 2119 language shouldn't be used in > >> Section 5.3? > >> > > I see no problem with the (quite limited) use of RFC2119 > language in > > the places in section 5.3 where it appears. It seems quite > appropriate > > to me,. > > > I need to read through each paragraph to determine what the > implications > are. > > >>> > >>>> For example, what happens if a receiver-initiated > reservation meets > >>>> a domain with a QoS model that only supports sender-initiated > >>>> reservations.]] > >>>> > >>> In order to make this work I think you have to have recursive > >>> signaling at the edge of the domain. > >> Correct. > >> > >> As an example, in RMD these different cases got considered. > >> > >> If you only assume that sender-initiated reservations exist then > >> documents are simpler since they obviously don't need to > consider all > >> the different cases. > >> We noticed this problem already with the mobility document > where the > >> receiver-initiated reservations are just painful. > >> > > But this is up to the applications which is more > useful/natural, no? > > If you are saying that receiver-initiated is harder to > achieve under > > some circumstances, then sure. Applications should be cognizant of > > that and use receiver-initiated only when they can't > conveniently use > > sender-initiated. Conversely, some applications (e.g. multicast and > > multi-unicast) can get all tied up in knots with sender-initiated > > reservations. But to say that interoperability fails > because some QoSM > > decides receiver-initiated reservations are a pain and > redefines QOS > > NSLP to eliminate them over its domain strikes me as a very poor > > tradeoff. > I agree with your statement about multicast QoS reservations. > I wonder > whether someone wants to use path-coupled QoS signaling for multicast > communication. > > > Ciao > Hannes > > > Cheers, Dave. > > > >> > >>> > >>>> That's it for now. I will provide more detailed comments later. > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> > >> 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 Thu Jan 04 06:58:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2REK-0007Z0-EP; Thu, 04 Jan 2007 06:57:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2REI-0007Yt-Vp for nsis@ietf.org; Thu, 04 Jan 2007 06:57:54 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2REH-0005Fx-Tj for nsis@ietf.org; Thu, 04 Jan 2007 06:57:54 -0500 Received: (qmail invoked by alias); 04 Jan 2007 11:57:52 -0000 Received: from p549879CC.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.121.204] by mail.gmx.net (mp010) with SMTP; 04 Jan 2007 12:57:52 +0100 X-Authenticated: #29516787 Message-ID: <459CEBCF.3020507@gmx.net> Date: Thu, 04 Jan 2007 12:58:07 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] QSPEC Template Draft Review References: <000301c72fdd$23903640$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <000301c72fdd$23903640$4c0d5982@dynamic.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.0 (/) X-Scan-Signature: b4be0d55bab88df9d21005ced9551e26 Cc: 'David R Oran' , 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, if this is the case then the following text needs to be changed: A QOSM specification MUST include the following: - role of QNEs, e.g., location, frequency, statefulness, etc. - QSPEC definition including QSPEC parameters [hannes] Replace the following statement with: " - QSPEC procedures applicable to this QOSM " this one: " - QSPEC signaling description for all signaling exchanges. The signaling exchanges are listed in Section 5.3. " - QNE processing rules describing how QSPEC information is treated and interpreted in the RMF, e.g., admission control, scheduling, policy control, QoS parameter accumulation (e.g., delay). - at least one bit-level QSPEC example - QSPEC parameter behavior for new QSPEC parameters the QOSM specification defines - define what happens in case of preemption if the default QNI behavior (tear down preempted reservation) is not followed (see Section 5.3.5) Ciao Hannes Georgios Karagiannis wrote: > Hi Hannes > > Regarding the following point: > >>> * Signaling >>> > > >>> Different QoSMs can nicely interwork if >>> a) the QoS NSLP or the QSPEC document mandates a single signaling mode >>> b) all QoSMs "support" all signaling modes. >>> By support I mean that they describe what needs to be done in the >>> > different cases. > >>> Returning a failure might also be a possible option. >>> > > >>> While all possible signaling modes are described in the QSPEC document >>> I couldn't see a mandate for a QoSM document to also describe what todo >>> > for all the signaling modes. > > >>> [[ I call the signaling exchanges and respective message processing >>> rules in this context "signaling modes" lacking a better term.]] >>> > > Regarding signaling the NSIS WG introduced the concept of QOSM to be able > to support your b) option: > >>> b) all QoSMs "support" all signaling modes. >>> By support I mean that they describe what needs to be done in the >>> > different cases. > >>> Returning a failure might also be a possible option. >>> > > Best Regards, > Georgios > > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: woensdag 3 januari 2007 22:22 >> To: David R Oran >> Cc: nsis@ietf.org >> Subject: Re: [NSIS] QSPEC Template Draft Review >> >> Hi Dave, >> >> thanks for your quick response. >> >> David R Oran wrote: >> >>> On Jan 3, 2007, at 6:16 AM, Hannes Tschofenig wrote: >>> >>> >>>> Hi David, >>>> >>>> David R Oran wrote: >>>> >>>>> On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote: >>>>> >>>>> >>> [snip] >>> >>>>>> With this respect, the abstract and Section 5.4 regarding >>>>>> extensibility have to be updated. >>>>>> >>>>>> Usage of RFC 2119 language is a bit challenging in this document >>>>>> given that it means "If a QoSM decides to use a certain >>>>>> >> parameter >> >>>>>> then it must implement the parameter as mentioned in this >>>>>> document.". Do you need to a normative reference since >>>>>> >> it is just a >> >>>>>> template of QoS parameters? >>>>>> >>>>>> >>>>> I think so, at least in the sense that the parameters have well >>>>> defined semantics that are not dependent of any local >>>>> >> QoSM's whim to >> >>>>> redefine. If a given QNI says "I want delay variance >>>>> >> under 200ms and >> >>>>> if you can't give it to me I don't want my traffic admitted" then >>>>> the QoSM can't just ignore that or decide that it means something >>>>> else. For example if an RMF in one of the nodes allows an >>>>> >> EF queue >> >>>>> for other traffic with a maximum depth more than 200ms >>>>> >> then there's >> >>>>> no way it can admit the traffic needing a delay variance >>>>> >> under 200ms. >> >>>> I see it differently. The current collection of parameters are >>>> available to a QoSM designer. They can decide whether to use it or >>>> define something new. Every QoSM is allowed to define >>>> >> whatever they >> >>>> want. If I want to define a IEEE 802.16e QoSM then nobody should >>>> prevent me from doing so. I would want to use the >>>> >> parameters that are >> >>>> available in the IEEE spec. For example, when I tried to map the >>>> existing QSPEC parameters to the existing IEEE 802.16e parameters >>>> then I noticed that they are similar but not exactly the >>>> >> same. Hence, >> >>>> even if they look similar I would like to define my own >>>> >> based on .16e >> >>>> rather than reusing the QSPEC parameters. >>>> >>>> >>> And herein lies the core of the issue that has bedeviled >>> >> the working >> >>> group lately (and perhaps since inception, I don't know since my >>> participation has been sporadic). I see the purpose of NSIS >>> >> to define >> >>> a signaling scheme which works end-to-end on the Internet, >>> >> rather than >> >>> just an architecture and template for defining a set of >>> non-interoperable custom, per-network QoS signaling and description >>> schemes. To do this there have to be a core set of QoS parameters >>> which are universally understood from which you can build the vast >>> majority of QoS schemes. Let's face it, the number of feasible data >>> plane queueing/scheduling/policing/shaping algorithms is in >>> >> fact not >> >>> that large. >>> I think it has yet to be demonstrated that the network-specific QoS >>> parameter cannot in all but some corner cases be >>> >> represented using the >> >>> parameters we have come up with. Most of the argument has >>> >> been based >> >>> on RMFs that wish to be "simpler" than the general case in >>> >> which the >> >>> exact constraints and traffic model parameters of the source are >>> enforced. This is fine, but it does NOT mean that we need a >>> free-for-all in terms of parameter space. It is in fact why we >>> restructured the Qspec parameters so that the user could be >>> >> explicit >> >>> and control what is advisory and what is mandatory for admission. >>> >>> Even more important, we don't need a free-for-all in the >>> >> operation of >> >>> QoS NSLP. The idea that the QoSM can change the signaling state >>> machines for the NSLP is quite scary to me, which is why I >>> >> suggested >> >>> the language which said a QOSM isn't permitted to redefine >>> >> the way QOS >> >>> NSLP works. >>> >>> It's pretty clear that a number of people on the WG >>> >> disagree with this >> >>> position. That's fine - I said I'd shut up if the WG >>> >> consensus went a >> >>> different way. However, I do detect the weight of opinion >>> >> being closer >> >>> to what I wrote above. I'll leave it to the WG chair to assess this. >>> >> There are a few aspects that need to be discussed here. >> >> I read the QSPEC draft many, many times already (and >> different versions). Whenever I read through the abstract and >> the introduction I had the impression that I understood what >> the rest of the document is going to contain. I was always >> wrong. This time I was wrong as well. >> >> It shouldn't be too difficult to tell the reader what the >> document wants to accomplish. If I don't understand it then >> how should someone else (slightly ignoring the fact that >> everyone else might be smarter)? >> >> Let us separate the signaling from the QoS parameter story >> since they are largely a different subject. Let us try to >> understand what interoperability means. >> >> * Signaling >> >> Different QoSMs can nicely interwork if >> a) the QoS NSLP or the QSPEC document mandates a single signaling mode >> b) all QoSMs "support" all signaling modes. >> By support I mean that they describe what needs to be done in >> the different cases. Returning a failure might also be a >> possible option. >> >> While all possible signaling modes are described in the QSPEC >> document I couldn't see a mandate for a QoSM document to also >> describe what todo for all the signaling modes. >> >> [[ I call the signaling exchanges and respective message >> processing rules in this context "signaling modes" lacking a >> better term.]] >> >> * QoS Parameters >> >> From an interoperability point of view it would be ideal to >> have a single QoSM that is understood by everyone. I got the >> impression that this was the initial goal of the QSPEC >> document. Having a core set of parameters that are understood >> by everyone and a few optional parameters was an interesting >> idea, I thought. [[ I was never really 100 % convinced that >> it can actually work but that's another story. I personally >> was just unhappy about the choice of mandatory parameters. ]] >> >> Another alternative is to define mappings from one QoSM to >> another one.This is done today already but there are no >> procedures and documents in the NSIS working group for >> defining these mappings. With this approach every QoSM can >> essentially define whatever they want if a reasonable mapping exists. >> >> Having a mapping is obviously better than just looking at >> mandatory-to-understand parameters (and ignoring the optional >> parameters). >> >> From your description it seems that the QSPEC contains a >> number of parameters that are supposed to be complete and >> MUST be used by future QoSMs. To avoid interoperability >> problems QoSMs ideally must never not introduce parameters. >> Since some of QSPEC authors are also QoSM authors they >> ensured that their QoSM is nicely supported. To allow the >> end-to-end story to work it is necessary to consider today's >> access networks and the QoS parameters that are being used >> there. Is someone ever wants to use a path-coupled signaling >> solution then two approaches are possible >> a) the end host already uses a QoS signaling protocol like >> RSVP or NSIS >> b) the end host uses a link layer protocol (with QoS >> extensions) towards the access network and the network >> triggers the NSIS signaling exchange [A combination of the >> two is also possible.] >> >> In any case I guess you have to deal with the QoS parameters >> of the specific link layer. I wonder whether someone has >> looked at these issues already and whether the QSPEC QoS >> parameter and local QoSM model supports this extensibility. >> >> As an example, the Traffic Priority as defined in IEEE802.16e >> has 8 priority levels. What would I do? This parameter does >> not correspond to anything in the QSPEC document at the moment. >> >> The typical question I have is: I want to implement QoSM X. >> What do I have to implement from the QSPEC draft? >> >> [ A minor technical issue: Are there problems (in the IETF document >> processing) if normative references point to documents that >> are non-IETF documents? ] >> >> I am not sure I understood your comment regarding " >> The idea that the QoSM can change the signaling state >> machines for the NSLP is quite scary to me, which is why I >> suggested the language which said a QOSM isn't permitted to >> redefine the way QOS NSLP works. >> " >> >> >>>> The idea of a template is to offer a set of parameters >>>> >> that might be >> >>>> used when building QoSMs. With a specific QoSM some of these QSPEC >>>> parameters are hopefully implemented. >>>> >>>> >>> If the QSPEC specification is viewed as just a >>> >> template/base schema, >> >>> then I think we will have failed pretty miserably. We will have the >>> illusion of interoperability and not real interoperability. >>> >> This is what I read from the abstract and the introduction. Maybe it >> would be appropriate to delete the term "template" from the document. >> >> >> >>>> The question with the parameter selection is therefore: Are these >>>> useful parameters that might be reused by a number of QoSMs? >>>> >>>> >>> I'd turn it around and say "given that end-to-end QoS >>> >> interoperability >> >>> is a main goal of NSIS, does the particular QoSM achieve this well >>> enough to admit the traffic as requested by the QNI". If the QoSM >>> can't do what the user asked then it's the job of the QSPEC >>> >> semantics >> >>> and the QOS NSLP signaling machinery to not admit the traffic, and >>> tell the user why. It's up to the user/QNI to formulate QoS >>> >> requests >> >>> that are adequate to the needs of the application but which >>> >> have high >> >>> probability of being admitted under conditions where there are >>> adequate resources. QoS NSLP and Qspecs (as we have them in the >>> current drafts) give us the tools to accomplish this. If we >>> >> treat the >> >>> Qspec parameters just as "useful suggestions" I think we will have >>> pretty definitely sacrificed this goal for the Internet, >>> >> which is what >> >>> NSIS exists for. >>> >> This sounds like a very nice. When it comes to the details >> things get a >> bit more difficult. >> >> >>>>>> Regarding processing description: >>>>>> >>>>>> I never understood why the processing description is >>>>>> >> also provided >> >>>>>> in this document. I provided this comment already in the >>>>>> >> past but >> >>>>>> obviously the authors didn't like it too much. Not a big deal >>>>>> though. In some sense it is largely a matter of taste anyway. >>>>>> Instead of reducing the processing description it was actually >>>>>> enhanced; I was surprised to find a QSPEC encapsulation >>>>>> >> technique >> >>>>>> in Section 5.1. I always thought that this is a QoS NSLP >>>>>> >> draft aspect. >> >>>>> Well, this was the subject of a spirited debate among >>>>> >> some of the WG >> >>>>> participants. I didn't particularly like the way it >>>>> >> turned out, but >> >>>>> there seems to be rough consensus that QSPEC >>>>> >> encapsulation should be >> >>>>> part of other QSPEC itself. >>>>> >>>> I must have missed this discussion. If people like it that >>>> >> way then >> >>>> it should be fine. >>>> >>>> >>>>>> This is probably a document writing style and a matter of >>>>>> worksplit between the QoS NSLP and the QSPEC document authors. A >>>>>> deployable solution requires GIST, the QoS NSLP, the QSPEC and a >>>>>> QoSM (and the AAA part) and a reader might want to read >>>>>> >> all these >> >>>>>> documents anyway. >>>>>> >>>>>> Section 5.3 should be informative only; no RFC 2119 >>>>>> >> language since >> >>>>>> the current text just outlines all possible combinations. >>>>>> Currently, one can sometimes find RFC 2119 language in some >>>>>> subsections. The QoSMs provide the normative text and >>>>>> >> may restrict >> >>>>>> the available combinations. [[Note that this might raise >>>>>> interesting problems given that different QoSMs implement a >>>>>> different signaling behavior and interworking between different >>>>>> QoSMs might be really challenging. >>>>>> >>>>> This was one of the reasons I proposed restricting the >>>>> >> variability >> >>>>> among QOSMs to be in the RMF only and not to allow different >>>>> signaling semantics. I lost that one. >>>>> >>>> Another alternative is that the QSPEC document demands that QoSM >>>> documents define all possible signaling behaviors. Then it >>>> >> would be >> >>>> fine as well. It would make the QoSMs more complicated. I, >>>> >> btw, was >> >>>> never in favor of receiver-initiated signaling behavior since the >>>> authorization story is really mood. >>>> >>>> >>>> Do you agree with me that RFC 2119 language shouldn't be used in >>>> Section 5.3? >>>> >>>> >>> I see no problem with the (quite limited) use of RFC2119 >>> >> language in >> >>> the places in section 5.3 where it appears. It seems quite >>> >> appropriate >> >>> to me,. >>> >>> >> I need to read through each paragraph to determine what the >> implications >> are. >> >> >>>>>> For example, what happens if a receiver-initiated >>>>>> >> reservation meets >> >>>>>> a domain with a QoS model that only supports sender-initiated >>>>>> reservations.]] >>>>>> >>>>>> >>>>> In order to make this work I think you have to have recursive >>>>> signaling at the edge of the domain. >>>>> >>>> Correct. >>>> >>>> As an example, in RMD these different cases got considered. >>>> >>>> If you only assume that sender-initiated reservations exist then >>>> documents are simpler since they obviously don't need to >>>> >> consider all >> >>>> the different cases. >>>> We noticed this problem already with the mobility document >>>> >> where the >> >>>> receiver-initiated reservations are just painful. >>>> >>>> >>> But this is up to the applications which is more >>> >> useful/natural, no? >> >>> If you are saying that receiver-initiated is harder to >>> >> achieve under >> >>> some circumstances, then sure. Applications should be cognizant of >>> that and use receiver-initiated only when they can't >>> >> conveniently use >> >>> sender-initiated. Conversely, some applications (e.g. multicast and >>> multi-unicast) can get all tied up in knots with sender-initiated >>> reservations. But to say that interoperability fails >>> >> because some QoSM >> >>> decides receiver-initiated reservations are a pain and >>> >> redefines QOS >> >>> NSLP to eliminate them over its domain strikes me as a very poor >>> tradeoff. >>> >> I agree with your statement about multicast QoS reservations. >> I wonder >> whether someone wants to use path-coupled QoS signaling for multicast >> communication. >> >> >> Ciao >> Hannes >> >> >>> Cheers, Dave. >>> >>> >>>>>> That's it for now. I will provide more detailed comments later. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> >>>> 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 Thu Jan 04 07:15:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2RV4-00019P-6R; Thu, 04 Jan 2007 07:15:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2RV2-00017k-RS for nsis@ietf.org; Thu, 04 Jan 2007 07:15:12 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2RUw-0007qm-Cj for nsis@ietf.org; Thu, 04 Jan 2007 07:15:12 -0500 Received: (qmail invoked by alias); 04 Jan 2007 12:15:03 -0000 Received: from p549879CC.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.121.204] by mail.gmx.net (mp026) with SMTP; 04 Jan 2007 13:15:03 +0100 X-Authenticated: #29516787 Message-ID: <459CEFD5.6010808@gmx.net> Date: Thu, 04 Jan 2007 13:15:17 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt 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: 884d655656c6d298dae25b0122479d16 Cc: "john.loughney@nokia.com" , "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, Georgios Karagiannis wrote: > Hi John > > I mainly disagree with the following three points that were never > discussed before: > > Point_1):Removed the QSPEC control information > --------------------------------------------------------------- > Jerry mentioned in a previous e-mail that this QSPEC control information > concept is not removed but it is renamed to Traffic Handling Directives. > > If that is the case then Jerry will have to use the same definitions for > the > QSEPC control information as used in Section 5.3.1 of: > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > Thus my proposal is to change section 4.3.3 as given in v.13 of the QSEPC > template draft and include the general concept of the QSPEC control > information that was given in Section 5.3.1 of version 12 of the QSEPC > template draft. Note that the name can be changed but the semantics > should remain the same. Thus please chnage Section 4.3.3 as follows: > > FROM: > > 4.3.3 Traffic Handling Directives > > The parameter describes how the QNE will process > excess traffic, that is, out-of-profile traffic. Excess traffic MAY > be dropped, shaped and/or remarked. The excess treatment parameter is > initially set by the QNI and cannot be overwritten. > > > INTO: > > 4.3.3 Traffic Handling Directives > > Traffic Handling Directives are used for signaling QOSM RMF functions > not defined in QoS NSLP. It enables building new RMF functions > required by a QOSM within a QoS NSLP signaling framework, such as > specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. > > = > > The parameter describes how the QNE will process > excess traffic, that is, out-of-profile traffic. Excess traffic MAY > be dropped, shaped and/or remarked. The excess treatment parameter is > initially set by the QNI and is read-only. > > Do you worry about a potential loss of extensibility here? > ------------------------------- > > Point_2: dictates that encpasulation of the original initiator QSEPC > feature cannot be used in combination with the tunneling (parallel > session) feature. > > In the discussion that we have had in the nsis mailing list and during > the IETF meeting it was stated that both these features should be > possible, while now version 13 of the QSPEC template draft dicates that > these two feratures cannot be used togetherand at the same time by the > same QoS model. > As I mentioned in all the discussions the encapsulation of the original > QSPEC feature is needed to satisfy Requirement: > "5.4.2. It SHOULD be Possible to Add and Remove Local Domain > Information" given in: http://www.ietf.org/rfc/rfc3726.txt > Therefore the encapsulation (of the original initiator QSEPC into a local > QSPEC) feature should be seen as an independent feature and it should be > able to be used in combination with the tunneling (parallel session) > feature that is used for another goal. > > Thius my proposal is that it should be mentioned that even when the > tunneling (parallel session) feature is used, it is also allowed to use, > at the same time, the encapsulation (of the original initiator QSEPC > into a local QSPEC) feature in order to satisfy Requirement 5.4.2 of RFC > 3726. > How would this, for example, impact RMD? > --------------------------- > > Point_3: QSEPC template draft dictates which QOS-NSLP signaling features > should be used by QOS models. > > We have never discussed an agreed that the QSPEC template draft defines > how the QOS-NSLP functionality should be used by QoS models. This should > be defined by the QOS-NSLP draft. > Therefore, regarding this issue the QSPEC template draft should refer to > Section "3.1.2. QoS Models and QoS Specifications"" of: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt > > Therefore the QSPEC tempate draft should adpat the definitiojn of the QoS > models according to what Section 3.1.2 of the QOS-NSLP draft is saying > and refer to Section 3.1.2 of the QOS-NSLP draft. > > I guess this aspect refers to the previous discussion I had with Dave and with you subsequently. When reading through Section 3.1.2 of http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt I am sure that the QoS NSLP authors are going to re-write the section. Ciao Hannes > Best Regards, > Georgios > > > > > > > > On 12/23/2006, "john.loughney@nokia.com" > wrote: > > >> Hi all, >> >> When Jerry posted the draft with the change log, I basically noted >> that the changes were based upon previous discussions, on the >> mailing list and the meeting. >> >> I am unsure of the techincal issues that are being raised. Rather >> than get into a discussion of what was discussed or not, what I >> would like to understand better is more understanding what are >> the technical issues behind Georgios' issues. >> >> Additionally, I would like to hear from others about their opinions >> on this issue. >> >> thanks, >> John >> >> >>> -----Original Message----- >>> From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>> Sent: 22 December, 2006 20:12 >>> To: Georgios Karagiannis; nsis@ietf.org >>> Cc: Ash, Gerald R (Jerry), ALABS >>> Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt >>> >>> Georgios, >>> >>> It's not true as you and 2 others have stated that the changes >>> were not discussed. They were discussed, at length. For >>> example, the revised definition of QOSM was clearly stated and >>> discussed on the list, see >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.htm >>> l and also see all the list discussion following that post. >>> The revised definition and all the other changes were clearly >>> presented in the slides at IETF-67, see minutes and slides at >>> http://www3.ietf.org/proceedings/06nov/index.html. You can >>> listen to the complete IETF-67 presentation/discussion again >>> at >>> http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf >>> 67ch4-thu >>> -am.mp3. >>> >>> You can review the slides, meeting discussion, list >>> discussion, meeting minutes, and verify that for yourself. >>> >>> So the editors did not 'make up the changes without >>> discussion' as you and 2 others have suggested. That is >>> certainly wrong and I think you should acknowledge that. >>> >>> It is not useful going forward to debate the past, but >>> incendiary wrong statements should not go unanswered. >>> >>> Once again, I've responded to your technical comments, you can >>> comment further if you wish. >>> >>> It would be good for others to comment on the technical points. >>> >>> Jerry >>> >>> -----Original Message----- >>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>> Sent: Friday, December 22, 2006 11:36 AM >>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >>> Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt >>> >>> Hi Jerry >>> >>> The changes that are included in version 13 of the QSEPC >>> template draft regarding the QSPEC control information and the >>> limitations of the QoS models have never been discussed >>> because they were never stated clearly. >>> >>> If they would have been stated clearly then I would have sent >>> my comments at that time instead of sending them now! >>> >>> Furthermore, from what I have seen in v. 13 of the draft you >>> also have not solved the stacking issue, because you are >>> actually dictating that encapsulation cannot be combined and >>> used together with the tunneling (parallel sessions) method. >>> >>> >>> Best Regards, >>> Georgios >>> >>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>>>> Sent: vrijdag 22 december 2006 16:37 >>>>> To: Georgios Karagiannis; nsis@ietf.org >>>>> Cc: Ash, Gerald R (Jerry), ALABS >>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt >>>>> >>>>> Georgios, >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>>> Sent: Friday, December 22, 2006 9:13 AM >>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt >>>>>> >>>>>> Hi Jerry >>>>>> >>>>>> By just saying that "these changes are suggested by Dave in the >>>>>> e-mail" does not work. >>>>>> >>>>>> The proposal of Dave was not clear on the QoS model changes >>>>>> >>>>> that you >>>>> >>>>>> wanted to do. >>>>>> >>>>> All changes to the draft have been extensively discussed on >>>>> >>>> the list >>>> >>>>> and are all contained in the slides presented at IETF-67. >>>>> >>> You were >>> >>>>> there at >>>>> IETF-67 and participated in all the list discussion. The >>>>> >>>> summary of >>>> >>>>> changes in the slides is quite specific and clear, take >>>>> >>>> another look. >>>> >>>>> Have a look at the minutes as well >>>>> http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt. The only >>>>> disagreements noted are with regard to stacking, which is an issue >>>>> that we later resolved on the list. Go back and check it out. >>>>> >>>>> >>>>>> Now I understand which changes you want to include in the QSPEC >>>>>> template draft. >>>>>> This is also the reason of disagreeing with you now and sending >>>>>> comments to the nsis list. >>>>>> >>>>> I responded to your further comments, see below. Others are >>>>> encouraged to comment as well. >>>>> >>>>> Jerry >>>>> >>>>> >>>>>> Furthermore, note that the QOS-NSLP draft defines which >>>>>> >>>>> capabilities >>>>> >>>>>> should be supported by the QoS models and not the QSPEC template >>>>>> draft. >>>>>> >>>>>> Best Regards, >>>>>> Georgios >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>>>>>> Sent: vrijdag 22 december 2006 15:01 >>>>>>> To: Georgios Karagiannis; nsis@ietf.org >>>>>>> Cc: Ash, Gerald R (Jerry), ALABS >>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt >>>>>>> >>>>>>> Georgios, >>>>>>> >>>>>>> See below. >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>>>>> Sent: Thursday, December 21, 2006 9:22 AM >>>>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >>>>>>>> Cc: 'Attila Bader (IJ/ETH)'; 'Lars Westberg' >>>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt >>>>>>>> >>>>>>>> Hi Jerry >>>>>>>> >>>>>>>> Please see below! I have severe concerns about some changes >>>>>>>> >>>>>>> that have >>>>>>> >>>>>>>> been done in the QSPEC template draft. >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>>>>>>>> Sent: woensdag 20 december 2006 14:20 >>>>>>>>> To: Georgios Karagiannis; nsis@ietf.org >>>>>>>>> Cc: Ash, Gerald R (Jerry), ALABS >>>>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt >>>>>>>>> >>>>>>>>> Hi Georgios, >>>>>>>>> >>>>>>>>> See below. >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Georgios Karagiannis >>>>>>>>>> >>> [mailto:karagian@cs.utwente.nl] >>> >>>>>>>>>> Sent: Wednesday, December 20, 2006 5:26 AM >>>>>>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >>>>>>>>>> Subject: Comments on draft-ietf-nsis-qspec-13.txt >>>>>>>>>> >>>>>>>>>> Hi Jerry >>>>>>>>>> >>>>>>>>>> Here are my comments on draft-ietf-nsis-qspec-13.txt: >>>>>>>>>> >>>>>>>>>> Comment_1: >>>>>>>>>> -------------- >>>>>>>>>> Please reinclude the concept of QSPEC control >>>>>>>>>> >>>>>>> information that was >>>>>>> >>>>>>>>>> included in all previous versions of the QSPEC >>>>>>>>>> >>>>> template draft. >>>>> >>>>>>>>>> In >>>>>>>>>> >>>>>>>>>> >>>> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt: this >>>> >>>>>>>>>> concept was described in Section 5.1. >>>>>>>>>> >>>>>>>>> Please see previous email comment on QSPEC control >>>>>>>>> >>>>> information. >>>>> >>>>>>>> Georgios: >>>>>>>> In order to emphasize the need of having QSPEC control >>>>>>>> >>>>>> information >>>>>> >>>>>>>> parameters I would however appreciate if the name of >>>>>>>> >>>>>>> Section 4.3.3 >>>>>>> >>>>>>>> is changed >>>>>>>> From: >>>>>>>> 4.3.3 Traffic Handling Directives >>>>>>>> INTO: >>>>>>>> 4.3.3 QSPEC control information >>>>>>>> >>>>>>> The updated QSPEC parameter terminology/semantics are as >>>>>>> >>>>> suggested >>>>> >>>>>>> by Dave Oran (see slides presented at IETF-67 >>>>>>> http://www3.ietf.org/proceedings/06nov/index.html). I >>>>>>> >>>> think the >>>> >>>>>>> current terminology is more clear/descriptive of the QSPEC >>>>>>> parameters so I don't favor going backwards to less clear >>>>>>> terminology. I was never clear on why we used the 'control >>>>>>> information' terminology in the first place, e.g., I >>>>>>> >>>> don't think >>>> >>>>>>> it's a very good descriptor of the 'excess treatment' >>>>>>> >>> parameter. >>> >>>>>>> Perhaps Dave can comment on this point also when he >>>>>>> >>>> gets a chance. >>>> >>>>>>>>>> Comment_2: >>>>>>>>>> ----------- >>>>>>>>>> >>>>>>>>>> Section 6.1: >>>>>>>>>> Please reintroduce the format that is required >>>>>>>>>> >>> in order to >>> >>>>>>>>> specify the >>>>>>>>> >>>>>>>>>> QSPEC control information, see: >>>>>>>>>> Section 7.1 of: >>>>>>>>>> >>>>>>>>>> >>>>>> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt >>>>>> >>>>>>>>> Please see previous email comment on QSPEC control >>>>>>>>> >>>>> information. >>>>> >>>>>>>> Georgios: If you rename section 4.3.3 to QSPEC control >>>>>>>> >>>>>> information >>>>>> >>>>>>>> then I think that reformatting of section 6.1 is not needed. >>>>>>>> Please add the proposed sentence by Dave (but change >>>>>>>> >>> the term >>> >>>>>>>> "handling directives" to "QSPEC control Information"). I am >>>>>>>> >>>>>>> not sure >>>>>>> >>>>>>>> where it is better to add this sentence, maybe in >>>>>>>> >>> Section 5.4. >>> >>>>>>>> "QoSMs are free, subject to IANA registration and review >>>>>>>> >>>>>> rules, to >>>>>> >>>>>>>> extend QSPECs by adding parameters of any of the kinds >>>>>>>> >>>>>> supported by >>>>>> >>>>>>>> the standard QSPEC. This includes traffic description >>>>>>>> >>>>> parameters, >>>>> >>>>>>>> constraint parameters and QSPEC control information. >>>>>>>> >>>>>> QoSMs are not >>>>>> >>>>>>>> permitted, however, to reinterpret or redefine the >>>>>>>> >>>>> standard QSPEC >>>>> >>>>>>>> parameters specified in this document" >>>>>>>> >>>>>>> Yes, the text suggested by Dave will be added. >>>>>>> >>>>>>> >>>>>>>>>> Comment_3: >>>>>>>>>> ---------- >>>>>>>>>> Section 4.1 :QoS Models >>>>>>>>>> The definition of the QoS model is not complete. An >>>>>>>>>> >>>>> important >>>>> >>>>>>>>>> sentence that was used in the previous version of the >>>>>>>>>> >>>>>> draft is >>>>>> >>>>>>>>>> removed. >>>>>>>>>> Please add the following sentence to the definition >>>>>>>>>> >>>>>> of the QoS >>>>>> >>>>>>>>>> Model >>>>>>>>>> (QOSM): >>>>>>>>>> >>>>>>>>>> The same as described above have to be applied in >>>>>>>>>> >>>>>> this section. >>>>>> >>>>>>>>>> After the following sentence: >>>>>>>>>> >>>>>>>>>> "A QOSM specification MAY include the following:" >>>>>>>>>> >>>>>>>>>> include the following bullet: >>>>>>>>>> "- it specifies how to use QOS NSLP to signal for >>>>>>>>>> >>>> this QOSM" >>>> >>>>>>>>> That sentence was removed in Dave's proposed QOSM >>>>>>>>> >>>>>>> re-definition, see >>>>>>> >>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht >>>> >>>>>>>>> ml. It was unclear what that sentence meant, QoS-NSLP >>>>>>>>> >>>>>>> specifies how >>>>>>> >>>>>>>>> to signal, not QOSM specifications, so the sentence >>>>>>>>> >>>>> was removed. >>>>> >>>>>>>>> I believe the sentence was intended to mean that when >>>>>>>>> >>>>> QoS NSLP >>>>> >>>>>>>>> allows various options to be selected, a QOSM should >>>>>>>>> >>>>> be able to >>>>> >>>>>>>>> determine which option is used. For that purpose the >>>>>>>>> >>>>> following >>>>> >>>>>>>>> sentence was added in Section 4.1: >>>>>>>>> >>>>>>>>> " A QOSM specification MAY include the following: >>>>>>>>> ... >>>>>>>>> - can state which QoS-NSLP options a QOSM wants to >>>>>>>>> >>>>>> use, when >>>>>> >>>>>>>>> several options are available for a QOSM (e.g., >>>>>>>>> >>>>>>> local QSPEC to >>>>>>> >>>>>>>>> either be a) tunneled or b) encapsulate >>>>>>>>> >>>>> initiator QSPEC)." >>>>> >>>>>>>>> Also, to avoid any misinterpretation that QOSMs are free >>>>>>>>> >>>>>>> to specify >>>>>>> >>>>>>>>> additional constraints, state machines, protocol data, >>>>>>>>> >>>>>>> etc. for NSLP >>>>>>> >>>>>>>>> beyond that which is specific in the QoS NSLP >>>>>>>>> >>>>>> specification, the >>>>>> >>>>>>>>> following was added to Section 4.1: >>>>>>>>> >>>>>>>>> " QOSMs affect the operation of the RMF in NSIS-capable >>>>>>>>> >>>>>>> nodes, the >>>>>>> >>>>>>>>> information carried in QSPEC objects, and may under some >>>>>>>>> circumstances (e.g. aggregation) cause a separate NSLP >>>>>>>>> session to be >>>>>>>>> instantiated by having the RMF as a QNI. QOSMs >>>>>>>>> >>>> all utilize >>>> >>>>>>>>> the common >>>>>>>>> data, state machines, and APIs of the underlying NSIS >>>>>>>>> protocols and >>>>>>>>> are not expected to re-define or extend these in >>>>>>>>> >>>> any way." >>>> >>>>>>>> Georgios: >>>>>>>> Regarding the sentence in Section 4.1: >>>>>>>> "QOSMs all utilize >>>>>>>> the common data, state machines, and APIs of the >>>>>>>> >>>>> underlying NSIS >>>>> >>>>>>>> protocols and are not expected to re-define or extend >>>>>>>> >>>>>> these in any >>>>>> >>>>>>>> way." >>>>>>>> >>>>>>>> This sentence restricts the possibility of QoS model to use >>>>>>>> >>>>>>> RMF states >>>>>>> >>>>>>>> and data that are not been defined in neither >>>>>>>> >>>> QoS-NSLP or QSPEC. >>>> >>>>>>>> This sentence should be removed. >>>>>>>> >>>>>>> I disagree. The quoted text was introduced by Dave Oran >>>>>>> >>>>> in addition >>>>> >>>>>>> to removing the phrase implying that a QOSM could specify >>>>>>> >>>>> signaling >>>>> >>>>>>> protocol changes, and I agree with this. >>>>>>> Any changes/extensions to the signaling protocol or state >>>>>>> >>>>> machines >>>>> >>>>>>> are within the scope of QoS-NSLP draft and not the QSPEC >>>>>>> >>>>> draft or a >>>>> >>>>>>> QOSM specification draft. I think you have noted that >>>>>>> >>>>> also in your >>>>> >>>>>>> subsequent posting at >>>>>>> >>>>>>> >>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07352.html. >>>> >>>>>>> If any extensions are required to the NSIS signaling >>>>>>> >>>>> protocol as a >>>>> >>>>>>> result of the 'severe change on QoS Model definition and >>>>>>> capabilities' >>>>>>> you have noted, those proposed changes/extensions should be >>>>>>> addressed to the QoS NSLP draft IMO. >>>>>>> >>>>>>> Perhaps Dave can comment here also when he gets a chance. >>>>>>> >>>>>>> >>>>>>>>>> Comment_4: >>>>>>>>>> ------------- >>>>>>>>>> Section 5.1 Local QSPEC definition and processing >>>>>>>>>> >>>>>>>>>> By reading this section it gives the impression >>>>>>>>>> >>>>> that the two >>>>> >>>>>>>>>> methods >>>>>>>>>> a) and b) cannot be used by the same QoS model. >>>>>>>>>> Method a): translate the >>>>>>>>>> initiator QSPEC into a local QSPEC and encapsulate the >>>>>>>>>> >>>>>>> initiator >>>>>>> >>>>>>>>>> QSPEC in the RESERVE message Method b): b) tunnel the >>>>>>>>>> >>>>>> initiator >>>>>> >>>>>>>>>> QSPEC through the local domain and reserve resources by >>>>>>>>>> >>>>>>> generating >>>>>>> >>>>>>>>>> a new RESERVE message through the local domain >>>>>>>>>> >>>>> containing the >>>>> >>>>>>>>>> local QSPEC. >>>>>>>>>> >>>>>>>>>> Note that according to the discussions that we have had >>>>>>>>>> >>>>>>> until now >>>>>>> >>>>>>>>>> method a) should be able to be used in combination with >>>>>>>>>> >>>>>>> method b) >>>>>>> >>>>>>>>>> by the same QoS model for the situation that the >>>>>>>>>> >>>>> local QSPEC >>>>> >>>>>>>>>> encapsulates the initiator QSPEC in order to satisfy >>>>>>>>>> >>>>>>> requirement >>>>>>> >>>>>>>>>> 5.4.2 that is specified in RFC 3726, see: >>>>>>>>>> http://www.ietf.org/rfc/rfc3726.txt >>>>>>>>>> >>>>>>>>>> Please add the following sentence at the end of >>>>>>>>>> >>> the first >>> >>>>>>>>>> paragraph of Section 5.1. >>>>>>>>>> "Note that when method b) is used, the >>>>>>>>>> >>>> encapsulation of the >>>> >>>>>>>>>> initiator QSPEC into a local QSPEC should also be >>>>>>>>>> >>>>>> possible when >>>>>> >>>>>>>>>> the local QoS model needs to satisfy Requirement >>>>>>>>>> 5.4.2 specified in RFC 3726, by adding and >>>>>>>>>> >>> removing local >>> >>>>>>>>>> QOSM-specific Control Information parameters on >>>>>>>>>> >>>> top of the >>>> >>>>>>>>>> initiator QSPEC." >>>>>>>>>> >>>>>>>>> Your comment here is not clear to me. It would help to >>>>>>>>> >>>>>>> provide an >>>>>>> >>>>>>>>> example to illustrate what you are trying to accomplish. >>>>>>>>> >>>>>>> It seems >>>>>>> >>>>>>>>> that you are trying to specify QoS-NSLP functionality, >>>>>>>>> >>>>>>> rather than >>>>>>> >>>>>>>>> QSPEC functionality. If so, that functionality should be >>>>>>>>> >>>>>>> specified >>>>>>> >>>>>>>>> in the QoS-NSLP draft rather than the QSPEC draft, >>>>>>>>> >>>>> perhaps the >>>>> >>>>>>>>> QoS-NSLP authors can comment. >>>>>>>>> >>>>>>>> Georgios: >>>>>>>> No I am not trying to define QOS-NSLP functionality. >>>>>>>> This is related to QSPEC control information that has to be >>>>>>>> >>>>>>> carried by >>>>>>> >>>>>>>> end-to-end messages. >>>>>>>> What I am trying to say is that all the discussion that >>>>>>>> >>>>>> we have had >>>>>> >>>>>>>> regarding the encapsulation of the QSPEC object were >>>>>>>> >>>>>>> associated with >>>>>>> >>>>>>>> requirement 5.4.2 of RFC 3726, see below: >>>>>>>> >>>>>>>> ----------------- >>>>>>>> "5.4.2. It SHOULD be Possible to Add and Remove >>>>>>>> >>> Local Domain >>> >>>>>>>> Information >>>>>>>> >>>>>>>> It SHOULD be possible to add and remove local >>>>>>>> >>>> scope elements. >>>> >>>>>>>> Compared to Requirement 5.3.5 this requirement does use >>>>>>>> >>>>>>> the normal >>>>>>> >>>>>>>> signaling process and message exchange for >>>>>>>> >>>> transporting local >>>> >>>>>>>> information. For example, at the entrance to a >>>>>>>> >>>>> domain, domain- >>>>> >>>>>>>> specific information is added information is added, which >>>>>>>> is used in >>>>>>>> this domain only, and the information is removed >>>>>>>> >>>> again when a >>>> >>>>>>>> signaling message leaves the domain. The motivation >>>>>>>> >>>>> is in the >>>>> >>>>>>>> economy of re-using the protocol for domain internal >>>>>>>> >>>>>> signaling of >>>>>> >>>>>>>> various information pieces. Where additional >>>>>>>> >>>>>>> information is needed >>>>>>> >>>>>>>> within a particular domain, it should be possible to >>>>>>>> >>>>>>> carry this at >>>>>>> >>>>>>>> the same time as the end-to-end information.", >>>>>>>> >>>> from RFC 3726 >>>> >>>>>>>> ------------------ >>>>>>>> Thus what I am saying is: >>>>>>>> Please add the following sentence at the end of the first >>>>>>>> >>>>>>> paragraph of >>>>>>> >>>>>>>> Section 5.1. >>>>>>>> >>>>>>>> "Note that when method b) is used, the encapsulation of the >>>>>>>> >>>>>>> initiator >>>>>>> >>>>>>>> QSPEC into a local QSPEC should also be possible when the >>>>>>>> >>>>>> local QoS >>>>>> >>>>>>>> model needs to satisfy Requirement >>>>>>>> 5.4.2 specified in RFC 3726, by adding and removing local >>>>>>>> QOSM-specific Control Information parameters on top of the >>>>>>>> >>>>>>> initiator >>>>>>> >>>>>>>> QSPEC." >>>>>>>> >>>>>>> First, the suggested text isn't clear. If method b) is used >>>>>>> (tunneling) then presumably method a) is not also used at >>>>>>> >>>>> the same >>>>> >>>>>>> time. However, the phrasing of the above makes it >>>>>>> >>>> sound that way. >>>> >>>>>>> Second, an example would help here. I presume you are >>>>>>> >>>> referring >>>> >>>>>>> e.g., to RMD adding 'control information' (i.e., 'handling >>>>>>> directive') parameters to the local QSPEC that are not >>>>>>> >>>>> included in >>>>> >>>>>>> the initiator QSPEC. I think the requirement would be >>>>>>> >>>>> that the RMD >>>>> >>>>>>> QOSM provides a local QSPEC that is consistent with the >>>>>>> >>>> initiator >>>> >>>>>>> QSPEC, as we agreed on the list (see also slide 8 of >>>>>>> >>>> the IETF-67 >>>> >>>>>>> presentation). >>>>>>> >>>>>>> If the local QSPEC introduces functionality >>>>>>> >>>> inconsistent with the >>>> >>>>>>> initiator QSPEC by appending the handling directive >>>>>>> >>>>> parameters, then >>>>> >>>>>>> it is not allowed. >>>>>>> >>>>>>> >>>>>>>>>> Comment_5: >>>>>>>>>> ----------- >>>>>>>>>> Section 5.1, last paragraph: >>>>>>>>>> >>>>>>>>>> Please change the following: >>>>>>>>>> "For example, RMD can define a local QSPEC that >>>>>>>>>> >>>>>> contains TMOD = >>>>>> >>>>>>>>>> bandwidth (sets r=p, b/m to large)." >>>>>>>>>> >>>>>>>>>> Into: >>>>>>>>>> "For example, in RMD the TMOD parameters contained in >>>>>>>>>> >>>>>>> the original >>>>>>> >>>>>>>>>> initiator QSPEC are mapped into the equivalent TMOD >>>>>>>>>> >>>>> parameter >>>>> >>>>>>>>>> representing only the peak bandwidth in the local QSPEC." >>>>>>>>>> >>>>>>>>> OK with me. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Comment_6: >>>>>>>>>> ------------- >>>>>>>>>> In Section 5.3.1, 5.3.2, 5.3.3 the rules that have to >>>>>>>>>> >>>>>>> be followed >>>>>>> >>>>>>>>>> regarding the QSPEC control information are not given: >>>>>>>>>> >>>>>>>>>> Please include the following paragraph at the end of >>>>>>>>>> >>>>>>> this section: >>>>>>> >>>>>>>>>> "Regarding QSPEC Control Information, the default rule >>>>>>>>>> >>>>>>> is that all >>>>>>> >>>>>>>>>> QSPEC 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. When >>>>>>>>>> >>>>>>> traveling in the >>>>>>> >>>>>>>>>> RESPONSE message, all QSPEC Control Information >>>>>>>>>> >>>>>>> parameters are >>>>>>> >>>>>>>>>> read-only. Note that a QOSM specification may >>>>>>>>>> >>>>>> define its own >>>>>> >>>>>>>>>> QOSM-specific Control Information parameters and >>>>>>>>>> processing rules." >>>>>>>>>> >>>>>>>>> Please see previous email comment on QSPEC control >>>>>>>>> >>>>> information. >>>>> >>>>>>>> Georgios: I think that a description of how the >>>>>>>> >>> QSPEC control >>> >>>>>>>> information is handled is needed. >>>>>>>> >>>>>>> Please see above comments on 'control information' terminology. >>>>>>> >>>>>>> Thanks, >>>>>>> Jerry >>>>>>> >>>>>>> >>>>>>>>>> Comment_7: >>>>>>>>>> ------------ >>>>>>>>>> Section 6.1: >>>>>>>>>> I do not understand the second sentence from the >>>>>>>>>> >>> below two >>> >>>>>>>>>> sentences: >>>>>>>>>> "N Flag: Not-supported QSPEC parameter flag (see >>>>>>>>>> >>>>>> Section 5.2.2). >>>>>> >>>>>>>>>> For QSPEC parameters the value of this flag >>>>>>>>>> >>>>>>> is always >>>>>>> >>>>>>>>>> zero." >>>>>>>>>> >>>>>>>>> Good catch, this is a typo, the sentence should be removed. >>>>>>>>> >>>>>>>>> >>>>>>>> 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 >>> >>> > > _______________________________________________ > 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 Jan 04 07:45:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2RyM-0002z4-2e; Thu, 04 Jan 2007 07:45:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2RyL-0002yy-DH for nsis@ietf.org; Thu, 04 Jan 2007 07:45:29 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2RyK-0004EC-Fl for nsis@ietf.org; Thu, 04 Jan 2007 07:45:29 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l04CixHv005159; Thu, 4 Jan 2007 13:45:14 +0100 (MET) From: "Georgios Karagiannis" To: "'Hannes Tschofenig'" Subject: RE: [NSIS] QSPEC Template Draft Review Date: Thu, 4 Jan 2007 13:45:01 +0100 Message-ID: <002101c72ffe$2d0ddb70$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.3028 Thread-Index: Accv977tXzdUrCdzRFu++WT8JyllEgABFwVw In-Reply-To: <459CEBCF.3020507@gmx.net> X-Spam-Score: 0.25 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 04 Jan 2007 13:45:17 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: eb4c5242518af073df6fe45f0d1cde3e Cc: 'David R Oran' , 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 I believe that what you propose in this e-mail is different than what you proposed in the earlier e-mail! What I would prefer to add to the existing QOSM related list is the following text: "The definition of a QoS model may also have implications on how local behavior should be implemented in the areas where the QoS NSLP gives freedom to implementers. For example, it may be useful to identify recommended behavior for how a RESERVE message that is forwarded relates to that received, or when additional signaling sessions should be started based on existing sessions, such as required for aggregate reservations. In some cases, suggestions may be made on whether state that may optionally be retained should be held in particular scenarios. A QoS model may specify reservation preemption, e.g., an incoming resource request may cause removal of an earlier reservation." Best Regards, Georgios > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: donderdag 4 januari 2007 12:58 > To: Georgios Karagiannis > Cc: 'David R Oran'; nsis@ietf.org > Subject: Re: [NSIS] QSPEC Template Draft Review > > Hi Georgios, > > if this is the case then the following text needs to be changed: > > A QOSM specification MUST include the following: > > - role of QNEs, e.g., location, frequency, statefulness, etc. > - QSPEC definition including QSPEC parameters [hannes] > Replace the following statement with: > " > - QSPEC procedures applicable to this QOSM " > this one: > " > - QSPEC signaling description for all signaling exchanges. > The signaling exchanges are listed in Section 5.3. > " > > - QNE processing rules describing how QSPEC information is treated > and interpreted in the RMF, e.g., > admission control, scheduling, policy control, QoS parameter > accumulation (e.g., delay). > - at least one bit-level QSPEC example > - QSPEC parameter behavior for new QSPEC parameters the QOSM > specification defines > - define what happens in case of preemption if the default QNI > behavior (tear down preempted reservation) is not followed (see > Section 5.3.5) > > Ciao > Hannes > > > Georgios Karagiannis wrote: > > Hi Hannes > > > > Regarding the following point: > > > >>> * Signaling > >>> > > > > > >>> Different QoSMs can nicely interwork if > >>> a) the QoS NSLP or the QSPEC document mandates a single signaling > >>> mode > >>> b) all QoSMs "support" all signaling modes. > >>> By support I mean that they describe what needs to be done in the > >>> > > different cases. > > > >>> Returning a failure might also be a possible option. > >>> > > > > > >>> While all possible signaling modes are described in the QSPEC > >>> document I couldn't see a mandate for a QoSM document to also > >>> describe what todo > >>> > > for all the signaling modes. > > > > > >>> [[ I call the signaling exchanges and respective message > processing > >>> rules in this context "signaling modes" lacking a better term.]] > >>> > > > > Regarding signaling the NSIS WG introduced the concept of > QOSM to be > > able to support your b) option: > > > >>> b) all QoSMs "support" all signaling modes. > >>> By support I mean that they describe what needs to be done in the > >>> > > different cases. > > > >>> Returning a failure might also be a possible option. > >>> > > > > Best Regards, > > Georgios > > > > > > > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: woensdag 3 januari 2007 22:22 > >> To: David R Oran > >> Cc: nsis@ietf.org > >> Subject: Re: [NSIS] QSPEC Template Draft Review > >> > >> Hi Dave, > >> > >> thanks for your quick response. > >> > >> David R Oran wrote: > >> > >>> On Jan 3, 2007, at 6:16 AM, Hannes Tschofenig wrote: > >>> > >>> > >>>> Hi David, > >>>> > >>>> David R Oran wrote: > >>>> > >>>>> On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote: > >>>>> > >>>>> > >>> [snip] > >>> > >>>>>> With this respect, the abstract and Section 5.4 regarding > >>>>>> extensibility have to be updated. > >>>>>> > >>>>>> Usage of RFC 2119 language is a bit challenging in > this document > >>>>>> given that it means "If a QoSM decides to use a certain > >>>>>> > >> parameter > >> > >>>>>> then it must implement the parameter as mentioned in this > >>>>>> document.". Do you need to a normative reference since > >>>>>> > >> it is just a > >> > >>>>>> template of QoS parameters? > >>>>>> > >>>>>> > >>>>> I think so, at least in the sense that the parameters have well > >>>>> defined semantics that are not dependent of any local > >>>>> > >> QoSM's whim to > >> > >>>>> redefine. If a given QNI says "I want delay variance > >>>>> > >> under 200ms and > >> > >>>>> if you can't give it to me I don't want my traffic > admitted" then > >>>>> the QoSM can't just ignore that or decide that it means > something > >>>>> else. For example if an RMF in one of the nodes allows an > >>>>> > >> EF queue > >> > >>>>> for other traffic with a maximum depth more than 200ms > >>>>> > >> then there's > >> > >>>>> no way it can admit the traffic needing a delay variance > >>>>> > >> under 200ms. > >> > >>>> I see it differently. The current collection of parameters are > >>>> available to a QoSM designer. They can decide whether to > use it or > >>>> define something new. Every QoSM is allowed to define > >>>> > >> whatever they > >> > >>>> want. If I want to define a IEEE 802.16e QoSM then nobody should > >>>> prevent me from doing so. I would want to use the > >>>> > >> parameters that are > >> > >>>> available in the IEEE spec. For example, when I tried to map the > >>>> existing QSPEC parameters to the existing IEEE 802.16e > parameters > >>>> then I noticed that they are similar but not exactly the > >>>> > >> same. Hence, > >> > >>>> even if they look similar I would like to define my own > >>>> > >> based on .16e > >> > >>>> rather than reusing the QSPEC parameters. > >>>> > >>>> > >>> And herein lies the core of the issue that has bedeviled > >>> > >> the working > >> > >>> group lately (and perhaps since inception, I don't know since my > >>> participation has been sporadic). I see the purpose of NSIS > >>> > >> to define > >> > >>> a signaling scheme which works end-to-end on the Internet, > >>> > >> rather than > >> > >>> just an architecture and template for defining a set of > >>> non-interoperable custom, per-network QoS signaling and > description > >>> schemes. To do this there have to be a core set of QoS parameters > >>> which are universally understood from which you can build > the vast > >>> majority of QoS schemes. Let's face it, the number of > feasible data > >>> plane queueing/scheduling/policing/shaping algorithms is in > >>> > >> fact not > >> > >>> that large. > >>> I think it has yet to be demonstrated that the > network-specific QoS > >>> parameter cannot in all but some corner cases be > >>> > >> represented using the > >> > >>> parameters we have come up with. Most of the argument has > >>> > >> been based > >> > >>> on RMFs that wish to be "simpler" than the general case in > >>> > >> which the > >> > >>> exact constraints and traffic model parameters of the source are > >>> enforced. This is fine, but it does NOT mean that we need a > >>> free-for-all in terms of parameter space. It is in fact why we > >>> restructured the Qspec parameters so that the user could be > >>> > >> explicit > >> > >>> and control what is advisory and what is mandatory for admission. > >>> > >>> Even more important, we don't need a free-for-all in the > >>> > >> operation of > >> > >>> QoS NSLP. The idea that the QoSM can change the signaling state > >>> machines for the NSLP is quite scary to me, which is why I > >>> > >> suggested > >> > >>> the language which said a QOSM isn't permitted to redefine > >>> > >> the way QOS > >> > >>> NSLP works. > >>> > >>> It's pretty clear that a number of people on the WG > >>> > >> disagree with this > >> > >>> position. That's fine - I said I'd shut up if the WG > >>> > >> consensus went a > >> > >>> different way. However, I do detect the weight of opinion > >>> > >> being closer > >> > >>> to what I wrote above. I'll leave it to the WG chair to > assess this. > >>> > >> There are a few aspects that need to be discussed here. > >> > >> I read the QSPEC draft many, many times already (and different > >> versions). Whenever I read through the abstract and the > introduction > >> I had the impression that I understood what the rest of > the document > >> is going to contain. I was always wrong. This time I was wrong as > >> well. > >> > >> It shouldn't be too difficult to tell the reader what the document > >> wants to accomplish. If I don't understand it then how > should someone > >> else (slightly ignoring the fact that everyone else might be > >> smarter)? > >> > >> Let us separate the signaling from the QoS parameter story > since they > >> are largely a different subject. Let us try to understand what > >> interoperability means. > >> > >> * Signaling > >> > >> Different QoSMs can nicely interwork if > >> a) the QoS NSLP or the QSPEC document mandates a single signaling > >> mode > >> b) all QoSMs "support" all signaling modes. > >> By support I mean that they describe what needs to be done in the > >> different cases. Returning a failure might also be a > possible option. > >> > >> While all possible signaling modes are described in the QSPEC > >> document I couldn't see a mandate for a QoSM document to also > >> describe what todo for all the signaling modes. > >> > >> [[ I call the signaling exchanges and respective message > processing > >> rules in this context "signaling modes" lacking a better term.]] > >> > >> * QoS Parameters > >> > >> From an interoperability point of view it would be ideal > to have a > >> single QoSM that is understood by everyone. I got the > impression that > >> this was the initial goal of the QSPEC document. Having a > core set of > >> parameters that are understood by everyone and a few optional > >> parameters was an interesting idea, I thought. [[ I was > never really > >> 100 % convinced that it can actually work but that's > another story. I > >> personally was just unhappy about the choice of mandatory > parameters. > >> ]] > >> > >> Another alternative is to define mappings from one QoSM to another > >> one.This is done today already but there are no procedures and > >> documents in the NSIS working group for defining these > mappings. With > >> this approach every QoSM can essentially define whatever > they want if > >> a reasonable mapping exists. > >> > >> Having a mapping is obviously better than just looking at > >> mandatory-to-understand parameters (and ignoring the optional > >> parameters). > >> > >> From your description it seems that the QSPEC contains a > number of > >> parameters that are supposed to be complete and MUST be used by > >> future QoSMs. To avoid interoperability problems QoSMs > ideally must > >> never not introduce parameters. > >> Since some of QSPEC authors are also QoSM authors they > ensured that > >> their QoSM is nicely supported. To allow the end-to-end > story to work > >> it is necessary to consider today's access networks and the QoS > >> parameters that are being used there. Is someone ever > wants to use a > >> path-coupled signaling solution then two approaches are possible > >> a) the end host already uses a QoS signaling protocol like RSVP or > >> NSIS > >> b) the end host uses a link layer protocol (with QoS > >> extensions) towards the access network and the network > triggers the > >> NSIS signaling exchange [A combination of the two is also > possible.] > >> > >> In any case I guess you have to deal with the QoS > parameters of the > >> specific link layer. I wonder whether someone has looked at these > >> issues already and whether the QSPEC QoS parameter and local QoSM > >> model supports this extensibility. > >> > >> As an example, the Traffic Priority as defined in > IEEE802.16e has 8 > >> priority levels. What would I do? This parameter does not > correspond > >> to anything in the QSPEC document at the moment. > >> > >> The typical question I have is: I want to implement QoSM X. > >> What do I have to implement from the QSPEC draft? > >> > >> [ A minor technical issue: Are there problems (in the > IETF document > >> processing) if normative references point to documents that are > >> non-IETF documents? ] > >> > >> I am not sure I understood your comment regarding " > >> The idea that the QoSM can change the signaling state machines for > >> the NSLP is quite scary to me, which is why I suggested > the language > >> which said a QOSM isn't permitted to redefine the way QOS > NSLP works. > >> " > >> > >> > >>>> The idea of a template is to offer a set of parameters > >>>> > >> that might be > >> > >>>> used when building QoSMs. With a specific QoSM some of > these QSPEC > >>>> parameters are hopefully implemented. > >>>> > >>>> > >>> If the QSPEC specification is viewed as just a > >>> > >> template/base schema, > >> > >>> then I think we will have failed pretty miserably. We > will have the > >>> illusion of interoperability and not real interoperability. > >>> > >> This is what I read from the abstract and the > introduction. Maybe it > >> would be appropriate to delete the term "template" from > the document. > >> > >> > >> > >>>> The question with the parameter selection is therefore: > Are these > >>>> useful parameters that might be reused by a number of QoSMs? > >>>> > >>>> > >>> I'd turn it around and say "given that end-to-end QoS > >>> > >> interoperability > >> > >>> is a main goal of NSIS, does the particular QoSM achieve > this well > >>> enough to admit the traffic as requested by the QNI". If the QoSM > >>> can't do what the user asked then it's the job of the QSPEC > >>> > >> semantics > >> > >>> and the QOS NSLP signaling machinery to not admit the > traffic, and > >>> tell the user why. It's up to the user/QNI to formulate QoS > >>> > >> requests > >> > >>> that are adequate to the needs of the application but which > >>> > >> have high > >> > >>> probability of being admitted under conditions where there are > >>> adequate resources. QoS NSLP and Qspecs (as we have them in the > >>> current drafts) give us the tools to accomplish this. If we > >>> > >> treat the > >> > >>> Qspec parameters just as "useful suggestions" I think we > will have > >>> pretty definitely sacrificed this goal for the Internet, > >>> > >> which is what > >> > >>> NSIS exists for. > >>> > >> This sounds like a very nice. When it comes to the details > things get > >> a bit more difficult. > >> > >> > >>>>>> Regarding processing description: > >>>>>> > >>>>>> I never understood why the processing description is > >>>>>> > >> also provided > >> > >>>>>> in this document. I provided this comment already in the > >>>>>> > >> past but > >> > >>>>>> obviously the authors didn't like it too much. Not a big deal > >>>>>> though. In some sense it is largely a matter of taste anyway. > >>>>>> Instead of reducing the processing description it was actually > >>>>>> enhanced; I was surprised to find a QSPEC encapsulation > >>>>>> > >> technique > >> > >>>>>> in Section 5.1. I always thought that this is a QoS NSLP > >>>>>> > >> draft aspect. > >> > >>>>> Well, this was the subject of a spirited debate among > >>>>> > >> some of the WG > >> > >>>>> participants. I didn't particularly like the way it > >>>>> > >> turned out, but > >> > >>>>> there seems to be rough consensus that QSPEC > >>>>> > >> encapsulation should be > >> > >>>>> part of other QSPEC itself. > >>>>> > >>>> I must have missed this discussion. If people like it that > >>>> > >> way then > >> > >>>> it should be fine. > >>>> > >>>> > >>>>>> This is probably a document writing style and a matter of > >>>>>> worksplit between the QoS NSLP and the QSPEC document > authors. A > >>>>>> deployable solution requires GIST, the QoS NSLP, the > QSPEC and a > >>>>>> QoSM (and the AAA part) and a reader might want to read > >>>>>> > >> all these > >> > >>>>>> documents anyway. > >>>>>> > >>>>>> Section 5.3 should be informative only; no RFC 2119 > >>>>>> > >> language since > >> > >>>>>> the current text just outlines all possible combinations. > >>>>>> Currently, one can sometimes find RFC 2119 language in some > >>>>>> subsections. The QoSMs provide the normative text and > >>>>>> > >> may restrict > >> > >>>>>> the available combinations. [[Note that this might raise > >>>>>> interesting problems given that different QoSMs implement a > >>>>>> different signaling behavior and interworking between > different > >>>>>> QoSMs might be really challenging. > >>>>>> > >>>>> This was one of the reasons I proposed restricting the > >>>>> > >> variability > >> > >>>>> among QOSMs to be in the RMF only and not to allow different > >>>>> signaling semantics. I lost that one. > >>>>> > >>>> Another alternative is that the QSPEC document demands that QoSM > >>>> documents define all possible signaling behaviors. Then it > >>>> > >> would be > >> > >>>> fine as well. It would make the QoSMs more complicated. I, > >>>> > >> btw, was > >> > >>>> never in favor of receiver-initiated signaling behavior > since the > >>>> authorization story is really mood. > >>>> > >>>> > >>>> Do you agree with me that RFC 2119 language shouldn't be used in > >>>> Section 5.3? > >>>> > >>>> > >>> I see no problem with the (quite limited) use of RFC2119 > >>> > >> language in > >> > >>> the places in section 5.3 where it appears. It seems quite > >>> > >> appropriate > >> > >>> to me,. > >>> > >>> > >> I need to read through each paragraph to determine what the > >> implications are. > >> > >> > >>>>>> For example, what happens if a receiver-initiated > >>>>>> > >> reservation meets > >> > >>>>>> a domain with a QoS model that only supports sender-initiated > >>>>>> reservations.]] > >>>>>> > >>>>>> > >>>>> In order to make this work I think you have to have recursive > >>>>> signaling at the edge of the domain. > >>>>> > >>>> Correct. > >>>> > >>>> As an example, in RMD these different cases got considered. > >>>> > >>>> If you only assume that sender-initiated reservations exist then > >>>> documents are simpler since they obviously don't need to > >>>> > >> consider all > >> > >>>> the different cases. > >>>> We noticed this problem already with the mobility document > >>>> > >> where the > >> > >>>> receiver-initiated reservations are just painful. > >>>> > >>>> > >>> But this is up to the applications which is more > >>> > >> useful/natural, no? > >> > >>> If you are saying that receiver-initiated is harder to > >>> > >> achieve under > >> > >>> some circumstances, then sure. Applications should be > cognizant of > >>> that and use receiver-initiated only when they can't > >>> > >> conveniently use > >> > >>> sender-initiated. Conversely, some applications (e.g. > multicast and > >>> multi-unicast) can get all tied up in knots with sender-initiated > >>> reservations. But to say that interoperability fails > >>> > >> because some QoSM > >> > >>> decides receiver-initiated reservations are a pain and > >>> > >> redefines QOS > >> > >>> NSLP to eliminate them over its domain strikes me as a very poor > >>> tradeoff. > >>> > >> I agree with your statement about multicast QoS reservations. > >> I wonder > >> whether someone wants to use path-coupled QoS signaling > for multicast > >> communication. > >> > >> > >> Ciao > >> Hannes > >> > >> > >>> Cheers, Dave. > >>> > >>> > >>>>>> That's it for now. I will provide more detailed comments later. > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> > >>>>>> > >>>> 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 04 08:14:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SQH-0003I2-QL; Thu, 04 Jan 2007 08:14:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SQG-0003Hd-LA for nsis@ietf.org; Thu, 04 Jan 2007 08:14:20 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2SQ7-0000gV-UG for nsis@ietf.org; Thu, 04 Jan 2007 08:14:20 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l04DDbC3006330; Thu, 4 Jan 2007 14:13:55 +0100 (MET) From: "Georgios Karagiannis" To: "'Hannes Tschofenig'" Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 14:13:40 +0100 Message-ID: <002701c73002$31ce25d0$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.3028 Thread-Index: Accv+fb106GFgntAQb6TS261LT42lQABzTHA In-Reply-To: <459CEFD5.6010808@gmx.net> X-Spam-Score: 0.3 () AWL,FVGT_s_OBFU_Q1,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 04 Jan 2007 14:13:58 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3c3f5218b222da1e73e850f1438da613 Cc: john.loughney@nokia.com, 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 Hannes Please see in line! > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: donderdag 4 januari 2007 13:15 > To: Georgios Karagiannis > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > Subject: Re: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > > Hi Georgios, > > Georgios Karagiannis wrote: > > Hi John > > > > I mainly disagree with the following three points that were never > > discussed before: > > > > Point_1):Removed the QSPEC control information > > --------------------------------------------------------------- > > Jerry mentioned in a previous e-mail that this QSPEC control > > information concept is not removed but it is renamed to > Traffic Handling Directives. > > > > If that is the case then Jerry will have to use the same > definitions > > for the QSEPC control information as used in Section 5.3.1 of: > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > > > Thus my proposal is to change section 4.3.3 as given in v.13 of the > > QSEPC template draft and include the general concept of the QSPEC > > control information that was given in Section 5.3.1 of > version 12 of > > the QSEPC template draft. Note that the name can be changed but the > > semantics should remain the same. Thus please chnage > Section 4.3.3 as follows: > > > > FROM: > > > > 4.3.3 Traffic Handling Directives > > > > The parameter describes how the QNE > will process > > excess traffic, that is, out-of-profile traffic. Excess > traffic MAY > > be dropped, shaped and/or remarked. The excess treatment > parameter is > > initially set by the QNI and cannot be overwritten. > > > > > > INTO: > > > > 4.3.3 Traffic Handling Directives > > > > Traffic Handling Directives are used for signaling QOSM > RMF functions > > not defined in QoS NSLP. It enables building new RMF functions > > required by a QOSM within a QoS NSLP signaling framework, such as > > specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. > > > > = > > > > The parameter describes how the QNE > will process > > excess traffic, that is, out-of-profile traffic. Excess > traffic MAY > > be dropped, shaped and/or remarked. The excess treatment > parameter is > > initially set by the QNI and is read-only. > > > > > > Do you worry about a potential loss of extensibility here? Georgios: yes I am very much worried about extensibility and flexibility. > > ------------------------------- > > > > Point_2: dictates that encpasulation of the original > initiator QSEPC > > feature cannot be used in combination with the tunneling (parallel > > session) feature. > > > > In the discussion that we have had in the nsis mailing list > and during > > the IETF meeting it was stated that both these features should be > > possible, while now version 13 of the QSPEC template draft dicates > > that these two feratures cannot be used togetherand at the > same time > > by the same QoS model. > > As I mentioned in all the discussions the encapsulation of the > > original QSPEC feature is needed to satisfy Requirement: > > "5.4.2. It SHOULD be Possible to Add and Remove Local Domain > > Information" given in: http://www.ietf.org/rfc/rfc3726.txt > > Therefore the encapsulation (of the original initiator QSEPC into a > > local > > QSPEC) feature should be seen as an independent feature and > it should > > be able to be used in combination with the tunneling (parallel > > session) feature that is used for another goal. > > > > Thius my proposal is that it should be mentioned that even when the > > tunneling (parallel session) feature is used, it is also allowed to > > use, at the same time, the encapsulation (of the original initiator > > QSEPC into a local QSPEC) feature in order to satisfy Requirement > > 5.4.2 of RFC 3726. > > > > How would this, for example, impact RMD? Georgios: For RMD-QOSM this will mean that for each local refresh RESERVE message an additional RESPONSE message will have to be generated. > > > --------------------------- > > > > Point_3: QSEPC template draft dictates which QOS-NSLP signaling > > features should be used by QOS models. > > > > We have never discussed an agreed that the QSPEC template draft > > defines how the QOS-NSLP functionality should be used by > QoS models. > > This should be defined by the QOS-NSLP draft. > > Therefore, regarding this issue the QSPEC template draft > should refer > > to Section "3.1.2. QoS Models and QoS Specifications"" of: > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt > > > > Therefore the QSPEC tempate draft should adpat the > definitiojn of the > > QoS models according to what Section 3.1.2 of the QOS-NSLP draft is > > saying and refer to Section 3.1.2 of the QOS-NSLP draft. > > > > > > I guess this aspect refers to the previous discussion I had > with Dave and with you subsequently. Georgios: If the the folowing paragraph is added to the proposed QoS model capability list it will satisfy my concerns: "The definition of a QoS model may also have implications on how local behavior should be implemented in the areas where the QoS NSLP gives freedom to implementers. For example, it may be useful to identify recommended behavior for how a RESERVE message that is forwarded relates to that received, or when additional signaling sessions should be started based on existing sessions, such as required for aggregate reservations. In some cases, suggestions may be made on whether state that may optionally be retained should be held in particular scenarios. A QoS model may specify reservation preemption, e.g., an incoming resource request may cause removal of an earlier reservation." Best regards, Georgios > > When reading through Section 3.1.2 of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-1 2.txt I am sure that the QoS NSLP authors are going to re-write > the section. > > > Ciao > Hannes > > Best Regards, > > Georgios > > > > > > > > > > > > > > > > On 12/23/2006, "john.loughney@nokia.com" > > wrote: > > > > > >> Hi all, > >> > >> When Jerry posted the draft with the change log, I basically noted > >> that the changes were based upon previous discussions, on > the mailing > >> list and the meeting. > >> > >> I am unsure of the techincal issues that are being raised. Rather > >> than get into a discussion of what was discussed or not, > what I would > >> like to understand better is more understanding what are the > >> technical issues behind Georgios' issues. > >> > >> Additionally, I would like to hear from others about their > opinions > >> on this issue. > >> > >> thanks, > >> John > >> > >> > >>> -----Original Message----- > >>> From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > >>> Sent: 22 December, 2006 20:12 > >>> To: Georgios Karagiannis; nsis@ietf.org > >>> Cc: Ash, Gerald R (Jerry), ALABS > >>> Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > >>> > >>> Georgios, > >>> > >>> It's not true as you and 2 others have stated that the > changes were > >>> not discussed. They were discussed, at length. For example, the > >>> revised definition of QOSM was clearly stated and > discussed on the > >>> list, see > >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.htm > >>> l and also see all the list discussion following that post. > >>> The revised definition and all the other changes were clearly > >>> presented in the slides at IETF-67, see minutes and slides at > >>> http://www3.ietf.org/proceedings/06nov/index.html. You > can listen > >>> to the complete IETF-67 presentation/discussion again at > >>> http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf > >>> 67ch4-thu > >>> -am.mp3. > >>> > >>> You can review the slides, meeting discussion, list discussion, > >>> meeting minutes, and verify that for yourself. > >>> > >>> So the editors did not 'make up the changes without > discussion' as > >>> you and 2 others have suggested. That is certainly wrong and I > >>> think you should acknowledge that. > >>> > >>> It is not useful going forward to debate the past, but incendiary > >>> wrong statements should not go unanswered. > >>> > >>> Once again, I've responded to your technical comments, you can > >>> comment further if you wish. > >>> > >>> It would be good for others to comment on the technical points. > >>> > >>> Jerry > >>> > >>> -----Original Message----- > >>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>> Sent: Friday, December 22, 2006 11:36 AM > >>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > >>> Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > >>> > >>> Hi Jerry > >>> > >>> The changes that are included in version 13 of the QSEPC template > >>> draft regarding the QSPEC control information and the > limitations of > >>> the QoS models have never been discussed because they were never > >>> stated clearly. > >>> > >>> If they would have been stated clearly then I would have sent my > >>> comments at that time instead of sending them now! > >>> > >>> Furthermore, from what I have seen in v. 13 of the draft you also > >>> have not solved the stacking issue, because you are actually > >>> dictating that encapsulation cannot be combined and used together > >>> with the tunneling (parallel sessions) method. > >>> > >>> > >>> Best Regards, > >>> Georgios > >>> > >>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > >>>>> Sent: vrijdag 22 december 2006 16:37 > >>>>> To: Georgios Karagiannis; nsis@ietf.org > >>>>> Cc: Ash, Gerald R (Jerry), ALABS > >>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > >>>>> > >>>>> Georgios, > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>>>>> Sent: Friday, December 22, 2006 9:13 AM > >>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > >>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > >>>>>> > >>>>>> Hi Jerry > >>>>>> > >>>>>> By just saying that "these changes are suggested by > Dave in the > >>>>>> e-mail" does not work. > >>>>>> > >>>>>> The proposal of Dave was not clear on the QoS model changes > >>>>>> > >>>>> that you > >>>>> > >>>>>> wanted to do. > >>>>>> > >>>>> All changes to the draft have been extensively discussed on > >>>>> > >>>> the list > >>>> > >>>>> and are all contained in the slides presented at IETF-67. > >>>>> > >>> You were > >>> > >>>>> there at > >>>>> IETF-67 and participated in all the list discussion. The > >>>>> > >>>> summary of > >>>> > >>>>> changes in the slides is quite specific and clear, take > >>>>> > >>>> another look. > >>>> > >>>>> Have a look at the minutes as well > >>>>> > http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt. The only > >>>>> disagreements noted are with regard to stacking, which > is an issue > >>>>> that we later resolved on the list. Go back and check it out. > >>>>> > >>>>> > >>>>>> Now I understand which changes you want to include in > the QSPEC > >>>>>> template draft. > >>>>>> This is also the reason of disagreeing with you now > and sending > >>>>>> comments to the nsis list. > >>>>>> > >>>>> I responded to your further comments, see below. Others are > >>>>> encouraged to comment as well. > >>>>> > >>>>> Jerry > >>>>> > >>>>> > >>>>>> Furthermore, note that the QOS-NSLP draft defines which > >>>>>> > >>>>> capabilities > >>>>> > >>>>>> should be supported by the QoS models and not the > QSPEC template > >>>>>> draft. > >>>>>> > >>>>>> Best Regards, > >>>>>> Georgios > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > >>>>>>> Sent: vrijdag 22 december 2006 15:01 > >>>>>>> To: Georgios Karagiannis; nsis@ietf.org > >>>>>>> Cc: Ash, Gerald R (Jerry), ALABS > >>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > >>>>>>> > >>>>>>> Georgios, > >>>>>>> > >>>>>>> See below. > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>>>>>>> Sent: Thursday, December 21, 2006 9:22 AM > >>>>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > >>>>>>>> Cc: 'Attila Bader (IJ/ETH)'; 'Lars Westberg' > >>>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > >>>>>>>> > >>>>>>>> Hi Jerry > >>>>>>>> > >>>>>>>> Please see below! I have severe concerns about some changes > >>>>>>>> > >>>>>>> that have > >>>>>>> > >>>>>>>> been done in the QSPEC template draft. > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > >>>>>>>>> Sent: woensdag 20 december 2006 14:20 > >>>>>>>>> To: Georgios Karagiannis; nsis@ietf.org > >>>>>>>>> Cc: Ash, Gerald R (Jerry), ALABS > >>>>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > >>>>>>>>> > >>>>>>>>> Hi Georgios, > >>>>>>>>> > >>>>>>>>> See below. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Georgios Karagiannis > >>>>>>>>>> > >>> [mailto:karagian@cs.utwente.nl] > >>> > >>>>>>>>>> Sent: Wednesday, December 20, 2006 5:26 AM > >>>>>>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > >>>>>>>>>> Subject: Comments on draft-ietf-nsis-qspec-13.txt > >>>>>>>>>> > >>>>>>>>>> Hi Jerry > >>>>>>>>>> > >>>>>>>>>> Here are my comments on draft-ietf-nsis-qspec-13.txt: > >>>>>>>>>> > >>>>>>>>>> Comment_1: > >>>>>>>>>> -------------- > >>>>>>>>>> Please reinclude the concept of QSPEC control > >>>>>>>>>> > >>>>>>> information that was > >>>>>>> > >>>>>>>>>> included in all previous versions of the QSPEC > >>>>>>>>>> > >>>>> template draft. > >>>>> > >>>>>>>>>> In > >>>>>>>>>> > >>>>>>>>>> > >>>> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt: > >>>> this > >>>> > >>>>>>>>>> concept was described in Section 5.1. > >>>>>>>>>> > >>>>>>>>> Please see previous email comment on QSPEC control > >>>>>>>>> > >>>>> information. > >>>>> > >>>>>>>> Georgios: > >>>>>>>> In order to emphasize the need of having QSPEC control > >>>>>>>> > >>>>>> information > >>>>>> > >>>>>>>> parameters I would however appreciate if the name of > >>>>>>>> > >>>>>>> Section 4.3.3 > >>>>>>> > >>>>>>>> is changed > >>>>>>>> From: > >>>>>>>> 4.3.3 Traffic Handling Directives > >>>>>>>> INTO: > >>>>>>>> 4.3.3 QSPEC control information > >>>>>>>> > >>>>>>> The updated QSPEC parameter terminology/semantics are as > >>>>>>> > >>>>> suggested > >>>>> > >>>>>>> by Dave Oran (see slides presented at IETF-67 > >>>>>>> http://www3.ietf.org/proceedings/06nov/index.html). I > >>>>>>> > >>>> think the > >>>> > >>>>>>> current terminology is more clear/descriptive of the QSPEC > >>>>>>> parameters so I don't favor going backwards to less clear > >>>>>>> terminology. I was never clear on why we used the 'control > >>>>>>> information' terminology in the first place, e.g., I > >>>>>>> > >>>> don't think > >>>> > >>>>>>> it's a very good descriptor of the 'excess treatment' > >>>>>>> > >>> parameter. > >>> > >>>>>>> Perhaps Dave can comment on this point also when he > >>>>>>> > >>>> gets a chance. > >>>> > >>>>>>>>>> Comment_2: > >>>>>>>>>> ----------- > >>>>>>>>>> > >>>>>>>>>> Section 6.1: > >>>>>>>>>> Please reintroduce the format that is required > >>>>>>>>>> > >>> in order to > >>> > >>>>>>>>> specify the > >>>>>>>>> > >>>>>>>>>> QSPEC control information, see: > >>>>>>>>>> Section 7.1 of: > >>>>>>>>>> > >>>>>>>>>> > >>>>>> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > >>>>>> > >>>>>>>>> Please see previous email comment on QSPEC control > >>>>>>>>> > >>>>> information. > >>>>> > >>>>>>>> Georgios: If you rename section 4.3.3 to QSPEC control > >>>>>>>> > >>>>>> information > >>>>>> > >>>>>>>> then I think that reformatting of section 6.1 is not needed. > >>>>>>>> Please add the proposed sentence by Dave (but change > >>>>>>>> > >>> the term > >>> > >>>>>>>> "handling directives" to "QSPEC control Information"). I am > >>>>>>>> > >>>>>>> not sure > >>>>>>> > >>>>>>>> where it is better to add this sentence, maybe in > >>>>>>>> > >>> Section 5.4. > >>> > >>>>>>>> "QoSMs are free, subject to IANA registration and review > >>>>>>>> > >>>>>> rules, to > >>>>>> > >>>>>>>> extend QSPECs by adding parameters of any of the kinds > >>>>>>>> > >>>>>> supported by > >>>>>> > >>>>>>>> the standard QSPEC. This includes traffic description > >>>>>>>> > >>>>> parameters, > >>>>> > >>>>>>>> constraint parameters and QSPEC control information. > >>>>>>>> > >>>>>> QoSMs are not > >>>>>> > >>>>>>>> permitted, however, to reinterpret or redefine the > >>>>>>>> > >>>>> standard QSPEC > >>>>> > >>>>>>>> parameters specified in this document" > >>>>>>>> > >>>>>>> Yes, the text suggested by Dave will be added. > >>>>>>> > >>>>>>> > >>>>>>>>>> Comment_3: > >>>>>>>>>> ---------- > >>>>>>>>>> Section 4.1 :QoS Models > >>>>>>>>>> The definition of the QoS model is not complete. An > >>>>>>>>>> > >>>>> important > >>>>> > >>>>>>>>>> sentence that was used in the previous version of the > >>>>>>>>>> > >>>>>> draft is > >>>>>> > >>>>>>>>>> removed. > >>>>>>>>>> Please add the following sentence to the definition > >>>>>>>>>> > >>>>>> of the QoS > >>>>>> > >>>>>>>>>> Model > >>>>>>>>>> (QOSM): > >>>>>>>>>> > >>>>>>>>>> The same as described above have to be applied in > >>>>>>>>>> > >>>>>> this section. > >>>>>> > >>>>>>>>>> After the following sentence: > >>>>>>>>>> > >>>>>>>>>> "A QOSM specification MAY include the following:" > >>>>>>>>>> > >>>>>>>>>> include the following bullet: > >>>>>>>>>> "- it specifies how to use QOS NSLP to signal for > >>>>>>>>>> > >>>> this QOSM" > >>>> > >>>>>>>>> That sentence was removed in Dave's proposed QOSM > >>>>>>>>> > >>>>>>> re-definition, see > >>>>>>> > >>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht > >>>> > >>>>>>>>> ml. It was unclear what that sentence meant, QoS-NSLP > >>>>>>>>> > >>>>>>> specifies how > >>>>>>> > >>>>>>>>> to signal, not QOSM specifications, so the sentence > >>>>>>>>> > >>>>> was removed. > >>>>> > >>>>>>>>> I believe the sentence was intended to mean that when > >>>>>>>>> > >>>>> QoS NSLP > >>>>> > >>>>>>>>> allows various options to be selected, a QOSM should > >>>>>>>>> > >>>>> be able to > >>>>> > >>>>>>>>> determine which option is used. For that purpose the > >>>>>>>>> > >>>>> following > >>>>> > >>>>>>>>> sentence was added in Section 4.1: > >>>>>>>>> > >>>>>>>>> " A QOSM specification MAY include the following: > >>>>>>>>> ... > >>>>>>>>> - can state which QoS-NSLP options a QOSM wants to > >>>>>>>>> > >>>>>> use, when > >>>>>> > >>>>>>>>> several options are available for a QOSM (e.g., > >>>>>>>>> > >>>>>>> local QSPEC to > >>>>>>> > >>>>>>>>> either be a) tunneled or b) encapsulate > >>>>>>>>> > >>>>> initiator QSPEC)." > >>>>> > >>>>>>>>> Also, to avoid any misinterpretation that QOSMs are free > >>>>>>>>> > >>>>>>> to specify > >>>>>>> > >>>>>>>>> additional constraints, state machines, protocol data, > >>>>>>>>> > >>>>>>> etc. for NSLP > >>>>>>> > >>>>>>>>> beyond that which is specific in the QoS NSLP > >>>>>>>>> > >>>>>> specification, the > >>>>>> > >>>>>>>>> following was added to Section 4.1: > >>>>>>>>> > >>>>>>>>> " QOSMs affect the operation of the RMF in NSIS-capable > >>>>>>>>> > >>>>>>> nodes, the > >>>>>>> > >>>>>>>>> information carried in QSPEC objects, and may under some > >>>>>>>>> circumstances (e.g. aggregation) cause a separate NSLP > >>>>>>>>> session to be > >>>>>>>>> instantiated by having the RMF as a QNI. QOSMs > >>>>>>>>> > >>>> all utilize > >>>> > >>>>>>>>> the common > >>>>>>>>> data, state machines, and APIs of the underlying NSIS > >>>>>>>>> protocols and > >>>>>>>>> are not expected to re-define or extend these in > >>>>>>>>> > >>>> any way." > >>>> > >>>>>>>> Georgios: > >>>>>>>> Regarding the sentence in Section 4.1: > >>>>>>>> "QOSMs all utilize > >>>>>>>> the common data, state machines, and APIs of the > >>>>>>>> > >>>>> underlying NSIS > >>>>> > >>>>>>>> protocols and are not expected to re-define or extend > >>>>>>>> > >>>>>> these in any > >>>>>> > >>>>>>>> way." > >>>>>>>> > >>>>>>>> This sentence restricts the possibility of QoS model to use > >>>>>>>> > >>>>>>> RMF states > >>>>>>> > >>>>>>>> and data that are not been defined in neither > >>>>>>>> > >>>> QoS-NSLP or QSPEC. > >>>> > >>>>>>>> This sentence should be removed. > >>>>>>>> > >>>>>>> I disagree. The quoted text was introduced by Dave Oran > >>>>>>> > >>>>> in addition > >>>>> > >>>>>>> to removing the phrase implying that a QOSM could specify > >>>>>>> > >>>>> signaling > >>>>> > >>>>>>> protocol changes, and I agree with this. > >>>>>>> Any changes/extensions to the signaling protocol or state > >>>>>>> > >>>>> machines > >>>>> > >>>>>>> are within the scope of QoS-NSLP draft and not the QSPEC > >>>>>>> > >>>>> draft or a > >>>>> > >>>>>>> QOSM specification draft. I think you have noted that > >>>>>>> > >>>>> also in your > >>>>> > >>>>>>> subsequent posting at > >>>>>>> > >>>>>>> > >>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07352.html. > >>>> > >>>>>>> If any extensions are required to the NSIS signaling > >>>>>>> > >>>>> protocol as a > >>>>> > >>>>>>> result of the 'severe change on QoS Model definition and > >>>>>>> capabilities' > >>>>>>> you have noted, those proposed changes/extensions should be > >>>>>>> addressed to the QoS NSLP draft IMO. > >>>>>>> > >>>>>>> Perhaps Dave can comment here also when he gets a chance. > >>>>>>> > >>>>>>> > >>>>>>>>>> Comment_4: > >>>>>>>>>> ------------- > >>>>>>>>>> Section 5.1 Local QSPEC definition and processing > >>>>>>>>>> > >>>>>>>>>> By reading this section it gives the impression > >>>>>>>>>> > >>>>> that the two > >>>>> > >>>>>>>>>> methods > >>>>>>>>>> a) and b) cannot be used by the same QoS model. > >>>>>>>>>> Method a): translate the > >>>>>>>>>> initiator QSPEC into a local QSPEC and encapsulate the > >>>>>>>>>> > >>>>>>> initiator > >>>>>>> > >>>>>>>>>> QSPEC in the RESERVE message Method b): b) tunnel the > >>>>>>>>>> > >>>>>> initiator > >>>>>> > >>>>>>>>>> QSPEC through the local domain and reserve resources by > >>>>>>>>>> > >>>>>>> generating > >>>>>>> > >>>>>>>>>> a new RESERVE message through the local domain > >>>>>>>>>> > >>>>> containing the > >>>>> > >>>>>>>>>> local QSPEC. > >>>>>>>>>> > >>>>>>>>>> Note that according to the discussions that we have had > >>>>>>>>>> > >>>>>>> until now > >>>>>>> > >>>>>>>>>> method a) should be able to be used in combination with > >>>>>>>>>> > >>>>>>> method b) > >>>>>>> > >>>>>>>>>> by the same QoS model for the situation that the > >>>>>>>>>> > >>>>> local QSPEC > >>>>> > >>>>>>>>>> encapsulates the initiator QSPEC in order to satisfy > >>>>>>>>>> > >>>>>>> requirement > >>>>>>> > >>>>>>>>>> 5.4.2 that is specified in RFC 3726, see: > >>>>>>>>>> http://www.ietf.org/rfc/rfc3726.txt > >>>>>>>>>> > >>>>>>>>>> Please add the following sentence at the end of > >>>>>>>>>> > >>> the first > >>> > >>>>>>>>>> paragraph of Section 5.1. > >>>>>>>>>> "Note that when method b) is used, the > >>>>>>>>>> > >>>> encapsulation of the > >>>> > >>>>>>>>>> initiator QSPEC into a local QSPEC should also be > >>>>>>>>>> > >>>>>> possible when > >>>>>> > >>>>>>>>>> the local QoS model needs to satisfy Requirement > >>>>>>>>>> 5.4.2 specified in RFC 3726, by adding and > >>>>>>>>>> > >>> removing local > >>> > >>>>>>>>>> QOSM-specific Control Information parameters on > >>>>>>>>>> > >>>> top of the > >>>> > >>>>>>>>>> initiator QSPEC." > >>>>>>>>>> > >>>>>>>>> Your comment here is not clear to me. It would help to > >>>>>>>>> > >>>>>>> provide an > >>>>>>> > >>>>>>>>> example to illustrate what you are trying to accomplish. > >>>>>>>>> > >>>>>>> It seems > >>>>>>> > >>>>>>>>> that you are trying to specify QoS-NSLP functionality, > >>>>>>>>> > >>>>>>> rather than > >>>>>>> > >>>>>>>>> QSPEC functionality. If so, that functionality should be > >>>>>>>>> > >>>>>>> specified > >>>>>>> > >>>>>>>>> in the QoS-NSLP draft rather than the QSPEC draft, > >>>>>>>>> > >>>>> perhaps the > >>>>> > >>>>>>>>> QoS-NSLP authors can comment. > >>>>>>>>> > >>>>>>>> Georgios: > >>>>>>>> No I am not trying to define QOS-NSLP functionality. > >>>>>>>> This is related to QSPEC control information that has to be > >>>>>>>> > >>>>>>> carried by > >>>>>>> > >>>>>>>> end-to-end messages. > >>>>>>>> What I am trying to say is that all the discussion that > >>>>>>>> > >>>>>> we have had > >>>>>> > >>>>>>>> regarding the encapsulation of the QSPEC object were > >>>>>>>> > >>>>>>> associated with > >>>>>>> > >>>>>>>> requirement 5.4.2 of RFC 3726, see below: > >>>>>>>> > >>>>>>>> ----------------- > >>>>>>>> "5.4.2. It SHOULD be Possible to Add and Remove > >>>>>>>> > >>> Local Domain > >>> > >>>>>>>> Information > >>>>>>>> > >>>>>>>> It SHOULD be possible to add and remove local > >>>>>>>> > >>>> scope elements. > >>>> > >>>>>>>> Compared to Requirement 5.3.5 this requirement does use > >>>>>>>> > >>>>>>> the normal > >>>>>>> > >>>>>>>> signaling process and message exchange for > >>>>>>>> > >>>> transporting local > >>>> > >>>>>>>> information. For example, at the entrance to a > >>>>>>>> > >>>>> domain, domain- > >>>>> > >>>>>>>> specific information is added information is added, which > >>>>>>>> is used in > >>>>>>>> this domain only, and the information is removed > >>>>>>>> > >>>> again when a > >>>> > >>>>>>>> signaling message leaves the domain. The motivation > >>>>>>>> > >>>>> is in the > >>>>> > >>>>>>>> economy of re-using the protocol for domain internal > >>>>>>>> > >>>>>> signaling of > >>>>>> > >>>>>>>> various information pieces. Where additional > >>>>>>>> > >>>>>>> information is needed > >>>>>>> > >>>>>>>> within a particular domain, it should be possible to > >>>>>>>> > >>>>>>> carry this at > >>>>>>> > >>>>>>>> the same time as the end-to-end information.", > >>>>>>>> > >>>> from RFC 3726 > >>>> > >>>>>>>> ------------------ > >>>>>>>> Thus what I am saying is: > >>>>>>>> Please add the following sentence at the end of the first > >>>>>>>> > >>>>>>> paragraph of > >>>>>>> > >>>>>>>> Section 5.1. > >>>>>>>> > >>>>>>>> "Note that when method b) is used, the encapsulation of the > >>>>>>>> > >>>>>>> initiator > >>>>>>> > >>>>>>>> QSPEC into a local QSPEC should also be possible when the > >>>>>>>> > >>>>>> local QoS > >>>>>> > >>>>>>>> model needs to satisfy Requirement > >>>>>>>> 5.4.2 specified in RFC 3726, by adding and removing local > >>>>>>>> QOSM-specific Control Information parameters on top of the > >>>>>>>> > >>>>>>> initiator > >>>>>>> > >>>>>>>> QSPEC." > >>>>>>>> > >>>>>>> First, the suggested text isn't clear. If method b) is used > >>>>>>> (tunneling) then presumably method a) is not also used at > >>>>>>> > >>>>> the same > >>>>> > >>>>>>> time. However, the phrasing of the above makes it > >>>>>>> > >>>> sound that way. > >>>> > >>>>>>> Second, an example would help here. I presume you are > >>>>>>> > >>>> referring > >>>> > >>>>>>> e.g., to RMD adding 'control information' (i.e., 'handling > >>>>>>> directive') parameters to the local QSPEC that are not > >>>>>>> > >>>>> included in > >>>>> > >>>>>>> the initiator QSPEC. I think the requirement would be > >>>>>>> > >>>>> that the RMD > >>>>> > >>>>>>> QOSM provides a local QSPEC that is consistent with the > >>>>>>> > >>>> initiator > >>>> > >>>>>>> QSPEC, as we agreed on the list (see also slide 8 of > >>>>>>> > >>>> the IETF-67 > >>>> > >>>>>>> presentation). > >>>>>>> > >>>>>>> If the local QSPEC introduces functionality > >>>>>>> > >>>> inconsistent with the > >>>> > >>>>>>> initiator QSPEC by appending the handling directive > >>>>>>> > >>>>> parameters, then > >>>>> > >>>>>>> it is not allowed. > >>>>>>> > >>>>>>> > >>>>>>>>>> Comment_5: > >>>>>>>>>> ----------- > >>>>>>>>>> Section 5.1, last paragraph: > >>>>>>>>>> > >>>>>>>>>> Please change the following: > >>>>>>>>>> "For example, RMD can define a local QSPEC that > >>>>>>>>>> > >>>>>> contains TMOD = > >>>>>> > >>>>>>>>>> bandwidth (sets r=p, b/m to large)." > >>>>>>>>>> > >>>>>>>>>> Into: > >>>>>>>>>> "For example, in RMD the TMOD parameters contained in > >>>>>>>>>> > >>>>>>> the original > >>>>>>> > >>>>>>>>>> initiator QSPEC are mapped into the equivalent TMOD > >>>>>>>>>> > >>>>> parameter > >>>>> > >>>>>>>>>> representing only the peak bandwidth in the local QSPEC." > >>>>>>>>>> > >>>>>>>>> OK with me. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Comment_6: > >>>>>>>>>> ------------- > >>>>>>>>>> In Section 5.3.1, 5.3.2, 5.3.3 the rules that have to > >>>>>>>>>> > >>>>>>> be followed > >>>>>>> > >>>>>>>>>> regarding the QSPEC control information are not given: > >>>>>>>>>> > >>>>>>>>>> Please include the following paragraph at the end of > >>>>>>>>>> > >>>>>>> this section: > >>>>>>> > >>>>>>>>>> "Regarding QSPEC Control Information, the default rule > >>>>>>>>>> > >>>>>>> is that all > >>>>>>> > >>>>>>>>>> QSPEC 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. When > >>>>>>>>>> > >>>>>>> traveling in the > >>>>>>> > >>>>>>>>>> RESPONSE message, all QSPEC Control Information > >>>>>>>>>> > >>>>>>> parameters are > >>>>>>> > >>>>>>>>>> read-only. Note that a QOSM specification may > >>>>>>>>>> > >>>>>> define its own > >>>>>> > >>>>>>>>>> QOSM-specific Control Information parameters and > >>>>>>>>>> processing rules." > >>>>>>>>>> > >>>>>>>>> Please see previous email comment on QSPEC control > >>>>>>>>> > >>>>> information. > >>>>> > >>>>>>>> Georgios: I think that a description of how the > >>>>>>>> > >>> QSPEC control > >>> > >>>>>>>> information is handled is needed. > >>>>>>>> > >>>>>>> Please see above comments on 'control information' > terminology. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Jerry > >>>>>>> > >>>>>>> > >>>>>>>>>> Comment_7: > >>>>>>>>>> ------------ > >>>>>>>>>> Section 6.1: > >>>>>>>>>> I do not understand the second sentence from the > >>>>>>>>>> > >>> below two > >>> > >>>>>>>>>> sentences: > >>>>>>>>>> "N Flag: Not-supported QSPEC parameter flag (see > >>>>>>>>>> > >>>>>> Section 5.2.2). > >>>>>> > >>>>>>>>>> For QSPEC parameters the value of this flag > >>>>>>>>>> > >>>>>>> is always > >>>>>>> > >>>>>>>>>> zero." > >>>>>>>>>> > >>>>>>>>> Good catch, this is a typo, the sentence should be removed. > >>>>>>>>> > >>>>>>>>> > >>>>>>>> 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 > >>> > >>> > > > > _______________________________________________ > > 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 Jan 04 08:16:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SS2-0004xz-63; Thu, 04 Jan 2007 08:16:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SS0-0004qV-PN for nsis@ietf.org; Thu, 04 Jan 2007 08:16:08 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2SRy-0001Pb-9V for nsis@ietf.org; Thu, 04 Jan 2007 08:16:08 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l04DE8J0029200; Thu, 4 Jan 2007 15:14:24 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 15:15:25 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 15:15:25 +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] QSPEC Template Draft Review Date: Thu, 4 Jan 2007 15:15:28 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Template Draft Review Thread-Index: AccvPnb/T/Ja08LeQkq0WtRCgH25jgAw7t/w From: To: , X-OriginalArrivalTime: 04 Jan 2007 13:15:25.0722 (UTC) FILETIME=[65AC7FA0:01C73002] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Dave, >And herein lies the core of the issue that has bedeviled the=20 >working group lately (and perhaps since inception, I don't=20 >know since my participation has been sporadic). I see the=20 >purpose of NSIS to define a signaling scheme which works=20 >end-to-end on the Internet, rather than just an architecture=20 >and template for defining a set of non- interoperable custom,=20 >per-network QoS signaling and description schemes. To do this=20 >there have to be a core set of QoS parameters which are=20 >universally understood from which you can build the vast=20 >majority of QoS schemes. Let's face it, the number of feasible=20 >data plane queueing/scheduling/policing/shaping algorithms is=20 >in fact not that large. I think it has yet to be demonstrated=20 >that the network- specific QoS parameter cannot in all but=20 >some corner cases be represented using the parameters we have=20 >come up with. Most of the argument has been based on RMFs that=20 >wish to be "simpler" than the general case in which the exact=20 >constraints and traffic model parameters of the source are=20 >enforced. This is fine, but it does NOT mean that we need a=20 >free-for-all in terms of parameter space. It is in fact why we=20 >restructured the Qspec parameters so that the user could be=20 >explicit and control what is advisory and what is mandatory=20 >for admission. I agree that this is the goal, in my opinion. There might be some QoSM domains that do a little extra, but I think they need to provide the ability to perform end-to-end signaling. It has never been a goal of the working group to support non-interworking QoS models, or QoS models that would not support end-to-end signaling. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 04 08:40:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SpB-0002fd-Lk; Thu, 04 Jan 2007 08:40:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SpB-0002fS-3A for nsis@ietf.org; Thu, 04 Jan 2007 08:40:05 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Sp7-0005df-Ga for nsis@ietf.org; Thu, 04 Jan 2007 08:40:04 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l04DdvJ2006800; Thu, 4 Jan 2007 14:39:57 +0100 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 l04Ddv0d024729; Thu, 4 Jan 2007 14:39:57 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 14:39:57 +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: AW: [NSIS] QSPEC Template Draft Review Date: Thu, 4 Jan 2007 14:39:55 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC02529729@MCHP7R6A.ww002.siemens.net> In-Reply-To: <002101c72ffe$2d0ddb70$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Template Draft Review Thread-Index: Accv977tXzdUrCdzRFu++WT8JyllEgABFwVwAAJPv1A= From: "Tschofenig, Hannes" To: "Georgios Karagiannis" , "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jan 2007 13:39:57.0592 (UTC) FILETIME=[D2FA0980:01C73005] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97b8643c8d9cc60b17ea5996f3e435cb Cc: David R Oran , 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, > Hi Hannes >=20 > I believe that what you propose in this e-mail is different=20 > than what you proposed in the earlier e-mail! I haven't proposed anything in my mail. I tried to understand the new draft version and the implications.=20 I responded to your mail that told me that the QSPEC draft now requires QoSMs to support all signaling modes. If this is the desired behavior then the QSPEC draft has to be changed in the way I indicated.=20 I would like to better understand the implications.=20 Ciao Hannes >=20 > What I would prefer to add to the existing QOSM related list is the > following text: > =20 > "The definition of a QoS model may also have implications=20 > on how local > behavior should be implemented in the areas where the QoS=20 > NSLP gives > freedom to implementers. For example, it may be useful to identify > recommended behavior for how a RESERVE message that is forwarded > relates to that received, or when additional signaling sessions > should be started based on existing sessions, such as required for > aggregate reservations. In some cases, suggestions may be made on > whether state that may optionally be retained should be held in > particular scenarios. A QoS model may specify reservation > preemption, e.g., an incoming resource request may cause removal of > an earlier reservation." >=20 > Best Regards, > Georgios >=20 >=20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > Sent: donderdag 4 januari 2007 12:58 > > To: Georgios Karagiannis > > Cc: 'David R Oran'; nsis@ietf.org > > Subject: Re: [NSIS] QSPEC Template Draft Review > >=20 > > Hi Georgios, > >=20 > > if this is the case then the following text needs to be changed: > >=20 > > A QOSM specification MUST include the following: > >=20 > > - role of QNEs, e.g., location, frequency, statefulness, etc. > > - QSPEC definition including QSPEC parameters [hannes]=20 > > Replace the following statement with: > > " > > - QSPEC procedures applicable to this QOSM " > > this one: > > " > > - QSPEC signaling description for all signaling exchanges. > > The signaling exchanges are listed in Section 5.3. > > " > >=20 > > - QNE processing rules describing how QSPEC information=20 > is treated > > and interpreted in the RMF, e.g., > > admission control, scheduling, policy control, QoS parameter > > accumulation (e.g., delay). > > - at least one bit-level QSPEC example > > - QSPEC parameter behavior for new QSPEC parameters the QOSM > > specification defines > > - define what happens in case of preemption if the default QNI > > behavior (tear down preempted reservation) is not followed (see > > Section 5.3.5) > >=20 > > Ciao > > Hannes > >=20 > >=20 > > Georgios Karagiannis wrote: > > > Hi Hannes > > > > > > Regarding the following point: > > > =20 > > >>> * Signaling > > >>> =20 > > > > > > =20 > > >>> Different QoSMs can nicely interwork if > > >>> a) the QoS NSLP or the QSPEC document mandates a single=20 > signaling=20 > > >>> mode > > >>> b) all QoSMs "support" all signaling modes. > > >>> By support I mean that they describe what needs to be=20 > done in the > > >>> =20 > > > different cases.=20 > > > =20 > > >>> Returning a failure might also be a possible option. > > >>> =20 > > > > > > =20 > > >>> While all possible signaling modes are described in the QSPEC=20 > > >>> document I couldn't see a mandate for a QoSM document to also=20 > > >>> describe what todo > > >>> =20 > > > for all the signaling modes. > > > > > > =20 > > >>> [[ I call the signaling exchanges and respective message=20 > > processing=20 > > >>> rules in this context "signaling modes" lacking a better term.]] > > >>> =20 > > > > > > Regarding signaling the NSIS WG introduced the concept of=20 > > QOSM to be=20 > > > able to support your b) option: > > > =20 > > >>> b) all QoSMs "support" all signaling modes. > > >>> By support I mean that they describe what needs to be=20 > done in the > > >>> =20 > > > different cases.=20 > > > =20 > > >>> Returning a failure might also be a possible option. > > >>> =20 > > > > > > Best Regards, > > > Georgios > > > > > > =20 > > > > > > =20 > > >> -----Original Message----- > > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >> Sent: woensdag 3 januari 2007 22:22 > > >> To: David R Oran > > >> Cc: nsis@ietf.org > > >> Subject: Re: [NSIS] QSPEC Template Draft Review > > >> > > >> Hi Dave, > > >> > > >> thanks for your quick response. > > >> > > >> David R Oran wrote: > > >> =20 > > >>> On Jan 3, 2007, at 6:16 AM, Hannes Tschofenig wrote: > > >>> > > >>> =20 > > >>>> Hi David, > > >>>> > > >>>> David R Oran wrote: > > >>>> =20 > > >>>>> On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote: > > >>>>> > > >>>>> =20 > > >>> [snip] > > >>> =20 > > >>>>>> With this respect, the abstract and Section 5.4 regarding=20 > > >>>>>> extensibility have to be updated. > > >>>>>> > > >>>>>> Usage of RFC 2119 language is a bit challenging in=20 > > this document=20 > > >>>>>> given that it means "If a QoSM decides to use a certain > > >>>>>> =20 > > >> parameter > > >> =20 > > >>>>>> then it must implement the parameter as mentioned in this=20 > > >>>>>> document.". Do you need to a normative reference since > > >>>>>> =20 > > >> it is just a > > >> =20 > > >>>>>> template of QoS parameters? > > >>>>>> > > >>>>>> =20 > > >>>>> I think so, at least in the sense that the parameters=20 > have well=20 > > >>>>> defined semantics that are not dependent of any local > > >>>>> =20 > > >> QoSM's whim to > > >> =20 > > >>>>> redefine. If a given QNI says "I want delay variance > > >>>>> =20 > > >> under 200ms and > > >> =20 > > >>>>> if you can't give it to me I don't want my traffic=20 > > admitted" then=20 > > >>>>> the QoSM can't just ignore that or decide that it means=20 > > something=20 > > >>>>> else. For example if an RMF in one of the nodes allows an > > >>>>> =20 > > >> EF queue > > >> =20 > > >>>>> for other traffic with a maximum depth more than 200ms > > >>>>> =20 > > >> then there's > > >> =20 > > >>>>> no way it can admit the traffic needing a delay variance > > >>>>> =20 > > >> under 200ms. > > >> =20 > > >>>> I see it differently. The current collection of parameters are=20 > > >>>> available to a QoSM designer. They can decide whether to=20 > > use it or=20 > > >>>> define something new. Every QoSM is allowed to define > > >>>> =20 > > >> whatever they > > >> =20 > > >>>> want. If I want to define a IEEE 802.16e QoSM then=20 > nobody should=20 > > >>>> prevent me from doing so. I would want to use the > > >>>> =20 > > >> parameters that are > > >> =20 > > >>>> available in the IEEE spec. For example, when I tried=20 > to map the=20 > > >>>> existing QSPEC parameters to the existing IEEE 802.16e=20 > > parameters=20 > > >>>> then I noticed that they are similar but not exactly the > > >>>> =20 > > >> same. Hence, > > >> =20 > > >>>> even if they look similar I would like to define my own > > >>>> =20 > > >> based on .16e > > >> =20 > > >>>> rather than reusing the QSPEC parameters. > > >>>> > > >>>> =20 > > >>> And herein lies the core of the issue that has bedeviled > > >>> =20 > > >> the working > > >> =20 > > >>> group lately (and perhaps since inception, I don't know=20 > since my=20 > > >>> participation has been sporadic). I see the purpose of NSIS > > >>> =20 > > >> to define > > >> =20 > > >>> a signaling scheme which works end-to-end on the Internet, > > >>> =20 > > >> rather than > > >> =20 > > >>> just an architecture and template for defining a set of=20 > > >>> non-interoperable custom, per-network QoS signaling and=20 > > description=20 > > >>> schemes. To do this there have to be a core set of QoS=20 > parameters=20 > > >>> which are universally understood from which you can build=20 > > the vast=20 > > >>> majority of QoS schemes. Let's face it, the number of=20 > > feasible data=20 > > >>> plane queueing/scheduling/policing/shaping algorithms is in > > >>> =20 > > >> fact not > > >> =20 > > >>> that large. > > >>> I think it has yet to be demonstrated that the=20 > > network-specific QoS=20 > > >>> parameter cannot in all but some corner cases be > > >>> =20 > > >> represented using the > > >> =20 > > >>> parameters we have come up with. Most of the argument has > > >>> =20 > > >> been based > > >> =20 > > >>> on RMFs that wish to be "simpler" than the general case in > > >>> =20 > > >> which the > > >> =20 > > >>> exact constraints and traffic model parameters of the=20 > source are=20 > > >>> enforced. This is fine, but it does NOT mean that we need a=20 > > >>> free-for-all in terms of parameter space. It is in fact why we=20 > > >>> restructured the Qspec parameters so that the user could be > > >>> =20 > > >> explicit > > >> =20 > > >>> and control what is advisory and what is mandatory for=20 > admission. > > >>> > > >>> Even more important, we don't need a free-for-all in the > > >>> =20 > > >> operation of > > >> =20 > > >>> QoS NSLP. The idea that the QoSM can change the signaling state=20 > > >>> machines for the NSLP is quite scary to me, which is why I > > >>> =20 > > >> suggested > > >> =20 > > >>> the language which said a QOSM isn't permitted to redefine > > >>> =20 > > >> the way QOS > > >> =20 > > >>> NSLP works. > > >>> > > >>> It's pretty clear that a number of people on the WG > > >>> =20 > > >> disagree with this > > >> =20 > > >>> position. That's fine - I said I'd shut up if the WG > > >>> =20 > > >> consensus went a > > >> =20 > > >>> different way. However, I do detect the weight of opinion > > >>> =20 > > >> being closer > > >> =20 > > >>> to what I wrote above. I'll leave it to the WG chair to=20 > > assess this. > > >>> =20 > > >> There are a few aspects that need to be discussed here. > > >> > > >> I read the QSPEC draft many, many times already (and different=20 > > >> versions). Whenever I read through the abstract and the=20 > > introduction=20 > > >> I had the impression that I understood what the rest of=20 > > the document=20 > > >> is going to contain. I was always wrong. This time I was=20 > wrong as=20 > > >> well. > > >> > > >> It shouldn't be too difficult to tell the reader what=20 > the document=20 > > >> wants to accomplish. If I don't understand it then how=20 > > should someone=20 > > >> else (slightly ignoring the fact that everyone else might be=20 > > >> smarter)? > > >> > > >> Let us separate the signaling from the QoS parameter story=20 > > since they=20 > > >> are largely a different subject. Let us try to understand what=20 > > >> interoperability means. > > >> > > >> * Signaling > > >> > > >> Different QoSMs can nicely interwork if > > >> a) the QoS NSLP or the QSPEC document mandates a single=20 > signaling=20 > > >> mode > > >> b) all QoSMs "support" all signaling modes. > > >> By support I mean that they describe what needs to be=20 > done in the=20 > > >> different cases. Returning a failure might also be a=20 > > possible option. > > >> > > >> While all possible signaling modes are described in the QSPEC=20 > > >> document I couldn't see a mandate for a QoSM document to also=20 > > >> describe what todo for all the signaling modes. > > >> > > >> [[ I call the signaling exchanges and respective message=20 > > processing=20 > > >> rules in this context "signaling modes" lacking a better term.]] > > >> > > >> * QoS Parameters > > >> > > >> From an interoperability point of view it would be ideal=20 > > to have a=20 > > >> single QoSM that is understood by everyone. I got the=20 > > impression that=20 > > >> this was the initial goal of the QSPEC document. Having a=20 > > core set of=20 > > >> parameters that are understood by everyone and a few optional=20 > > >> parameters was an interesting idea, I thought. [[ I was=20 > > never really=20 > > >> 100 % convinced that it can actually work but that's=20 > > another story. I=20 > > >> personally was just unhappy about the choice of mandatory=20 > > parameters.=20 > > >> ]] > > >> > > >> Another alternative is to define mappings from one QoSM=20 > to another=20 > > >> one.This is done today already but there are no procedures and=20 > > >> documents in the NSIS working group for defining these=20 > > mappings. With=20 > > >> this approach every QoSM can essentially define whatever=20 > > they want if=20 > > >> a reasonable mapping exists. > > >> > > >> Having a mapping is obviously better than just looking at=20 > > >> mandatory-to-understand parameters (and ignoring the optional=20 > > >> parameters). > > >> > > >> From your description it seems that the QSPEC contains a=20 > > number of=20 > > >> parameters that are supposed to be complete and MUST be used by=20 > > >> future QoSMs. To avoid interoperability problems QoSMs=20 > > ideally must=20 > > >> never not introduce parameters. > > >> Since some of QSPEC authors are also QoSM authors they=20 > > ensured that=20 > > >> their QoSM is nicely supported. To allow the end-to-end=20 > > story to work=20 > > >> it is necessary to consider today's access networks and the QoS=20 > > >> parameters that are being used there. Is someone ever=20 > > wants to use a=20 > > >> path-coupled signaling solution then two approaches are possible > > >> a) the end host already uses a QoS signaling protocol=20 > like RSVP or=20 > > >> NSIS > > >> b) the end host uses a link layer protocol (with QoS > > >> extensions) towards the access network and the network=20 > > triggers the=20 > > >> NSIS signaling exchange [A combination of the two is also=20 > > possible.] > > >> > > >> In any case I guess you have to deal with the QoS=20 > > parameters of the=20 > > >> specific link layer. I wonder whether someone has looked=20 > at these=20 > > >> issues already and whether the QSPEC QoS parameter and=20 > local QoSM=20 > > >> model supports this extensibility. > > >> > > >> As an example, the Traffic Priority as defined in=20 > > IEEE802.16e has 8=20 > > >> priority levels. What would I do? This parameter does not=20 > > correspond=20 > > >> to anything in the QSPEC document at the moment. > > >> > > >> The typical question I have is: I want to implement QoSM X.=20 > > >> What do I have to implement from the QSPEC draft? > > >> > > >> [ A minor technical issue: Are there problems (in the=20 > > IETF document > > >> processing) if normative references point to documents that are=20 > > >> non-IETF documents? ] > > >> > > >> I am not sure I understood your comment regarding " > > >> The idea that the QoSM can change the signaling state=20 > machines for=20 > > >> the NSLP is quite scary to me, which is why I suggested=20 > > the language=20 > > >> which said a QOSM isn't permitted to redefine the way QOS=20 > > NSLP works. > > >> " > > >> > > >> =20 > > >>>> The idea of a template is to offer a set of parameters > > >>>> =20 > > >> that might be > > >> =20 > > >>>> used when building QoSMs. With a specific QoSM some of=20 > > these QSPEC=20 > > >>>> parameters are hopefully implemented. > > >>>> > > >>>> =20 > > >>> If the QSPEC specification is viewed as just a > > >>> =20 > > >> template/base schema, > > >> =20 > > >>> then I think we will have failed pretty miserably. We=20 > > will have the=20 > > >>> illusion of interoperability and not real interoperability. > > >>> =20 > > >> This is what I read from the abstract and the=20 > > introduction. Maybe it=20 > > >> would be appropriate to delete the term "template" from=20 > > the document. > > >> > > >> > > >> =20 > > >>>> The question with the parameter selection is therefore:=20 > > Are these=20 > > >>>> useful parameters that might be reused by a number of QoSMs? > > >>>> > > >>>> =20 > > >>> I'd turn it around and say "given that end-to-end QoS > > >>> =20 > > >> interoperability > > >> =20 > > >>> is a main goal of NSIS, does the particular QoSM achieve=20 > > this well=20 > > >>> enough to admit the traffic as requested by the QNI".=20 > If the QoSM=20 > > >>> can't do what the user asked then it's the job of the QSPEC > > >>> =20 > > >> semantics > > >> =20 > > >>> and the QOS NSLP signaling machinery to not admit the=20 > > traffic, and=20 > > >>> tell the user why. It's up to the user/QNI to formulate QoS > > >>> =20 > > >> requests > > >> =20 > > >>> that are adequate to the needs of the application but which > > >>> =20 > > >> have high > > >> =20 > > >>> probability of being admitted under conditions where there are=20 > > >>> adequate resources. QoS NSLP and Qspecs (as we have them in the=20 > > >>> current drafts) give us the tools to accomplish this. If we > > >>> =20 > > >> treat the > > >> =20 > > >>> Qspec parameters just as "useful suggestions" I think we=20 > > will have=20 > > >>> pretty definitely sacrificed this goal for the Internet, > > >>> =20 > > >> which is what > > >> =20 > > >>> NSIS exists for. > > >>> =20 > > >> This sounds like a very nice. When it comes to the details=20 > > things get=20 > > >> a bit more difficult. > > >> > > >> =20 > > >>>>>> Regarding processing description: > > >>>>>> > > >>>>>> I never understood why the processing description is > > >>>>>> =20 > > >> also provided > > >> =20 > > >>>>>> in this document. I provided this comment already in the > > >>>>>> =20 > > >> past but > > >> =20 > > >>>>>> obviously the authors didn't like it too much. Not a=20 > big deal=20 > > >>>>>> though. In some sense it is largely a matter of taste anyway. > > >>>>>> Instead of reducing the processing description it=20 > was actually=20 > > >>>>>> enhanced; I was surprised to find a QSPEC encapsulation > > >>>>>> =20 > > >> technique > > >> =20 > > >>>>>> in Section 5.1. I always thought that this is a QoS NSLP > > >>>>>> =20 > > >> draft aspect. > > >> =20 > > >>>>> Well, this was the subject of a spirited debate among > > >>>>> =20 > > >> some of the WG > > >> =20 > > >>>>> participants. I didn't particularly like the way it > > >>>>> =20 > > >> turned out, but > > >> =20 > > >>>>> there seems to be rough consensus that QSPEC > > >>>>> =20 > > >> encapsulation should be > > >> =20 > > >>>>> part of other QSPEC itself. > > >>>>> =20 > > >>>> I must have missed this discussion. If people like it that > > >>>> =20 > > >> way then > > >> =20 > > >>>> it should be fine. > > >>>> > > >>>> =20 > > >>>>>> This is probably a document writing style and a matter of=20 > > >>>>>> worksplit between the QoS NSLP and the QSPEC document=20 > > authors. A=20 > > >>>>>> deployable solution requires GIST, the QoS NSLP, the=20 > > QSPEC and a=20 > > >>>>>> QoSM (and the AAA part) and a reader might want to read > > >>>>>> =20 > > >> all these > > >> =20 > > >>>>>> documents anyway. > > >>>>>> > > >>>>>> Section 5.3 should be informative only; no RFC 2119 > > >>>>>> =20 > > >> language since > > >> =20 > > >>>>>> the current text just outlines all possible combinations.=20 > > >>>>>> Currently, one can sometimes find RFC 2119 language in some=20 > > >>>>>> subsections. The QoSMs provide the normative text and > > >>>>>> =20 > > >> may restrict > > >> =20 > > >>>>>> the available combinations. [[Note that this might raise=20 > > >>>>>> interesting problems given that different QoSMs implement a=20 > > >>>>>> different signaling behavior and interworking between=20 > > different=20 > > >>>>>> QoSMs might be really challenging. > > >>>>>> =20 > > >>>>> This was one of the reasons I proposed restricting the > > >>>>> =20 > > >> variability > > >> =20 > > >>>>> among QOSMs to be in the RMF only and not to allow different=20 > > >>>>> signaling semantics. I lost that one. > > >>>>> =20 > > >>>> Another alternative is that the QSPEC document demands=20 > that QoSM=20 > > >>>> documents define all possible signaling behaviors. Then it > > >>>> =20 > > >> would be > > >> =20 > > >>>> fine as well. It would make the QoSMs more complicated. I, > > >>>> =20 > > >> btw, was > > >> =20 > > >>>> never in favor of receiver-initiated signaling behavior=20 > > since the=20 > > >>>> authorization story is really mood. > > >>>> > > >>>> > > >>>> Do you agree with me that RFC 2119 language shouldn't=20 > be used in=20 > > >>>> Section 5.3? > > >>>> > > >>>> =20 > > >>> I see no problem with the (quite limited) use of RFC2119 > > >>> =20 > > >> language in > > >> =20 > > >>> the places in section 5.3 where it appears. It seems quite > > >>> =20 > > >> appropriate > > >> =20 > > >>> to me,. > > >>> > > >>> =20 > > >> I need to read through each paragraph to determine what the=20 > > >> implications are. > > >> > > >> =20 > > >>>>>> For example, what happens if a receiver-initiated > > >>>>>> =20 > > >> reservation meets > > >> =20 > > >>>>>> a domain with a QoS model that only supports=20 > sender-initiated=20 > > >>>>>> reservations.]] > > >>>>>> > > >>>>>> =20 > > >>>>> In order to make this work I think you have to have recursive=20 > > >>>>> signaling at the edge of the domain. > > >>>>> =20 > > >>>> Correct. > > >>>> > > >>>> As an example, in RMD these different cases got considered. > > >>>> > > >>>> If you only assume that sender-initiated reservations=20 > exist then=20 > > >>>> documents are simpler since they obviously don't need to > > >>>> =20 > > >> consider all > > >> =20 > > >>>> the different cases. > > >>>> We noticed this problem already with the mobility document > > >>>> =20 > > >> where the > > >> =20 > > >>>> receiver-initiated reservations are just painful. > > >>>> > > >>>> =20 > > >>> But this is up to the applications which is more > > >>> =20 > > >> useful/natural, no?=20 > > >> =20 > > >>> If you are saying that receiver-initiated is harder to > > >>> =20 > > >> achieve under > > >> =20 > > >>> some circumstances, then sure. Applications should be=20 > > cognizant of=20 > > >>> that and use receiver-initiated only when they can't > > >>> =20 > > >> conveniently use > > >> =20 > > >>> sender-initiated. Conversely, some applications (e.g.=20 > > multicast and > > >>> multi-unicast) can get all tied up in knots with=20 > sender-initiated=20 > > >>> reservations. But to say that interoperability fails > > >>> =20 > > >> because some QoSM > > >> =20 > > >>> decides receiver-initiated reservations are a pain and > > >>> =20 > > >> redefines QOS > > >> =20 > > >>> NSLP to eliminate them over its domain strikes me as a=20 > very poor=20 > > >>> tradeoff. > > >>> =20 > > >> I agree with your statement about multicast QoS reservations.=20 > > >> I wonder > > >> whether someone wants to use path-coupled QoS signaling=20 > > for multicast=20 > > >> communication. > > >> > > >> > > >> Ciao > > >> Hannes > > >> > > >> =20 > > >>> Cheers, Dave. > > >>> > > >>> =20 > > >>>>>> That's it for now. I will provide more detailed=20 > comments later. > > >>>>>> > > >>>>>> Ciao > > >>>>>> Hannes > > >>>>>> > > >>>>>> > > >>>>>> =20 > > >>>> Ciao > > >>>> Hannes > > >>>> > > >>>> =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 > >=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 Thu Jan 04 08:43:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SsD-0004Vi-Et; Thu, 04 Jan 2007 08:43:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SsC-0004VX-RM for nsis@ietf.org; Thu, 04 Jan 2007 08:43:12 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Ss9-0006Wx-Pe for nsis@ietf.org; Thu, 04 Jan 2007 08:43:12 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l04Dgqgn007339; Thu, 4 Jan 2007 14:42:56 +0100 (MET) From: "Georgios Karagiannis" To: "'Tschofenig, Hannes'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] QSPEC Template Draft Review Date: Thu, 4 Jan 2007 14:42:55 +0100 Message-ID: <002a01c73006$40073660$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.3028 Thread-Index: Accv977tXzdUrCdzRFu++WT8JyllEgABFwVwAAJPv1AAADBHUA== In-Reply-To: <6F0CB04509C11D46A54232E852E390AC02529729@MCHP7R6A.ww002.siemens.net> X-Spam-Score: 0.249 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 04 Jan 2007 14:42:59 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 959bc20619a369a796f66bb9e13b5f74 Cc: 'David R Oran' , 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 If the the folowing paragraph is added to the proposed QoS model capability list it will satisfy my concerns on this issue: "The definition of a QoS model may also have implications on how local behavior should be implemented in the areas where the QoS NSLP gives freedom to implementers. For example, it may be useful to identify recommended behavior for how a RESERVE message that is forwarded relates to that received, or when additional signaling sessions should be started based on existing sessions, such as required for aggregate reservations. In some cases, suggestions may be made on whether state that may optionally be retained should be held in particular scenarios. A QoS model may specify reservation preemption, e.g., an incoming resource request may cause removal of an earlier reservation." Best regards, Georgios > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: donderdag 4 januari 2007 14:40 > To: Georgios Karagiannis; Hannes Tschofenig > Cc: David R Oran; nsis@ietf.org > Subject: AW: [NSIS] QSPEC Template Draft Review > > Hi Georgios, > > > > Hi Hannes > > > > I believe that what you propose in this e-mail is different > than what > > you proposed in the earlier e-mail! > > I haven't proposed anything in my mail. I tried to understand > the new draft version and the implications. > > I responded to your mail that told me that the QSPEC draft > now requires QoSMs to support all signaling modes. If this is > the desired behavior then the QSPEC draft has to be changed > in the way I indicated. > > I would like to better understand the implications. > > Ciao > Hannes > > > > > What I would prefer to add to the existing QOSM related list is the > > following text: > > > > "The definition of a QoS model may also have implications on how > > local > > behavior should be implemented in the areas where the QoS NSLP > > gives > > freedom to implementers. For example, it may be useful > to identify > > recommended behavior for how a RESERVE message that is forwarded > > relates to that received, or when additional signaling sessions > > should be started based on existing sessions, such as > required for > > aggregate reservations. In some cases, suggestions may be made on > > whether state that may optionally be retained should be held in > > particular scenarios. A QoS model may specify reservation > > preemption, e.g., an incoming resource request may cause > removal of > > an earlier reservation." > > > > Best Regards, > > Georgios > > > > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: donderdag 4 januari 2007 12:58 > > > To: Georgios Karagiannis > > > Cc: 'David R Oran'; nsis@ietf.org > > > Subject: Re: [NSIS] QSPEC Template Draft Review > > > > > > Hi Georgios, > > > > > > if this is the case then the following text needs to be changed: > > > > > > A QOSM specification MUST include the following: > > > > > > - role of QNEs, e.g., location, frequency, statefulness, etc. > > > - QSPEC definition including QSPEC parameters [hannes] Replace > > > the following statement with: > > > " > > > - QSPEC procedures applicable to this QOSM " > > > this one: > > > " > > > - QSPEC signaling description for all signaling exchanges. > > > The signaling exchanges are listed in Section 5.3. > > > " > > > > > > - QNE processing rules describing how QSPEC information > > is treated > > > and interpreted in the RMF, e.g., > > > admission control, scheduling, policy control, QoS parameter > > > accumulation (e.g., delay). > > > - at least one bit-level QSPEC example > > > - QSPEC parameter behavior for new QSPEC parameters the QOSM > > > specification defines > > > - define what happens in case of preemption if the default QNI > > > behavior (tear down preempted reservation) is not > followed (see > > > Section 5.3.5) > > > > > > Ciao > > > Hannes > > > > > > > > > Georgios Karagiannis wrote: > > > > Hi Hannes > > > > > > > > Regarding the following point: > > > > > > > >>> * Signaling > > > >>> > > > > > > > > > > > >>> Different QoSMs can nicely interwork if > > > >>> a) the QoS NSLP or the QSPEC document mandates a single > > signaling > > > >>> mode > > > >>> b) all QoSMs "support" all signaling modes. > > > >>> By support I mean that they describe what needs to be > > done in the > > > >>> > > > > different cases. > > > > > > > >>> Returning a failure might also be a possible option. > > > >>> > > > > > > > > > > > >>> While all possible signaling modes are described in the QSPEC > > > >>> document I couldn't see a mandate for a QoSM document to also > > > >>> describe what todo > > > >>> > > > > for all the signaling modes. > > > > > > > > > > > >>> [[ I call the signaling exchanges and respective message > > > processing > > > >>> rules in this context "signaling modes" lacking a > better term.]] > > > >>> > > > > > > > > Regarding signaling the NSIS WG introduced the concept of > > > QOSM to be > > > > able to support your b) option: > > > > > > > >>> b) all QoSMs "support" all signaling modes. > > > >>> By support I mean that they describe what needs to be > > done in the > > > >>> > > > > different cases. > > > > > > > >>> Returning a failure might also be a possible option. > > > >>> > > > > > > > > Best Regards, > > > > Georgios > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > >> Sent: woensdag 3 januari 2007 22:22 > > > >> To: David R Oran > > > >> Cc: nsis@ietf.org > > > >> Subject: Re: [NSIS] QSPEC Template Draft Review > > > >> > > > >> Hi Dave, > > > >> > > > >> thanks for your quick response. > > > >> > > > >> David R Oran wrote: > > > >> > > > >>> On Jan 3, 2007, at 6:16 AM, Hannes Tschofenig wrote: > > > >>> > > > >>> > > > >>>> Hi David, > > > >>>> > > > >>>> David R Oran wrote: > > > >>>> > > > >>>>> On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote: > > > >>>>> > > > >>>>> > > > >>> [snip] > > > >>> > > > >>>>>> With this respect, the abstract and Section 5.4 regarding > > > >>>>>> extensibility have to be updated. > > > >>>>>> > > > >>>>>> Usage of RFC 2119 language is a bit challenging in > > > this document > > > >>>>>> given that it means "If a QoSM decides to use a certain > > > >>>>>> > > > >> parameter > > > >> > > > >>>>>> then it must implement the parameter as mentioned in this > > > >>>>>> document.". Do you need to a normative reference since > > > >>>>>> > > > >> it is just a > > > >> > > > >>>>>> template of QoS parameters? > > > >>>>>> > > > >>>>>> > > > >>>>> I think so, at least in the sense that the parameters > > have well > > > >>>>> defined semantics that are not dependent of any local > > > >>>>> > > > >> QoSM's whim to > > > >> > > > >>>>> redefine. If a given QNI says "I want delay variance > > > >>>>> > > > >> under 200ms and > > > >> > > > >>>>> if you can't give it to me I don't want my traffic > > > admitted" then > > > >>>>> the QoSM can't just ignore that or decide that it means > > > something > > > >>>>> else. For example if an RMF in one of the nodes allows an > > > >>>>> > > > >> EF queue > > > >> > > > >>>>> for other traffic with a maximum depth more than 200ms > > > >>>>> > > > >> then there's > > > >> > > > >>>>> no way it can admit the traffic needing a delay variance > > > >>>>> > > > >> under 200ms. > > > >> > > > >>>> I see it differently. The current collection of > parameters are > > > >>>> available to a QoSM designer. They can decide whether to > > > use it or > > > >>>> define something new. Every QoSM is allowed to define > > > >>>> > > > >> whatever they > > > >> > > > >>>> want. If I want to define a IEEE 802.16e QoSM then > > nobody should > > > >>>> prevent me from doing so. I would want to use the > > > >>>> > > > >> parameters that are > > > >> > > > >>>> available in the IEEE spec. For example, when I tried > > to map the > > > >>>> existing QSPEC parameters to the existing IEEE 802.16e > > > parameters > > > >>>> then I noticed that they are similar but not exactly the > > > >>>> > > > >> same. Hence, > > > >> > > > >>>> even if they look similar I would like to define my own > > > >>>> > > > >> based on .16e > > > >> > > > >>>> rather than reusing the QSPEC parameters. > > > >>>> > > > >>>> > > > >>> And herein lies the core of the issue that has bedeviled > > > >>> > > > >> the working > > > >> > > > >>> group lately (and perhaps since inception, I don't know > > since my > > > >>> participation has been sporadic). I see the purpose of NSIS > > > >>> > > > >> to define > > > >> > > > >>> a signaling scheme which works end-to-end on the Internet, > > > >>> > > > >> rather than > > > >> > > > >>> just an architecture and template for defining a set of > > > >>> non-interoperable custom, per-network QoS signaling and > > > description > > > >>> schemes. To do this there have to be a core set of QoS > > parameters > > > >>> which are universally understood from which you can build > > > the vast > > > >>> majority of QoS schemes. Let's face it, the number of > > > feasible data > > > >>> plane queueing/scheduling/policing/shaping algorithms is in > > > >>> > > > >> fact not > > > >> > > > >>> that large. > > > >>> I think it has yet to be demonstrated that the > > > network-specific QoS > > > >>> parameter cannot in all but some corner cases be > > > >>> > > > >> represented using the > > > >> > > > >>> parameters we have come up with. Most of the argument has > > > >>> > > > >> been based > > > >> > > > >>> on RMFs that wish to be "simpler" than the general case in > > > >>> > > > >> which the > > > >> > > > >>> exact constraints and traffic model parameters of the > > source are > > > >>> enforced. This is fine, but it does NOT mean that we need a > > > >>> free-for-all in terms of parameter space. It is in > fact why we > > > >>> restructured the Qspec parameters so that the user could be > > > >>> > > > >> explicit > > > >> > > > >>> and control what is advisory and what is mandatory for > > admission. > > > >>> > > > >>> Even more important, we don't need a free-for-all in the > > > >>> > > > >> operation of > > > >> > > > >>> QoS NSLP. The idea that the QoSM can change the > signaling state > > > >>> machines for the NSLP is quite scary to me, which is why I > > > >>> > > > >> suggested > > > >> > > > >>> the language which said a QOSM isn't permitted to redefine > > > >>> > > > >> the way QOS > > > >> > > > >>> NSLP works. > > > >>> > > > >>> It's pretty clear that a number of people on the WG > > > >>> > > > >> disagree with this > > > >> > > > >>> position. That's fine - I said I'd shut up if the WG > > > >>> > > > >> consensus went a > > > >> > > > >>> different way. However, I do detect the weight of opinion > > > >>> > > > >> being closer > > > >> > > > >>> to what I wrote above. I'll leave it to the WG chair to > > > assess this. > > > >>> > > > >> There are a few aspects that need to be discussed here. > > > >> > > > >> I read the QSPEC draft many, many times already (and different > > > >> versions). Whenever I read through the abstract and the > > > introduction > > > >> I had the impression that I understood what the rest of > > > the document > > > >> is going to contain. I was always wrong. This time I was > > wrong as > > > >> well. > > > >> > > > >> It shouldn't be too difficult to tell the reader what > > the document > > > >> wants to accomplish. If I don't understand it then how > > > should someone > > > >> else (slightly ignoring the fact that everyone else might be > > > >> smarter)? > > > >> > > > >> Let us separate the signaling from the QoS parameter story > > > since they > > > >> are largely a different subject. Let us try to understand what > > > >> interoperability means. > > > >> > > > >> * Signaling > > > >> > > > >> Different QoSMs can nicely interwork if > > > >> a) the QoS NSLP or the QSPEC document mandates a single > > signaling > > > >> mode > > > >> b) all QoSMs "support" all signaling modes. > > > >> By support I mean that they describe what needs to be > > done in the > > > >> different cases. Returning a failure might also be a > > > possible option. > > > >> > > > >> While all possible signaling modes are described in the QSPEC > > > >> document I couldn't see a mandate for a QoSM document to also > > > >> describe what todo for all the signaling modes. > > > >> > > > >> [[ I call the signaling exchanges and respective message > > > processing > > > >> rules in this context "signaling modes" lacking a > better term.]] > > > >> > > > >> * QoS Parameters > > > >> > > > >> From an interoperability point of view it would be ideal > > > to have a > > > >> single QoSM that is understood by everyone. I got the > > > impression that > > > >> this was the initial goal of the QSPEC document. Having a > > > core set of > > > >> parameters that are understood by everyone and a few optional > > > >> parameters was an interesting idea, I thought. [[ I was > > > never really > > > >> 100 % convinced that it can actually work but that's > > > another story. I > > > >> personally was just unhappy about the choice of mandatory > > > parameters. > > > >> ]] > > > >> > > > >> Another alternative is to define mappings from one QoSM > > to another > > > >> one.This is done today already but there are no procedures and > > > >> documents in the NSIS working group for defining these > > > mappings. With > > > >> this approach every QoSM can essentially define whatever > > > they want if > > > >> a reasonable mapping exists. > > > >> > > > >> Having a mapping is obviously better than just looking at > > > >> mandatory-to-understand parameters (and ignoring the optional > > > >> parameters). > > > >> > > > >> From your description it seems that the QSPEC contains a > > > number of > > > >> parameters that are supposed to be complete and MUST > be used by > > > >> future QoSMs. To avoid interoperability problems QoSMs > > > ideally must > > > >> never not introduce parameters. > > > >> Since some of QSPEC authors are also QoSM authors they > > > ensured that > > > >> their QoSM is nicely supported. To allow the end-to-end > > > story to work > > > >> it is necessary to consider today's access networks > and the QoS > > > >> parameters that are being used there. Is someone ever > > > wants to use a > > > >> path-coupled signaling solution then two approaches > are possible > > > >> a) the end host already uses a QoS signaling protocol > > like RSVP or > > > >> NSIS > > > >> b) the end host uses a link layer protocol (with QoS > > > >> extensions) towards the access network and the network > > > triggers the > > > >> NSIS signaling exchange [A combination of the two is also > > > possible.] > > > >> > > > >> In any case I guess you have to deal with the QoS > > > parameters of the > > > >> specific link layer. I wonder whether someone has looked > > at these > > > >> issues already and whether the QSPEC QoS parameter and > > local QoSM > > > >> model supports this extensibility. > > > >> > > > >> As an example, the Traffic Priority as defined in > > > IEEE802.16e has 8 > > > >> priority levels. What would I do? This parameter does not > > > correspond > > > >> to anything in the QSPEC document at the moment. > > > >> > > > >> The typical question I have is: I want to implement QoSM X. > > > >> What do I have to implement from the QSPEC draft? > > > >> > > > >> [ A minor technical issue: Are there problems (in the > > > IETF document > > > >> processing) if normative references point to > documents that are > > > >> non-IETF documents? ] > > > >> > > > >> I am not sure I understood your comment regarding " > > > >> The idea that the QoSM can change the signaling state > > machines for > > > >> the NSLP is quite scary to me, which is why I suggested > > > the language > > > >> which said a QOSM isn't permitted to redefine the way QOS > > > NSLP works. > > > >> " > > > >> > > > >> > > > >>>> The idea of a template is to offer a set of parameters > > > >>>> > > > >> that might be > > > >> > > > >>>> used when building QoSMs. With a specific QoSM some of > > > these QSPEC > > > >>>> parameters are hopefully implemented. > > > >>>> > > > >>>> > > > >>> If the QSPEC specification is viewed as just a > > > >>> > > > >> template/base schema, > > > >> > > > >>> then I think we will have failed pretty miserably. We > > > will have the > > > >>> illusion of interoperability and not real interoperability. > > > >>> > > > >> This is what I read from the abstract and the > > > introduction. Maybe it > > > >> would be appropriate to delete the term "template" from > > > the document. > > > >> > > > >> > > > >> > > > >>>> The question with the parameter selection is therefore: > > > Are these > > > >>>> useful parameters that might be reused by a number of QoSMs? > > > >>>> > > > >>>> > > > >>> I'd turn it around and say "given that end-to-end QoS > > > >>> > > > >> interoperability > > > >> > > > >>> is a main goal of NSIS, does the particular QoSM achieve > > > this well > > > >>> enough to admit the traffic as requested by the QNI". > > If the QoSM > > > >>> can't do what the user asked then it's the job of the QSPEC > > > >>> > > > >> semantics > > > >> > > > >>> and the QOS NSLP signaling machinery to not admit the > > > traffic, and > > > >>> tell the user why. It's up to the user/QNI to formulate QoS > > > >>> > > > >> requests > > > >> > > > >>> that are adequate to the needs of the application but which > > > >>> > > > >> have high > > > >> > > > >>> probability of being admitted under conditions where > there are > > > >>> adequate resources. QoS NSLP and Qspecs (as we have > them in the > > > >>> current drafts) give us the tools to accomplish this. If we > > > >>> > > > >> treat the > > > >> > > > >>> Qspec parameters just as "useful suggestions" I think we > > > will have > > > >>> pretty definitely sacrificed this goal for the Internet, > > > >>> > > > >> which is what > > > >> > > > >>> NSIS exists for. > > > >>> > > > >> This sounds like a very nice. When it comes to the details > > > things get > > > >> a bit more difficult. > > > >> > > > >> > > > >>>>>> Regarding processing description: > > > >>>>>> > > > >>>>>> I never understood why the processing description is > > > >>>>>> > > > >> also provided > > > >> > > > >>>>>> in this document. I provided this comment already in the > > > >>>>>> > > > >> past but > > > >> > > > >>>>>> obviously the authors didn't like it too much. Not a > > big deal > > > >>>>>> though. In some sense it is largely a matter of > taste anyway. > > > >>>>>> Instead of reducing the processing description it > > was actually > > > >>>>>> enhanced; I was surprised to find a QSPEC encapsulation > > > >>>>>> > > > >> technique > > > >> > > > >>>>>> in Section 5.1. I always thought that this is a QoS NSLP > > > >>>>>> > > > >> draft aspect. > > > >> > > > >>>>> Well, this was the subject of a spirited debate among > > > >>>>> > > > >> some of the WG > > > >> > > > >>>>> participants. I didn't particularly like the way it > > > >>>>> > > > >> turned out, but > > > >> > > > >>>>> there seems to be rough consensus that QSPEC > > > >>>>> > > > >> encapsulation should be > > > >> > > > >>>>> part of other QSPEC itself. > > > >>>>> > > > >>>> I must have missed this discussion. If people like it that > > > >>>> > > > >> way then > > > >> > > > >>>> it should be fine. > > > >>>> > > > >>>> > > > >>>>>> This is probably a document writing style and a matter of > > > >>>>>> worksplit between the QoS NSLP and the QSPEC document > > > authors. A > > > >>>>>> deployable solution requires GIST, the QoS NSLP, the > > > QSPEC and a > > > >>>>>> QoSM (and the AAA part) and a reader might want to read > > > >>>>>> > > > >> all these > > > >> > > > >>>>>> documents anyway. > > > >>>>>> > > > >>>>>> Section 5.3 should be informative only; no RFC 2119 > > > >>>>>> > > > >> language since > > > >> > > > >>>>>> the current text just outlines all possible combinations. > > > >>>>>> Currently, one can sometimes find RFC 2119 > language in some > > > >>>>>> subsections. The QoSMs provide the normative text and > > > >>>>>> > > > >> may restrict > > > >> > > > >>>>>> the available combinations. [[Note that this might raise > > > >>>>>> interesting problems given that different QoSMs > implement a > > > >>>>>> different signaling behavior and interworking between > > > different > > > >>>>>> QoSMs might be really challenging. > > > >>>>>> > > > >>>>> This was one of the reasons I proposed restricting the > > > >>>>> > > > >> variability > > > >> > > > >>>>> among QOSMs to be in the RMF only and not to allow > different > > > >>>>> signaling semantics. I lost that one. > > > >>>>> > > > >>>> Another alternative is that the QSPEC document demands > > that QoSM > > > >>>> documents define all possible signaling behaviors. Then it > > > >>>> > > > >> would be > > > >> > > > >>>> fine as well. It would make the QoSMs more complicated. I, > > > >>>> > > > >> btw, was > > > >> > > > >>>> never in favor of receiver-initiated signaling behavior > > > since the > > > >>>> authorization story is really mood. > > > >>>> > > > >>>> > > > >>>> Do you agree with me that RFC 2119 language shouldn't > > be used in > > > >>>> Section 5.3? > > > >>>> > > > >>>> > > > >>> I see no problem with the (quite limited) use of RFC2119 > > > >>> > > > >> language in > > > >> > > > >>> the places in section 5.3 where it appears. It seems quite > > > >>> > > > >> appropriate > > > >> > > > >>> to me,. > > > >>> > > > >>> > > > >> I need to read through each paragraph to determine what the > > > >> implications are. > > > >> > > > >> > > > >>>>>> For example, what happens if a receiver-initiated > > > >>>>>> > > > >> reservation meets > > > >> > > > >>>>>> a domain with a QoS model that only supports > > sender-initiated > > > >>>>>> reservations.]] > > > >>>>>> > > > >>>>>> > > > >>>>> In order to make this work I think you have to have > recursive > > > >>>>> signaling at the edge of the domain. > > > >>>>> > > > >>>> Correct. > > > >>>> > > > >>>> As an example, in RMD these different cases got considered. > > > >>>> > > > >>>> If you only assume that sender-initiated reservations > > exist then > > > >>>> documents are simpler since they obviously don't need to > > > >>>> > > > >> consider all > > > >> > > > >>>> the different cases. > > > >>>> We noticed this problem already with the mobility document > > > >>>> > > > >> where the > > > >> > > > >>>> receiver-initiated reservations are just painful. > > > >>>> > > > >>>> > > > >>> But this is up to the applications which is more > > > >>> > > > >> useful/natural, no? > > > >> > > > >>> If you are saying that receiver-initiated is harder to > > > >>> > > > >> achieve under > > > >> > > > >>> some circumstances, then sure. Applications should be > > > cognizant of > > > >>> that and use receiver-initiated only when they can't > > > >>> > > > >> conveniently use > > > >> > > > >>> sender-initiated. Conversely, some applications (e.g. > > > multicast and > > > >>> multi-unicast) can get all tied up in knots with > > sender-initiated > > > >>> reservations. But to say that interoperability fails > > > >>> > > > >> because some QoSM > > > >> > > > >>> decides receiver-initiated reservations are a pain and > > > >>> > > > >> redefines QOS > > > >> > > > >>> NSLP to eliminate them over its domain strikes me as a > > very poor > > > >>> tradeoff. > > > >>> > > > >> I agree with your statement about multicast QoS reservations. > > > >> I wonder > > > >> whether someone wants to use path-coupled QoS signaling > > > for multicast > > > >> communication. > > > >> > > > >> > > > >> Ciao > > > >> Hannes > > > >> > > > >> > > > >>> Cheers, Dave. > > > >>> > > > >>> > > > >>>>>> That's it for now. I will provide more detailed > > comments later. > > > >>>>>> > > > >>>>>> Ciao > > > >>>>>> Hannes > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>> 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 > > > > > > > > > > > _______________________________________________ > > 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 Jan 04 08:49:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Sxw-0007eG-86; Thu, 04 Jan 2007 08:49:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Sxu-0007cv-Or for nsis@ietf.org; Thu, 04 Jan 2007 08:49:06 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Sxr-0007a8-3q for nsis@ietf.org; Thu, 04 Jan 2007 08:49:06 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l04DmuBL013218; Thu, 4 Jan 2007 14:48:56 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l04Dmu6u031107; Thu, 4 Jan 2007 14:48:56 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 14:48:56 +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: AW: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 14:48:53 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC02529734@MCHP7R6A.ww002.siemens.net> In-Reply-To: <002701c73002$31ce25d0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Thread-Index: Accv+fb106GFgntAQb6TS261LT42lQABzTHAAAEt00A= From: "Tschofenig, Hannes" To: "Georgios Karagiannis" , "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jan 2007 13:48:56.0422 (UTC) FILETIME=[1424F860:01C73007] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8820e85a5ca81f3730470cf2fcb6c557 Cc: john.loughney@nokia.com, 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,=20 =20 > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Gesendet: Donnerstag, 4. Januar 2007 14:14 > An: 'Hannes Tschofenig' > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > Betreff: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt >=20 > Hi Hannes >=20 > Please see in line! > =20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > Sent: donderdag 4 januari 2007 13:15 > > To: Georgios Karagiannis > > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > > Subject: Re: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > >=20 > > Hi Georgios, > >=20 > > Georgios Karagiannis wrote: > > > Hi John > > > > > > I mainly disagree with the following three points that were never=20 > > > discussed before: > > > > > > Point_1):Removed the QSPEC control information > > > --------------------------------------------------------------- > > > Jerry mentioned in a previous e-mail that this QSPEC control=20 > > > information concept is not removed but it is renamed to=20 > > Traffic Handling Directives. > > > > > > If that is the case then Jerry will have to use the same=20 > > definitions=20 > > > for the QSEPC control information as used in Section 5.3.1 of: > > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > > > > > Thus my proposal is to change section 4.3.3 as given in=20 > v.13 of the=20 > > > QSEPC template draft and include the general concept of the QSPEC=20 > > > control information that was given in Section 5.3.1 of=20 > > version 12 of=20 > > > the QSEPC template draft. Note that the name can be=20 > changed but the=20 > > > semantics should remain the same. Thus please chnage=20 > > Section 4.3.3 as follows: > > > > > > FROM: > > > > > > 4.3.3 Traffic Handling Directives > > > > > > The parameter describes how the QNE=20 > > will process > > > excess traffic, that is, out-of-profile traffic. Excess=20 > > traffic MAY > > > be dropped, shaped and/or remarked. The excess treatment=20 > > parameter is > > > initially set by the QNI and cannot be overwritten. > > > > > > > > > INTO: > > > > > > 4.3.3 Traffic Handling Directives > > > > > > Traffic Handling Directives are used for signaling QOSM=20 > > RMF functions > > > not defined in QoS NSLP. It enables building new RMF functions > > > required by a QOSM within a QoS NSLP signaling=20 > framework, such as > > > specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. > > > > > > =3D > > > > > > The parameter describes how the QNE=20 > > will process > > > excess traffic, that is, out-of-profile traffic. Excess=20 > > traffic MAY > > > be dropped, shaped and/or remarked. The excess treatment=20 > > parameter is > > > initially set by the QNI and is read-only. > > > > > > =20 > >=20 > > Do you worry about a potential loss of extensibility here? >=20 >=20 > Georgios: yes I am very much worried about extensibility and=20 > flexibility. >=20 Would you like the QSPEC draft to indicate how to extend the Traffic = Handling Directives?=20 Would there be an implication based on the current QSPEC draft for the = RMD document (as an example)? >=20 > > > ------------------------------- > > > > > > Point_2: dictates that encpasulation of the original=20 > > initiator QSEPC=20 > > > feature cannot be used in combination with the tunneling (parallel > > > session) feature. > > > > > > In the discussion that we have had in the nsis mailing list=20 > > and during=20 > > > the IETF meeting it was stated that both these features should be=20 > > > possible, while now version 13 of the QSPEC template=20 > draft dicates=20 > > > that these two feratures cannot be used togetherand at the=20 > > same time=20 > > > by the same QoS model. > > > As I mentioned in all the discussions the encapsulation of the=20 > > > original QSPEC feature is needed to satisfy Requirement: > > > "5.4.2. It SHOULD be Possible to Add and Remove Local Domain=20 > > > Information" given in: http://www.ietf.org/rfc/rfc3726.txt > > > Therefore the encapsulation (of the original initiator=20 > QSEPC into a=20 > > > local > > > QSPEC) feature should be seen as an independent feature and=20 > > it should=20 > > > be able to be used in combination with the tunneling (parallel=20 > > > session) feature that is used for another goal. > > > > > > Thius my proposal is that it should be mentioned that=20 > even when the=20 > > > tunneling (parallel session) feature is used, it is also=20 > allowed to=20 > > > use, at the same time, the encapsulation (of the original=20 > initiator=20 > > > QSEPC into a local QSPEC) feature in order to satisfy Requirement=20 > > > 5.4.2 of RFC 3726. > > > =20 > >=20 > > How would this, for example, impact RMD? >=20 > Georgios: For RMD-QOSM this will mean that for each local=20 > refresh RESERVE=20 > message an additional RESPONSE message will have to be generated. As an example, the exchange in Figure 3 of = http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-08.txt would = change from: QNE QNE QNE QNE Ingress Interior Interior Egress NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | RESERVE | | | | -------->| RESERVE | | | +--------------------------------------------->| | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +------------->| | | | | RESERVE | | | +-------> | | | |RESPONSE | | | |<------- | | | RESPONSE | |<---------------------------------------------+ RESPONSE| | | | <--------| | | | =20 Figure 3: Sender-initiated reservation with Reduced State Interior Nodes To=20 QNE QNE QNE QNE Ingress Interior Interior Egress NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | RESERVE | | | | -------->| RESERVE | | | +--------------------------------------------->| | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +------------->| | | | | RESERVE | | | +-------> | | | |RESPONSE | | | |<------- | | | RESPONSE'| |<---------------------------------------------+ | | | RESPONSE | |<---------------------------------------------+ RESPONSE| | | | <--------| | | | =20 Figure 3: Sender-initiated reservation with Reduced State Interior Nodes Correct? >=20 >=20 > >=20 > > > --------------------------- > > > > > > Point_3: QSEPC template draft dictates which QOS-NSLP signaling=20 > > > features should be used by QOS models. > > > > > > We have never discussed an agreed that the QSPEC template draft=20 > > > defines how the QOS-NSLP functionality should be used by=20 > > QoS models.=20 > > > This should be defined by the QOS-NSLP draft. > > > Therefore, regarding this issue the QSPEC template draft=20 > > should refer=20 > > > to Section "3.1.2. QoS Models and QoS Specifications"" of: > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt > > > > > > Therefore the QSPEC tempate draft should adpat the=20 > > definitiojn of the=20 > > > QoS models according to what Section 3.1.2 of the=20 > QOS-NSLP draft is=20 > > > saying and refer to Section 3.1.2 of the QOS-NSLP draft. > > > > > > =20 > >=20 > > I guess this aspect refers to the previous discussion I had=20 > > with Dave and with you subsequently. >=20 > Georgios: > If the the folowing paragraph=20 > is added to the proposed QoS model capability list=20 > it will satisfy my concerns: > "The definition of a QoS model may also have implications on how local > behavior should be implemented in the areas where the QoS=20 > NSLP gives > freedom to implementers. For example, it may be useful to identify > recommended behavior for how a RESERVE message that is forwarded > relates to that received, or when additional signaling sessions > should be started based on existing sessions, such as required for > aggregate reservations. In some cases, suggestions may be made on > whether state that may optionally be retained should be held in > particular scenarios. A QoS model may specify reservation > preemption, e.g., an incoming resource request may cause removal of > an earlier reservation." I wonder what the impact for the RMD draft are based on the fact that it = supports all signaling modes already. When I read it last time I thought = it described how RMD works in case of e2e sender-initiated and e2e = receiver-initiated reservation. Ciao Hannes >=20 > Best regards, > Georgios > >=20 > > When reading through Section 3.1.2 of > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-1 > 2.txt I am sure that the QoS NSLP authors are going to re-write > the > section. > >=20 > >=20 > > Ciao > > Hannes > > > Best Regards, > > > Georgios > > > > > > > > > > > > > > > > > > > > > > > > On 12/23/2006, "john.loughney@nokia.com" > > > wrote: > > > > > > =20 > > >> Hi all, > > >> > > >> When Jerry posted the draft with the change log, I=20 > basically noted=20 > > >> that the changes were based upon previous discussions, on=20 > > the mailing=20 > > >> list and the meeting. > > >> > > >> I am unsure of the techincal issues that are being=20 > raised. Rather=20 > > >> than get into a discussion of what was discussed or not,=20 > > what I would=20 > > >> like to understand better is more understanding what are the=20 > > >> technical issues behind Georgios' issues. > > >> > > >> Additionally, I would like to hear from others about their=20 > > opinions=20 > > >> on this issue. > > >> > > >> thanks, > > >> John > > >> > > >> =20 > > >>> -----Original Message----- > > >>> From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > >>> Sent: 22 December, 2006 20:12 > > >>> To: Georgios Karagiannis; nsis@ietf.org > > >>> Cc: Ash, Gerald R (Jerry), ALABS > > >>> Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > > >>> > > >>> Georgios, > > >>> > > >>> It's not true as you and 2 others have stated that the=20 > > changes were=20 > > >>> not discussed. They were discussed, at length. For=20 > example, the=20 > > >>> revised definition of QOSM was clearly stated and=20 > > discussed on the=20 > > >>> list, see=20 > > >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.htm > > >>> l and also see all the list discussion following that post. > > >>> The revised definition and all the other changes were clearly=20 > > >>> presented in the slides at IETF-67, see minutes and slides at=20 > > >>> http://www3.ietf.org/proceedings/06nov/index.html. You=20 > > can listen=20 > > >>> to the complete IETF-67 presentation/discussion again at=20 > > >>> http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf > > >>> 67ch4-thu > > >>> -am.mp3. > > >>> > > >>> You can review the slides, meeting discussion, list discussion,=20 > > >>> meeting minutes, and verify that for yourself. > > >>> > > >>> So the editors did not 'make up the changes without=20 > > discussion' as=20 > > >>> you and 2 others have suggested. That is certainly wrong and I=20 > > >>> think you should acknowledge that. > > >>> > > >>> It is not useful going forward to debate the past, but=20 > incendiary=20 > > >>> wrong statements should not go unanswered. > > >>> > > >>> Once again, I've responded to your technical comments, you can=20 > > >>> comment further if you wish. > > >>> > > >>> It would be good for others to comment on the technical points. > > >>> > > >>> Jerry > > >>> > > >>> -----Original Message----- > > >>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > >>> Sent: Friday, December 22, 2006 11:36 AM > > >>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > >>> Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > > >>> > > >>> Hi Jerry > > >>> > > >>> The changes that are included in version 13 of the=20 > QSEPC template=20 > > >>> draft regarding the QSPEC control information and the=20 > > limitations of=20 > > >>> the QoS models have never been discussed because they=20 > were never=20 > > >>> stated clearly. > > >>> > > >>> If they would have been stated clearly then I would=20 > have sent my=20 > > >>> comments at that time instead of sending them now! > > >>> > > >>> Furthermore, from what I have seen in v. 13 of the=20 > draft you also=20 > > >>> have not solved the stacking issue, because you are actually=20 > > >>> dictating that encapsulation cannot be combined and=20 > used together=20 > > >>> with the tunneling (parallel sessions) method. > > >>> > > >>> > > >>> Best Regards, > > >>> Georgios > > >>> > > >>> =20 > > >>>> > > >>>> =20 > > >>>>> -----Original Message----- > > >>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > >>>>> Sent: vrijdag 22 december 2006 16:37 > > >>>>> To: Georgios Karagiannis; nsis@ietf.org > > >>>>> Cc: Ash, Gerald R (Jerry), ALABS > > >>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > > >>>>> > > >>>>> Georgios, > > >>>>> > > >>>>> =20 > > >>>>>> -----Original Message----- > > >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > >>>>>> Sent: Friday, December 22, 2006 9:13 AM > > >>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > >>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > > >>>>>> > > >>>>>> Hi Jerry > > >>>>>> > > >>>>>> By just saying that "these changes are suggested by=20 > > Dave in the=20 > > >>>>>> e-mail" does not work. > > >>>>>> > > >>>>>> The proposal of Dave was not clear on the QoS model changes > > >>>>>> =20 > > >>>>> that you > > >>>>> =20 > > >>>>>> wanted to do. > > >>>>>> =20 > > >>>>> All changes to the draft have been extensively discussed on > > >>>>> =20 > > >>>> the list > > >>>> =20 > > >>>>> and are all contained in the slides presented at IETF-67. > > >>>>> =20 > > >>> You were > > >>> =20 > > >>>>> there at > > >>>>> IETF-67 and participated in all the list discussion. The > > >>>>> =20 > > >>>> summary of > > >>>> =20 > > >>>>> changes in the slides is quite specific and clear, take > > >>>>> =20 > > >>>> another look. > > >>>> =20 > > >>>>> Have a look at the minutes as well=20 > > >>>>>=20 > > http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt. The only=20 > > >>>>> disagreements noted are with regard to stacking, which=20 > > is an issue=20 > > >>>>> that we later resolved on the list. Go back and check it out. > > >>>>> > > >>>>> =20 > > >>>>>> Now I understand which changes you want to include in=20 > > the QSPEC=20 > > >>>>>> template draft. > > >>>>>> This is also the reason of disagreeing with you now=20 > > and sending=20 > > >>>>>> comments to the nsis list. > > >>>>>> =20 > > >>>>> I responded to your further comments, see below. Others are=20 > > >>>>> encouraged to comment as well. > > >>>>> > > >>>>> Jerry > > >>>>> > > >>>>> =20 > > >>>>>> Furthermore, note that the QOS-NSLP draft defines which > > >>>>>> =20 > > >>>>> capabilities > > >>>>> =20 > > >>>>>> should be supported by the QoS models and not the=20 > > QSPEC template=20 > > >>>>>> draft. > > >>>>>> > > >>>>>> Best Regards, > > >>>>>> Georgios > > >>>>>> > > >>>>>> > > >>>>>> =20 > > >>>>>>> -----Original Message----- > > >>>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > >>>>>>> Sent: vrijdag 22 december 2006 15:01 > > >>>>>>> To: Georgios Karagiannis; nsis@ietf.org > > >>>>>>> Cc: Ash, Gerald R (Jerry), ALABS > > >>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > > >>>>>>> > > >>>>>>> Georgios, > > >>>>>>> > > >>>>>>> See below. > > >>>>>>> > > >>>>>>> =20 > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > >>>>>>>> Sent: Thursday, December 21, 2006 9:22 AM > > >>>>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > >>>>>>>> Cc: 'Attila Bader (IJ/ETH)'; 'Lars Westberg' > > >>>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > > >>>>>>>> > > >>>>>>>> Hi Jerry > > >>>>>>>> > > >>>>>>>> Please see below! I have severe concerns about some changes > > >>>>>>>> =20 > > >>>>>>> that have > > >>>>>>> =20 > > >>>>>>>> been done in the QSPEC template draft. > > >>>>>>>> > > >>>>>>>> =20 > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > >>>>>>>>> Sent: woensdag 20 december 2006 14:20 > > >>>>>>>>> To: Georgios Karagiannis; nsis@ietf.org > > >>>>>>>>> Cc: Ash, Gerald R (Jerry), ALABS > > >>>>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > > >>>>>>>>> > > >>>>>>>>> Hi Georgios, > > >>>>>>>>> > > >>>>>>>>> See below. > > >>>>>>>>> > > >>>>>>>>> =20 > > >>>>>>>>>> -----Original Message----- > > >>>>>>>>>> From: Georgios Karagiannis > > >>>>>>>>>> =20 > > >>> [mailto:karagian@cs.utwente.nl] > > >>> =20 > > >>>>>>>>>> Sent: Wednesday, December 20, 2006 5:26 AM > > >>>>>>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > >>>>>>>>>> Subject: Comments on draft-ietf-nsis-qspec-13.txt > > >>>>>>>>>> > > >>>>>>>>>> Hi Jerry > > >>>>>>>>>> > > >>>>>>>>>> Here are my comments on draft-ietf-nsis-qspec-13.txt: > > >>>>>>>>>> > > >>>>>>>>>> Comment_1: > > >>>>>>>>>> -------------- > > >>>>>>>>>> Please reinclude the concept of QSPEC control > > >>>>>>>>>> =20 > > >>>>>>> information that was > > >>>>>>> =20 > > >>>>>>>>>> included in all previous versions of the QSPEC > > >>>>>>>>>> =20 > > >>>>> template draft. > > >>>>> =20 > > >>>>>>>>>> In > > >>>>>>>>>> > > >>>>>>>>>> =20 > > >>>>=20 > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt:=20 > > >>>> this > > >>>> =20 > > >>>>>>>>>> concept was described in Section 5.1. > > >>>>>>>>>> =20 > > >>>>>>>>> Please see previous email comment on QSPEC control > > >>>>>>>>> =20 > > >>>>> information. > > >>>>> =20 > > >>>>>>>> Georgios: > > >>>>>>>> In order to emphasize the need of having QSPEC control > > >>>>>>>> =20 > > >>>>>> information > > >>>>>> =20 > > >>>>>>>> parameters I would however appreciate if the name of > > >>>>>>>> =20 > > >>>>>>> Section 4.3.3 > > >>>>>>> =20 > > >>>>>>>> is changed > > >>>>>>>> From: > > >>>>>>>> 4.3.3 Traffic Handling Directives > > >>>>>>>> INTO: > > >>>>>>>> 4.3.3 QSPEC control information > > >>>>>>>> =20 > > >>>>>>> The updated QSPEC parameter terminology/semantics are as > > >>>>>>> =20 > > >>>>> suggested > > >>>>> =20 > > >>>>>>> by Dave Oran (see slides presented at IETF-67=20 > > >>>>>>> http://www3.ietf.org/proceedings/06nov/index.html). I > > >>>>>>> =20 > > >>>> think the > > >>>> =20 > > >>>>>>> current terminology is more clear/descriptive of the QSPEC=20 > > >>>>>>> parameters so I don't favor going backwards to less clear=20 > > >>>>>>> terminology. I was never clear on why we used the 'control=20 > > >>>>>>> information' terminology in the first place, e.g., I > > >>>>>>> =20 > > >>>> don't think > > >>>> =20 > > >>>>>>> it's a very good descriptor of the 'excess treatment' > > >>>>>>> =20 > > >>> parameter. > > >>> =20 > > >>>>>>> Perhaps Dave can comment on this point also when he > > >>>>>>> =20 > > >>>> gets a chance. > > >>>> =20 > > >>>>>>>>>> Comment_2: > > >>>>>>>>>> ----------- > > >>>>>>>>>> > > >>>>>>>>>> Section 6.1: > > >>>>>>>>>> Please reintroduce the format that is required > > >>>>>>>>>> =20 > > >>> in order to > > >>> =20 > > >>>>>>>>> specify the > > >>>>>>>>> =20 > > >>>>>>>>>> QSPEC control information, see: > > >>>>>>>>>> Section 7.1 of: > > >>>>>>>>>> > > >>>>>>>>>> =20 > > >>>>>>=20 > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > >>>>>> =20 > > >>>>>>>>> Please see previous email comment on QSPEC control > > >>>>>>>>> =20 > > >>>>> information. > > >>>>> =20 > > >>>>>>>> Georgios: If you rename section 4.3.3 to QSPEC control > > >>>>>>>> =20 > > >>>>>> information > > >>>>>> =20 > > >>>>>>>> then I think that reformatting of section 6.1 is=20 > not needed. > > >>>>>>>> Please add the proposed sentence by Dave (but change > > >>>>>>>> =20 > > >>> the term > > >>> =20 > > >>>>>>>> "handling directives" to "QSPEC control Information"). I am > > >>>>>>>> =20 > > >>>>>>> not sure > > >>>>>>> =20 > > >>>>>>>> where it is better to add this sentence, maybe in > > >>>>>>>> =20 > > >>> Section 5.4. > > >>> =20 > > >>>>>>>> "QoSMs are free, subject to IANA registration and review > > >>>>>>>> =20 > > >>>>>> rules, to > > >>>>>> =20 > > >>>>>>>> extend QSPECs by adding parameters of any of the kinds > > >>>>>>>> =20 > > >>>>>> supported by > > >>>>>> =20 > > >>>>>>>> the standard QSPEC. This includes traffic description > > >>>>>>>> =20 > > >>>>> parameters, > > >>>>> =20 > > >>>>>>>> constraint parameters and QSPEC control information. > > >>>>>>>> =20 > > >>>>>> QoSMs are not > > >>>>>> =20 > > >>>>>>>> permitted, however, to reinterpret or redefine the > > >>>>>>>> =20 > > >>>>> standard QSPEC > > >>>>> =20 > > >>>>>>>> parameters specified in this document" > > >>>>>>>> =20 > > >>>>>>> Yes, the text suggested by Dave will be added. > > >>>>>>> > > >>>>>>> =20 > > >>>>>>>>>> Comment_3: > > >>>>>>>>>> ---------- > > >>>>>>>>>> Section 4.1 :QoS Models > > >>>>>>>>>> The definition of the QoS model is not complete. An > > >>>>>>>>>> =20 > > >>>>> important > > >>>>> =20 > > >>>>>>>>>> sentence that was used in the previous version of the > > >>>>>>>>>> =20 > > >>>>>> draft is > > >>>>>> =20 > > >>>>>>>>>> removed. > > >>>>>>>>>> Please add the following sentence to the definition > > >>>>>>>>>> =20 > > >>>>>> of the QoS > > >>>>>> =20 > > >>>>>>>>>> Model > > >>>>>>>>>> (QOSM): > > >>>>>>>>>> > > >>>>>>>>>> The same as described above have to be applied in > > >>>>>>>>>> =20 > > >>>>>> this section. > > >>>>>> =20 > > >>>>>>>>>> After the following sentence: > > >>>>>>>>>> > > >>>>>>>>>> "A QOSM specification MAY include the following:" > > >>>>>>>>>> > > >>>>>>>>>> include the following bullet: > > >>>>>>>>>> "- it specifies how to use QOS NSLP to signal for > > >>>>>>>>>> =20 > > >>>> this QOSM" > > >>>> =20 > > >>>>>>>>> That sentence was removed in Dave's proposed QOSM > > >>>>>>>>> =20 > > >>>>>>> re-definition, see > > >>>>>>> =20 > > >>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht > > >>>> =20 > > >>>>>>>>> ml. It was unclear what that sentence meant, QoS-NSLP > > >>>>>>>>> =20 > > >>>>>>> specifies how > > >>>>>>> =20 > > >>>>>>>>> to signal, not QOSM specifications, so the sentence > > >>>>>>>>> =20 > > >>>>> was removed. > > >>>>> =20 > > >>>>>>>>> I believe the sentence was intended to mean that when > > >>>>>>>>> =20 > > >>>>> QoS NSLP > > >>>>> =20 > > >>>>>>>>> allows various options to be selected, a QOSM should > > >>>>>>>>> =20 > > >>>>> be able to > > >>>>> =20 > > >>>>>>>>> determine which option is used. For that purpose the > > >>>>>>>>> =20 > > >>>>> following > > >>>>> =20 > > >>>>>>>>> sentence was added in Section 4.1: > > >>>>>>>>> > > >>>>>>>>> " A QOSM specification MAY include the following: > > >>>>>>>>> ... > > >>>>>>>>> - can state which QoS-NSLP options a QOSM wants to > > >>>>>>>>> =20 > > >>>>>> use, when > > >>>>>> =20 > > >>>>>>>>> several options are available for a QOSM (e.g., > > >>>>>>>>> =20 > > >>>>>>> local QSPEC to > > >>>>>>> =20 > > >>>>>>>>> either be a) tunneled or b) encapsulate > > >>>>>>>>> =20 > > >>>>> initiator QSPEC)." > > >>>>> =20 > > >>>>>>>>> Also, to avoid any misinterpretation that QOSMs are free > > >>>>>>>>> =20 > > >>>>>>> to specify > > >>>>>>> =20 > > >>>>>>>>> additional constraints, state machines, protocol data, > > >>>>>>>>> =20 > > >>>>>>> etc. for NSLP > > >>>>>>> =20 > > >>>>>>>>> beyond that which is specific in the QoS NSLP > > >>>>>>>>> =20 > > >>>>>> specification, the > > >>>>>> =20 > > >>>>>>>>> following was added to Section 4.1: > > >>>>>>>>> > > >>>>>>>>> " QOSMs affect the operation of the RMF in NSIS-capable > > >>>>>>>>> =20 > > >>>>>>> nodes, the > > >>>>>>> =20 > > >>>>>>>>> information carried in QSPEC objects, and may=20 > under some > > >>>>>>>>> circumstances (e.g. aggregation) cause a separate NSLP > > >>>>>>>>> session to be > > >>>>>>>>> instantiated by having the RMF as a QNI. QOSMs > > >>>>>>>>> =20 > > >>>> all utilize > > >>>> =20 > > >>>>>>>>> the common > > >>>>>>>>> data, state machines, and APIs of the underlying NSIS > > >>>>>>>>> protocols and > > >>>>>>>>> are not expected to re-define or extend these in > > >>>>>>>>> =20 > > >>>> any way." > > >>>> =20 > > >>>>>>>> Georgios: > > >>>>>>>> Regarding the sentence in Section 4.1: > > >>>>>>>> "QOSMs all utilize > > >>>>>>>> the common data, state machines, and APIs of the > > >>>>>>>> =20 > > >>>>> underlying NSIS > > >>>>> =20 > > >>>>>>>> protocols and are not expected to re-define or extend > > >>>>>>>> =20 > > >>>>>> these in any > > >>>>>> =20 > > >>>>>>>> way." > > >>>>>>>> > > >>>>>>>> This sentence restricts the possibility of QoS model to use > > >>>>>>>> =20 > > >>>>>>> RMF states > > >>>>>>> =20 > > >>>>>>>> and data that are not been defined in neither > > >>>>>>>> =20 > > >>>> QoS-NSLP or QSPEC. > > >>>> =20 > > >>>>>>>> This sentence should be removed. > > >>>>>>>> =20 > > >>>>>>> I disagree. The quoted text was introduced by Dave Oran > > >>>>>>> =20 > > >>>>> in addition > > >>>>> =20 > > >>>>>>> to removing the phrase implying that a QOSM could specify > > >>>>>>> =20 > > >>>>> signaling > > >>>>> =20 > > >>>>>>> protocol changes, and I agree with this. > > >>>>>>> Any changes/extensions to the signaling protocol or state > > >>>>>>> =20 > > >>>>> machines > > >>>>> =20 > > >>>>>>> are within the scope of QoS-NSLP draft and not the QSPEC > > >>>>>>> =20 > > >>>>> draft or a > > >>>>> =20 > > >>>>>>> QOSM specification draft. I think you have noted that > > >>>>>>> =20 > > >>>>> also in your > > >>>>> =20 > > >>>>>>> subsequent posting at > > >>>>>>> > > >>>>>>> =20 > > >>>>=20 > http://www1.ietf.org/mail-archive/web/nsis/current/msg07352.html. > > >>>> =20 > > >>>>>>> If any extensions are required to the NSIS signaling > > >>>>>>> =20 > > >>>>> protocol as a > > >>>>> =20 > > >>>>>>> result of the 'severe change on QoS Model definition and=20 > > >>>>>>> capabilities' > > >>>>>>> you have noted, those proposed changes/extensions should be=20 > > >>>>>>> addressed to the QoS NSLP draft IMO. > > >>>>>>> > > >>>>>>> Perhaps Dave can comment here also when he gets a chance. > > >>>>>>> > > >>>>>>> =20 > > >>>>>>>>>> Comment_4: > > >>>>>>>>>> ------------- > > >>>>>>>>>> Section 5.1 Local QSPEC definition and processing > > >>>>>>>>>> > > >>>>>>>>>> By reading this section it gives the impression > > >>>>>>>>>> =20 > > >>>>> that the two > > >>>>> =20 > > >>>>>>>>>> methods > > >>>>>>>>>> a) and b) cannot be used by the same QoS model. > > >>>>>>>>>> Method a): translate the > > >>>>>>>>>> initiator QSPEC into a local QSPEC and encapsulate the > > >>>>>>>>>> =20 > > >>>>>>> initiator > > >>>>>>> =20 > > >>>>>>>>>> QSPEC in the RESERVE message Method b): b) tunnel the > > >>>>>>>>>> =20 > > >>>>>> initiator > > >>>>>> =20 > > >>>>>>>>>> QSPEC through the local domain and reserve resources by > > >>>>>>>>>> =20 > > >>>>>>> generating > > >>>>>>> =20 > > >>>>>>>>>> a new RESERVE message through the local domain > > >>>>>>>>>> =20 > > >>>>> containing the > > >>>>> =20 > > >>>>>>>>>> local QSPEC. > > >>>>>>>>>> > > >>>>>>>>>> Note that according to the discussions that we have had > > >>>>>>>>>> =20 > > >>>>>>> until now > > >>>>>>> =20 > > >>>>>>>>>> method a) should be able to be used in combination with > > >>>>>>>>>> =20 > > >>>>>>> method b) > > >>>>>>> =20 > > >>>>>>>>>> by the same QoS model for the situation that the > > >>>>>>>>>> =20 > > >>>>> local QSPEC > > >>>>> =20 > > >>>>>>>>>> encapsulates the initiator QSPEC in order to satisfy > > >>>>>>>>>> =20 > > >>>>>>> requirement > > >>>>>>> =20 > > >>>>>>>>>> 5.4.2 that is specified in RFC 3726, see: > > >>>>>>>>>> http://www.ietf.org/rfc/rfc3726.txt > > >>>>>>>>>> > > >>>>>>>>>> Please add the following sentence at the end of > > >>>>>>>>>> =20 > > >>> the first > > >>> =20 > > >>>>>>>>>> paragraph of Section 5.1. > > >>>>>>>>>> "Note that when method b) is used, the > > >>>>>>>>>> =20 > > >>>> encapsulation of the > > >>>> =20 > > >>>>>>>>>> initiator QSPEC into a local QSPEC should also be > > >>>>>>>>>> =20 > > >>>>>> possible when > > >>>>>> =20 > > >>>>>>>>>> the local QoS model needs to satisfy Requirement > > >>>>>>>>>> 5.4.2 specified in RFC 3726, by adding and > > >>>>>>>>>> =20 > > >>> removing local > > >>> =20 > > >>>>>>>>>> QOSM-specific Control Information parameters on > > >>>>>>>>>> =20 > > >>>> top of the > > >>>> =20 > > >>>>>>>>>> initiator QSPEC." > > >>>>>>>>>> =20 > > >>>>>>>>> Your comment here is not clear to me. It would help to > > >>>>>>>>> =20 > > >>>>>>> provide an > > >>>>>>> =20 > > >>>>>>>>> example to illustrate what you are trying to accomplish. > > >>>>>>>>> =20 > > >>>>>>> It seems > > >>>>>>> =20 > > >>>>>>>>> that you are trying to specify QoS-NSLP functionality, > > >>>>>>>>> =20 > > >>>>>>> rather than > > >>>>>>> =20 > > >>>>>>>>> QSPEC functionality. If so, that functionality should be > > >>>>>>>>> =20 > > >>>>>>> specified > > >>>>>>> =20 > > >>>>>>>>> in the QoS-NSLP draft rather than the QSPEC draft, > > >>>>>>>>> =20 > > >>>>> perhaps the > > >>>>> =20 > > >>>>>>>>> QoS-NSLP authors can comment. > > >>>>>>>>> =20 > > >>>>>>>> Georgios: > > >>>>>>>> No I am not trying to define QOS-NSLP functionality. > > >>>>>>>> This is related to QSPEC control information that has to be > > >>>>>>>> =20 > > >>>>>>> carried by > > >>>>>>> =20 > > >>>>>>>> end-to-end messages. > > >>>>>>>> What I am trying to say is that all the discussion that > > >>>>>>>> =20 > > >>>>>> we have had > > >>>>>> =20 > > >>>>>>>> regarding the encapsulation of the QSPEC object were > > >>>>>>>> =20 > > >>>>>>> associated with > > >>>>>>> =20 > > >>>>>>>> requirement 5.4.2 of RFC 3726, see below: > > >>>>>>>> > > >>>>>>>> ----------------- > > >>>>>>>> "5.4.2. It SHOULD be Possible to Add and Remove > > >>>>>>>> =20 > > >>> Local Domain > > >>> =20 > > >>>>>>>> Information > > >>>>>>>> > > >>>>>>>> It SHOULD be possible to add and remove local > > >>>>>>>> =20 > > >>>> scope elements. > > >>>> =20 > > >>>>>>>> Compared to Requirement 5.3.5 this requirement does use > > >>>>>>>> =20 > > >>>>>>> the normal > > >>>>>>> =20 > > >>>>>>>> signaling process and message exchange for > > >>>>>>>> =20 > > >>>> transporting local > > >>>> =20 > > >>>>>>>> information. For example, at the entrance to a > > >>>>>>>> =20 > > >>>>> domain, domain- > > >>>>> =20 > > >>>>>>>> specific information is added information is=20 > added, which > > >>>>>>>> is used in > > >>>>>>>> this domain only, and the information is removed > > >>>>>>>> =20 > > >>>> again when a > > >>>> =20 > > >>>>>>>> signaling message leaves the domain. The motivation > > >>>>>>>> =20 > > >>>>> is in the > > >>>>> =20 > > >>>>>>>> economy of re-using the protocol for domain internal > > >>>>>>>> =20 > > >>>>>> signaling of > > >>>>>> =20 > > >>>>>>>> various information pieces. Where additional > > >>>>>>>> =20 > > >>>>>>> information is needed > > >>>>>>> =20 > > >>>>>>>> within a particular domain, it should be possible to > > >>>>>>>> =20 > > >>>>>>> carry this at > > >>>>>>> =20 > > >>>>>>>> the same time as the end-to-end information.", > > >>>>>>>> =20 > > >>>> from RFC 3726 > > >>>> =20 > > >>>>>>>> ------------------ > > >>>>>>>> Thus what I am saying is: > > >>>>>>>> Please add the following sentence at the end of the first > > >>>>>>>> =20 > > >>>>>>> paragraph of > > >>>>>>> =20 > > >>>>>>>> Section 5.1. > > >>>>>>>> > > >>>>>>>> "Note that when method b) is used, the encapsulation of the > > >>>>>>>> =20 > > >>>>>>> initiator > > >>>>>>> =20 > > >>>>>>>> QSPEC into a local QSPEC should also be possible when the > > >>>>>>>> =20 > > >>>>>> local QoS > > >>>>>> =20 > > >>>>>>>> model needs to satisfy Requirement > > >>>>>>>> 5.4.2 specified in RFC 3726, by adding and removing local=20 > > >>>>>>>> QOSM-specific Control Information parameters on top of the > > >>>>>>>> =20 > > >>>>>>> initiator > > >>>>>>> =20 > > >>>>>>>> QSPEC." > > >>>>>>>> =20 > > >>>>>>> First, the suggested text isn't clear. If method b) is used > > >>>>>>> (tunneling) then presumably method a) is not also used at > > >>>>>>> =20 > > >>>>> the same > > >>>>> =20 > > >>>>>>> time. However, the phrasing of the above makes it > > >>>>>>> =20 > > >>>> sound that way. > > >>>> =20 > > >>>>>>> Second, an example would help here. I presume you are > > >>>>>>> =20 > > >>>> referring > > >>>> =20 > > >>>>>>> e.g., to RMD adding 'control information' (i.e., 'handling > > >>>>>>> directive') parameters to the local QSPEC that are not > > >>>>>>> =20 > > >>>>> included in > > >>>>> =20 > > >>>>>>> the initiator QSPEC. I think the requirement would be > > >>>>>>> =20 > > >>>>> that the RMD > > >>>>> =20 > > >>>>>>> QOSM provides a local QSPEC that is consistent with the > > >>>>>>> =20 > > >>>> initiator > > >>>> =20 > > >>>>>>> QSPEC, as we agreed on the list (see also slide 8 of > > >>>>>>> =20 > > >>>> the IETF-67 > > >>>> =20 > > >>>>>>> presentation). > > >>>>>>> > > >>>>>>> If the local QSPEC introduces functionality > > >>>>>>> =20 > > >>>> inconsistent with the > > >>>> =20 > > >>>>>>> initiator QSPEC by appending the handling directive > > >>>>>>> =20 > > >>>>> parameters, then > > >>>>> =20 > > >>>>>>> it is not allowed. > > >>>>>>> > > >>>>>>> =20 > > >>>>>>>>>> Comment_5: > > >>>>>>>>>> ----------- > > >>>>>>>>>> Section 5.1, last paragraph: > > >>>>>>>>>> > > >>>>>>>>>> Please change the following: > > >>>>>>>>>> "For example, RMD can define a local QSPEC that > > >>>>>>>>>> =20 > > >>>>>> contains TMOD =3D > > >>>>>> =20 > > >>>>>>>>>> bandwidth (sets r=3Dp, b/m to large)." > > >>>>>>>>>> > > >>>>>>>>>> Into: > > >>>>>>>>>> "For example, in RMD the TMOD parameters contained in > > >>>>>>>>>> =20 > > >>>>>>> the original > > >>>>>>> =20 > > >>>>>>>>>> initiator QSPEC are mapped into the equivalent TMOD > > >>>>>>>>>> =20 > > >>>>> parameter > > >>>>> =20 > > >>>>>>>>>> representing only the peak bandwidth in the local QSPEC." > > >>>>>>>>>> =20 > > >>>>>>>>> OK with me. > > >>>>>>>>> > > >>>>>>>>> =20 > > >>>>>>>>>> Comment_6: > > >>>>>>>>>> ------------- > > >>>>>>>>>> In Section 5.3.1, 5.3.2, 5.3.3 the rules that have to > > >>>>>>>>>> =20 > > >>>>>>> be followed > > >>>>>>> =20 > > >>>>>>>>>> regarding the QSPEC control information are not given: > > >>>>>>>>>> > > >>>>>>>>>> Please include the following paragraph at the end of > > >>>>>>>>>> =20 > > >>>>>>> this section: > > >>>>>>> =20 > > >>>>>>>>>> "Regarding QSPEC Control Information, the default rule > > >>>>>>>>>> =20 > > >>>>>>> is that all > > >>>>>>> =20 > > >>>>>>>>>> QSPEC parameters that have been included in > > >>>>>>>>>> =20 > > >>>> the RESERVE > > >>>> =20 > > >>>>>>>>>> message by > > >>>>>>>>>> the QNI are also included in the RESPONSE > > >>>>>>>>>> =20 > > >>>> message by the > > >>>> =20 > > >>>>>>>>>> QNR with the > > >>>>>>>>>> value they had when arriving at the QNR. When > > >>>>>>>>>> =20 > > >>>>>>> traveling in the > > >>>>>>> =20 > > >>>>>>>>>> RESPONSE message, all QSPEC Control Information > > >>>>>>>>>> =20 > > >>>>>>> parameters are > > >>>>>>> =20 > > >>>>>>>>>> read-only. Note that a QOSM specification may > > >>>>>>>>>> =20 > > >>>>>> define its own > > >>>>>> =20 > > >>>>>>>>>> QOSM-specific Control Information parameters and > > >>>>>>>>>> processing rules." > > >>>>>>>>>> =20 > > >>>>>>>>> Please see previous email comment on QSPEC control > > >>>>>>>>> =20 > > >>>>> information. > > >>>>> =20 > > >>>>>>>> Georgios: I think that a description of how the > > >>>>>>>> =20 > > >>> QSPEC control > > >>> =20 > > >>>>>>>> information is handled is needed. > > >>>>>>>> =20 > > >>>>>>> Please see above comments on 'control information'=20 > > terminology. > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> Jerry > > >>>>>>> > > >>>>>>> =20 > > >>>>>>>>>> Comment_7: > > >>>>>>>>>> ------------ > > >>>>>>>>>> Section 6.1: > > >>>>>>>>>> I do not understand the second sentence from the > > >>>>>>>>>> =20 > > >>> below two > > >>> =20 > > >>>>>>>>>> sentences: > > >>>>>>>>>> "N Flag: Not-supported QSPEC parameter flag (see > > >>>>>>>>>> =20 > > >>>>>> Section 5.2.2). > > >>>>>> =20 > > >>>>>>>>>> For QSPEC parameters the value of this flag > > >>>>>>>>>> =20 > > >>>>>>> is always > > >>>>>>> =20 > > >>>>>>>>>> zero." > > >>>>>>>>>> =20 > > >>>>>>>>> Good catch, this is a typo, the sentence should=20 > be removed. > > >>>>>>>>> > > >>>>>>>>> =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 > > >>> > > >>> =20 > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > =20 > >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 04 09:06:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2TEF-0002Ls-5C; Thu, 04 Jan 2007 09:05:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2TEE-0002Ln-Fy for nsis@ietf.org; Thu, 04 Jan 2007 09:05:58 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2TEC-00029Y-16 for nsis@ietf.org; Thu, 04 Jan 2007 09:05:58 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l04E4dr1008082; Thu, 4 Jan 2007 15:04:43 +0100 (MET) From: "Georgios Karagiannis" To: "'Tschofenig, Hannes'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 15:04:41 +0100 Message-ID: <002c01c73009$4ad3ec70$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.3028 Thread-Index: Accv+fb106GFgntAQb6TS261LT42lQABzTHAAAEt00AAAHr7gA== In-Reply-To: <6F0CB04509C11D46A54232E852E390AC02529734@MCHP7R6A.ww002.siemens.net> X-Spam-Score: 0.299 () AWL,FVGT_s_OBFU_Q1,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 04 Jan 2007 15:04:48 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7393021445f38f9de2859aed58f010 Cc: john.loughney@nokia.com, 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 Hannes Please see in line!=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: donderdag 4 januari 2007 14:49 > To: Georgios Karagiannis; Hannes Tschofenig > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > Subject: AW: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt >=20 > Hi Georgios,=20 > =20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Gesendet: Donnerstag, 4. Januar 2007 14:14 > > An: 'Hannes Tschofenig' > > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > > Betreff: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > >=20 > > Hi Hannes > >=20 > > Please see in line! > > =20 > >=20 > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: donderdag 4 januari 2007 13:15 > > > To: Georgios Karagiannis > > > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > > > Subject: Re: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > > >=20 > > > Hi Georgios, > > >=20 > > > Georgios Karagiannis wrote: > > > > Hi John > > > > > > > > I mainly disagree with the following three points that=20 > were never=20 > > > > discussed before: > > > > > > > > Point_1):Removed the QSPEC control information > > > > --------------------------------------------------------------- > > > > Jerry mentioned in a previous e-mail that this QSPEC control=20 > > > > information concept is not removed but it is renamed to > > > Traffic Handling Directives. > > > > > > > > If that is the case then Jerry will have to use the same > > > definitions > > > > for the QSEPC control information as used in Section 5.3.1 of: > > > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > > > > > > > Thus my proposal is to change section 4.3.3 as given in > > v.13 of the > > > > QSEPC template draft and include the general concept of=20 > the QSPEC=20 > > > > control information that was given in Section 5.3.1 of > > > version 12 of > > > > the QSEPC template draft. Note that the name can be > > changed but the > > > > semantics should remain the same. Thus please chnage > > > Section 4.3.3 as follows: > > > > > > > > FROM: > > > > > > > > 4.3.3 Traffic Handling Directives > > > > > > > > The parameter describes how the QNE > > > will process > > > > excess traffic, that is, out-of-profile traffic. Excess > > > traffic MAY > > > > be dropped, shaped and/or remarked. The excess treatment > > > parameter is > > > > initially set by the QNI and cannot be overwritten. > > > > > > > > > > > > INTO: > > > > > > > > 4.3.3 Traffic Handling Directives > > > > > > > > Traffic Handling Directives are used for signaling QOSM > > > RMF functions > > > > not defined in QoS NSLP. It enables building new=20 > RMF functions > > > > required by a QOSM within a QoS NSLP signaling > > framework, such as > > > > specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. > > > > > > > > =3D > > > > > > > > The parameter describes how the QNE > > > will process > > > > excess traffic, that is, out-of-profile traffic. Excess > > > traffic MAY > > > > be dropped, shaped and/or remarked. The excess treatment > > > parameter is > > > > initially set by the QNI and is read-only. > > > > > > > > =20 > > >=20 > > > Do you worry about a potential loss of extensibility here? > >=20 > >=20 > > Georgios: yes I am very much worried about extensibility and=20 > > flexibility. > >=20 >=20 > Would you like the QSPEC draft to indicate how to extend the=20 > Traffic Handling Directives?=20 >=20 > Would there be an implication based on the current QSPEC=20 > draft for the RMD document (as an example)? Georgios: The RMD-QOSM uses many QSPEC spcific control information parameters=20 that are different and have to be processed differently=20 than the parameter. It should be possible to define = and use=20 such parameters. > >=20 > > > > ------------------------------- > > > > > > > > Point_2: dictates that encpasulation of the original > > > initiator QSEPC > > > > feature cannot be used in combination with the=20 > tunneling (parallel > > > > session) feature. > > > > > > > > In the discussion that we have had in the nsis mailing list > > > and during > > > > the IETF meeting it was stated that both these features=20 > should be=20 > > > > possible, while now version 13 of the QSPEC template > > draft dicates > > > > that these two feratures cannot be used togetherand at the > > > same time > > > > by the same QoS model. > > > > As I mentioned in all the discussions the encapsulation of the=20 > > > > original QSPEC feature is needed to satisfy Requirement: > > > > "5.4.2. It SHOULD be Possible to Add and Remove Local Domain=20 > > > > Information" given in: http://www.ietf.org/rfc/rfc3726.txt > > > > Therefore the encapsulation (of the original initiator > > QSEPC into a > > > > local > > > > QSPEC) feature should be seen as an independent feature and > > > it should > > > > be able to be used in combination with the tunneling (parallel > > > > session) feature that is used for another goal. > > > > > > > > Thius my proposal is that it should be mentioned that > > even when the > > > > tunneling (parallel session) feature is used, it is also > > allowed to > > > > use, at the same time, the encapsulation (of the original > > initiator > > > > QSEPC into a local QSPEC) feature in order to satisfy=20 > Requirement > > > > 5.4.2 of RFC 3726. > > > > =20 > > >=20 > > > How would this, for example, impact RMD? > >=20 > > Georgios: For RMD-QOSM this will mean that for each local refresh=20 > > RESERVE message an additional RESPONSE message will have to be=20 > > generated. >=20 >=20 >=20 > As an example, the exchange in Figure 3 of=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-08.txt > would change from: >=20 >=20 > QNE QNE QNE QNE > Ingress Interior Interior Egress > NTLP stateful NTLP stateless NTLP stateless NTLP stateful > | | | | > RESERVE | | | | > -------->| RESERVE | | | > +--------------------------------------------->| > | RESERVE' | | | > +-------------->| | | > | | RESERVE' | | > | +-------------->| | > | | | RESERVE' | > | | +------------->| > | | | =20 > | RESERVE > | | | =20 > +-------> > | | | =20 > |RESPONSE > | | | =20 > |<------- > | | | RESPONSE | > |<---------------------------------------------+ > RESPONSE| | | | > <--------| | | | > =20 > Figure 3: Sender-initiated reservation with Reduced State Interior > Nodes >=20 > To=20 >=20 > QNE QNE QNE QNE > Ingress Interior Interior Egress > NTLP stateful NTLP stateless NTLP stateless NTLP stateful > | | | | > RESERVE | | | | > -------->| RESERVE | | | > +--------------------------------------------->| > | RESERVE' | | | > +-------------->| | | > | | RESERVE' | | > | +-------------->| | > | | | RESERVE' | > | | +------------->| > | | | =20 > | RESERVE > | | | =20 > +-------> > | | | =20 > |RESPONSE > | | | =20 > |<------- > | | | RESPONSE'| > |<---------------------------------------------+ > | | | RESPONSE | > |<---------------------------------------------+ > RESPONSE| | | | > <--------| | | | > =20 > Figure 3: Sender-initiated reservation with Reduced State Interior > Nodes >=20 >=20 > Correct? Georgios: Yes it is correct, but I have to mention that I have made a mistake=20 in the argumentation given above. (Note that this function=20 is related to=20 the initiation message and not the refresh message: Georgios: For RMD-QOSM this will mean that for each local initiator=20 RESERVE message an additional RESPONSE message will have to be = generated. >=20 > >=20 > >=20 > > >=20 > > > > --------------------------- > > > > > > > > Point_3: QSEPC template draft dictates which QOS-NSLP signaling=20 > > > > features should be used by QOS models. > > > > > > > > We have never discussed an agreed that the QSPEC template draft=20 > > > > defines how the QOS-NSLP functionality should be used by > > > QoS models.=20 > > > > This should be defined by the QOS-NSLP draft. > > > > Therefore, regarding this issue the QSPEC template draft > > > should refer > > > > to Section "3.1.2. QoS Models and QoS Specifications"" of: > > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt > > > > > > > > Therefore the QSPEC tempate draft should adpat the > > > definitiojn of the > > > > QoS models according to what Section 3.1.2 of the > > QOS-NSLP draft is > > > > saying and refer to Section 3.1.2 of the QOS-NSLP draft. > > > > > > > > =20 > > >=20 > > > I guess this aspect refers to the previous discussion I had with=20 > > > Dave and with you subsequently. > >=20 > > Georgios: > > If the the folowing paragraph > > is added to the proposed QoS model capability list it will=20 > satisfy my=20 > > concerns: > > "The definition of a QoS model may also have implications=20 > on how local > > behavior should be implemented in the areas where the QoS NSLP=20 > > gives > > freedom to implementers. For example, it may be useful=20 > to identify > > recommended behavior for how a RESERVE message that is forwarded > > relates to that received, or when additional signaling sessions > > should be started based on existing sessions, such as=20 > required for > > aggregate reservations. In some cases, suggestions may be made on > > whether state that may optionally be retained should be held in > > particular scenarios. A QoS model may specify reservation > > preemption, e.g., an incoming resource request may cause=20 > removal of > > an earlier reservation." >=20 > I wonder what the impact for the RMD draft are based on the=20 > fact that it supports all signaling modes already. When I=20 > read it last time I thought it described how RMD works in=20 > case of e2e sender-initiated and e2e receiver-initiated reservation. Georgios: RMD-QOSM uses signaling modes, such as=20 severe congestion handling and others. Best regards, Georgios >=20 > Ciao > Hannes >=20 > >=20 > > Best regards, > > Georgios > > >=20 > > > When reading through Section 3.1.2 of > > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-1 > > 2.txt I am sure that the QoS NSLP authors are going to=20 > re-write > the=20 > > section. > > >=20 > > >=20 > > > Ciao > > > Hannes > > > > Best Regards, > > > > Georgios > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 12/23/2006, "john.loughney@nokia.com"=20 > > > > > wrote: > > > > > > > > =20 > > > >> Hi all, > > > >> > > > >> When Jerry posted the draft with the change log, I > > basically noted > > > >> that the changes were based upon previous discussions, on > > > the mailing > > > >> list and the meeting. > > > >> > > > >> I am unsure of the techincal issues that are being > > raised. Rather > > > >> than get into a discussion of what was discussed or not, > > > what I would > > > >> like to understand better is more understanding what are the=20 > > > >> technical issues behind Georgios' issues. > > > >> > > > >> Additionally, I would like to hear from others about their > > > opinions > > > >> on this issue. > > > >> > > > >> thanks, > > > >> John > > > >> > > > >> =20 > > > >>> -----Original Message----- > > > >>> From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > > >>> Sent: 22 December, 2006 20:12 > > > >>> To: Georgios Karagiannis; nsis@ietf.org > > > >>> Cc: Ash, Gerald R (Jerry), ALABS > > > >>> Subject: RE: [NSIS] RE: Comments on=20 > draft-ietf-nsis-qspec-13.txt > > > >>> > > > >>> Georgios, > > > >>> > > > >>> It's not true as you and 2 others have stated that the > > > changes were > > > >>> not discussed. They were discussed, at length. For > > example, the > > > >>> revised definition of QOSM was clearly stated and > > > discussed on the > > > >>> list, see > > > >>>=20 > http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.htm > > > >>> l and also see all the list discussion following that post. > > > >>> The revised definition and all the other changes were clearly=20 > > > >>> presented in the slides at IETF-67, see minutes and slides at=20 > > > >>> http://www3.ietf.org/proceedings/06nov/index.html. You > > > can listen > > > >>> to the complete IETF-67 presentation/discussion again at=20 > > > >>>=20 > http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf > > > >>> 67ch4-thu > > > >>> -am.mp3. > > > >>> > > > >>> You can review the slides, meeting discussion, list=20 > discussion,=20 > > > >>> meeting minutes, and verify that for yourself. > > > >>> > > > >>> So the editors did not 'make up the changes without > > > discussion' as > > > >>> you and 2 others have suggested. That is certainly=20 > wrong and I=20 > > > >>> think you should acknowledge that. > > > >>> > > > >>> It is not useful going forward to debate the past, but > > incendiary > > > >>> wrong statements should not go unanswered. > > > >>> > > > >>> Once again, I've responded to your technical=20 > comments, you can=20 > > > >>> comment further if you wish. > > > >>> > > > >>> It would be good for others to comment on the=20 > technical points. > > > >>> > > > >>> Jerry > > > >>> > > > >>> -----Original Message----- > > > >>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > >>> Sent: Friday, December 22, 2006 11:36 AM > > > >>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > > >>> Subject: RE: [NSIS] RE: Comments on=20 > draft-ietf-nsis-qspec-13.txt > > > >>> > > > >>> Hi Jerry > > > >>> > > > >>> The changes that are included in version 13 of the > > QSEPC template > > > >>> draft regarding the QSPEC control information and the > > > limitations of > > > >>> the QoS models have never been discussed because they > > were never > > > >>> stated clearly. > > > >>> > > > >>> If they would have been stated clearly then I would > > have sent my > > > >>> comments at that time instead of sending them now! > > > >>> > > > >>> Furthermore, from what I have seen in v. 13 of the > > draft you also > > > >>> have not solved the stacking issue, because you are actually=20 > > > >>> dictating that encapsulation cannot be combined and > > used together > > > >>> with the tunneling (parallel sessions) method. > > > >>> > > > >>> > > > >>> Best Regards, > > > >>> Georgios > > > >>> > > > >>> =20 > > > >>>> > > > >>>> =20 > > > >>>>> -----Original Message----- > > > >>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > > >>>>> Sent: vrijdag 22 december 2006 16:37 > > > >>>>> To: Georgios Karagiannis; nsis@ietf.org > > > >>>>> Cc: Ash, Gerald R (Jerry), ALABS > > > >>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > > > >>>>> > > > >>>>> Georgios, > > > >>>>> > > > >>>>> =20 > > > >>>>>> -----Original Message----- > > > >>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > >>>>>> Sent: Friday, December 22, 2006 9:13 AM > > > >>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > > >>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > > > >>>>>> > > > >>>>>> Hi Jerry > > > >>>>>> > > > >>>>>> By just saying that "these changes are suggested by > > > Dave in the > > > >>>>>> e-mail" does not work. > > > >>>>>> > > > >>>>>> The proposal of Dave was not clear on the QoS model changes > > > >>>>>> =20 > > > >>>>> that you > > > >>>>> =20 > > > >>>>>> wanted to do. > > > >>>>>> =20 > > > >>>>> All changes to the draft have been extensively discussed on > > > >>>>> =20 > > > >>>> the list > > > >>>> =20 > > > >>>>> and are all contained in the slides presented at IETF-67. > > > >>>>> =20 > > > >>> You were > > > >>> =20 > > > >>>>> there at > > > >>>>> IETF-67 and participated in all the list discussion. The > > > >>>>> =20 > > > >>>> summary of > > > >>>> =20 > > > >>>>> changes in the slides is quite specific and clear, take > > > >>>>> =20 > > > >>>> another look. > > > >>>> =20 > > > >>>>> Have a look at the minutes as well > > > >>>>>=20 > > > http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt. The only > > > >>>>> disagreements noted are with regard to stacking, which > > > is an issue > > > >>>>> that we later resolved on the list. Go back and=20 > check it out. > > > >>>>> > > > >>>>> =20 > > > >>>>>> Now I understand which changes you want to include in > > > the QSPEC > > > >>>>>> template draft. > > > >>>>>> This is also the reason of disagreeing with you now > > > and sending > > > >>>>>> comments to the nsis list. > > > >>>>>> =20 > > > >>>>> I responded to your further comments, see below. =20 > Others are=20 > > > >>>>> encouraged to comment as well. > > > >>>>> > > > >>>>> Jerry > > > >>>>> > > > >>>>> =20 > > > >>>>>> Furthermore, note that the QOS-NSLP draft defines which > > > >>>>>> =20 > > > >>>>> capabilities > > > >>>>> =20 > > > >>>>>> should be supported by the QoS models and not the > > > QSPEC template > > > >>>>>> draft. > > > >>>>>> > > > >>>>>> Best Regards, > > > >>>>>> Georgios > > > >>>>>> > > > >>>>>> > > > >>>>>> =20 > > > >>>>>>> -----Original Message----- > > > >>>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > > >>>>>>> Sent: vrijdag 22 december 2006 15:01 > > > >>>>>>> To: Georgios Karagiannis; nsis@ietf.org > > > >>>>>>> Cc: Ash, Gerald R (Jerry), ALABS > > > >>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > > > >>>>>>> > > > >>>>>>> Georgios, > > > >>>>>>> > > > >>>>>>> See below. > > > >>>>>>> > > > >>>>>>> =20 > > > >>>>>>>> -----Original Message----- > > > >>>>>>>> From: Georgios Karagiannis=20 > [mailto:karagian@cs.utwente.nl] > > > >>>>>>>> Sent: Thursday, December 21, 2006 9:22 AM > > > >>>>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > > >>>>>>>> Cc: 'Attila Bader (IJ/ETH)'; 'Lars Westberg' > > > >>>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > > > >>>>>>>> > > > >>>>>>>> Hi Jerry > > > >>>>>>>> > > > >>>>>>>> Please see below! I have severe concerns about=20 > some changes > > > >>>>>>>> =20 > > > >>>>>>> that have > > > >>>>>>> =20 > > > >>>>>>>> been done in the QSPEC template draft. > > > >>>>>>>> > > > >>>>>>>> =20 > > > >>>>>>>>> -----Original Message----- > > > >>>>>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > > >>>>>>>>> Sent: woensdag 20 december 2006 14:20 > > > >>>>>>>>> To: Georgios Karagiannis; nsis@ietf.org > > > >>>>>>>>> Cc: Ash, Gerald R (Jerry), ALABS > > > >>>>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt > > > >>>>>>>>> > > > >>>>>>>>> Hi Georgios, > > > >>>>>>>>> > > > >>>>>>>>> See below. > > > >>>>>>>>> > > > >>>>>>>>> =20 > > > >>>>>>>>>> -----Original Message----- > > > >>>>>>>>>> From: Georgios Karagiannis > > > >>>>>>>>>> =20 > > > >>> [mailto:karagian@cs.utwente.nl] > > > >>> =20 > > > >>>>>>>>>> Sent: Wednesday, December 20, 2006 5:26 AM > > > >>>>>>>>>> To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > > >>>>>>>>>> Subject: Comments on draft-ietf-nsis-qspec-13.txt > > > >>>>>>>>>> > > > >>>>>>>>>> Hi Jerry > > > >>>>>>>>>> > > > >>>>>>>>>> Here are my comments on draft-ietf-nsis-qspec-13.txt: > > > >>>>>>>>>> > > > >>>>>>>>>> Comment_1: > > > >>>>>>>>>> -------------- > > > >>>>>>>>>> Please reinclude the concept of QSPEC control > > > >>>>>>>>>> =20 > > > >>>>>>> information that was > > > >>>>>>> =20 > > > >>>>>>>>>> included in all previous versions of the QSPEC > > > >>>>>>>>>> =20 > > > >>>>> template draft. > > > >>>>> =20 > > > >>>>>>>>>> In > > > >>>>>>>>>> > > > >>>>>>>>>> =20 > > > >>>>=20 > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt:=20 > > > >>>> this > > > >>>> =20 > > > >>>>>>>>>> concept was described in Section 5.1. > > > >>>>>>>>>> =20 > > > >>>>>>>>> Please see previous email comment on QSPEC control > > > >>>>>>>>> =20 > > > >>>>> information. > > > >>>>> =20 > > > >>>>>>>> Georgios: > > > >>>>>>>> In order to emphasize the need of having QSPEC control > > > >>>>>>>> =20 > > > >>>>>> information > > > >>>>>> =20 > > > >>>>>>>> parameters I would however appreciate if the name of > > > >>>>>>>> =20 > > > >>>>>>> Section 4.3.3 > > > >>>>>>> =20 > > > >>>>>>>> is changed > > > >>>>>>>> From: > > > >>>>>>>> 4.3.3 Traffic Handling Directives > > > >>>>>>>> INTO: > > > >>>>>>>> 4.3.3 QSPEC control information > > > >>>>>>>> =20 > > > >>>>>>> The updated QSPEC parameter terminology/semantics are as > > > >>>>>>> =20 > > > >>>>> suggested > > > >>>>> =20 > > > >>>>>>> by Dave Oran (see slides presented at IETF-67=20 > > > >>>>>>> http://www3.ietf.org/proceedings/06nov/index.html). I > > > >>>>>>> =20 > > > >>>> think the > > > >>>> =20 > > > >>>>>>> current terminology is more clear/descriptive of=20 > the QSPEC=20 > > > >>>>>>> parameters so I don't favor going backwards to less clear=20 > > > >>>>>>> terminology. I was never clear on why we used=20 > the 'control=20 > > > >>>>>>> information' terminology in the first place, e.g., I > > > >>>>>>> =20 > > > >>>> don't think > > > >>>> =20 > > > >>>>>>> it's a very good descriptor of the 'excess treatment' > > > >>>>>>> =20 > > > >>> parameter. > > > >>> =20 > > > >>>>>>> Perhaps Dave can comment on this point also when he > > > >>>>>>> =20 > > > >>>> gets a chance. > > > >>>> =20 > > > >>>>>>>>>> Comment_2: > > > >>>>>>>>>> ----------- > > > >>>>>>>>>> > > > >>>>>>>>>> Section 6.1: > > > >>>>>>>>>> Please reintroduce the format that is required > > > >>>>>>>>>> =20 > > > >>> in order to > > > >>> =20 > > > >>>>>>>>> specify the > > > >>>>>>>>> =20 > > > >>>>>>>>>> QSPEC control information, see: > > > >>>>>>>>>> Section 7.1 of: > > > >>>>>>>>>> > > > >>>>>>>>>> =20 > > > >>>>>>=20 > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > > >>>>>> =20 > > > >>>>>>>>> Please see previous email comment on QSPEC control > > > >>>>>>>>> =20 > > > >>>>> information. > > > >>>>> =20 > > > >>>>>>>> Georgios: If you rename section 4.3.3 to QSPEC control > > > >>>>>>>> =20 > > > >>>>>> information > > > >>>>>> =20 > > > >>>>>>>> then I think that reformatting of section 6.1 is > > not needed. > > > >>>>>>>> Please add the proposed sentence by Dave (but change > > > >>>>>>>> =20 > > > >>> the term > > > >>> =20 > > > >>>>>>>> "handling directives" to "QSPEC control=20 > Information"). I am > > > >>>>>>>> =20 > > > >>>>>>> not sure > > > >>>>>>> =20 > > > >>>>>>>> where it is better to add this sentence, maybe in > > > >>>>>>>> =20 > > > >>> Section 5.4. > > > >>> =20 > > > >>>>>>>> "QoSMs are free, subject to IANA registration and review > > > >>>>>>>> =20 > > > >>>>>> rules, to > > > >>>>>> =20 > > > >>>>>>>> extend QSPECs by adding parameters of any of the kinds > > > >>>>>>>> =20 > > > >>>>>> supported by > > > >>>>>> =20 > > > >>>>>>>> the standard QSPEC. This includes traffic description > > > >>>>>>>> =20 > > > >>>>> parameters, > > > >>>>> =20 > > > >>>>>>>> constraint parameters and QSPEC control information. > > > >>>>>>>> =20 > > > >>>>>> QoSMs are not > > > >>>>>> =20 > > > >>>>>>>> permitted, however, to reinterpret or redefine the > > > >>>>>>>> =20 > > > >>>>> standard QSPEC > > > >>>>> =20 > > > >>>>>>>> parameters specified in this document" > > > >>>>>>>> =20 > > > >>>>>>> Yes, the text suggested by Dave will be added. > > > >>>>>>> > > > >>>>>>> =20 > > > >>>>>>>>>> Comment_3: > > > >>>>>>>>>> ---------- > > > >>>>>>>>>> Section 4.1 :QoS Models > > > >>>>>>>>>> The definition of the QoS model is not complete. An > > > >>>>>>>>>> =20 > > > >>>>> important > > > >>>>> =20 > > > >>>>>>>>>> sentence that was used in the previous version of the > > > >>>>>>>>>> =20 > > > >>>>>> draft is > > > >>>>>> =20 > > > >>>>>>>>>> removed. > > > >>>>>>>>>> Please add the following sentence to the definition > > > >>>>>>>>>> =20 > > > >>>>>> of the QoS > > > >>>>>> =20 > > > >>>>>>>>>> Model > > > >>>>>>>>>> (QOSM): > > > >>>>>>>>>> > > > >>>>>>>>>> The same as described above have to be applied in > > > >>>>>>>>>> =20 > > > >>>>>> this section. > > > >>>>>> =20 > > > >>>>>>>>>> After the following sentence: > > > >>>>>>>>>> > > > >>>>>>>>>> "A QOSM specification MAY include the following:" > > > >>>>>>>>>> > > > >>>>>>>>>> include the following bullet: > > > >>>>>>>>>> "- it specifies how to use QOS NSLP to signal for > > > >>>>>>>>>> =20 > > > >>>> this QOSM" > > > >>>> =20 > > > >>>>>>>>> That sentence was removed in Dave's proposed QOSM > > > >>>>>>>>> =20 > > > >>>>>>> re-definition, see > > > >>>>>>> =20 > > > >>>>=20 > http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht > > > >>>> =20 > > > >>>>>>>>> ml. It was unclear what that sentence meant, QoS-NSLP > > > >>>>>>>>> =20 > > > >>>>>>> specifies how > > > >>>>>>> =20 > > > >>>>>>>>> to signal, not QOSM specifications, so the sentence > > > >>>>>>>>> =20 > > > >>>>> was removed. > > > >>>>> =20 > > > >>>>>>>>> I believe the sentence was intended to mean that when > > > >>>>>>>>> =20 > > > >>>>> QoS NSLP > > > >>>>> =20 > > > >>>>>>>>> allows various options to be selected, a QOSM should > > > >>>>>>>>> =20 > > > >>>>> be able to > > > >>>>> =20 > > > >>>>>>>>> determine which option is used. For that purpose the > > > >>>>>>>>> =20 > > > >>>>> following > > > >>>>> =20 > > > >>>>>>>>> sentence was added in Section 4.1: > > > >>>>>>>>> > > > >>>>>>>>> " A QOSM specification MAY include the following: > > > >>>>>>>>> ... > > > >>>>>>>>> - can state which QoS-NSLP options a QOSM wants to > > > >>>>>>>>> =20 > > > >>>>>> use, when > > > >>>>>> =20 > > > >>>>>>>>> several options are available for a QOSM (e.g., > > > >>>>>>>>> =20 > > > >>>>>>> local QSPEC to > > > >>>>>>> =20 > > > >>>>>>>>> either be a) tunneled or b) encapsulate > > > >>>>>>>>> =20 > > > >>>>> initiator QSPEC)." > > > >>>>> =20 > > > >>>>>>>>> Also, to avoid any misinterpretation that QOSMs are free > > > >>>>>>>>> =20 > > > >>>>>>> to specify > > > >>>>>>> =20 > > > >>>>>>>>> additional constraints, state machines, protocol data, > > > >>>>>>>>> =20 > > > >>>>>>> etc. for NSLP > > > >>>>>>> =20 > > > >>>>>>>>> beyond that which is specific in the QoS NSLP > > > >>>>>>>>> =20 > > > >>>>>> specification, the > > > >>>>>> =20 > > > >>>>>>>>> following was added to Section 4.1: > > > >>>>>>>>> > > > >>>>>>>>> " QOSMs affect the operation of the RMF in NSIS-capable > > > >>>>>>>>> =20 > > > >>>>>>> nodes, the > > > >>>>>>> =20 > > > >>>>>>>>> information carried in QSPEC objects, and may > > under some > > > >>>>>>>>> circumstances (e.g. aggregation) cause a=20 > separate NSLP > > > >>>>>>>>> session to be > > > >>>>>>>>> instantiated by having the RMF as a QNI. QOSMs > > > >>>>>>>>> =20 > > > >>>> all utilize > > > >>>> =20 > > > >>>>>>>>> the common > > > >>>>>>>>> data, state machines, and APIs of the underlying NSIS > > > >>>>>>>>> protocols and > > > >>>>>>>>> are not expected to re-define or extend these in > > > >>>>>>>>> =20 > > > >>>> any way." > > > >>>> =20 > > > >>>>>>>> Georgios: > > > >>>>>>>> Regarding the sentence in Section 4.1: > > > >>>>>>>> "QOSMs all utilize > > > >>>>>>>> the common data, state machines, and APIs of the > > > >>>>>>>> =20 > > > >>>>> underlying NSIS > > > >>>>> =20 > > > >>>>>>>> protocols and are not expected to re-define or extend > > > >>>>>>>> =20 > > > >>>>>> these in any > > > >>>>>> =20 > > > >>>>>>>> way." > > > >>>>>>>> > > > >>>>>>>> This sentence restricts the possibility of QoS=20 > model to use > > > >>>>>>>> =20 > > > >>>>>>> RMF states > > > >>>>>>> =20 > > > >>>>>>>> and data that are not been defined in neither > > > >>>>>>>> =20 > > > >>>> QoS-NSLP or QSPEC. > > > >>>> =20 > > > >>>>>>>> This sentence should be removed. > > > >>>>>>>> =20 > > > >>>>>>> I disagree. The quoted text was introduced by Dave Oran > > > >>>>>>> =20 > > > >>>>> in addition > > > >>>>> =20 > > > >>>>>>> to removing the phrase implying that a QOSM could specify > > > >>>>>>> =20 > > > >>>>> signaling > > > >>>>> =20 > > > >>>>>>> protocol changes, and I agree with this. > > > >>>>>>> Any changes/extensions to the signaling protocol or state > > > >>>>>>> =20 > > > >>>>> machines > > > >>>>> =20 > > > >>>>>>> are within the scope of QoS-NSLP draft and not the QSPEC > > > >>>>>>> =20 > > > >>>>> draft or a > > > >>>>> =20 > > > >>>>>>> QOSM specification draft. I think you have noted that > > > >>>>>>> =20 > > > >>>>> also in your > > > >>>>> =20 > > > >>>>>>> subsequent posting at > > > >>>>>>> > > > >>>>>>> =20 > > > >>>>=20 > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07352.html. > > > >>>> =20 > > > >>>>>>> If any extensions are required to the NSIS signaling > > > >>>>>>> =20 > > > >>>>> protocol as a > > > >>>>> =20 > > > >>>>>>> result of the 'severe change on QoS Model definition and=20 > > > >>>>>>> capabilities' > > > >>>>>>> you have noted, those proposed changes/extensions=20 > should be=20 > > > >>>>>>> addressed to the QoS NSLP draft IMO. > > > >>>>>>> > > > >>>>>>> Perhaps Dave can comment here also when he gets a chance. > > > >>>>>>> > > > >>>>>>> =20 > > > >>>>>>>>>> Comment_4: > > > >>>>>>>>>> ------------- > > > >>>>>>>>>> Section 5.1 Local QSPEC definition and processing > > > >>>>>>>>>> > > > >>>>>>>>>> By reading this section it gives the impression > > > >>>>>>>>>> =20 > > > >>>>> that the two > > > >>>>> =20 > > > >>>>>>>>>> methods > > > >>>>>>>>>> a) and b) cannot be used by the same QoS model. > > > >>>>>>>>>> Method a): translate the > > > >>>>>>>>>> initiator QSPEC into a local QSPEC and encapsulate the > > > >>>>>>>>>> =20 > > > >>>>>>> initiator > > > >>>>>>> =20 > > > >>>>>>>>>> QSPEC in the RESERVE message Method b): b) tunnel the > > > >>>>>>>>>> =20 > > > >>>>>> initiator > > > >>>>>> =20 > > > >>>>>>>>>> QSPEC through the local domain and reserve resources by > > > >>>>>>>>>> =20 > > > >>>>>>> generating > > > >>>>>>> =20 > > > >>>>>>>>>> a new RESERVE message through the local domain > > > >>>>>>>>>> =20 > > > >>>>> containing the > > > >>>>> =20 > > > >>>>>>>>>> local QSPEC. > > > >>>>>>>>>> > > > >>>>>>>>>> Note that according to the discussions that we have had > > > >>>>>>>>>> =20 > > > >>>>>>> until now > > > >>>>>>> =20 > > > >>>>>>>>>> method a) should be able to be used in combination with > > > >>>>>>>>>> =20 > > > >>>>>>> method b) > > > >>>>>>> =20 > > > >>>>>>>>>> by the same QoS model for the situation that the > > > >>>>>>>>>> =20 > > > >>>>> local QSPEC > > > >>>>> =20 > > > >>>>>>>>>> encapsulates the initiator QSPEC in order to satisfy > > > >>>>>>>>>> =20 > > > >>>>>>> requirement > > > >>>>>>> =20 > > > >>>>>>>>>> 5.4.2 that is specified in RFC 3726, see: > > > >>>>>>>>>> http://www.ietf.org/rfc/rfc3726.txt > > > >>>>>>>>>> > > > >>>>>>>>>> Please add the following sentence at the end of > > > >>>>>>>>>> =20 > > > >>> the first > > > >>> =20 > > > >>>>>>>>>> paragraph of Section 5.1. > > > >>>>>>>>>> "Note that when method b) is used, the > > > >>>>>>>>>> =20 > > > >>>> encapsulation of the > > > >>>> =20 > > > >>>>>>>>>> initiator QSPEC into a local QSPEC should also be > > > >>>>>>>>>> =20 > > > >>>>>> possible when > > > >>>>>> =20 > > > >>>>>>>>>> the local QoS model needs to satisfy Requirement > > > >>>>>>>>>> 5.4.2 specified in RFC 3726, by adding and > > > >>>>>>>>>> =20 > > > >>> removing local > > > >>> =20 > > > >>>>>>>>>> QOSM-specific Control Information parameters on > > > >>>>>>>>>> =20 > > > >>>> top of the > > > >>>> =20 > > > >>>>>>>>>> initiator QSPEC." > > > >>>>>>>>>> =20 > > > >>>>>>>>> Your comment here is not clear to me. It would help to > > > >>>>>>>>> =20 > > > >>>>>>> provide an > > > >>>>>>> =20 > > > >>>>>>>>> example to illustrate what you are trying to accomplish. > > > >>>>>>>>> =20 > > > >>>>>>> It seems > > > >>>>>>> =20 > > > >>>>>>>>> that you are trying to specify QoS-NSLP functionality, > > > >>>>>>>>> =20 > > > >>>>>>> rather than > > > >>>>>>> =20 > > > >>>>>>>>> QSPEC functionality. If so, that functionality=20 > should be > > > >>>>>>>>> =20 > > > >>>>>>> specified > > > >>>>>>> =20 > > > >>>>>>>>> in the QoS-NSLP draft rather than the QSPEC draft, > > > >>>>>>>>> =20 > > > >>>>> perhaps the > > > >>>>> =20 > > > >>>>>>>>> QoS-NSLP authors can comment. > > > >>>>>>>>> =20 > > > >>>>>>>> Georgios: > > > >>>>>>>> No I am not trying to define QOS-NSLP functionality. > > > >>>>>>>> This is related to QSPEC control information=20 > that has to be > > > >>>>>>>> =20 > > > >>>>>>> carried by > > > >>>>>>> =20 > > > >>>>>>>> end-to-end messages. > > > >>>>>>>> What I am trying to say is that all the discussion that > > > >>>>>>>> =20 > > > >>>>>> we have had > > > >>>>>> =20 > > > >>>>>>>> regarding the encapsulation of the QSPEC object were > > > >>>>>>>> =20 > > > >>>>>>> associated with > > > >>>>>>> =20 > > > >>>>>>>> requirement 5.4.2 of RFC 3726, see below: > > > >>>>>>>> > > > >>>>>>>> ----------------- > > > >>>>>>>> "5.4.2. It SHOULD be Possible to Add and Remove > > > >>>>>>>> =20 > > > >>> Local Domain > > > >>> =20 > > > >>>>>>>> Information > > > >>>>>>>> > > > >>>>>>>> It SHOULD be possible to add and remove local > > > >>>>>>>> =20 > > > >>>> scope elements. > > > >>>> =20 > > > >>>>>>>> Compared to Requirement 5.3.5 this=20 > requirement does use > > > >>>>>>>> =20 > > > >>>>>>> the normal > > > >>>>>>> =20 > > > >>>>>>>> signaling process and message exchange for > > > >>>>>>>> =20 > > > >>>> transporting local > > > >>>> =20 > > > >>>>>>>> information. For example, at the entrance to a > > > >>>>>>>> =20 > > > >>>>> domain, domain- > > > >>>>> =20 > > > >>>>>>>> specific information is added information is > > added, which > > > >>>>>>>> is used in > > > >>>>>>>> this domain only, and the information is removed > > > >>>>>>>> =20 > > > >>>> again when a > > > >>>> =20 > > > >>>>>>>> signaling message leaves the domain. The motivation > > > >>>>>>>> =20 > > > >>>>> is in the > > > >>>>> =20 > > > >>>>>>>> economy of re-using the protocol for domain internal > > > >>>>>>>> =20 > > > >>>>>> signaling of > > > >>>>>> =20 > > > >>>>>>>> various information pieces. Where additional > > > >>>>>>>> =20 > > > >>>>>>> information is needed > > > >>>>>>> =20 > > > >>>>>>>> within a particular domain, it should be possible to > > > >>>>>>>> =20 > > > >>>>>>> carry this at > > > >>>>>>> =20 > > > >>>>>>>> the same time as the end-to-end information.", > > > >>>>>>>> =20 > > > >>>> from RFC 3726 > > > >>>> =20 > > > >>>>>>>> ------------------ > > > >>>>>>>> Thus what I am saying is: > > > >>>>>>>> Please add the following sentence at the end of the first > > > >>>>>>>> =20 > > > >>>>>>> paragraph of > > > >>>>>>> =20 > > > >>>>>>>> Section 5.1. > > > >>>>>>>> > > > >>>>>>>> "Note that when method b) is used, the=20 > encapsulation of the > > > >>>>>>>> =20 > > > >>>>>>> initiator > > > >>>>>>> =20 > > > >>>>>>>> QSPEC into a local QSPEC should also be possible when the > > > >>>>>>>> =20 > > > >>>>>> local QoS > > > >>>>>> =20 > > > >>>>>>>> model needs to satisfy Requirement > > > >>>>>>>> 5.4.2 specified in RFC 3726, by adding and=20 > removing local=20 > > > >>>>>>>> QOSM-specific Control Information parameters on=20 > top of the > > > >>>>>>>> =20 > > > >>>>>>> initiator > > > >>>>>>> =20 > > > >>>>>>>> QSPEC." > > > >>>>>>>> =20 > > > >>>>>>> First, the suggested text isn't clear. If method=20 > b) is used > > > >>>>>>> (tunneling) then presumably method a) is not also used at > > > >>>>>>> =20 > > > >>>>> the same > > > >>>>> =20 > > > >>>>>>> time. However, the phrasing of the above makes it > > > >>>>>>> =20 > > > >>>> sound that way. > > > >>>> =20 > > > >>>>>>> Second, an example would help here. I presume you are > > > >>>>>>> =20 > > > >>>> referring > > > >>>> =20 > > > >>>>>>> e.g., to RMD adding 'control information' (i.e., 'handling > > > >>>>>>> directive') parameters to the local QSPEC that are not > > > >>>>>>> =20 > > > >>>>> included in > > > >>>>> =20 > > > >>>>>>> the initiator QSPEC. I think the requirement would be > > > >>>>>>> =20 > > > >>>>> that the RMD > > > >>>>> =20 > > > >>>>>>> QOSM provides a local QSPEC that is consistent with the > > > >>>>>>> =20 > > > >>>> initiator > > > >>>> =20 > > > >>>>>>> QSPEC, as we agreed on the list (see also slide 8 of > > > >>>>>>> =20 > > > >>>> the IETF-67 > > > >>>> =20 > > > >>>>>>> presentation). > > > >>>>>>> > > > >>>>>>> If the local QSPEC introduces functionality > > > >>>>>>> =20 > > > >>>> inconsistent with the > > > >>>> =20 > > > >>>>>>> initiator QSPEC by appending the handling directive > > > >>>>>>> =20 > > > >>>>> parameters, then > > > >>>>> =20 > > > >>>>>>> it is not allowed. > > > >>>>>>> > > > >>>>>>> =20 > > > >>>>>>>>>> Comment_5: > > > >>>>>>>>>> ----------- > > > >>>>>>>>>> Section 5.1, last paragraph: > > > >>>>>>>>>> > > > >>>>>>>>>> Please change the following: > > > >>>>>>>>>> "For example, RMD can define a local QSPEC that > > > >>>>>>>>>> =20 > > > >>>>>> contains TMOD =3D > > > >>>>>> =20 > > > >>>>>>>>>> bandwidth (sets r=3Dp, b/m to large)." > > > >>>>>>>>>> > > > >>>>>>>>>> Into: > > > >>>>>>>>>> "For example, in RMD the TMOD parameters contained in > > > >>>>>>>>>> =20 > > > >>>>>>> the original > > > >>>>>>> =20 > > > >>>>>>>>>> initiator QSPEC are mapped into the equivalent TMOD > > > >>>>>>>>>> =20 > > > >>>>> parameter > > > >>>>> =20 > > > >>>>>>>>>> representing only the peak bandwidth in the=20 > local QSPEC." > > > >>>>>>>>>> =20 > > > >>>>>>>>> OK with me. > > > >>>>>>>>> > > > >>>>>>>>> =20 > > > >>>>>>>>>> Comment_6: > > > >>>>>>>>>> ------------- > > > >>>>>>>>>> In Section 5.3.1, 5.3.2, 5.3.3 the rules that have to > > > >>>>>>>>>> =20 > > > >>>>>>> be followed > > > >>>>>>> =20 > > > >>>>>>>>>> regarding the QSPEC control information are not given: > > > >>>>>>>>>> > > > >>>>>>>>>> Please include the following paragraph at the end of > > > >>>>>>>>>> =20 > > > >>>>>>> this section: > > > >>>>>>> =20 > > > >>>>>>>>>> "Regarding QSPEC Control Information, the default rule > > > >>>>>>>>>> =20 > > > >>>>>>> is that all > > > >>>>>>> =20 > > > >>>>>>>>>> QSPEC parameters that have been included in > > > >>>>>>>>>> =20 > > > >>>> the RESERVE > > > >>>> =20 > > > >>>>>>>>>> message by > > > >>>>>>>>>> the QNI are also included in the RESPONSE > > > >>>>>>>>>> =20 > > > >>>> message by the > > > >>>> =20 > > > >>>>>>>>>> QNR with the > > > >>>>>>>>>> value they had when arriving at the QNR. When > > > >>>>>>>>>> =20 > > > >>>>>>> traveling in the > > > >>>>>>> =20 > > > >>>>>>>>>> RESPONSE message, all QSPEC Control Information > > > >>>>>>>>>> =20 > > > >>>>>>> parameters are > > > >>>>>>> =20 > > > >>>>>>>>>> read-only. Note that a QOSM specification may > > > >>>>>>>>>> =20 > > > >>>>>> define its own > > > >>>>>> =20 > > > >>>>>>>>>> QOSM-specific Control Information parameters and > > > >>>>>>>>>> processing rules." > > > >>>>>>>>>> =20 > > > >>>>>>>>> Please see previous email comment on QSPEC control > > > >>>>>>>>> =20 > > > >>>>> information. > > > >>>>> =20 > > > >>>>>>>> Georgios: I think that a description of how the > > > >>>>>>>> =20 > > > >>> QSPEC control > > > >>> =20 > > > >>>>>>>> information is handled is needed. > > > >>>>>>>> =20 > > > >>>>>>> Please see above comments on 'control information'=20 > > > terminology. > > > >>>>>>> > > > >>>>>>> Thanks, > > > >>>>>>> Jerry > > > >>>>>>> > > > >>>>>>> =20 > > > >>>>>>>>>> Comment_7: > > > >>>>>>>>>> ------------ > > > >>>>>>>>>> Section 6.1: > > > >>>>>>>>>> I do not understand the second sentence from the > > > >>>>>>>>>> =20 > > > >>> below two > > > >>> =20 > > > >>>>>>>>>> sentences: > > > >>>>>>>>>> "N Flag: Not-supported QSPEC parameter flag (see > > > >>>>>>>>>> =20 > > > >>>>>> Section 5.2.2). > > > >>>>>> =20 > > > >>>>>>>>>> For QSPEC parameters the value of this flag > > > >>>>>>>>>> =20 > > > >>>>>>> is always > > > >>>>>>> =20 > > > >>>>>>>>>> zero." > > > >>>>>>>>>> =20 > > > >>>>>>>>> Good catch, this is a typo, the sentence should > > be removed. > > > >>>>>>>>> > > > >>>>>>>>> =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 > > > >>> > > > >>> =20 > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > =20 > > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > 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 Jan 04 09:26:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2TXR-0004E0-6F; Thu, 04 Jan 2007 09:25:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2TXP-0004Dl-V9 for nsis@ietf.org; Thu, 04 Jan 2007 09:25:47 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2TXO-0005Yo-Gm for nsis@ietf.org; Thu, 04 Jan 2007 09:25:47 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l04EPcIE007955; Thu, 4 Jan 2007 15:25:38 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l04EPcK0023576; Thu, 4 Jan 2007 15:25:38 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 15:25:38 +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: AW: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 15:25:36 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC02529770@MCHP7R6A.ww002.siemens.net> In-Reply-To: <002c01c73009$4ad3ec70$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Thread-Index: Accv+fb106GFgntAQb6TS261LT42lQABzTHAAAEt00AAAHr7gAAA3Cmw From: "Tschofenig, Hannes" To: "Georgios Karagiannis" , "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jan 2007 14:25:38.0399 (UTC) FILETIME=[349FFEF0:01C7300C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: john.loughney@nokia.com, 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,=20 Hi QSPEC authors,=20 I guess we are getting closer to the core issues and we need input from the QSPEC authors.=20 ~snip~ > Georgios: The RMD-QOSM uses many QSPEC spcific control information > parameters=20 > that are different and have to be processed differently=20 > than the parameter. It should be possible=20 > to define and > use=20 > such parameters. Question to the QSPEC authors: What should happen with these control parameters in a QoSM like RMD?=20 [[Minor question: Wouldn't the NSIS PCN QoSM also require additional signaling exchanges? ]] ~snip~ > > Correct? > Georgios: Yes it is correct, but I have to mention that I have made a > mistake=20 > in the argumentation given above. (Note that this function=20 > is related to=20 > the initiation message and not the refresh message: > Georgios: For RMD-QOSM this will mean that for each local initiator=20 > RESERVE message an additional RESPONSE message will have to=20 > be generated. If this additional message is only relevant for the initial setup then the impact shouldn't be large? Right?=20 ~snip~ > Georgios: RMD-QOSM uses signaling modes, such as=20 > severe congestion handling and others. Question to the QSPEC authors: What would happen to these types of signaling exchanges?=20 >=20 > Best regards, > Georgios Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 04 09:34:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2TfV-0001u4-Cy; Thu, 04 Jan 2007 09:34:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2TfU-0001rq-1A for nsis@ietf.org; Thu, 04 Jan 2007 09:34:08 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2TfS-0006rB-IV for nsis@ietf.org; Thu, 04 Jan 2007 09:34:08 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l04EXGYV009034; Thu, 4 Jan 2007 15:33:20 +0100 (MET) From: "Georgios Karagiannis" To: "'Tschofenig, Hannes'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 15:33:19 +0100 Message-ID: <002d01c7300d$4a5e9890$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.3028 Thread-Index: Accv+fb106GFgntAQb6TS261LT42lQABzTHAAAEt00AAAHr7gAAA3CmwAABRqnA= In-Reply-To: <6F0CB04509C11D46A54232E852E390AC02529770@MCHP7R6A.ww002.siemens.net> X-Spam-Score: 0.249 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 04 Jan 2007 15:33:21 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: john.loughney@nokia.com, 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 Hannes Please see in line! > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: donderdag 4 januari 2007 15:26 > To: Georgios Karagiannis; Hannes Tschofenig > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > Subject: AW: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > > Hi Georgios, > Hi QSPEC authors, > > I guess we are getting closer to the core issues and we need > input from the QSPEC authors. > > ~snip~ > > Georgios: The RMD-QOSM uses many QSPEC spcific control information > > parameters that are different and have to be processed differently > > than the parameter. It should be > possible to define > > and use such parameters. > > > Question to the QSPEC authors: What should happen with these > control parameters in a QoSM like RMD? > > [[Minor question: Wouldn't the NSIS PCN QoSM also require > additional signaling exchanges? ]] Georgios: Yes I think so! > > ~snip~ > > > > Correct? > > Georgios: Yes it is correct, but I have to mention that I > have made a > > mistake in the argumentation given above. (Note that this > function is > > related to the initiation message and not the refresh message: > > Georgios: For RMD-QOSM this will mean that for each local initiator > > RESERVE message an additional RESPONSE message will have to be > > generated. > > If this additional message is only relevant for the initial > setup then the impact shouldn't be large? Right? Georgios: Yes you are right, but when this feature is used it will severely increase the performance of NSIS when such solutions are applied in very highly utilised networks! > ~snip~ > > > Georgios: RMD-QOSM uses signaling modes, such as severe congestion > > handling and others. > > > Question to the QSPEC authors: What would happen to these > types of signaling exchanges? Georgios: Note that such signaling modes will also be required by the NSIS PCN QoSM! Best Regards, Georgios > > > > > > Best regards, > > Georgios > > Ciao > Hannes > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 04 09:44:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Toh-0000pu-7A; Thu, 04 Jan 2007 09:43:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Tof-0000po-OS for nsis@ietf.org; Thu, 04 Jan 2007 09:43:37 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Toc-000894-5j for nsis@ietf.org; Thu, 04 Jan 2007 09:43:37 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 650EB3AB; Thu, 4 Jan 2007 15:43:31 +0100 (CET) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 15:43:30 +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] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 15:43:30 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E910F73A3@esealmw116.eemea.ericsson.se> In-Reply-To: <6F0CB04509C11D46A54232E852E390AC02529770@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Thread-Index: Accv+fb106GFgntAQb6TS261LT42lQABzTHAAAEt00AAAHr7gAAA3CmwAABgUuA= From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Tschofenig, Hannes" , "Georgios Karagiannis" , "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jan 2007 14:43:30.0856 (UTC) FILETIME=[B3DBF280:01C7300E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: john.loughney@nokia.com, 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,=20 I do not think that the three points Georgios has raised would be = unresolvable issues. See below,=20 Best regards, Attila >-----Original Message----- >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 >Sent: Thursday, January 04, 2007 3:26 PM >To: Georgios Karagiannis; Hannes Tschofenig >Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org >Subject: AW: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > >Hi Georgios, >Hi QSPEC authors,=20 > >I guess we are getting closer to the core issues and we need=20 >input from the QSPEC authors.=20 > >~snip~ >> Georgios: The RMD-QOSM uses many QSPEC spcific control information=20 >> parameters that are different and have to be processed differently=20 >> than the parameter. It should be possible=20 >to define=20 >> and use such parameters. > > >Question to the QSPEC authors: What should happen with these=20 >control parameters in a QoSM like RMD?=20 I assume that such control information is still possible to define and = use. Control information was not removed, it was renamed and definition = has changed. Traffic handling directives may not the best name. QoS NSLP = allows different signaling options, that is another reason for control = information, so there should be "signaling handling directives" as well. = I do not see problems adding the text proposed by Georgios.=20 > >[[Minor question: Wouldn't the NSIS PCN QoSM also require=20 >additional signaling exchanges? ]] > I assume, yes. >~snip~ > >> > Correct? >> Georgios: Yes it is correct, but I have to mention that I=20 >have made a=20 >> mistake in the argumentation given above. (Note that this=20 >function is=20 >> related to the initiation message and not the refresh message: >> Georgios: For RMD-QOSM this will mean that for each local initiator=20 >> RESERVE message an additional RESPONSE message will have to be=20 >> generated. > >If this additional message is only relevant for the initial=20 >setup then the impact shouldn't be large? Right?=20 > >~snip~ > >> Georgios: RMD-QOSM uses signaling modes, such as severe congestion=20 >> handling and others. > > >Question to the QSPEC authors: What would happen to these=20 >types of signaling exchanges?=20 > > I do not think QSpec template doc. should contain signaling definitions = or restictions like which signaling options should be used. It should be = defined by QoS model. Can we aggree with it? I think, to update the = template doc. according to it does not require much change. >>=20 >> Best regards, >> Georgios > >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 Thu Jan 04 09:53:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2TxZ-0004EF-WE; Thu, 04 Jan 2007 09:52:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2TxX-0004E6-W3 for nsis@ietf.org; Thu, 04 Jan 2007 09:52:47 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2TxW-00017F-Il for nsis@ietf.org; Thu, 04 Jan 2007 09:52:47 -0500 Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id l04EqZSc010539; Thu, 4 Jan 2007 15:52:35 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l04EqZO2019832; Thu, 4 Jan 2007 15:52:35 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 15:52: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: AW: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 15:52:33 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC025297A2@MCHP7R6A.ww002.siemens.net> In-Reply-To: <002d01c7300d$4a5e9890$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Thread-Index: Accv+fb106GFgntAQb6TS261LT42lQABzTHAAAEt00AAAHr7gAAA3CmwAABRqnAAAJs5YA== From: "Tschofenig, Hannes" To: "Georgios Karagiannis" , "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jan 2007 14:52:35.0391 (UTC) FILETIME=[F86D64F0:01C7300F] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: john.loughney@nokia.com, 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, =20 > Georgios: Yes you are right, but when this feature is used=20 > it will severely increase the performance of NSIS when such=20 > solutions are > applied=20 > in very highly utilised networks! You mean 'severely impact the performance'.=20 Every end-to-end reservation setup request would add a single message within the RMD domain.=20 Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 04 10:08:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2UCG-0007xY-U3; Thu, 04 Jan 2007 10:08:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2UCF-0007xS-Vl for nsis@ietf.org; Thu, 04 Jan 2007 10:07:59 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2UCC-0002kj-M6 for nsis@ietf.org; Thu, 04 Jan 2007 10:07:59 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l04F6lpZ010304; Thu, 4 Jan 2007 16:06:51 +0100 (MET) From: "Georgios Karagiannis" To: "'Tschofenig, Hannes'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 16:06:49 +0100 Message-ID: <002e01c73011$f8dc4170$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.3028 Thread-Index: Accv+fb106GFgntAQb6TS261LT42lQABzTHAAAEt00AAAHr7gAAA3CmwAABRqnAAAJs5YAAApH2g In-Reply-To: <6F0CB04509C11D46A54232E852E390AC025297A2@MCHP7R6A.ww002.siemens.net> X-Spam-Score: 0.25 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 04 Jan 2007 16:06:51 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: john.loughney@nokia.com, 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 Hannes Please see in line! > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: donderdag 4 januari 2007 15:53 > To: Georgios Karagiannis; Hannes Tschofenig > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > Subject: AW: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > > Hi Georgios, > > > > Georgios: Yes you are right, but when this feature is used it will > > severely increase the performance of NSIS when such solutions are > > applied in very highly utilised networks! > > You mean 'severely impact the performance'. > > Every end-to-end reservation setup request would add a single > message within the RMD domain. Georgios: yes, but in a highly utilsed domain that uses call holding time applications this number can be very large! Best regards, Georgios > > 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 Thu Jan 04 10:14:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2UHy-00028J-Ui; Thu, 04 Jan 2007 10:13:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2UHx-00022K-4f for nsis@ietf.org; Thu, 04 Jan 2007 10:13:53 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2UHv-0003cv-O7 for nsis@ietf.org; Thu, 04 Jan 2007 10:13:53 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l04FD7Qi010514; Thu, 4 Jan 2007 16:13:11 +0100 (MET) From: "Georgios Karagiannis" To: "'Georgios Karagiannis'" , "'Tschofenig, Hannes'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 16:13:09 +0100 Message-ID: <002f01c73012$db759810$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.3028 Thread-Index: Accv+fb106GFgntAQb6TS261LT42lQABzTHAAAEt00AAAHr7gAAA3CmwAABRqnAAAJs5YAAApH2gAABOHoA= In-Reply-To: <002e01c73011$f8dc4170$4c0d5982@dynamic.ewi.utwente.nl> X-Spam-Score: 0.25 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 04 Jan 2007 16:13:12 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: john.loughney@nokia.com, 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 hannes I meant: Georgios: yes, but in a highly utilsed domain that uses short call holding time applications this number can be very large! Best regards, Georgios > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: donderdag 4 januari 2007 16:07 > To: 'Tschofenig, Hannes'; 'Hannes Tschofenig' > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > > Hi Hannes > > Please see in line! > > > -----Original Message----- > > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: donderdag 4 januari 2007 15:53 > > To: Georgios Karagiannis; Hannes Tschofenig > > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > > Subject: AW: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > > > > Hi Georgios, > > > > > > > Georgios: Yes you are right, but when this feature is > used it will > > > severely increase the performance of NSIS when such solutions are > > > applied in very highly utilised networks! > > > > You mean 'severely impact the performance'. > > > > Every end-to-end reservation setup request would add a > single message > > within the RMD domain. > > Georgios: yes, but in a highly utilsed domain that uses call > holding time applications this number can be very large! > > Best regards, > Georgios > > > > > 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 Thu Jan 04 10:42:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Uj4-0003s3-Im; Thu, 04 Jan 2007 10:41:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Uj3-0003rh-72 for nsis@ietf.org; Thu, 04 Jan 2007 10:41:53 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Uj1-0008TU-NH for nsis@ietf.org; Thu, 04 Jan 2007 10:41:53 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l04Fe3Yq022724; Thu, 4 Jan 2007 17:40:30 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 17:38:56 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 17:38:56 +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] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 17:38:55 +0200 Message-ID: In-Reply-To: <002f01c73012$db759810$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Thread-Index: Accv+fb106GFgntAQb6TS261LT42lQABzTHAAAEt00AAAHr7gAAA3CmwAABRqnAAAJs5YAAApH2gAABOHoAAAOUGQA== From: To: , , X-OriginalArrivalTime: 04 Jan 2007 15:38:56.0948 (UTC) FILETIME=[725D4F40:01C73016] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070104174030-564BFBB0-73AC6AB9/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 meant: >Georgios: yes, but in a highly utilsed domain that uses short=20 >call holding time applications this number can be very large! Do you have any simulation results or estimates? I'd like to understand a little bit about making a special purpose solution when we are trying to define a general protocol. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 04 10:53:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Utv-0002bb-Pw; Thu, 04 Jan 2007 10:53:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Utu-0002bW-VV for nsis@ietf.org; Thu, 04 Jan 2007 10:53:06 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Utt-0002uQ-J7 for nsis@ietf.org; Thu, 04 Jan 2007 10:53:06 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l04FqokF011821; Thu, 4 Jan 2007 16:52:54 +0100 (MET) From: "Georgios Karagiannis" To: , , Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 16:52:52 +0100 Message-ID: <003401c73018$68089610$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.3028 Thread-Index: Accv+fb106GFgntAQb6TS261LT42lQABzTHAAAEt00AAAHr7gAAA3CmwAABRqnAAAJs5YAAApH2gAABOHoAAAOUGQAAAS8Iw In-Reply-To: X-Spam-Score: 0.25 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 04 Jan 2007 16:52:55 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 John Just an example: Suppose that 100000 calls/second have to be supported by a RMD-QOSM aware domain. This will mean that in a worst case situation 100000 additional messages/sec will have to be processed by an interior node. Best regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 4 januari 2007 16:39 > To: karagian@cs.utwente.nl; hannes.tschofenig@siemens.com; > Hannes.Tschofenig@gmx.net > Cc: gash@att.com; nsis@ietf.org > Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > > Hi Georgios, > > > >I meant: > >Georgios: yes, but in a highly utilsed domain that uses short call > >holding time applications this number can be very large! > > Do you have any simulation results or estimates? I'd like to > understand a little bit about making a special purpose > solution when we are trying to define a general protocol. > > 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 Thu Jan 04 11:04:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2V4s-0004tZ-56; Thu, 04 Jan 2007 11:04:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2V4r-0004tU-Bk for nsis@ietf.org; Thu, 04 Jan 2007 11:04:25 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2V4m-0005eN-P9 for nsis@ietf.org; Thu, 04 Jan 2007 11:04:25 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1167926658!18181728!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 18014 invoked from network); 4 Jan 2007 16:04:19 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-7.tower-120.messagelabs.com with SMTP; 4 Jan 2007 16:04:19 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l04G4IOL029033; Thu, 4 Jan 2007 11:04:18 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l04G4Bsw028983; Thu, 4 Jan 2007 11:04:12 -0500 (EST) 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] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 10:04:11 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8091@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC808D@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Thread-Index: AccnNAmV02JEI4mYSJ2rqx7HFPHiiwIEzvwgADBavYA= From: "Ash, Gerald R \(Jerry\), ALABS" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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 John, All, Happy New Year! It appears we still have a few technical issues to resolve, as summarized below by Georgios, in addition to the editorial issues that have been raised on the list.=20 I believe that Dave mostly pulled us out of the dead-lock we've been in for the last several months, and that most of us agreed that the QSPEC was overall simplified and the issues were largely resolved. =20 I've commented on the 3 issues below; hopefully we can quickly reach consensus so we can move forward:=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Sunday, December 24, 2006 3:18 AM > To: john.loughney@nokia.com; Ash, Gerald R (Jerry), ALABS;=20 > nsis@ietf.org > Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt >=20 > Hi John >=20 > I mainly disagree with the following three points that were never > discussed before: >=20 > Point_1):Removed the QSPEC control information > --------------------------------------------------------------- > Jerry mentioned in a previous e-mail that this QSPEC control=20 > information > concept is not removed but it is renamed to Traffic Handling=20 > Directives. >=20 > If that is the case then Jerry will have to use the same=20 > definitions for > the > QSPEC control information as used in Section 5.3.1 of: > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt >=20 > Thus my proposal is to change section 4.3.3 as given in v.13=20 > of the QSPEC > template draft and include the general concept of the QSPEC control > information that was given in Section 5.3.1 of version 12 of the QSPEC > template draft. Note that the name can be changed but the semantics > should remain the same. Thus please change Section 4.3.3 as follows: >=20 > FROM: >=20 > 4.3.3 Traffic Handling Directives >=20 > The parameter describes how the QNE will process > excess traffic, that is, out-of-profile traffic. Excess=20 > traffic MAY > be dropped, shaped and/or remarked. The excess treatment=20 > parameter is > initially set by the QNI and cannot be overwritten. >=20 >=20 > INTO: >=20 > 4.3.3 Traffic Handling Directives >=20 > Traffic Handling Directives are used for signaling QOSM=20 > RMF functions > not defined in QoS NSLP. It enables building new RMF functions > required by a QOSM within a QoS NSLP signaling framework, such as > specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. I think most (perhaps all?) of us agree on this point: the QOSM specification SHOULD NOT be allowed to define 'new RMF functions required by a QOSM' UNLESS such NSIS signaling functionality is defined in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP signaling functionality. The above text seems to abide by the premise by stating that new RMF functions are specified only 'within a QoS NSLP signaling framework'. If so, I think we're in agreement. >=20 > =3D >=20 > The parameter describes how the QNE will process > excess traffic, that is, out-of-profile traffic. Excess=20 > traffic MAY > be dropped, shaped and/or remarked. The excess treatment=20 > parameter is > initially set by the QNI and is read-only. IMO we don't need to introduce the former "" terminology in addition to the "Traffic Handling Directives" terminology. Furthermore, "QSPEC control information" implies that the information applies to control of the QSPEC itself rather than another QoS parameter type like a handling directive. > ------------------------------- >=20 > Point_2: dictates that encapsulation of the original initiator QSPEC > feature cannot be used in combination with the tunneling (parallel > session) feature. >=20 > In the discussion that we have had in the nsis mailing list and during > the IETF meeting it was stated that both these features should be > possible, while now version 13 of the QSPEC template draft=20 > dictates that > these two features cannot be used together and at the same time by the > same QoS model. > As I mentioned in all the discussions the encapsulation of=20 > the original > QSPEC feature is needed to satisfy Requirement: > "5.4.2. It SHOULD be Possible to Add and Remove Local Domain > Information" given in: http://www.ietf.org/rfc/rfc3726.txt > Therefore the encapsulation (of the original initiator QSPEC=20 > into a local > QSPEC) feature should be seen as an independent feature and=20 > it should be > able to be used in combination with the tunneling (parallel session) > feature that is used for another goal. >=20 > Thus my proposal is that it should be mentioned that even when the > tunneling (parallel session) feature is used, it is also=20 > allowed to use, > at the same time, the encapsulation (of the original initiator QSPEC > into a local QSPEC) feature in order to satisfy Requirement=20 > 5.4.2 of RFC > 3726. I don't see a reason to preclude using, at the same time, both 1. tunneling a QSPEC through a local domain by initiating a new RESERVE at the domain edge, AND 2. defining a local QSPEC and encapsulating the initiator QSPEC, as defined in Section 5.1 of the QSPEC draft http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-13.txt. Georgios provided an example based on the RMD-QOSM of when it would be necessary to use both features at the same time. I think we're in agreement here. > --------------------------- >=20 > Point_3: QSPEC template draft dictates which QOS-NSLP=20 > signaling features > should be used by QOS models. >=20 > We have never discussed an agreed that the QSPEC template=20 > draft defines > how the QOS-NSLP functionality should be used by QoS models.=20 > This should > be defined by the QOS-NSLP draft. > Therefore, regarding this issue the QSPEC template draft=20 > should refer to > Section "3.1.2. QoS Models and QoS Specifications"" of: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt >=20 > Therefore the QSPEC template draft should adapt the=20 > definition of the QoS > models according to what Section 3.1.2 of the QOS-NSLP draft is saying > and refer to Section 3.1.2 of the QOS-NSLP draft. I'm not sure I fully understand Georgios' phrasing here. I agree that signaling functionality should only be defined by the QoS NSLP draft and that the QSPEC draft should not specify 'how the QoS NSLP functionality should be used by QoS models'. If that is the point, we're in agreement here also. It would really be good to get resolution and move on with QoS-NSLP/QSPEC at long last. If I understand correctly, I think we're mostly in agreement on the above issues. Thanks, Jerry >=20 > Best Regards, > Georgios >=20 > On 12/23/2006, "john.loughney@nokia.com" > wrote: >=20 > >Hi all, > > > >When Jerry posted the draft with the change log, I basically noted > >that the changes were based upon previous discussions, on the > >mailing list and the meeting. > > > >I am unsure of the technical issues that are being raised. Rather > >than get into a discussion of what was discussed or not, what I > >would like to understand better is more understanding what are > >the technical issues behind Georgios' issues. > > > >Additionally, I would like to hear from others about their opinions > >on this issue. > > > >thanks, > >John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 04 11:10:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2VAa-0005Ze-Lk; Thu, 04 Jan 2007 11:10:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2VAZ-0005ZT-6A for nsis@ietf.org; Thu, 04 Jan 2007 11:10:19 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2VAY-00071M-Jf for nsis@ietf.org; Thu, 04 Jan 2007 11:10:19 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l04GA1jN012463; Thu, 4 Jan 2007 17:10:06 +0100 (MET) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" , , Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Thu, 4 Jan 2007 17:10:04 +0100 Message-ID: <003801c7301a$ce9e9210$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.3028 Thread-Index: AccnNAmV02JEI4mYSJ2rqx7HFPHiiwIEzvwgADBavYAABHO2UA== In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC8091@KCCLUST06EVS1.ugd.att.com> X-Spam-Score: 0.3 () AWL,FVGT_s_OBFU_Q1,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 04 Jan 2007 17:10:07 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af 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 Regarding the following point, I think that we are not in agreement: >> I think most (perhaps all?) of us agree on this point: >> the QOSM specification SHOULD NOT be allowed to define >> 'new RMF functions required by a QOSM' UNLESS such NSIS >> signaling functionality is defined in QoS NSLP. I.e., a >> QOSM is not allowed to extend QoS NSLP signaling >> functionality. The above text seems to abide by >> the premise by stating that new RMF functions are >> specified only 'within a QoS NSLP signaling framework'. >> If so, I think we're in agreement. Please see the last e-mails sent by Hannes! Best regards, Georgios > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: donderdag 4 januari 2007 17:04 > To: john.loughney@nokia.com; nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > > Hi John, All, > > Happy New Year! > > It appears we still have a few technical issues to resolve, > as summarized below by Georgios, in addition to the editorial > issues that have been raised on the list. > > I believe that Dave mostly pulled us out of the dead-lock > we've been in for the last several months, and that most of > us agreed that the QSPEC was overall simplified and the > issues were largely resolved. > > I've commented on the 3 issues below; hopefully we can > quickly reach consensus so we can move forward: > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Sunday, December 24, 2006 3:18 AM > > To: john.loughney@nokia.com; Ash, Gerald R (Jerry), ALABS; > > nsis@ietf.org > > Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt > > > > Hi John > > > > I mainly disagree with the following three points that were never > > discussed before: > > > > Point_1):Removed the QSPEC control information > > --------------------------------------------------------------- > > Jerry mentioned in a previous e-mail that this QSPEC control > > information concept is not removed but it is renamed to Traffic > > Handling Directives. > > > > If that is the case then Jerry will have to use the same > definitions > > for the QSPEC control information as used in Section 5.3.1 of: > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > > > Thus my proposal is to change section 4.3.3 as given in v.13 of the > > QSPEC template draft and include the general concept of the QSPEC > > control information that was given in Section 5.3.1 of > version 12 of > > the QSPEC template draft. Note that the name can be changed but the > > semantics should remain the same. Thus please change > Section 4.3.3 as > > follows: > > > > FROM: > > > > 4.3.3 Traffic Handling Directives > > > > The parameter describes how the QNE > will process > > excess traffic, that is, out-of-profile traffic. Excess > > traffic MAY > > be dropped, shaped and/or remarked. The excess treatment > > parameter is > > initially set by the QNI and cannot be overwritten. > > > > > > INTO: > > > > 4.3.3 Traffic Handling Directives > > > > Traffic Handling Directives are used for signaling QOSM > > RMF functions > > not defined in QoS NSLP. It enables building new RMF functions > > required by a QOSM within a QoS NSLP signaling framework, such as > > specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. > > I think most (perhaps all?) of us agree on this point: the > QOSM specification SHOULD NOT be allowed to define 'new RMF > functions required by a QOSM' UNLESS such NSIS signaling > functionality is defined in QoS NSLP. I.e., a QOSM is not > allowed to extend QoS NSLP signaling functionality. The > above text seems to abide by the premise by stating that new > RMF functions are specified only 'within a QoS NSLP signaling > framework'. If so, I think we're in agreement. > > > > > = > > > > The parameter describes how the QNE > will process > > excess traffic, that is, out-of-profile traffic. Excess > > traffic MAY > > be dropped, shaped and/or remarked. The excess treatment > > parameter is > > initially set by the QNI and is read-only. > > IMO we don't need to introduce the former " Information>" > terminology in addition to the "Traffic Handling Directives" > terminology. Furthermore, "QSPEC control information" > implies that the information applies to control of the QSPEC > itself rather than another QoS parameter type like a handling > directive. > > > ------------------------------- > > > > Point_2: dictates that encapsulation of the original > initiator QSPEC > > feature cannot be used in combination with the tunneling (parallel > > session) feature. > > > > In the discussion that we have had in the nsis mailing list > and during > > the IETF meeting it was stated that both these features should be > > possible, while now version 13 of the QSPEC template draft dictates > > that these two features cannot be used together and at the > same time > > by the same QoS model. > > As I mentioned in all the discussions the encapsulation of the > > original QSPEC feature is needed to satisfy Requirement: > > "5.4.2. It SHOULD be Possible to Add and Remove Local Domain > > Information" given in: http://www.ietf.org/rfc/rfc3726.txt > > Therefore the encapsulation (of the original initiator QSPEC into a > > local > > QSPEC) feature should be seen as an independent feature and > it should > > be able to be used in combination with the tunneling (parallel > > session) feature that is used for another goal. > > > > Thus my proposal is that it should be mentioned that even when the > > tunneling (parallel session) feature is used, it is also allowed to > > use, at the same time, the encapsulation (of the original initiator > > QSPEC into a local QSPEC) feature in order to satisfy Requirement > > 5.4.2 of RFC > > 3726. > > I don't see a reason to preclude using, at the same time, > both 1. tunneling a QSPEC through a local domain by > initiating a new RESERVE at the domain edge, AND 2. defining > a local QSPEC and encapsulating the initiator QSPEC, as > defined in Section 5.1 of the QSPEC draft > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-13.txt. > > Georgios provided an example based on the RMD-QOSM of when it > would be necessary to use both features at the same time. I > think we're in agreement here. > > > --------------------------- > > > > Point_3: QSPEC template draft dictates which QOS-NSLP signaling > > features should be used by QOS models. > > > > We have never discussed an agreed that the QSPEC template draft > > defines how the QOS-NSLP functionality should be used by QoS models. > > This should > > be defined by the QOS-NSLP draft. > > Therefore, regarding this issue the QSPEC template draft > should refer > > to Section "3.1.2. QoS Models and QoS Specifications"" of: > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt > > > > Therefore the QSPEC template draft should adapt the > definition of the > > QoS models according to what Section 3.1.2 of the QOS-NSLP draft is > > saying and refer to Section 3.1.2 of the QOS-NSLP draft. > > I'm not sure I fully understand Georgios' phrasing here. I > agree that signaling functionality should only be defined by > the QoS NSLP draft and that the QSPEC draft should not > specify 'how the QoS NSLP functionality should be used by QoS > models'. If that is the point, we're in agreement here also. > > It would really be good to get resolution and move on with > QoS-NSLP/QSPEC at long last. If I understand correctly, I > think we're mostly in agreement on the above issues. > > Thanks, > Jerry > > > > > Best Regards, > > Georgios > > > > On 12/23/2006, "john.loughney@nokia.com" > > wrote: > > > > >Hi all, > > > > > >When Jerry posted the draft with the change log, I basically noted > > >that the changes were based upon previous discussions, on > the mailing > > >list and the meeting. > > > > > >I am unsure of the technical issues that are being raised. Rather > > >than get into a discussion of what was discussed or not, > what I would > > >like to understand better is more understanding what are the > > >technical issues behind Georgios' issues. > > > > > >Additionally, I would like to hear from others about their > opinions > > >on this issue. > > > > > >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 Fri Jan 05 04:03:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2kym-0006cj-MI; Fri, 05 Jan 2007 04:03:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2kyk-0006cU-VO; Fri, 05 Jan 2007 04:03:10 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2kyi-0007iS-Aj; Fri, 05 Jan 2007 04:03:10 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1H2kyd-0001mZ-HX; Fri, 05 Jan 2007 10:03:05 +0100 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1H2kyc-0004mz-M1; Fri, 05 Jan 2007 10:03:02 +0100 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 6559F87EF; Fri, 5 Jan 2007 10:03:01 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1H2kya-0005hB-PE; Fri, 05 Jan 2007 10:03:00 +0100 Message-ID: <459F65D9.4070609@tm.uka.de> Date: Sat, 06 Jan 2007 10:03:21 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Roland Bless , nsis-imp@ietf.org, 'NSIS Group' Subject: Re: [NSIS] RE: [Nsis-imp] Next Interop References: <200611141442.kAEEgNYc025279@smtp2.dei.uc.pt> <455B05B4.2090806@tm.uka.de> In-Reply-To: <455B05B4.2090806@tm.uka.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 2.7 DATE_IN_FUTURE_24_48 Date: is 24 to 48 hours after Received: date -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.9 AWL AWL: From: address is in the auto white-list X-Spam-Score: 2.0 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 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, [best wishes for the new year to everyone!] Roland Bless wrote: > I just saw that the week from 19.2.-23.2.2007 would > be indeed a good fit, since there is a conference Since the proposed date above is getting nearer I want to hear peoples opinions once more. Maybe the implementers need more time to finish their code? I got one request to shift it after April 1st that would be after the next IETF meeting. That would be ok for me, too. What do others think? Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 05 05:56:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mjv-0006iQ-03; Fri, 05 Jan 2007 05:55:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mjt-0006iK-NG for nsis@ietf.org; Fri, 05 Jan 2007 05:55:57 -0500 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 1H2mjs-000787-CS for nsis@ietf.org; Fri, 05 Jan 2007 05:55:57 -0500 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; Fri, 05 Jan 2007 12:55:53 +0200 id 000AFF30.459E2EB9.00001B40 Date: Fri, 5 Jan 2007 12:55:52 +0200 (EET) 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: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [NSIS] QSPEC, QOSMs, QoS NSLP interactions 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 (especially Dave, Jerry, Georgios, etc.), I've been following this latest discussion on the QSPEC and QoS NSLP interactions, and state machines. I understand (or I think I do) Dave's comment that QOSMs (or RMF) should not be able to affect the QoS NSLP state machine, and that is a good and valid point. Yet, how would e.g. reservation and signaling aggregation (e.g. the mentioned separate signaling session for local domain use), resource pre-emption or the local QSPEC concept work? Don't these in fact change the normal operation of the QoS NSLP at the edges of a special treatment domain? Since one of the main purposes of the QSPEC is to allow a QNI to request something e2e, and QNEs along the way MUST commit to that exact request (not downgrading anything, upgrading would be fine, right?) but how they do it is not fixed, doesn't this apply also to the QoS NSLP, so something along "The end-to-end semantic and QoS NSLP messaging by the QNI, or any peer QNE MUST BE preserved, and within those bounds a QOSM must operate." This means that e.g., a) The resource request by the QNI and response from the QNR must be followed and passed through intact by a QOSM X domain, b) confirmation requests must be answered, c) tear-down must be followed, etc. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 05 06:05:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mt3-0001pw-S3; Fri, 05 Jan 2007 06:05:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mt1-0001lt-QW for nsis@ietf.org; Fri, 05 Jan 2007 06:05:23 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2mt0-0001a1-DJ for nsis@ietf.org; Fri, 05 Jan 2007 06:05:23 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l05B56FA012102; Fri, 5 Jan 2007 12:05:12 +0100 (MET) From: "Georgios Karagiannis" To: "'Jukka MJ Manner'" , Subject: RE: [NSIS] QSPEC, QOSMs, QoS NSLP interactions Date: Fri, 5 Jan 2007 12:05:10 +0100 Message-ID: <000801c730b9$60f37740$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccwuDhMDrip9T9fTNOuKXh4yNtZnQAANwjQ X-Spam-Score: 0.252 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 05 Jan 2007 12:05:13 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 In other words you are saying that a QOSM could affect the QOS-NSLP state machine only if: "The end-to-end semantic and QoS NSLP messaging by the QNI, or any peer QNE MUST BE preserved, and within those bounds a QOSM must operate." If yes, then I agree with the above! Best regards, Georgios > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: vrijdag 5 januari 2007 11:56 > To: nsis@ietf.org > Subject: [NSIS] QSPEC, QOSMs, QoS NSLP interactions > > > Hi (especially Dave, Jerry, Georgios, etc.), > > I've been following this latest discussion on the QSPEC and > QoS NSLP interactions, and state machines. I understand (or I > think I do) Dave's comment that QOSMs (or RMF) should not be > able to affect the QoS NSLP state machine, and that is a good > and valid point. > > Yet, how would e.g. reservation and signaling aggregation > (e.g. the mentioned separate signaling session for local > domain use), resource pre-emption or the local QSPEC concept > work? Don't these in fact change the normal operation of the > QoS NSLP at the edges of a special treatment domain? > > Since one of the main purposes of the QSPEC is to allow a QNI > to request something e2e, and QNEs along the way MUST commit > to that exact request (not downgrading anything, upgrading > would be fine, right?) but how they do it is not fixed, > doesn't this apply also to the QoS NSLP, so something along > > "The end-to-end semantic and QoS NSLP messaging by the QNI, > or any peer QNE MUST BE preserved, and within those bounds a > QOSM must operate." > > This means that e.g., > a) The resource request by the QNI and response from the QNR must be > followed and passed through intact by a QOSM X domain, > b) confirmation requests must be answered, > c) tear-down must be followed, etc. > > > 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 Jan 05 07:52:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oYP-0002fa-71; Fri, 05 Jan 2007 07:52:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oYN-0002fQ-8Y for nsis@ietf.org; Fri, 05 Jan 2007 07:52:11 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oYL-0006Xf-Pl for nsis@ietf.org; Fri, 05 Jan 2007 07:52:11 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l05CnoNp015289; Fri, 5 Jan 2007 14:50:23 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 14:51:50 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 14:51:50 +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] RE: Comments on draft-ietf-nsis-qspec-13.txt Date: Fri, 5 Jan 2007 14:51:49 +0200 Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC8091@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt Thread-Index: AccnNAmV02JEI4mYSJ2rqx7HFPHiiwIEzvwgADBavYAAL9pRYA== From: To: , X-OriginalArrivalTime: 05 Jan 2007 12:51:50.0429 (UTC) FILETIME=[4481ACD0:01C730C8] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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, I will reply to your points one by one, in separate mails. >It appears we still have a few technical issues to resolve, as=20 >summarized below by Georgios, in addition to the editorial=20 >issues that have been raised on the list.=20 > >I believe that Dave mostly pulled us out of the dead-lock=20 >we've been in for the last several months, and that most of us=20 >agreed that the QSPEC was overall simplified and the issues=20 >were largely resolved. =20 Yes, I believe we have rough consensus on this. I suggest we move forward on this. More in my next mails. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 05 07:55:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oav-0004GF-2w; Fri, 05 Jan 2007 07:54:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oau-0004GA-9U for nsis@ietf.org; Fri, 05 Jan 2007 07:54:48 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oao-000747-P3 for nsis@ietf.org; Fri, 05 Jan 2007 07:54:48 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l05CqwHF002031; Fri, 5 Jan 2007 14:53:26 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 14:54:09 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 14:54:09 +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: Fri, 5 Jan 2007 14:54:08 +0200 Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC8091@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus on: Removed the QSPEC control information Thread-Index: AccnNAmV02JEI4mYSJ2rqx7HFPHiiwIEzvwgADBavYAAL+fiEA== From: To: , X-OriginalArrivalTime: 05 Jan 2007 12:54:09.0362 (UTC) FILETIME=[97512B20:01C730C8] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [NSIS] Consensus on: Removed the QSPEC control information 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 >> Point_1):Removed the QSPEC control information >> --------------------------------------------------------------- >> Jerry mentioned in a previous e-mail that this QSPEC control=20 >> information concept is not removed but it is renamed to Traffic=20 >> Handling Directives. >>=20 >> If that is the case then Jerry will have to use the same definitions=20 >> for the QSPEC control information as used in Section 5.3.1 of: >> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt >>=20 >> Thus my proposal is to change section 4.3.3 as given in v.13 of the=20 >> QSPEC template draft and include the general concept of the QSPEC=20 >> control information that was given in Section 5.3.1 of version 12 of=20 >> the QSPEC template draft. Note that the name can be changed but the=20 >> semantics should remain the same. Thus please change Section=20 >4.3.3 as=20 >> follows: >>=20 >> FROM: >>=20 >> 4.3.3 Traffic Handling Directives >>=20 >> The parameter describes how the QNE will process >> excess traffic, that is, out-of-profile traffic. Excess traffic MAY >> be dropped, shaped and/or remarked. The excess treatment parameter is >> initially set by the QNI and cannot be overwritten. >>=20 >> INTO: >>=20 >> 4.3.3 Traffic Handling Directives >>=20 >> Traffic Handling Directives are used for signaling QOSM=20 >> RMF functions >> not defined in QoS NSLP. It enables building new RMF functions >> required by a QOSM within a QoS NSLP signaling framework, such as >> specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. > >I think most (perhaps all?) of us agree on this point: the=20 >QOSM specification SHOULD NOT be allowed to define 'new RMF=20 >functions required by a QOSM' UNLESS such NSIS signaling=20 >functionality is defined in QoS NSLP. I.e., a QOSM is not=20 >allowed to extend QoS NSLP signaling functionality. The above=20 >text seems to abide by the premise by stating that new RMF=20 >functions are specified only 'within a QoS NSLP signaling=20 >framework'. If so, I think we're in agreement. I agree with Jerry's text, and I believe we have rough consensus on this. If anyone disagrees with consensus, a short mail stating that you disagree is needed. On point, in order to extend QoS NSLP signaling, a Standards Track RFC is needed. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 05 07:58:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oeB-0005Rn-Qt; Fri, 05 Jan 2007 07:58:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oeB-0005Re-4D for nsis@ietf.org; Fri, 05 Jan 2007 07:58:11 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oe9-0007Vz-In for nsis@ietf.org; Fri, 05 Jan 2007 07:58:11 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l05CuRhf017223; Fri, 5 Jan 2007 14:56:27 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 14:57:44 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 14:57: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jan 2007 14:57:43 +0200 Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC8091@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Point 2: dictates that encapsulation of the original initiator QSPEC ... Thread-Index: AccnNAmV02JEI4mYSJ2rqx7HFPHiiwIEzvwgADBavYAAL/pCsA== From: To: , X-OriginalArrivalTime: 05 Jan 2007 12:57:43.0862 (UTC) FILETIME=[172B4560:01C730C9] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070105145627-42995BB0-28C1462B/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [NSIS] Point 2: dictates that encapsulation of the original initiator QSPEC ... 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 >> Point_2: dictates that encapsulation of the original initiator QSPEC=20 >> feature cannot be used in combination with the tunneling (parallel >> session) feature. >>=20 >> In the discussion that we have had in the nsis mailing list and during=20 >> the IETF meeting it was stated that both these features should be=20 >> possible, while now version 13 of the QSPEC template draft dictates=20 >> that these two features cannot be used together and at the same time=20 >> by the same QoS model. >> As I mentioned in all the discussions the encapsulation of the=20 >> original QSPEC feature is needed to satisfy Requirement: >> "5.4.2. It SHOULD be Possible to Add and Remove Local Domain=20 >> Information" given in: http://www.ietf.org/rfc/rfc3726.txt >> Therefore the encapsulation (of the original initiator QSPEC into a local >> QSPEC) feature should be seen as an independent feature and it should >> be able to be used in combination with the tunneling (parallel=20 >> session) feature that is used for another goal. >>=20 >> Thus my proposal is that it should be mentioned that even when the=20 >> tunneling (parallel session) feature is used, it is also allowed to=20 >> use, at the same time, the encapsulation (of the original initiator=20 >> QSPEC into a local QSPEC) feature in order to satisfy Requirement >> 5.4.2 of RFC >> 3726. > >I don't see a reason to preclude using, at the same time, both=20 >1. tunneling a QSPEC through a local domain by initiating a=20 >new RESERVE at the domain edge, AND 2. defining a local QSPEC=20 >and encapsulating the initiator QSPEC, as defined in Section=20 >5.1 of the QSPEC draft=20 >http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-13.txt. > >Georgios provided an example based on the RMD-QOSM of when it=20 >would be necessary to use both features at the same time. I=20 >think we're in agreement here. I agree as well. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 05 08:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ohA-0007GD-Nf; Fri, 05 Jan 2007 08:01:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oh9-0007G4-Gw for nsis@ietf.org; Fri, 05 Jan 2007 08:01:15 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oh8-00087D-1U for nsis@ietf.org; Fri, 05 Jan 2007 08:01:15 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l05Cx1LY006323; Fri, 5 Jan 2007 14:59:32 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 15:01:01 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 15:01:01 +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: Fri, 5 Jan 2007 15:01:01 +0200 Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC8091@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Point 3: QSPEC template draft dictates which QOS-NSLP signaling .... Thread-Index: AccnNAmV02JEI4mYSJ2rqx7HFPHiiwIEzvwgADBavYAAMBu0MA== From: To: , X-OriginalArrivalTime: 05 Jan 2007 13:01:01.0530 (UTC) FILETIME=[8CFD03A0:01C730C9] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070105145932-1829DBB0-0721E24A/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [NSIS] Point 3: QSPEC template draft dictates which QOS-NSLP signaling .... 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 >> Point_3: QSPEC template draft dictates which QOS-NSLP signaling=20 >> features should be used by QOS models. >>=20 >> We have never discussed an agreed that the QSPEC template draft=20 >> defines how the QOS-NSLP functionality should be used by QoS models. >> This should be defined by the QOS-NSLP draft. >> Therefore, regarding this issue the QSPEC template draft should refer=20 >> to Section "3.1.2. QoS Models and QoS Specifications"" of: >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt >>=20 >> Therefore the QSPEC template draft should adapt the definition of the >> QoS models according to what Section 3.1.2 of the QOS-NSLP draft is=20 >> saying and refer to Section 3.1.2 of the QOS-NSLP draft. > >I'm not sure I fully understand Georgios' phrasing here. I=20 >agree that signaling functionality should only be defined by=20 >the QoS NSLP draft and that the QSPEC draft should not specify=20 >'how the QoS NSLP functionality should be used by QoS models'.=20 > If that is the point, we're in agreement here also. I agree with Jerry's view on this. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 05 08:33:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pBq-0004fp-2Z; Fri, 05 Jan 2007 08:32:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pBo-0004fj-9k for nsis@ietf.org; Fri, 05 Jan 2007 08:32:56 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2pBj-0006Rk-Jx for nsis@ietf.org; Fri, 05 Jan 2007 08:32:56 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l05DWKBH017574; Fri, 5 Jan 2007 14:32:32 +0100 (MET) From: "Georgios Karagiannis" To: , , Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Date: Fri, 5 Jan 2007 14:32:23 +0100 Message-ID: <000c01c730cd$f2809350$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccnNAmV02JEI4mYSJ2rqx7HFPHiiwIEzvwgADBavYAAL+fiEAABV2ZQ X-Spam-Score: 0.303 () AWL,FVGT_s_OBFU_Q1,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 05 Jan 2007 14:32:32 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 I think that description and proposal of Jukka, please see e-mail sent by Jukka, gives a solution to this problem. Best regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: vrijdag 5 januari 2007 13:54 > To: gash@att.com; nsis@ietf.org > Subject: [NSIS] Consensus on: Removed the QSPEC control information > > > >> Point_1):Removed the QSPEC control information > >> --------------------------------------------------------------- > >> Jerry mentioned in a previous e-mail that this QSPEC control > >> information concept is not removed but it is renamed to Traffic > >> Handling Directives. > >> > >> If that is the case then Jerry will have to use the same > definitions > >> for the QSPEC control information as used in Section 5.3.1 of: > >> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > >> > >> Thus my proposal is to change section 4.3.3 as given in > v.13 of the > >> QSPEC template draft and include the general concept of the QSPEC > >> control information that was given in Section 5.3.1 of > version 12 of > >> the QSPEC template draft. Note that the name can be > changed but the > >> semantics should remain the same. Thus please change Section > >4.3.3 as > >> follows: > >> > >> FROM: > >> > >> 4.3.3 Traffic Handling Directives > >> > >> The parameter describes how the QNE will > process > >> excess traffic, that is, out-of-profile traffic. Excess traffic > MAY > >> be dropped, shaped and/or remarked. The excess > treatment parameter > is > >> initially set by the QNI and cannot be overwritten. > >> > >> INTO: > >> > >> 4.3.3 Traffic Handling Directives > >> > >> Traffic Handling Directives are used for signaling QOSM > >> RMF functions > >> not defined in QoS NSLP. It enables building new RMF functions > >> required by a QOSM within a QoS NSLP signaling > framework, such as > >> specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. > > > >I think most (perhaps all?) of us agree on this point: the QOSM > >specification SHOULD NOT be allowed to define 'new RMF functions > >required by a QOSM' UNLESS such NSIS signaling functionality > is defined > >in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP > signaling > >functionality. The above text seems to abide by the premise > by stating > >that new RMF functions are specified only 'within a QoS NSLP > signaling > >framework'. If so, I think we're in agreement. > > I agree with Jerry's text, and I believe we have rough > consensus on this. > If anyone disagrees with consensus, a short mail stating that > you disagree is needed. > > On point, in order to extend QoS NSLP signaling, a Standards > Track RFC is needed. > > 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 Fri Jan 05 09:03:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pel-0000sa-JX; Fri, 05 Jan 2007 09:02:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pej-0000nd-FP for nsis@ietf.org; Fri, 05 Jan 2007 09:02:49 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ped-0004Ms-QY for nsis@ietf.org; Fri, 05 Jan 2007 09:02:49 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 075B74F0001; Fri, 5 Jan 2007 15:02:39 +0100 (CET) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 15:02:38 +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] Consensus on: Removed the QSPEC control information Date: Fri, 5 Jan 2007 15:02:36 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E910F73A9@esealmw116.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Consensus on: Removed the QSPEC control information Thread-Index: AccnNAmV02JEI4mYSJ2rqx7HFPHiiwIEzvwgADBavYAAL+fiEAACTYYQ From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: , , X-OriginalArrivalTime: 05 Jan 2007 14:02:38.0269 (UTC) FILETIME=[286A9ED0:01C730D2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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,=20 I disagree, I think the right approach is what Yukka sent.=20 >> "The end-to-end semantic and QoS NSLP messaging by the QNI, or any peer = QNE MUST BE preserved, and within those bounds a QOSM must operate." This means that e.g., a) The resource request by the QNI and response from the QNR must be=20 followed and passed through intact by a QOSM X domain, b) confirmation requests must be answered, c) tear-down must be followed, etc. " >> I think QoS NSLP operation can be extended in a local QoS domain without = distroying e2e QoS-NSLP operation. Best regards, Attila >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 >Sent: Friday, January 05, 2007 1:54 PM >To: gash@att.com; nsis@ietf.org >Subject: [NSIS] Consensus on: Removed the QSPEC control information > > >>> Point_1):Removed the QSPEC control information >>> --------------------------------------------------------------- >>> Jerry mentioned in a previous e-mail that this QSPEC control=20 >>> information concept is not removed but it is renamed to Traffic=20 >>> Handling Directives. >>>=20 >>> If that is the case then Jerry will have to use the same=20 >definitions=20 >>> for the QSPEC control information as used in Section 5.3.1 of: >>> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt >>>=20 >>> Thus my proposal is to change section 4.3.3 as given in v.13 of the=20 >>> QSPEC template draft and include the general concept of the QSPEC=20 >>> control information that was given in Section 5.3.1 of=20 >version 12 of=20 >>> the QSPEC template draft. Note that the name can be changed but the=20 >>> semantics should remain the same. Thus please change Section >>4.3.3 as >>> follows: >>>=20 >>> FROM: >>>=20 >>> 4.3.3 Traffic Handling Directives >>>=20 >>> The parameter describes how the QNE will >process >>> excess traffic, that is, out-of-profile traffic. Excess traffic >MAY >>> be dropped, shaped and/or remarked. The excess treatment=20 >parameter >is >>> initially set by the QNI and cannot be overwritten. >>>=20 >>> INTO: >>>=20 >>> 4.3.3 Traffic Handling Directives >>>=20 >>> Traffic Handling Directives are used for signaling QOSM=20 >>> RMF functions >>> not defined in QoS NSLP. It enables building new RMF functions >>> required by a QOSM within a QoS NSLP signaling framework, such as >>> specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. >> >>I think most (perhaps all?) of us agree on this point: the QOSM=20 >>specification SHOULD NOT be allowed to define 'new RMF functions=20 >>required by a QOSM' UNLESS such NSIS signaling functionality=20 >is defined=20 >>in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP=20 >signaling=20 >>functionality. The above text seems to abide by the premise=20 >by stating=20 >>that new RMF functions are specified only 'within a QoS NSLP=20 >signaling=20 >>framework'. If so, I think we're in agreement. > >I agree with Jerry's text, and I believe we have rough=20 >consensus on this. >If anyone disagrees with consensus, a short mail stating that=20 >you disagree is needed. > >On point, in order to extend QoS NSLP signaling, a Standards=20 >Track RFC is needed. > >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 Fri Jan 05 09:10:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2plg-00044f-Hw; Fri, 05 Jan 2007 09:10:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2plg-00044a-0f for nsis@ietf.org; Fri, 05 Jan 2007 09:10:00 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ple-0006Qq-H5 for nsis@ietf.org; Fri, 05 Jan 2007 09:09:59 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l05E83H5029761; Fri, 5 Jan 2007 16:08:18 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 16:09:36 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 16:09:35 +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] QSPEC, QOSMs, QoS NSLP interactions Date: Fri, 5 Jan 2007 16:09:33 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC, QOSMs, QoS NSLP interactions Thread-Index: AccwuDwkhRfh/014RoCR+GLBaV7u6AAGtcgQ From: To: , X-OriginalArrivalTime: 05 Jan 2007 14:09:35.0494 (UTC) FILETIME=[211A1A60:01C730D3] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070105160818-73E7EBB0-12D8B902/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Jukka, I can't really parse the text you have supplied. Where do you think such text should be added? John=20 >-----Original Message----- >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 >Sent: 05 January, 2007 12:56 >To: nsis@ietf.org >Subject: [NSIS] QSPEC, QOSMs, QoS NSLP interactions > > >Hi (especially Dave, Jerry, Georgios, etc.), > >I've been following this latest discussion on the QSPEC and=20 >QoS NSLP interactions, and state machines. I understand (or I=20 >think I do) Dave's comment that QOSMs (or RMF) should not be=20 >able to affect the QoS NSLP state machine, and that is a good=20 >and valid point. > >Yet, how would e.g. reservation and signaling aggregation=20 >(e.g. the mentioned separate signaling session for local=20 >domain use), resource pre-emption or the local QSPEC concept=20 >work? Don't these in fact change the normal operation of the=20 >QoS NSLP at the edges of a special treatment domain? > >Since one of the main purposes of the QSPEC is to allow a QNI=20 >to request something e2e, and QNEs along the way MUST commit=20 >to that exact request (not downgrading anything, upgrading=20 >would be fine, right?) but how they do it is not fixed,=20 >doesn't this apply also to the QoS NSLP, so something along > >"The end-to-end semantic and QoS NSLP messaging by the QNI, or=20 >any peer QNE MUST BE preserved, and within those bounds a QOSM=20 >must operate." > >This means that e.g., >a) The resource request by the QNI and response from the QNR must be=20 > followed and passed through intact by a QOSM X domain, >b) confirmation requests must be answered, >c) tear-down must be followed, etc. > > >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 Jan 05 09:32:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q6k-0005L5-Tr; Fri, 05 Jan 2007 09:31:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q6j-0005Eq-7F for nsis@ietf.org; Fri, 05 Jan 2007 09:31:45 -0500 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 1H2q6h-00037O-NV for nsis@ietf.org; Fri, 05 Jan 2007 09:31:45 -0500 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; Fri, 05 Jan 2007 16:31:42 +0200 id 000AFDDE.459E614E.00001380 Date: Fri, 5 Jan 2007 16:31:42 +0200 (EET) From: Jukka MJ Manner To: john.loughney@nokia.com Subject: RE: [NSIS] QSPEC, QOSMs, QoS NSLP interactions 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 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, I don't really have a direct placeholder for it, but somewhere in both QSPEC and QoS NSLP. My main point was to get feedback on whether we should relax the NSLP messaging and RMF interfactions from their current wording, similarly than resource provisioning is not specified, just that it must support the QNI's request. A certain domain running a QOSM X can well do certain optimizations, incl. separate signaling sessions and aggregation, provided that 1) it fulfils the original request of the QNIs, and 2) the end-to-end semantic and the end-to-end QoS NSLP messaging by the QNI, or any peer QNE are preserved. Within those bounds a QOSM must operate, incl. any domain internal optimized signaling. Jukka On Fri, 5 Jan 2007, john.loughney@nokia.com wrote: > Jukka, > > I can't really parse the text you have supplied. Where do you think > such text should be added? > > John > > >-----Original Message----- > >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >Sent: 05 January, 2007 12:56 > >To: nsis@ietf.org > >Subject: [NSIS] QSPEC, QOSMs, QoS NSLP interactions > > > > > >Hi (especially Dave, Jerry, Georgios, etc.), > > > >I've been following this latest discussion on the QSPEC and > >QoS NSLP interactions, and state machines. I understand (or I > >think I do) Dave's comment that QOSMs (or RMF) should not be > >able to affect the QoS NSLP state machine, and that is a good > >and valid point. > > > >Yet, how would e.g. reservation and signaling aggregation > >(e.g. the mentioned separate signaling session for local > >domain use), resource pre-emption or the local QSPEC concept > >work? Don't these in fact change the normal operation of the > >QoS NSLP at the edges of a special treatment domain? > > > >Since one of the main purposes of the QSPEC is to allow a QNI > >to request something e2e, and QNEs along the way MUST commit > >to that exact request (not downgrading anything, upgrading > >would be fine, right?) but how they do it is not fixed, > >doesn't this apply also to the QoS NSLP, so something along > > > >"The end-to-end semantic and QoS NSLP messaging by the QNI, or > >any peer QNE MUST BE preserved, and within those bounds a QOSM > >must operate." > > > >This means that e.g., > >a) The resource request by the QNI and response from the QNR must be > > followed and passed through intact by a QOSM X domain, > >b) confirmation requests must be answered, > >c) tear-down must be followed, etc. > > > > > >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 Jan 05 09:56:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qTz-0007bX-TJ; Fri, 05 Jan 2007 09:55:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qTy-0007bR-Hr for nsis@ietf.org; Fri, 05 Jan 2007 09:55:46 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2qTx-0001A3-40 for nsis@ietf.org; Fri, 05 Jan 2007 09:55:46 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1168008943!17497951!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 11925 invoked from network); 5 Jan 2007 14:55:43 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-6.tower-120.messagelabs.com with SMTP; 5 Jan 2007 14:55:43 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l05Etgvj026195; Fri, 5 Jan 2007 09:55:43 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l05EtSn6026068; Fri, 5 Jan 2007 09:55:37 -0500 (EST) 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] QSPEC, QOSMs, QoS NSLP interactions Date: Fri, 5 Jan 2007 08:55:35 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC809A@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC, QOSMs, QoS NSLP interactions Thread-Index: Accw1ldO1o2gVhHbTleV7jEwNuW8TwAAPx/w From: "Ash, Gerald R \(Jerry\), ALABS" To: "Jukka MJ Manner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Jukka, It seems you are not saying another contrary to what John stated as consensus in his posting at http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html: "the QOSM specification SHOULD NOT be allowed to define 'new RMF functions required by a QOSM' UNLESS such NSIS signaling functionality is defined in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP signaling functionality...new RMF functions are specified only 'within a QoS NSLP signaling framework'." Otherwise please clarify. Thanks, Jerry -----Original Message----- From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 Sent: Friday, January 05, 2007 9:32 AM To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] QSPEC, QOSMs, QoS NSLP interactions John, I don't really have a direct placeholder for it, but somewhere in both=20 QSPEC and QoS NSLP.=20 My main point was to get feedback on whether we should relax the NSLP=20 messaging and RMF interfactions from their current wording, similarly than=20 resource provisioning is not specified, just that it must support the=20 QNI's request. A certain domain running a QOSM X can well do certain=20 optimizations, incl. separate signaling sessions and aggregation, provided=20 that 1) it fulfils the original request of the QNIs, and 2) the end-to-end semantic and the end-to-end QoS NSLP messaging by the=20 QNI, or any peer QNE are preserved. Within those bounds a QOSM must operate, incl. any domain internal=20 optimized signaling. Jukka On Fri, 5 Jan 2007, john.loughney@nokia.com wrote: > Jukka, >=20 > I can't really parse the text you have supplied. Where do you think > such text should be added? >=20 > John=20 >=20 > >-----Original Message----- > >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > >Sent: 05 January, 2007 12:56 > >To: nsis@ietf.org > >Subject: [NSIS] QSPEC, QOSMs, QoS NSLP interactions > > > > > >Hi (especially Dave, Jerry, Georgios, etc.), > > > >I've been following this latest discussion on the QSPEC and=20 > >QoS NSLP interactions, and state machines. I understand (or I=20 > >think I do) Dave's comment that QOSMs (or RMF) should not be=20 > >able to affect the QoS NSLP state machine, and that is a good=20 > >and valid point. > > > >Yet, how would e.g. reservation and signaling aggregation=20 > >(e.g. the mentioned separate signaling session for local=20 > >domain use), resource pre-emption or the local QSPEC concept=20 > >work? Don't these in fact change the normal operation of the=20 > >QoS NSLP at the edges of a special treatment domain? > > > >Since one of the main purposes of the QSPEC is to allow a QNI=20 > >to request something e2e, and QNEs along the way MUST commit=20 > >to that exact request (not downgrading anything, upgrading=20 > >would be fine, right?) but how they do it is not fixed,=20 > >doesn't this apply also to the QoS NSLP, so something along > > > >"The end-to-end semantic and QoS NSLP messaging by the QNI, or=20 > >any peer QNE MUST BE preserved, and within those bounds a QOSM=20 > >must operate." > > > >This means that e.g., > >a) The resource request by the QNI and response from the QNR must be=20 > > followed and passed through intact by a QOSM X domain, > >b) confirmation requests must be answered, > >c) tear-down must be followed, etc. > > > > > >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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 05 10:02:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qa7-0001ft-Hj; Fri, 05 Jan 2007 10:02:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qa6-0001fg-6i for nsis@ietf.org; Fri, 05 Jan 2007 10:02:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2qa3-0002M3-OJ for nsis@ietf.org; Fri, 05 Jan 2007 10:02:06 -0500 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2007 07:02:03 -0800 Received: from [10.32.245.152] ([10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l05Ej9Wo015030; Fri, 5 Jan 2007 06:45:09 -0800 In-Reply-To: <53CCFDD6E346CB43994852666C210E910F73A9@esealmw116.eemea.ericsson.se> References: <53CCFDD6E346CB43994852666C210E910F73A9@esealmw116.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <11450E04-8CAC-4C43-A98F-1F1058296901@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [NSIS] Consensus on: Removed the QSPEC control information Date: Fri, 5 Jan 2007 10:01:58 -0500 To: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4860; t=1168008310; x=1168872310; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20Consensus=20on=3A=20Removed=20the=20QSPEC=20 control=20information |Sender:=20 |To:=20=3D?ISO-8859-1?Q?Attila_B=3DE1der_=3D28IJ/ETH=3D29?=3D=20; bh=lxVgO1ke4KDKojzwaue+j4pFgcjcd8gBaM8YU/PL36w=; b=C3rP5KO5bXSu5kAr0ix6YSTnXLSLgnMVMx87GDv4THZ1v2upwQuBS5SAKuunnnQQadrJkS2B WzkccUFZNyl+KOCqG6fr9b929jmNNzPevVIz64hKy+Ut/S7fp0kU/Kdb; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: john.loughney@nokia.com, 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 On Jan 5, 2007, at 9:02 AM, Attila B=E1der (IJ/ETH) wrote: > Hi John, > > I disagree, I think the right approach is what Yukka sent. > >>> > "The end-to-end semantic and QoS NSLP messaging by the QNI, or any =20 > peer QNE MUST BE preserved, and within those bounds a QOSM must =20 > operate." > > This means that e.g., > a) The resource request by the QNI and response from the QNR must be > followed and passed through intact by a QOSM X domain, > b) confirmation requests must be answered, > c) tear-down must be followed, etc. " >>> > > I think QoS NSLP operation can be extended in a local QoS domain =20 > without distroying e2e QoS-NSLP operation. > John L. seemed to be of the view that if a particular domain-loal QoS =20= scheme (e.g. RMD) wants to use QoS-NSLP for its local scheme, then it =20= is free to modify it if and only if there is a standards track RFC =20 documenting the extensions/changes. This represents my view as well. =20 This is the only way we can ascertain upwards/downwards compatibility =20= and interoperability. Otherwise what you would have is a completely =20 private signaling scheme which claims conformance to a standard. These QoS-NSLP extensions would have no effect on the QSPEC =20 specification, unless the QSPEC itself is being extended, in which =20 case I think it's still an open issue whether or not you need a =20 standards track RFC for that. My guess would be yes if we adopt =20 Yukka's encoding scheme (because otherwise you could not find or =20 debug the end-to-end QSPEC when embedded in an extended local QSPEC), =20= but possibly no if we adopt a more layered encoding like QSPEC =20 stacking (so that the parser has a known regular encoding structure =20 to deal with). Cheers, Dave. > Best regards, Attila > > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: Friday, January 05, 2007 1:54 PM >> To: gash@att.com; nsis@ietf.org >> Subject: [NSIS] Consensus on: Removed the QSPEC control information >> >> >>>> Point_1):Removed the QSPEC control information >>>> --------------------------------------------------------------- >>>> Jerry mentioned in a previous e-mail that this QSPEC control >>>> information concept is not removed but it is renamed to Traffic >>>> Handling Directives. >>>> >>>> If that is the case then Jerry will have to use the same >> definitions >>>> for the QSPEC control information as used in Section 5.3.1 of: >>>> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt >>>> >>>> Thus my proposal is to change section 4.3.3 as given in v.13 of the >>>> QSPEC template draft and include the general concept of the QSPEC >>>> control information that was given in Section 5.3.1 of >> version 12 of >>>> the QSPEC template draft. Note that the name can be changed but the >>>> semantics should remain the same. Thus please change Section >>> 4.3.3 as >>>> follows: >>>> >>>> FROM: >>>> >>>> 4.3.3 Traffic Handling Directives >>>> >>>> The parameter describes how the QNE will >> process >>>> excess traffic, that is, out-of-profile traffic. Excess traffic >> MAY >>>> be dropped, shaped and/or remarked. The excess treatment >> parameter >> is >>>> initially set by the QNI and cannot be overwritten. >>>> >>>> INTO: >>>> >>>> 4.3.3 Traffic Handling Directives >>>> >>>> Traffic Handling Directives are used for signaling QOSM >>>> RMF functions >>>> not defined in QoS NSLP. It enables building new RMF functions >>>> required by a QOSM within a QoS NSLP signaling framework, =20 >>>> such as >>>> specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. >>> >>> I think most (perhaps all?) of us agree on this point: the QOSM >>> specification SHOULD NOT be allowed to define 'new RMF functions >>> required by a QOSM' UNLESS such NSIS signaling functionality >> is defined >>> in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP >> signaling >>> functionality. The above text seems to abide by the premise >> by stating >>> that new RMF functions are specified only 'within a QoS NSLP >> signaling >>> framework'. If so, I think we're in agreement. >> >> I agree with Jerry's text, and I believe we have rough >> consensus on this. >> If anyone disagrees with consensus, a short mail stating that >> you disagree is needed. >> >> On point, in order to extend QoS NSLP signaling, a Standards >> Track RFC is needed. >> >> 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 05 10:11:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qjC-0006M1-7z; Fri, 05 Jan 2007 10:11:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qjB-0006L1-Ca for nsis@ietf.org; Fri, 05 Jan 2007 10:11:29 -0500 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 1H2qjA-0004mT-37 for nsis@ietf.org; Fri, 05 Jan 2007 10:11:29 -0500 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-3.cisco.com with ESMTP; 05 Jan 2007 07:11:27 -0800 X-IronPort-AV: i="4.12,243,1165219200"; d="scan'208"; a="455399478:sNHT46041604" Received: from [10.32.245.152] ([10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l05EsXOl015396; Fri, 5 Jan 2007 06:54:33 -0800 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: David R Oran Subject: Re: [NSIS] QSPEC, QOSMs, QoS NSLP interactions Date: Fri, 5 Jan 2007 10:11:22 -0500 To: Jukka MJ Manner X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1949; t=1168008873; x=1168872873; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20QSPEC, =20QOSMs, =20QoS=20NSLP=20interactions |Sender:=20 |To:=20Jukka=20MJ=20Manner=20; bh=TfTDQAcJ0nm1MCj34+XykZVfevNUWptxugLgL5QaUfI=; b=Gmpg9Qcb3RTaxXFnUy0jgQT3Z0PrQObcXc66GNKCCZTYBsGmQzxTvzltkgMLkSypvbkZeOJP M9GCbc6SuRqrSI/3KMXYXQcKIomdeszDeezDxCBq/DHvM2CFPJh/5M6h; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); 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 On Jan 5, 2007, at 5:55 AM, Jukka MJ Manner wrote: > > Hi (especially Dave, Jerry, Georgios, etc.), > > I've been following this latest discussion on the QSPEC and QoS NSLP > interactions, and state machines. I understand (or I think I do) > Dave's > comment that QOSMs (or RMF) should not be able to affect the QoS NSLP > state machine, and that is a good and valid point. > > Yet, how would e.g. reservation and signaling aggregation (e.g. the > mentioned separate signaling session for local domain use), > resource pre-emption or the local QSPEC concept work? Don't these > in fact > change the normal operation of the QoS NSLP at the edges of a special > treatment domain? > Well, this is why I've always viewed priority and preemption as really part of the NSLP and not part of the QSPEC. > Since one of the main purposes of the QSPEC is to allow a QNI to > request > something e2e, and QNEs along the way MUST commit to that exact > request > (not downgrading anything, upgrading would be fine, right?) but how > they > do it is not fixed, doesn't this apply also to the QoS NSLP, so > something > along > > "The end-to-end semantic and QoS NSLP messaging by the QNI, or any > peer > QNE MUST BE preserved, and within those bounds a QOSM must operate." > True, and this is one major reason why we changed the design so the user could directly control what elements of the QSPEC constituted mandatory constraints to be met for admission to succeed. > This means that e.g., > a) The resource request by the QNI and response from the QNR must be > followed and passed through intact by a QOSM X domain, > b) confirmation requests must be answered, > c) tear-down must be followed, etc. > All true statements. Dave. > > 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 Jan 05 10:13:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qkt-00071M-O6; Fri, 05 Jan 2007 10:13:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qkr-0006wb-Lx for nsis@ietf.org; Fri, 05 Jan 2007 10:13:13 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2qkq-00054P-Bz for nsis@ietf.org; Fri, 05 Jan 2007 10:13:13 -0500 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 05 Jan 2007 07:13:09 -0800 X-IronPort-AV: i="4.12,243,1165219200"; d="scan'208"; a="98415887:sNHT45086661" Received: from [10.32.245.152] ([10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l05EuHvZ015480; Fri, 5 Jan 2007 06:56:17 -0800 In-Reply-To: <000801c730b9$60f37740$4c0d5982@dynamic.ewi.utwente.nl> References: <000801c730b9$60f37740$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9889A921-83FD-4987-BE14-3CF56DF013C1@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] QSPEC, QOSMs, QoS NSLP interactions Date: Fri, 5 Jan 2007 10:13:05 -0500 To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2587; t=1168008978; x=1168872978; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20QSPEC, =20QOSMs, =20QoS=20NSLP=20interactions |Sender:=20 |To:=20=22Georgios=20Karagiannis=22=20; bh=y+GwO2IGpRKqkjCt6wBs8x6NNiczu2riCeSl0kE2xmM=; b=ERUVBUq08WYJfY+1zINuHK7EE7gmul7GFLR+arAR32B2P3fegpbbLmFr/hKlRVN8dPVM6qOB G2Tl2cGZkbAYv68XFlJ0p5p36yXR424nPPdtGRBnNXT75tw1KydZD4al; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: '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 On Jan 5, 2007, at 6:05 AM, Georgios Karagiannis wrote: > Hi Jukka > > In other words you are saying that a QOSM could affect the > QOS-NSLP state machine only if: > "The end-to-end semantic and QoS NSLP messaging by the QNI, > or any peer QNE MUST BE preserved, and within those bounds a > QOSM must operate." > I think the constraints are stronger than this, if you want the domain-local elements to be able to claim conformance to the QOS NSLP specification. If not, the entire argument is moot, since then your domain-local signaling is completely proprietary and non-standard. > If yes, then I agree with the above! > > Best regards, > Georgios > >> -----Original Message----- >> From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >> Sent: vrijdag 5 januari 2007 11:56 >> To: nsis@ietf.org >> Subject: [NSIS] QSPEC, QOSMs, QoS NSLP interactions >> >> >> Hi (especially Dave, Jerry, Georgios, etc.), >> >> I've been following this latest discussion on the QSPEC and >> QoS NSLP interactions, and state machines. I understand (or I >> think I do) Dave's comment that QOSMs (or RMF) should not be >> able to affect the QoS NSLP state machine, and that is a good >> and valid point. >> >> Yet, how would e.g. reservation and signaling aggregation >> (e.g. the mentioned separate signaling session for local >> domain use), resource pre-emption or the local QSPEC concept >> work? Don't these in fact change the normal operation of the >> QoS NSLP at the edges of a special treatment domain? >> >> Since one of the main purposes of the QSPEC is to allow a QNI >> to request something e2e, and QNEs along the way MUST commit >> to that exact request (not downgrading anything, upgrading >> would be fine, right?) but how they do it is not fixed, >> doesn't this apply also to the QoS NSLP, so something along >> >> "The end-to-end semantic and QoS NSLP messaging by the QNI, >> or any peer QNE MUST BE preserved, and within those bounds a >> QOSM must operate." >> >> This means that e.g., >> a) The resource request by the QNI and response from the QNR must be >> followed and passed through intact by a QOSM X domain, >> b) confirmation requests must be answered, >> c) tear-down must be followed, etc. >> >> >> 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 Fri Jan 05 10:41:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rBq-0002kI-19; Fri, 05 Jan 2007 10:41:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rBp-0002kD-4c for nsis@ietf.org; Fri, 05 Jan 2007 10:41:05 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2rBn-000350-KV for nsis@ietf.org; Fri, 05 Jan 2007 10:41:05 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l05Fde6i023250; Fri, 5 Jan 2007 16:39:57 +0100 (MET) From: "Georgios Karagiannis" To: "'David R Oran'" , "=?iso-8859-1?Q?'Attila_B=E1der_=28IJ/ETH=29'?=" Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Date: Fri, 5 Jan 2007 16:39:42 +0100 Message-ID: <001d01c730df$bd5c6de0$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 In-Reply-To: <11450E04-8CAC-4C43-A98F-1F1058296901@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accw2oJGRpjrAe1JQpu492BPa6gptQABGBaw X-Spam-Score: 0.305 () AWL,FVGT_s_OBFU_Q1,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 05 Jan 2007 16:39:58 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: john.loughney@nokia.com, 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 Dave But I think that Jukka emphasized that it does not need to be=20 a standards track if it complies to: * the constraints specified in the QOS-NSLP document (see Jukkas = proposal),=20 and of course if the QOS model draft is approved by the IESG for publication.=20 Best regards, Georgios =20 > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com]=20 > Sent: vrijdag 5 januari 2007 16:02 > To: Attila B=E1der (IJ/ETH) > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > Subject: Re: [NSIS] Consensus on: Removed the QSPEC control=20 > information >=20 >=20 > On Jan 5, 2007, at 9:02 AM, Attila B=E1der (IJ/ETH) wrote: >=20 > > Hi John, > > > > I disagree, I think the right approach is what Yukka sent. > > > >>> > > "The end-to-end semantic and QoS NSLP messaging by the QNI, or any=20 > > peer QNE MUST BE preserved, and within those bounds a QOSM must=20 > > operate." > > > > This means that e.g., > > a) The resource request by the QNI and response from the QNR must be > > followed and passed through intact by a QOSM X domain, > > b) confirmation requests must be answered, > > c) tear-down must be followed, etc. " > >>> > > > > I think QoS NSLP operation can be extended in a local QoS domain=20 > > without distroying e2e QoS-NSLP operation. > > > John L. seemed to be of the view that if a particular=20 > domain-loal QoS scheme (e.g. RMD) wants to use QoS-NSLP for=20 > its local scheme, then it is free to modify it if and only if=20 > there is a standards track RFC documenting the=20 > extensions/changes. This represents my view as well. =20 > This is the only way we can ascertain upwards/downwards=20 > compatibility and interoperability. Otherwise what you would=20 > have is a completely private signaling scheme which claims=20 > conformance to a standard. >=20 > These QoS-NSLP extensions would have no effect on the QSPEC=20 > specification, unless the QSPEC itself is being extended, in=20 > which case I think it's still an open issue whether or not=20 > you need a standards track RFC for that. My guess would be=20 > yes if we adopt Yukka's encoding scheme (because otherwise=20 > you could not find or debug the end-to-end QSPEC when=20 > embedded in an extended local QSPEC), but possibly no if we=20 > adopt a more layered encoding like QSPEC stacking (so that=20 > the parser has a known regular encoding structure to deal with). >=20 > Cheers, Dave. >=20 > > Best regards, Attila > > > > > >> -----Original Message----- > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >> Sent: Friday, January 05, 2007 1:54 PM > >> To: gash@att.com; nsis@ietf.org > >> Subject: [NSIS] Consensus on: Removed the QSPEC control information > >> > >> > >>>> Point_1):Removed the QSPEC control information > >>>> --------------------------------------------------------------- > >>>> Jerry mentioned in a previous e-mail that this QSPEC control=20 > >>>> information concept is not removed but it is renamed to Traffic=20 > >>>> Handling Directives. > >>>> > >>>> If that is the case then Jerry will have to use the same > >> definitions > >>>> for the QSPEC control information as used in Section 5.3.1 of: > >>>> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > >>>> > >>>> Thus my proposal is to change section 4.3.3 as given in=20 > v.13 of the=20 > >>>> QSPEC template draft and include the general concept of=20 > the QSPEC=20 > >>>> control information that was given in Section 5.3.1 of > >> version 12 of > >>>> the QSPEC template draft. Note that the name can be=20 > changed but the=20 > >>>> semantics should remain the same. Thus please change Section > >>> 4.3.3 as > >>>> follows: > >>>> > >>>> FROM: > >>>> > >>>> 4.3.3 Traffic Handling Directives > >>>> > >>>> The parameter describes how the QNE will > >> process > >>>> excess traffic, that is, out-of-profile traffic. =20 > Excess traffic > >> MAY > >>>> be dropped, shaped and/or remarked. The excess treatment > >> parameter > >> is > >>>> initially set by the QNI and cannot be overwritten. > >>>> > >>>> INTO: > >>>> > >>>> 4.3.3 Traffic Handling Directives > >>>> > >>>> Traffic Handling Directives are used for signaling QOSM > >>>> RMF functions > >>>> not defined in QoS NSLP. It enables building new RMF=20 > functions > >>>> required by a QOSM within a QoS NSLP signaling=20 > framework, such=20 > >>>> as > >>>> specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. > >>> > >>> I think most (perhaps all?) of us agree on this point: the QOSM=20 > >>> specification SHOULD NOT be allowed to define 'new RMF functions=20 > >>> required by a QOSM' UNLESS such NSIS signaling functionality > >> is defined > >>> in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP > >> signaling > >>> functionality. The above text seems to abide by the premise > >> by stating > >>> that new RMF functions are specified only 'within a QoS NSLP > >> signaling > >>> framework'. If so, I think we're in agreement. > >> > >> I agree with Jerry's text, and I believe we have rough=20 > consensus on=20 > >> this. > >> If anyone disagrees with consensus, a short mail stating that you=20 > >> disagree is needed. > >> > >> On point, in order to extend QoS NSLP signaling, a Standards Track=20 > >> RFC is needed. > >> > >> 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 >=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 Fri Jan 05 11:53:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sJg-0005tA-14; Fri, 05 Jan 2007 11:53:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sJe-0005t5-IP for nsis@ietf.org; Fri, 05 Jan 2007 11:53:14 -0500 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 1H2sJd-0001SM-35 for nsis@ietf.org; Fri, 05 Jan 2007 11:53:14 -0500 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; Fri, 05 Jan 2007 18:53:08 +0200 id 000AFDCC.459E8274.0000278B Date: Fri, 5 Jan 2007 18:53:08 +0200 (EET) From: Jukka MJ Manner To: David R Oran Subject: Re: [NSIS] QSPEC, QOSMs, QoS NSLP interactions 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: f4c2cf0bccc868e4cc88dace71fb3f44 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 Thanks for the confirmation. :) Jukka On Fri, 5 Jan 2007, David R Oran wrote: > > On Jan 5, 2007, at 5:55 AM, Jukka MJ Manner wrote: > > > > >Hi (especially Dave, Jerry, Georgios, etc.), > > > >I've been following this latest discussion on the QSPEC and QoS NSLP > >interactions, and state machines. I understand (or I think I do) Dave's > >comment that QOSMs (or RMF) should not be able to affect the QoS NSLP > >state machine, and that is a good and valid point. > > > >Yet, how would e.g. reservation and signaling aggregation (e.g. the > >mentioned separate signaling session for local domain use), > >resource pre-emption or the local QSPEC concept work? Don't these in fact > >change the normal operation of the QoS NSLP at the edges of a special > >treatment domain? > > > Well, this is why I've always viewed priority and preemption as really part of > the NSLP and not part of the QSPEC. > > >Since one of the main purposes of the QSPEC is to allow a QNI to request > >something e2e, and QNEs along the way MUST commit to that exact request > >(not downgrading anything, upgrading would be fine, right?) but how they > >do it is not fixed, doesn't this apply also to the QoS NSLP, so something > >along > > > >"The end-to-end semantic and QoS NSLP messaging by the QNI, or any peer > >QNE MUST BE preserved, and within those bounds a QOSM must operate." > > > True, and this is one major reason why we changed the design so the user could > directly control what elements of the QSPEC constituted mandatory constraints > to be met for admission to succeed. > > >This means that e.g., > >a) The resource request by the QNI and response from the QNR must be > > followed and passed through intact by a QOSM X domain, > >b) confirmation requests must be answered, > >c) tear-down must be followed, etc. > > > All true statements. > > Dave. > > > > >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 Jan 05 12:06:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sWS-0003EB-7h; Fri, 05 Jan 2007 12:06:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sWQ-0003E5-EP for nsis@ietf.org; Fri, 05 Jan 2007 12:06:26 -0500 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 1H2sWM-0005OA-NS for nsis@ietf.org; Fri, 05 Jan 2007 12:06:26 -0500 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; Fri, 05 Jan 2007 19:06:21 +0200 id 000AFDE5.459E858D.00005992 Date: Fri, 5 Jan 2007 19:06:21 +0200 (EET) From: Jukka MJ Manner To: Georgios Karagiannis Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information In-Reply-To: <001d01c730df$bd5c6de0$4c0d5982@dynamic.ewi.utwente.nl> Message-ID: References: <001d01c730df$bd5c6de0$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_courier-22937-1168016782-0001-2" Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: John Loughney , "Ash, Gerald R \(Jerry\), ALABS" , 'David R Oran' , nsis@ietf.org, =?ISO-8859-1?Q?'Attila_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 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-22937-1168016782-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-ID: X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 Hi Georgios, I didn't imply that the constraints would include defining some new NSLP= messages, or other things that are not already part of the QSPEC, or the NSLP. Yet, a QOS Model might e.g., define new INFO_SPEC error/info codes, or a= new object within the QSPEC, but I guess those would require standards action, and a standards track RFC. A QOS Model should not change the end-to-end semantics of the NSLP, or o= f the QSPEC - this is what I wrote. I haven't read lately the RMD spec, so I don't know what are the functionality that are introduced in addition to what is already in the QSPEC and the NSLP. Cheers, Jukka On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > Hi Dave > > But I think that Jukka emphasized that it does not need to be > a standards track if it complies to: > * the constraints specified in the QOS-NSLP document (see Jukkas propo= sal), > and of course if the QOS model draft is approved by the IESG for > publication. > > > Best regards, > Georgios > > > > -----Original Message----- > > From: David R Oran [mailto:oran@cisco.com] > > Sent: vrijdag 5 januari 2007 16:02 > > To: Attila B=E1der (IJ/ETH) > > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > > Subject: Re: [NSIS] Consensus on: Removed the QSPEC control > > information > > > > > > On Jan 5, 2007, at 9:02 AM, Attila B=E1der (IJ/ETH) wrote: > > > > > Hi John, > > > > > > I disagree, I think the right approach is what Yukka sent. > > > > > >>> > > > "The end-to-end semantic and QoS NSLP messaging by the QNI, or any= > > > peer QNE MUST BE preserved, and within those bounds a QOSM must > > > operate." > > > > > > This means that e.g., > > > a) The resource request by the QNI and response from the QNR must = be > > > followed and passed through intact by a QOSM X domain, > > > b) confirmation requests must be answered, > > > c) tear-down must be followed, etc. " > > >>> > > > > > > I think QoS NSLP operation can be extended in a local QoS domain > > > without distroying e2e QoS-NSLP operation. > > > > > John L. seemed to be of the view that if a particular > > domain-loal QoS scheme (e.g. RMD) wants to use QoS-NSLP for > > its local scheme, then it is free to modify it if and only if > > there is a standards track RFC documenting the > > extensions/changes. This represents my view as well. > > This is the only way we can ascertain upwards/downwards > > compatibility and interoperability. Otherwise what you would > > have is a completely private signaling scheme which claims > > conformance to a standard. > > > > These QoS-NSLP extensions would have no effect on the QSPEC > > specification, unless the QSPEC itself is being extended, in > > which case I think it's still an open issue whether or not > > you need a standards track RFC for that. My guess would be > > yes if we adopt Yukka's encoding scheme (because otherwise > > you could not find or debug the end-to-end QSPEC when > > embedded in an extended local QSPEC), but possibly no if we > > adopt a more layered encoding like QSPEC stacking (so that > > the parser has a known regular encoding structure to deal with). > > > > Cheers, Dave. > > > > > Best regards, Attila > > > > > > > > >> -----Original Message----- > > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > >> Sent: Friday, January 05, 2007 1:54 PM > > >> To: gash@att.com; nsis@ietf.org > > >> Subject: [NSIS] Consensus on: Removed the QSPEC control informati= on > > >> > > >> > > >>>> Point_1):Removed the QSPEC control information > > >>>> --------------------------------------------------------------- > > >>>> Jerry mentioned in a previous e-mail that this QSPEC control > > >>>> information concept is not removed but it is renamed to Traffic= > > >>>> Handling Directives. > > >>>> > > >>>> If that is the case then Jerry will have to use the same > > >> definitions > > >>>> for the QSPEC control information as used in Section 5.3.1 of: > > >>>> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > >>>> > > >>>> Thus my proposal is to change section 4.3.3 as given in > > v.13 of the > > >>>> QSPEC template draft and include the general concept of > > the QSPEC > > >>>> control information that was given in Section 5.3.1 of > > >> version 12 of > > >>>> the QSPEC template draft. Note that the name can be > > changed but the > > >>>> semantics should remain the same. Thus please change Section > > >>> 4.3.3 as > > >>>> follows: > > >>>> > > >>>> FROM: > > >>>> > > >>>> 4.3.3 Traffic Handling Directives > > >>>> > > >>>> The parameter describes how the QNE will > > >> process > > >>>> excess traffic, that is, out-of-profile traffic. > > Excess traffic > > >> MAY > > >>>> be dropped, shaped and/or remarked. The excess treatment > > >> parameter > > >> is > > >>>> initially set by the QNI and cannot be overwritten. > > >>>> > > >>>> INTO: > > >>>> > > >>>> 4.3.3 Traffic Handling Directives > > >>>> > > >>>> Traffic Handling Directives are used for signaling QOSM > > >>>> RMF functions > > >>>> not defined in QoS NSLP. It enables building new RMF > > functions > > >>>> required by a QOSM within a QoS NSLP signaling > > framework, such > > >>>> as > > >>>> specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. > > >>> > > >>> I think most (perhaps all?) of us agree on this point: the QOSM > > >>> specification SHOULD NOT be allowed to define 'new RMF functions= > > >>> required by a QOSM' UNLESS such NSIS signaling functionality > > >> is defined > > >>> in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP > > >> signaling > > >>> functionality. The above text seems to abide by the premise > > >> by stating > > >>> that new RMF functions are specified only 'within a QoS NSLP > > >> signaling > > >>> framework'. If so, I think we're in agreement. > > >> > > >> I agree with Jerry's text, and I believe we have rough > > consensus on > > >> this. > > >> If anyone disagrees with consensus, a short mail stating that you= > > >> disagree is needed. > > >> > > >> On point, in order to extend QoS NSLP signaling, a Standards Trac= k > > >> RFC is needed. > > >> > > >> 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 > > > > _______________________________________________ > > 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 > --=_courier-22937-1168016782-0001-2 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 --=_courier-22937-1168016782-0001-2-- From nsis-bounces@ietf.org Fri Jan 05 12:18:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2shM-0008Vf-L4; Fri, 05 Jan 2007 12:17:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2shL-0008VW-4W for nsis@ietf.org; Fri, 05 Jan 2007 12:17:43 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2shJ-0001Ze-Qc for nsis@ietf.org; Fri, 05 Jan 2007 12:17:43 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l05HGg5B027024; Fri, 5 Jan 2007 18:16:47 +0100 (MET) From: "Georgios Karagiannis" To: "'Jukka MJ Manner'" Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Date: Fri, 5 Jan 2007 18:16:45 +0100 Message-ID: <002901c730ed$49f9f990$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accw685N06LaxP+JTP+ClOzB6d6r3wAAId5g X-Spam-Score: 0.305 () AWL,FVGT_s_OBFU_Q1,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 05 Jan 2007 18:16:48 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: 'John Loughney' , "'Ash, Gerald R \(Jerry\), ALABS'" , 'David R Oran' , 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 Jukka What I meant are your following statements: " A certain domain running a QOSM X can well do certain optimizations,=20 incl. separate signaling sessions and aggregation, provided that 1) it fulfils the original request of the QNIs, and 2) the end-to-end semantic and the end-to-end QoS NSLP messaging by the=20 QNI, or any peer QNE are preserved. Within those bounds a QOSM must operate, incl. any domain internal = optimized signaling." Of course no additional QoS-NSLP messages and QOS-NSLP objects can be defined by the QOS model. What a QOS model=20 should be able to do is to define new=20 QSPEC objects and to define how the QOS-NSLP siganling=20 in the domains internal, as you suggested under certain bounds,=20 can be optimized. Best Regards, Georgios =20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: vrijdag 5 januari 2007 18:06 > To: Georgios Karagiannis > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; John Loughney;=20 > Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > information >=20 >=20 > Hi Georgios, >=20 > I didn't imply that the constraints would include defining=20 > some new NSLP messages, or other things that are not already=20 > part of the QSPEC, or the NSLP. >=20 > Yet, a QOS Model might e.g., define new INFO_SPEC error/info=20 > codes, or a new object within the QSPEC, but I guess those=20 > would require standards action, and a standards track RFC. >=20 > A QOS Model should not change the end-to-end semantics of the=20 > NSLP, or of the QSPEC - this is what I wrote. >=20 >=20 > I haven't read lately the RMD spec, so I don't know what are the=20 > functionality that are introduced in addition to what is=20 > already in the=20 > QSPEC and the NSLP. >=20 > Cheers, > Jukka >=20 > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: >=20 > > Hi Dave > >=20 > > But I think that Jukka emphasized that it does not need to be=20 > > a standards track if it complies to: > > * the constraints specified in the QOS-NSLP document (see=20 > Jukkas proposal),=20 > > and of course if the QOS model draft is approved by the IESG for > > publication.=20 > >=20 > >=20 > > Best regards, > > Georgios > > =20 > >=20 > > > -----Original Message----- > > > From: David R Oran [mailto:oran@cisco.com]=20 > > > Sent: vrijdag 5 januari 2007 16:02 > > > To: Attila B=E1der (IJ/ETH) > > > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > > > Subject: Re: [NSIS] Consensus on: Removed the QSPEC control=20 > > > information > > >=20 > > >=20 > > > On Jan 5, 2007, at 9:02 AM, Attila B=E1der (IJ/ETH) wrote: > > >=20 > > > > Hi John, > > > > > > > > I disagree, I think the right approach is what Yukka sent. > > > > > > > >>> > > > > "The end-to-end semantic and QoS NSLP messaging by the=20 > QNI, or any=20 > > > > peer QNE MUST BE preserved, and within those bounds a QOSM must=20 > > > > operate." > > > > > > > > This means that e.g., > > > > a) The resource request by the QNI and response from=20 > the QNR must be > > > > followed and passed through intact by a QOSM X domain, > > > > b) confirmation requests must be answered, > > > > c) tear-down must be followed, etc. " > > > >>> > > > > > > > > I think QoS NSLP operation can be extended in a local=20 > QoS domain=20 > > > > without distroying e2e QoS-NSLP operation. > > > > > > > John L. seemed to be of the view that if a particular=20 > > > domain-loal QoS scheme (e.g. RMD) wants to use QoS-NSLP for=20 > > > its local scheme, then it is free to modify it if and only if=20 > > > there is a standards track RFC documenting the=20 > > > extensions/changes. This represents my view as well. =20 > > > This is the only way we can ascertain upwards/downwards=20 > > > compatibility and interoperability. Otherwise what you would=20 > > > have is a completely private signaling scheme which claims=20 > > > conformance to a standard. > > >=20 > > > These QoS-NSLP extensions would have no effect on the QSPEC=20 > > > specification, unless the QSPEC itself is being extended, in=20 > > > which case I think it's still an open issue whether or not=20 > > > you need a standards track RFC for that. My guess would be=20 > > > yes if we adopt Yukka's encoding scheme (because otherwise=20 > > > you could not find or debug the end-to-end QSPEC when=20 > > > embedded in an extended local QSPEC), but possibly no if we=20 > > > adopt a more layered encoding like QSPEC stacking (so that=20 > > > the parser has a known regular encoding structure to deal with). > > >=20 > > > Cheers, Dave. > > >=20 > > > > Best regards, Attila > > > > > > > > > > > >> -----Original Message----- > > > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > >> Sent: Friday, January 05, 2007 1:54 PM > > > >> To: gash@att.com; nsis@ietf.org > > > >> Subject: [NSIS] Consensus on: Removed the QSPEC=20 > control information > > > >> > > > >> > > > >>>> Point_1):Removed the QSPEC control information > > > >>>>=20 > --------------------------------------------------------------- > > > >>>> Jerry mentioned in a previous e-mail that this QSPEC control=20 > > > >>>> information concept is not removed but it is renamed=20 > to Traffic=20 > > > >>>> Handling Directives. > > > >>>> > > > >>>> If that is the case then Jerry will have to use the same > > > >> definitions > > > >>>> for the QSPEC control information as used in Section=20 > 5.3.1 of: > > > >>>>=20 > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > > >>>> > > > >>>> Thus my proposal is to change section 4.3.3 as given in=20 > > > v.13 of the=20 > > > >>>> QSPEC template draft and include the general concept of=20 > > > the QSPEC=20 > > > >>>> control information that was given in Section 5.3.1 of > > > >> version 12 of > > > >>>> the QSPEC template draft. Note that the name can be=20 > > > changed but the=20 > > > >>>> semantics should remain the same. Thus please change Section > > > >>> 4.3.3 as > > > >>>> follows: > > > >>>> > > > >>>> FROM: > > > >>>> > > > >>>> 4.3.3 Traffic Handling Directives > > > >>>> > > > >>>> The parameter describes how=20 > the QNE will > > > >> process > > > >>>> excess traffic, that is, out-of-profile traffic. =20 > > > Excess traffic > > > >> MAY > > > >>>> be dropped, shaped and/or remarked. The excess treatment > > > >> parameter > > > >> is > > > >>>> initially set by the QNI and cannot be overwritten. > > > >>>> > > > >>>> INTO: > > > >>>> > > > >>>> 4.3.3 Traffic Handling Directives > > > >>>> > > > >>>> Traffic Handling Directives are used for signaling QOSM > > > >>>> RMF functions > > > >>>> not defined in QoS NSLP. It enables building new RMF=20 > > > functions > > > >>>> required by a QOSM within a QoS NSLP signaling=20 > > > framework, such=20 > > > >>>> as > > > >>>> specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. > > > >>> > > > >>> I think most (perhaps all?) of us agree on this=20 > point: the QOSM=20 > > > >>> specification SHOULD NOT be allowed to define 'new=20 > RMF functions=20 > > > >>> required by a QOSM' UNLESS such NSIS signaling functionality > > > >> is defined > > > >>> in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP > > > >> signaling > > > >>> functionality. The above text seems to abide by the premise > > > >> by stating > > > >>> that new RMF functions are specified only 'within a QoS NSLP > > > >> signaling > > > >>> framework'. If so, I think we're in agreement. > > > >> > > > >> I agree with Jerry's text, and I believe we have rough=20 > > > consensus on=20 > > > >> this. > > > >> If anyone disagrees with consensus, a short mail=20 > stating that you=20 > > > >> disagree is needed. > > > >> > > > >> On point, in order to extend QoS NSLP signaling, a=20 > Standards Track=20 > > > >> RFC is needed. > > > >> > > > >> 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 > > >=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 Jan 05 12:19:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sig-0000cS-Pg; Fri, 05 Jan 2007 12:19:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sif-0000cG-LO for nsis@ietf.org; Fri, 05 Jan 2007 12:19:05 -0500 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 1H2siW-00028u-RX for nsis@ietf.org; Fri, 05 Jan 2007 12:19:04 -0500 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; Fri, 05 Jan 2007 19:18:52 +0200 id 000AFF21.459E887C.0000501A Date: Fri, 5 Jan 2007 19:18:51 +0200 (EET) From: Jukka MJ Manner To: "Ash, Gerald R \\\\(Jerry\\\\), ALABS" , Georgios Karagiannis Subject: RE: [NSIS] QSPEC, QOSMs, QoS NSLP interactions In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC809A@KCCLUST06EVS1.ugd.att.com> Message-ID: References: <9473683187ADC049A855ED2DA739ABCA0DDC809A@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: 22bbb45ef41b733eb2d03ee71ece8243 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, Yes, I think we are talking about the same thing - just wanted to check I got the discussion right. Still, one of the problems is about what is allowed for a QOSM to do, and what is not. What is a "new RMF function" (and what is not)? Clearly, separate signaling sessions for local domain use, session aggregation, session binding, etc. are all within the bounds. It would really help if the RMD folks could specify what would break in the RMD spec, is there functionality that is currently not included in the NSLP or the QSPEC. Jukka On Fri, 5 Jan 2007, Ash, Gerald R \(Jerry\), ALABS wrote: > Jukka, > > It seems you are not saying another contrary to what John stated as > consensus in his posting at > http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html: > > "the QOSM specification SHOULD NOT be allowed to define 'new RMF > functions required by a QOSM' UNLESS such NSIS signaling functionality > is defined in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP > signaling functionality...new RMF functions are specified only 'within a > QoS NSLP signaling framework'." > > Otherwise please clarify. > > Thanks, > Jerry > > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Friday, January 05, 2007 9:32 AM > To: john.loughney@nokia.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] QSPEC, QOSMs, QoS NSLP interactions > > John, > > I don't really have a direct placeholder for it, but somewhere in both > QSPEC and QoS NSLP. > > My main point was to get feedback on whether we should relax the NSLP > messaging and RMF interfactions from their current wording, similarly > than > resource provisioning is not specified, just that it must support the > QNI's request. A certain domain running a QOSM X can well do certain > optimizations, incl. separate signaling sessions and aggregation, > provided > that > > 1) it fulfils the original request of the QNIs, and > > 2) the end-to-end semantic and the end-to-end QoS NSLP messaging by the > QNI, or any peer QNE are preserved. > > Within those bounds a QOSM must operate, incl. any domain internal > optimized signaling. > > Jukka > > On Fri, 5 Jan 2007, john.loughney@nokia.com wrote: > > > Jukka, > > > > I can't really parse the text you have supplied. Where do you think > > such text should be added? > > > > John > > > > >-----Original Message----- > > >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > >Sent: 05 January, 2007 12:56 > > >To: nsis@ietf.org > > >Subject: [NSIS] QSPEC, QOSMs, QoS NSLP interactions > > > > > > > > >Hi (especially Dave, Jerry, Georgios, etc.), > > > > > >I've been following this latest discussion on the QSPEC and > > >QoS NSLP interactions, and state machines. I understand (or I > > >think I do) Dave's comment that QOSMs (or RMF) should not be > > >able to affect the QoS NSLP state machine, and that is a good > > >and valid point. > > > > > >Yet, how would e.g. reservation and signaling aggregation > > >(e.g. the mentioned separate signaling session for local > > >domain use), resource pre-emption or the local QSPEC concept > > >work? Don't these in fact change the normal operation of the > > >QoS NSLP at the edges of a special treatment domain? > > > > > >Since one of the main purposes of the QSPEC is to allow a QNI > > >to request something e2e, and QNEs along the way MUST commit > > >to that exact request (not downgrading anything, upgrading > > >would be fine, right?) but how they do it is not fixed, > > >doesn't this apply also to the QoS NSLP, so something along > > > > > >"The end-to-end semantic and QoS NSLP messaging by the QNI, or > > >any peer QNE MUST BE preserved, and within those bounds a QOSM > > >must operate." > > > > > >This means that e.g., > > >a) The resource request by the QNI and response from the QNR must be > > > followed and passed through intact by a QOSM X domain, > > >b) confirmation requests must be answered, > > >c) tear-down must be followed, etc. > > > > > > > > >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 Fri Jan 05 12:33:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2swI-0005ji-NI; Fri, 05 Jan 2007 12:33:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2swH-0005jb-SG for nsis@ietf.org; Fri, 05 Jan 2007 12:33:09 -0500 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 1H2swG-0006Vg-V3 for nsis@ietf.org; Fri, 05 Jan 2007 12:33:09 -0500 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; Fri, 05 Jan 2007 19:33:08 +0200 id 000AFDDE.459E8BD4.00006371 Date: Fri, 5 Jan 2007 19:33:08 +0200 (EET) From: Jukka MJ Manner To: Georgios Karagiannis Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information In-Reply-To: <002901c730ed$49f9f990$4c0d5982@dynamic.ewi.utwente.nl> Message-ID: References: <002901c730ed$49f9f990$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_courier-25464-1168018389-0001-2" X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Cc: 'John Loughney' , "'Ash, Gerald R \\\(Jerry\\\), ALABS'" , 'David R Oran' , 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 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-25464-1168018389-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 Hi Georgios, I guess new QSPEC objects could be allowed a) flexibly if their are only used within the local domain, and not e2e (which would require all QNEs to be upgraded), b) through NSLP standards action, if they need to be understood by all QNEs on the e2e path. I would expect the same goes with the NSLP, ie., if RMD changes the NSLP= message processing in some way, it can do so, but only for the local domain, without affecting any QNEs (incld QNI and QNR) outside the RMD domain). And this must still preserve the e2e messaging semantics. Jukka On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > Hi Jukka > > What I meant are your following statements: > " A certain domain running a QOSM X can well do certain optimizations,= > incl. separate signaling sessions and aggregation, provided that > > 1) it fulfils the original request of the QNIs, and > > 2) the end-to-end semantic and the end-to-end QoS NSLP messaging by th= e > QNI, or any peer QNE are preserved. > > Within those bounds a QOSM must operate, incl. any domain internal opt= imized > signaling." > > > Of course no additional QoS-NSLP messages and QOS-NSLP objects > can be defined by the QOS model. What a QOS model > should be able to do is to define new > QSPEC objects and to define how the QOS-NSLP siganling > in the domains internal, as you suggested under certain bounds, > can be optimized. > > Best Regards, > Georgios > > > > > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: vrijdag 5 januari 2007 18:06 > > To: Georgios Karagiannis > > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; John Loughney; > > Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > > information > > > > > > Hi Georgios, > > > > I didn't imply that the constraints would include defining > > some new NSLP messages, or other things that are not already > > part of the QSPEC, or the NSLP. > > > > Yet, a QOS Model might e.g., define new INFO_SPEC error/info > > codes, or a new object within the QSPEC, but I guess those > > would require standards action, and a standards track RFC. > > > > A QOS Model should not change the end-to-end semantics of the > > NSLP, or of the QSPEC - this is what I wrote. > > > > > > I haven't read lately the RMD spec, so I don't know what are the > > functionality that are introduced in addition to what is > > already in the > > QSPEC and the NSLP. > > > > Cheers, > > Jukka > > > > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > > > > > Hi Dave > > > > > > But I think that Jukka emphasized that it does not need to be > > > a standards track if it complies to: > > > * the constraints specified in the QOS-NSLP document (see > > Jukkas proposal), > > > and of course if the QOS model draft is approved by the IESG for > > > publication. > > > > > > > > > Best regards, > > > Georgios > > > > > > > > > > -----Original Message----- > > > > From: David R Oran [mailto:oran@cisco.com] > > > > Sent: vrijdag 5 januari 2007 16:02 > > > > To: Attila B=E1der (IJ/ETH) > > > > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > > > > Subject: Re: [NSIS] Consensus on: Removed the QSPEC control > > > > information > > > > > > > > > > > > On Jan 5, 2007, at 9:02 AM, Attila B=E1der (IJ/ETH) wrote: > > > > > > > > > Hi John, > > > > > > > > > > I disagree, I think the right approach is what Yukka sent. > > > > > > > > > >>> > > > > > "The end-to-end semantic and QoS NSLP messaging by the > > QNI, or any > > > > > peer QNE MUST BE preserved, and within those bounds a QOSM mus= t > > > > > operate." > > > > > > > > > > This means that e.g., > > > > > a) The resource request by the QNI and response from > > the QNR must be > > > > > followed and passed through intact by a QOSM X domain, > > > > > b) confirmation requests must be answered, > > > > > c) tear-down must be followed, etc. " > > > > >>> > > > > > > > > > > I think QoS NSLP operation can be extended in a local > > QoS domain > > > > > without distroying e2e QoS-NSLP operation. > > > > > > > > > John L. seemed to be of the view that if a particular > > > > domain-loal QoS scheme (e.g. RMD) wants to use QoS-NSLP for > > > > its local scheme, then it is free to modify it if and only if > > > > there is a standards track RFC documenting the > > > > extensions/changes. This represents my view as well. > > > > This is the only way we can ascertain upwards/downwards > > > > compatibility and interoperability. Otherwise what you would > > > > have is a completely private signaling scheme which claims > > > > conformance to a standard. > > > > > > > > These QoS-NSLP extensions would have no effect on the QSPEC > > > > specification, unless the QSPEC itself is being extended, in > > > > which case I think it's still an open issue whether or not > > > > you need a standards track RFC for that. My guess would be > > > > yes if we adopt Yukka's encoding scheme (because otherwise > > > > you could not find or debug the end-to-end QSPEC when > > > > embedded in an extended local QSPEC), but possibly no if we > > > > adopt a more layered encoding like QSPEC stacking (so that > > > > the parser has a known regular encoding structure to deal with). > > > > > > > > Cheers, Dave. > > > > > > > > > Best regards, Attila > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com= ] > > > > >> Sent: Friday, January 05, 2007 1:54 PM > > > > >> To: gash@att.com; nsis@ietf.org > > > > >> Subject: [NSIS] Consensus on: Removed the QSPEC > > control information > > > > >> > > > > >> > > > > >>>> Point_1):Removed the QSPEC control information > > > > >>>> > > --------------------------------------------------------------- > > > > >>>> Jerry mentioned in a previous e-mail that this QSPEC contro= l > > > > >>>> information concept is not removed but it is renamed > > to Traffic > > > > >>>> Handling Directives. > > > > >>>> > > > > >>>> If that is the case then Jerry will have to use the same > > > > >> definitions > > > > >>>> for the QSPEC control information as used in Section > > 5.3.1 of: > > > > >>>> > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > > > >>>> > > > > >>>> Thus my proposal is to change section 4.3.3 as given in > > > > v.13 of the > > > > >>>> QSPEC template draft and include the general concept of > > > > the QSPEC > > > > >>>> control information that was given in Section 5.3.1 of > > > > >> version 12 of > > > > >>>> the QSPEC template draft. Note that the name can be > > > > changed but the > > > > >>>> semantics should remain the same. Thus please change Sectio= n > > > > >>> 4.3.3 as > > > > >>>> follows: > > > > >>>> > > > > >>>> FROM: > > > > >>>> > > > > >>>> 4.3.3 Traffic Handling Directives > > > > >>>> > > > > >>>> The parameter describes how > > the QNE will > > > > >> process > > > > >>>> excess traffic, that is, out-of-profile traffic. > > > > Excess traffic > > > > >> MAY > > > > >>>> be dropped, shaped and/or remarked. The excess treatment > > > > >> parameter > > > > >> is > > > > >>>> initially set by the QNI and cannot be overwritten. > > > > >>>> > > > > >>>> INTO: > > > > >>>> > > > > >>>> 4.3.3 Traffic Handling Directives > > > > >>>> > > > > >>>> Traffic Handling Directives are used for signaling QOSM > > > > >>>> RMF functions > > > > >>>> not defined in QoS NSLP. It enables building new RMF > > > > functions > > > > >>>> required by a QOSM within a QoS NSLP signaling > > > > framework, such > > > > >>>> as > > > > >>>> specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. > > > > >>> > > > > >>> I think most (perhaps all?) of us agree on this > > point: the QOSM > > > > >>> specification SHOULD NOT be allowed to define 'new > > RMF functions > > > > >>> required by a QOSM' UNLESS such NSIS signaling functionality > > > > >> is defined > > > > >>> in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP > > > > >> signaling > > > > >>> functionality. The above text seems to abide by the premise > > > > >> by stating > > > > >>> that new RMF functions are specified only 'within a QoS NSLP > > > > >> signaling > > > > >>> framework'. If so, I think we're in agreement. > > > > >> > > > > >> I agree with Jerry's text, and I believe we have rough > > > > consensus on > > > > >> this. > > > > >> If anyone disagrees with consensus, a short mail > > stating that you > > > > >> disagree is needed. > > > > >> > > > > >> On point, in order to extend QoS NSLP signaling, a > > Standards Track > > > > >> RFC is needed. > > > > >> > > > > >> 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 > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > --=_courier-25464-1168018389-0001-2 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 --=_courier-25464-1168018389-0001-2-- From nsis-bounces@ietf.org Fri Jan 05 12:38:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2t1B-0008QA-50; Fri, 05 Jan 2007 12:38:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2t1A-0008PP-0E for nsis@ietf.org; Fri, 05 Jan 2007 12:38:12 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2t19-0007iM-Be for nsis@ietf.org; Fri, 05 Jan 2007 12:38:11 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l05HaqrV027604; Fri, 5 Jan 2007 18:36:56 +0100 (MET) From: "Georgios Karagiannis" To: "'Jukka MJ Manner'" Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Date: Fri, 5 Jan 2007 18:36:55 +0100 Message-ID: <002f01c730f0$1b376d10$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accw74uN5v+d7yRGS1umlRxWq6urBwAACJuw X-Spam-Score: 0.306 () AWL,FVGT_s_OBFU_Q1,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 05 Jan 2007 18:36:58 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Cc: 'John Loughney' , "'Ash, Gerald R \\\(Jerry\\\), ALABS'" , 'David R Oran' , 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 Jukka > I would expect the same goes with the NSLP, ie., if RMD=20 > changes the NSLP message processing in some way, it can do=20 > so, but only for the local domain, without affecting any QNEs=20 > (incld QNI and QNR) outside the RMD domain). And this must=20 > still preserve the e2e messaging semantics. Agreed, the change in the NSLP message processing holds only for the=20 QNEs within the local domain, not outside the domain. Best regards, Georgios =20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: vrijdag 5 januari 2007 18:33 > To: Georgios Karagiannis > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; 'John Loughney';=20 > 'Ash, Gerald R \(Jerry\), ALABS'; nsis@ietf.org > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > information >=20 >=20 > Hi Georgios, >=20 > I guess new QSPEC objects could be allowed >=20 > a) flexibly if their are only used within the local domain,=20 > and not e2e (which would require all QNEs to be upgraded), >=20 > b) through NSLP standards action, if they need to be=20 > understood by all=20 > QNEs on the e2e path. >=20 >=20 > I would expect the same goes with the NSLP, ie., if RMD=20 > changes the NSLP message processing in some way, it can do=20 > so, but only for the local domain, without affecting any QNEs=20 > (incld QNI and QNR) outside the RMD domain). And this must=20 > still preserve the e2e messaging semantics. >=20 > Jukka >=20 > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: >=20 > > Hi Jukka > >=20 > > What I meant are your following statements: > > " A certain domain running a QOSM X can well do certain=20 > optimizations,=20 > > incl. separate signaling sessions and aggregation, provided that > >=20 > > 1) it fulfils the original request of the QNIs, and > >=20 > > 2) the end-to-end semantic and the end-to-end QoS NSLP=20 > messaging by the=20 > > QNI, or any peer QNE are preserved. > >=20 > > Within those bounds a QOSM must operate, incl. any domain internal=20 > > optimized signaling." > >=20 > >=20 > > Of course no additional QoS-NSLP messages and QOS-NSLP=20 > objects can be=20 > > defined by the QOS model. What a QOS model should be able=20 > to do is to=20 > > define new QSPEC objects and to define how the QOS-NSLP=20 > siganling in=20 > > the domains internal, as you suggested under certain bounds, can be=20 > > optimized. > >=20 > > Best Regards, > > Georgios > >=20 > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: vrijdag 5 januari 2007 18:06 > > > To: Georgios Karagiannis > > > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; John Loughney; Ash, = > > > Gerald R (Jerry), ALABS; nsis@ietf.org > > > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > > > information > > >=20 > > >=20 > > > Hi Georgios, > > >=20 > > > I didn't imply that the constraints would include=20 > defining some new=20 > > > NSLP messages, or other things that are not already part of the=20 > > > QSPEC, or the NSLP. > > >=20 > > > Yet, a QOS Model might e.g., define new INFO_SPEC=20 > error/info codes,=20 > > > or a new object within the QSPEC, but I guess those would require=20 > > > standards action, and a standards track RFC. > > >=20 > > > A QOS Model should not change the end-to-end semantics of=20 > the NSLP,=20 > > > or of the QSPEC - this is what I wrote. > > >=20 > > >=20 > > > I haven't read lately the RMD spec, so I don't know what are the=20 > > > functionality that are introduced in addition to what is=20 > already in=20 > > > the QSPEC and the NSLP. > > >=20 > > > Cheers, > > > Jukka > > >=20 > > > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > > >=20 > > > > Hi Dave > > > >=20 > > > > But I think that Jukka emphasized that it does not need to be a=20 > > > > standards track if it complies to: > > > > * the constraints specified in the QOS-NSLP document (see > > > Jukkas proposal), > > > > and of course if the QOS model draft is approved by the=20 > IESG for=20 > > > > publication. > > > >=20 > > > >=20 > > > > Best regards, > > > > Georgios > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: David R Oran [mailto:oran@cisco.com] > > > > > Sent: vrijdag 5 januari 2007 16:02 > > > > > To: Attila B=E1der (IJ/ETH) > > > > > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > > > > > Subject: Re: [NSIS] Consensus on: Removed the QSPEC control=20 > > > > > information > > > > >=20 > > > > >=20 > > > > > On Jan 5, 2007, at 9:02 AM, Attila B=E1der (IJ/ETH) wrote: > > > > >=20 > > > > > > Hi John, > > > > > > > > > > > > I disagree, I think the right approach is what Yukka sent. > > > > > > > > > > > >>> > > > > > > "The end-to-end semantic and QoS NSLP messaging by the > > > QNI, or any > > > > > > peer QNE MUST BE preserved, and within those bounds a QOSM=20 > > > > > > must operate." > > > > > > > > > > > > This means that e.g., > > > > > > a) The resource request by the QNI and response from > > > the QNR must be > > > > > > followed and passed through intact by a QOSM X domain, > > > > > > b) confirmation requests must be answered, > > > > > > c) tear-down must be followed, etc. " > > > > > >>> > > > > > > > > > > > > I think QoS NSLP operation can be extended in a local > > > QoS domain > > > > > > without distroying e2e QoS-NSLP operation. > > > > > > > > > > > John L. seemed to be of the view that if a particular=20 > > > > > domain-loal QoS scheme (e.g. RMD) wants to use=20 > QoS-NSLP for its=20 > > > > > local scheme, then it is free to modify it if and=20 > only if there=20 > > > > > is a standards track RFC documenting the extensions/changes.=20 > > > > > This represents my view as well. > > > > > This is the only way we can ascertain upwards/downwards=20 > > > > > compatibility and interoperability. Otherwise what you would=20 > > > > > have is a completely private signaling scheme which claims=20 > > > > > conformance to a standard. > > > > >=20 > > > > > These QoS-NSLP extensions would have no effect on the QSPEC=20 > > > > > specification, unless the QSPEC itself is being extended, in=20 > > > > > which case I think it's still an open issue whether=20 > or not you=20 > > > > > need a standards track RFC for that. My guess would=20 > be yes if we=20 > > > > > adopt Yukka's encoding scheme (because otherwise you=20 > could not=20 > > > > > find or debug the end-to-end QSPEC when embedded in=20 > an extended=20 > > > > > local QSPEC), but possibly no if we adopt a more layered=20 > > > > > encoding like QSPEC stacking (so that the parser has a known=20 > > > > > regular encoding structure to deal with). > > > > >=20 > > > > > Cheers, Dave. > > > > >=20 > > > > > > Best regards, Attila > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: john.loughney@nokia.com=20 > > > > > >> [mailto:john.loughney@nokia.com] > > > > > >> Sent: Friday, January 05, 2007 1:54 PM > > > > > >> To: gash@att.com; nsis@ietf.org > > > > > >> Subject: [NSIS] Consensus on: Removed the QSPEC > > > control information > > > > > >> > > > > > >> > > > > > >>>> Point_1):Removed the QSPEC control information > > > > > >>>>=20 > > > --------------------------------------------------------------- > > > > > >>>> Jerry mentioned in a previous e-mail that this QSPEC=20 > > > > > >>>> control information concept is not removed but it is=20 > > > > > >>>> renamed > > > to Traffic > > > > > >>>> Handling Directives. > > > > > >>>> > > > > > >>>> If that is the case then Jerry will have to use the same > > > > > >> definitions > > > > > >>>> for the QSPEC control information as used in Section > > > 5.3.1 of: > > > > > >>>>=20 > > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > > > > >>>> > > > > > >>>> Thus my proposal is to change section 4.3.3 as given in > > > > > v.13 of the > > > > > >>>> QSPEC template draft and include the general concept of > > > > > the QSPEC > > > > > >>>> control information that was given in Section 5.3.1 of > > > > > >> version 12 of > > > > > >>>> the QSPEC template draft. Note that the name can be > > > > > changed but the > > > > > >>>> semantics should remain the same. Thus please change=20 > > > > > >>>> Section > > > > > >>> 4.3.3 as > > > > > >>>> follows: > > > > > >>>> > > > > > >>>> FROM: > > > > > >>>> > > > > > >>>> 4.3.3 Traffic Handling Directives > > > > > >>>> > > > > > >>>> The parameter describes how > > > the QNE will > > > > > >> process > > > > > >>>> excess traffic, that is, out-of-profile traffic. =20 > > > > > Excess traffic > > > > > >> MAY > > > > > >>>> be dropped, shaped and/or remarked. The=20 > excess treatment > > > > > >> parameter > > > > > >> is > > > > > >>>> initially set by the QNI and cannot be overwritten. > > > > > >>>> > > > > > >>>> INTO: > > > > > >>>> > > > > > >>>> 4.3.3 Traffic Handling Directives > > > > > >>>> > > > > > >>>> Traffic Handling Directives are used for=20 > signaling QOSM > > > > > >>>> RMF functions > > > > > >>>> not defined in QoS NSLP. It enables building new RMF > > > > > functions > > > > > >>>> required by a QOSM within a QoS NSLP signaling > > > > > framework, such > > > > > >>>> as > > > > > >>>> specified, for example, in [RMD-QOSM] and=20 > [Y.1541-QOSM]. > > > > > >>> > > > > > >>> I think most (perhaps all?) of us agree on this > > > point: the QOSM > > > > > >>> specification SHOULD NOT be allowed to define 'new > > > RMF functions > > > > > >>> required by a QOSM' UNLESS such NSIS signaling=20 > functionality > > > > > >> is defined > > > > > >>> in QoS NSLP. I.e., a QOSM is not allowed to=20 > extend QoS NSLP > > > > > >> signaling > > > > > >>> functionality. The above text seems to abide by=20 > the premise > > > > > >> by stating > > > > > >>> that new RMF functions are specified only 'within=20 > a QoS NSLP > > > > > >> signaling > > > > > >>> framework'. If so, I think we're in agreement. > > > > > >> > > > > > >> I agree with Jerry's text, and I believe we have rough > > > > > consensus on > > > > > >> this. > > > > > >> If anyone disagrees with consensus, a short mail > > > stating that you > > > > > >> disagree is needed. > > > > > >> > > > > > >> On point, in order to extend QoS NSLP signaling, a > > > Standards Track > > > > > >> RFC is needed. > > > > > >> > > > > > >> 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 > > > > >=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 > >=20 > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 05 12:53:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tFC-0005Vc-Fl; Fri, 05 Jan 2007 12:52:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tFB-0005VX-Ux for nsis@ietf.org; Fri, 05 Jan 2007 12:52:41 -0500 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 1H2tF9-0002gn-28 for nsis@ietf.org; Fri, 05 Jan 2007 12:52:41 -0500 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; Fri, 05 Jan 2007 19:52:34 +0200 id 000AFF2C.459E9062.0000589E Date: Fri, 5 Jan 2007 19:52:34 +0200 (EET) From: Jukka MJ Manner To: Georgios Karagiannis Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information In-Reply-To: <002f01c730f0$1b376d10$4c0d5982@dynamic.ewi.utwente.nl> Message-ID: References: <002f01c730f0$1b376d10$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_courier-22693-1168019559-0001-2" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: 'John Loughney' , "'Ash, Gerald R \\\\\\\(Jerry\\\\\\\), ALABS'" , 'David R Oran' , 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 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-22693-1168019559-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 Good. Then I don't see what the problem is. The e2e semantics of the NSLP messaging are preserved, and the request by the QNI is supported (provided the resources are there). Jukka On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > Hi Jukka > > > I would expect the same goes with the NSLP, ie., if RMD > > changes the NSLP message processing in some way, it can do > > so, but only for the local domain, without affecting any QNEs > > (incld QNI and QNR) outside the RMD domain). And this must > > still preserve the e2e messaging semantics. > > Agreed, the change in the NSLP message processing holds only for the > QNEs within the local domain, not outside the domain. > > > Best regards, > Georgios > > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: vrijdag 5 januari 2007 18:33 > > To: Georgios Karagiannis > > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; 'John Loughney'; > > 'Ash, Gerald R \(Jerry\), ALABS'; nsis@ietf.org > > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > > information > > > > > > Hi Georgios, > > > > I guess new QSPEC objects could be allowed > > > > a) flexibly if their are only used within the local domain, > > and not e2e (which would require all QNEs to be upgraded), > > > > b) through NSLP standards action, if they need to be > > understood by all > > QNEs on the e2e path. > > > > > > I would expect the same goes with the NSLP, ie., if RMD > > changes the NSLP message processing in some way, it can do > > so, but only for the local domain, without affecting any QNEs > > (incld QNI and QNR) outside the RMD domain). And this must > > still preserve the e2e messaging semantics. > > > > Jukka > > > > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > > > > > Hi Jukka > > > > > > What I meant are your following statements: > > > " A certain domain running a QOSM X can well do certain > > optimizations, > > > incl. separate signaling sessions and aggregation, provided that > > > > > > 1) it fulfils the original request of the QNIs, and > > > > > > 2) the end-to-end semantic and the end-to-end QoS NSLP > > messaging by the > > > QNI, or any peer QNE are preserved. > > > > > > Within those bounds a QOSM must operate, incl. any domain internal= > > > optimized signaling." > > > > > > > > > Of course no additional QoS-NSLP messages and QOS-NSLP > > objects can be > > > defined by the QOS model. What a QOS model should be able > > to do is to > > > define new QSPEC objects and to define how the QOS-NSLP > > siganling in > > > the domains internal, as you suggested under certain bounds, can b= e > > > optimized. > > > > > > Best Regards, > > > Georgios > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > Sent: vrijdag 5 januari 2007 18:06 > > > > To: Georgios Karagiannis > > > > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; John Loughney; As= h, > > > > Gerald R (Jerry), ALABS; nsis@ietf.org > > > > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > > > > information > > > > > > > > > > > > Hi Georgios, > > > > > > > > I didn't imply that the constraints would include > > defining some new > > > > NSLP messages, or other things that are not already part of the > > > > QSPEC, or the NSLP. > > > > > > > > Yet, a QOS Model might e.g., define new INFO_SPEC > > error/info codes, > > > > or a new object within the QSPEC, but I guess those would requir= e > > > > standards action, and a standards track RFC. > > > > > > > > A QOS Model should not change the end-to-end semantics of > > the NSLP, > > > > or of the QSPEC - this is what I wrote. > > > > > > > > > > > > I haven't read lately the RMD spec, so I don't know what are the= > > > > functionality that are introduced in addition to what is > > already in > > > > the QSPEC and the NSLP. > > > > > > > > Cheers, > > > > Jukka > > > > > > > > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > > > > > > > > > Hi Dave > > > > > > > > > > But I think that Jukka emphasized that it does not need to be = a > > > > > standards track if it complies to: > > > > > * the constraints specified in the QOS-NSLP document (see > > > > Jukkas proposal), > > > > > and of course if the QOS model draft is approved by the > > IESG for > > > > > publication. > > > > > > > > > > > > > > > Best regards, > > > > > Georgios > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: David R Oran [mailto:oran@cisco.com] > > > > > > Sent: vrijdag 5 januari 2007 16:02 > > > > > > To: Attila B=E1der (IJ/ETH) > > > > > > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > > > > > > Subject: Re: [NSIS] Consensus on: Removed the QSPEC control > > > > > > information > > > > > > > > > > > > > > > > > > On Jan 5, 2007, at 9:02 AM, Attila B=E1der (IJ/ETH) wrote: > > > > > > > > > > > > > Hi John, > > > > > > > > > > > > > > I disagree, I think the right approach is what Yukka sent. > > > > > > > > > > > > > >>> > > > > > > > "The end-to-end semantic and QoS NSLP messaging by the > > > > QNI, or any > > > > > > > peer QNE MUST BE preserved, and within those bounds a QOSM= > > > > > > > must operate." > > > > > > > > > > > > > > This means that e.g., > > > > > > > a) The resource request by the QNI and response from > > > > the QNR must be > > > > > > > followed and passed through intact by a QOSM X domain, > > > > > > > b) confirmation requests must be answered, > > > > > > > c) tear-down must be followed, etc. " > > > > > > >>> > > > > > > > > > > > > > > I think QoS NSLP operation can be extended in a local > > > > QoS domain > > > > > > > without distroying e2e QoS-NSLP operation. > > > > > > > > > > > > > John L. seemed to be of the view that if a particular > > > > > > domain-loal QoS scheme (e.g. RMD) wants to use > > QoS-NSLP for its > > > > > > local scheme, then it is free to modify it if and > > only if there > > > > > > is a standards track RFC documenting the extensions/changes.= > > > > > > This represents my view as well. > > > > > > This is the only way we can ascertain upwards/downwards > > > > > > compatibility and interoperability. Otherwise what you would= > > > > > > have is a completely private signaling scheme which claims > > > > > > conformance to a standard. > > > > > > > > > > > > These QoS-NSLP extensions would have no effect on the QSPEC > > > > > > specification, unless the QSPEC itself is being extended, in= > > > > > > which case I think it's still an open issue whether > > or not you > > > > > > need a standards track RFC for that. My guess would > > be yes if we > > > > > > adopt Yukka's encoding scheme (because otherwise you > > could not > > > > > > find or debug the end-to-end QSPEC when embedded in > > an extended > > > > > > local QSPEC), but possibly no if we adopt a more layered > > > > > > encoding like QSPEC stacking (so that the parser has a known= > > > > > > regular encoding structure to deal with). > > > > > > > > > > > > Cheers, Dave. > > > > > > > > > > > > > Best regards, Attila > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: john.loughney@nokia.com > > > > > > >> [mailto:john.loughney@nokia.com] > > > > > > >> Sent: Friday, January 05, 2007 1:54 PM > > > > > > >> To: gash@att.com; nsis@ietf.org > > > > > > >> Subject: [NSIS] Consensus on: Removed the QSPEC > > > > control information > > > > > > >> > > > > > > >> > > > > > > >>>> Point_1):Removed the QSPEC control information > > > > > > >>>> > > > > --------------------------------------------------------------- > > > > > > >>>> Jerry mentioned in a previous e-mail that this QSPEC > > > > > > >>>> control information concept is not removed but it is > > > > > > >>>> renamed > > > > to Traffic > > > > > > >>>> Handling Directives. > > > > > > >>>> > > > > > > >>>> If that is the case then Jerry will have to use the sam= e > > > > > > >> definitions > > > > > > >>>> for the QSPEC control information as used in Section > > > > 5.3.1 of: > > > > > > >>>> > > > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt > > > > > > >>>> > > > > > > >>>> Thus my proposal is to change section 4.3.3 as given in > > > > > > v.13 of the > > > > > > >>>> QSPEC template draft and include the general concept of > > > > > > the QSPEC > > > > > > >>>> control information that was given in Section 5.3.1 of > > > > > > >> version 12 of > > > > > > >>>> the QSPEC template draft. Note that the name can be > > > > > > changed but the > > > > > > >>>> semantics should remain the same. Thus please change > > > > > > >>>> Section > > > > > > >>> 4.3.3 as > > > > > > >>>> follows: > > > > > > >>>> > > > > > > >>>> FROM: > > > > > > >>>> > > > > > > >>>> 4.3.3 Traffic Handling Directives > > > > > > >>>> > > > > > > >>>> The parameter describes how > > > > the QNE will > > > > > > >> process > > > > > > >>>> excess traffic, that is, out-of-profile traffic. > > > > > > Excess traffic > > > > > > >> MAY > > > > > > >>>> be dropped, shaped and/or remarked. The > > excess treatment > > > > > > >> parameter > > > > > > >> is > > > > > > >>>> initially set by the QNI and cannot be overwritten. > > > > > > >>>> > > > > > > >>>> INTO: > > > > > > >>>> > > > > > > >>>> 4.3.3 Traffic Handling Directives > > > > > > >>>> > > > > > > >>>> Traffic Handling Directives are used for > > signaling QOSM > > > > > > >>>> RMF functions > > > > > > >>>> not defined in QoS NSLP. It enables building new RM= F > > > > > > functions > > > > > > >>>> required by a QOSM within a QoS NSLP signaling > > > > > > framework, such > > > > > > >>>> as > > > > > > >>>> specified, for example, in [RMD-QOSM] and > > [Y.1541-QOSM]. > > > > > > >>> > > > > > > >>> I think most (perhaps all?) of us agree on this > > > > point: the QOSM > > > > > > >>> specification SHOULD NOT be allowed to define 'new > > > > RMF functions > > > > > > >>> required by a QOSM' UNLESS such NSIS signaling > > functionality > > > > > > >> is defined > > > > > > >>> in QoS NSLP. I.e., a QOSM is not allowed to > > extend QoS NSLP > > > > > > >> signaling > > > > > > >>> functionality. The above text seems to abide by > > the premise > > > > > > >> by stating > > > > > > >>> that new RMF functions are specified only 'within > > a QoS NSLP > > > > > > >> signaling > > > > > > >>> framework'. If so, I think we're in agreement. > > > > > > >> > > > > > > >> I agree with Jerry's text, and I believe we have rough > > > > > > consensus on > > > > > > >> this. > > > > > > >> If anyone disagrees with consensus, a short mail > > > > stating that you > > > > > > >> disagree is needed. > > > > > > >> > > > > > > >> On point, in order to extend QoS NSLP signaling, a > > > > Standards Track > > > > > > >> RFC is needed. > > > > > > >> > > > > > > >> 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 > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > --=_courier-22693-1168019559-0001-2 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 --=_courier-22693-1168019559-0001-2-- From nsis-bounces@ietf.org Sat Jan 06 03:18:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H36kN-0004Cr-Jf; Sat, 06 Jan 2007 03:17:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H36kK-00049C-TW for nsis@ietf.org; Sat, 06 Jan 2007 03:17:44 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H36dh-00033o-GK for nsis@ietf.org; Sat, 06 Jan 2007 03:10:57 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0688arY018807; Sat, 6 Jan 2007 10:08:57 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Jan 2007 10:10:29 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Jan 2007 10:10:29 +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] Consensus on: Removed the QSPEC control information Date: Sat, 6 Jan 2007 10:10:29 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Consensus on: Removed the QSPEC control information Thread-Index: Accw8klokyyiQRdsSmybNBX8VQLNAgAd3wrw From: To: , X-OriginalArrivalTime: 06 Jan 2007 08:10:29.0221 (UTC) FILETIME=[20EF8150:01C7316A] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c Cc: gash@att.com, oran@cisco.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 Hi all, My bigger concern is - how will implementations work? Will we need 2 completely different implementations to work in different scenarios? What is the reuse of implementations conforming to the base Qos NSLP spec? I agree with Dave's point: > I think the constraints are stronger than this, if you want the = domain-local=20 > elements to be able to claim conformance to the QOS NSLP = specification. If not,=20 > the entire argument is moot, since then your domain-local signaling is = > completely proprietary and non-standard. John >-----Original Message----- >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 >Sent: 05 January, 2007 19:53 >To: Georgios Karagiannis >Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; Loughney John=20 >(Nokia-NRC/PaloAlto); 'Ash, Gerald R \\\(Jerry\\\), ALABS';=20 >nsis@ietf.org >Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information > > >Good. Then I don't see what the problem is. The e2e semantics=20 >of the NSLP messaging are preserved, and the request by the=20 >QNI is supported (provided the resources are there). > >Jukka > >On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > >> Hi Jukka >>=20 >> > I would expect the same goes with the NSLP, ie., if RMD=20 >changes the=20 >> > NSLP message processing in some way, it can do so, but=20 >only for the=20 >> > local domain, without affecting any QNEs (incld QNI and=20 >QNR) outside=20 >> > the RMD domain). And this must still preserve the e2e messaging=20 >> > semantics. >>=20 >> Agreed, the change in the NSLP message processing holds only for the=20 >> QNEs within the local domain, not outside the domain. >>=20 >>=20 >> Best regards, >> Georgios >> =20 >>=20 >> > -----Original Message----- >> > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >> > Sent: vrijdag 5 januari 2007 18:33 >> > To: Georgios Karagiannis >> > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; 'John=20 >Loughney'; 'Ash,=20 >> > Gerald R \(Jerry\), ALABS'; nsis@ietf.org >> > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 >> > information >> >=20 >> >=20 >> > Hi Georgios, >> >=20 >> > I guess new QSPEC objects could be allowed >> >=20 >> > a) flexibly if their are only used within the local=20 >domain, and not=20 >> > e2e (which would require all QNEs to be upgraded), >> >=20 >> > b) through NSLP standards action, if they need to be understood by=20 >> > all >> > QNEs on the e2e path. >> >=20 >> >=20 >> > I would expect the same goes with the NSLP, ie., if RMD=20 >changes the=20 >> > NSLP message processing in some way, it can do so, but=20 >only for the=20 >> > local domain, without affecting any QNEs (incld QNI and=20 >QNR) outside=20 >> > the RMD domain). And this must still preserve the e2e messaging=20 >> > semantics. >> >=20 >> > Jukka >> >=20 >> > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: >> >=20 >> > > Hi Jukka >> > >=20 >> > > What I meant are your following statements: >> > > " A certain domain running a QOSM X can well do certain >> > optimizations, >> > > incl. separate signaling sessions and aggregation, provided that >> > >=20 >> > > 1) it fulfils the original request of the QNIs, and >> > >=20 >> > > 2) the end-to-end semantic and the end-to-end QoS NSLP >> > messaging by the >> > > QNI, or any peer QNE are preserved. >> > >=20 >> > > Within those bounds a QOSM must operate, incl. any=20 >domain internal=20 >> > > optimized signaling." >> > >=20 >> > >=20 >> > > Of course no additional QoS-NSLP messages and QOS-NSLP >> > objects can be >> > > defined by the QOS model. What a QOS model should be able >> > to do is to >> > > define new QSPEC objects and to define how the QOS-NSLP >> > siganling in >> > > the domains internal, as you suggested under certain bounds, can=20 >> > > be optimized. >> > >=20 >> > > Best Regards, >> > > Georgios >> > >=20 >> > >=20 >> > >=20 >> > > =20 >> > >=20 >> > > > -----Original Message----- >> > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >> > > > Sent: vrijdag 5 januari 2007 18:06 >> > > > To: Georgios Karagiannis >> > > > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; John=20 >Loughney; Ash,=20 >> > > > Gerald R (Jerry), ALABS; nsis@ietf.org >> > > > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 >> > > > information >> > > >=20 >> > > >=20 >> > > > Hi Georgios, >> > > >=20 >> > > > I didn't imply that the constraints would include >> > defining some new >> > > > NSLP messages, or other things that are not already=20 >part of the=20 >> > > > QSPEC, or the NSLP. >> > > >=20 >> > > > Yet, a QOS Model might e.g., define new INFO_SPEC >> > error/info codes, >> > > > or a new object within the QSPEC, but I guess those would=20 >> > > > require standards action, and a standards track RFC. >> > > >=20 >> > > > A QOS Model should not change the end-to-end semantics of >> > the NSLP, >> > > > or of the QSPEC - this is what I wrote. >> > > >=20 >> > > >=20 >> > > > I haven't read lately the RMD spec, so I don't know=20 >what are the=20 >> > > > functionality that are introduced in addition to what is >> > already in >> > > > the QSPEC and the NSLP. >> > > >=20 >> > > > Cheers, >> > > > Jukka >> > > >=20 >> > > > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: >> > > >=20 >> > > > > Hi Dave >> > > > >=20 >> > > > > But I think that Jukka emphasized that it does not=20 >need to be=20 >> > > > > a standards track if it complies to: >> > > > > * the constraints specified in the QOS-NSLP document (see >> > > > Jukkas proposal), >> > > > > and of course if the QOS model draft is approved by the >> > IESG for >> > > > > publication. >> > > > >=20 >> > > > >=20 >> > > > > Best regards, >> > > > > Georgios >> > > > > =20 >> > > > >=20 >> > > > > > -----Original Message----- >> > > > > > From: David R Oran [mailto:oran@cisco.com] >> > > > > > Sent: vrijdag 5 januari 2007 16:02 >> > > > > > To: Attila B=E1der (IJ/ETH) >> > > > > > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org >> > > > > > Subject: Re: [NSIS] Consensus on: Removed the=20 >QSPEC control=20 >> > > > > > information >> > > > > >=20 >> > > > > >=20 >> > > > > > On Jan 5, 2007, at 9:02 AM, Attila B=E1der (IJ/ETH) wrote: >> > > > > >=20 >> > > > > > > Hi John, >> > > > > > > >> > > > > > > I disagree, I think the right approach is what=20 >Yukka sent. >> > > > > > > >> > > > > > >>> >> > > > > > > "The end-to-end semantic and QoS NSLP messaging by the >> > > > QNI, or any >> > > > > > > peer QNE MUST BE preserved, and within those=20 >bounds a QOSM=20 >> > > > > > > must operate." >> > > > > > > >> > > > > > > This means that e.g., >> > > > > > > a) The resource request by the QNI and response from >> > > > the QNR must be >> > > > > > > followed and passed through intact by a QOSM X domain, >> > > > > > > b) confirmation requests must be answered, >> > > > > > > c) tear-down must be followed, etc. " >> > > > > > >>> >> > > > > > > >> > > > > > > I think QoS NSLP operation can be extended in a local >> > > > QoS domain >> > > > > > > without distroying e2e QoS-NSLP operation. >> > > > > > > >> > > > > > John L. seemed to be of the view that if a particular=20 >> > > > > > domain-loal QoS scheme (e.g. RMD) wants to use >> > QoS-NSLP for its >> > > > > > local scheme, then it is free to modify it if and >> > only if there >> > > > > > is a standards track RFC documenting the=20 >extensions/changes.=20 >> > > > > > This represents my view as well. >> > > > > > This is the only way we can ascertain upwards/downwards=20 >> > > > > > compatibility and interoperability. Otherwise what=20 >you would=20 >> > > > > > have is a completely private signaling scheme which claims=20 >> > > > > > conformance to a standard. >> > > > > >=20 >> > > > > > These QoS-NSLP extensions would have no effect on=20 >the QSPEC=20 >> > > > > > specification, unless the QSPEC itself is being=20 >extended, in=20 >> > > > > > which case I think it's still an open issue whether >> > or not you >> > > > > > need a standards track RFC for that. My guess would >> > be yes if we >> > > > > > adopt Yukka's encoding scheme (because otherwise you >> > could not >> > > > > > find or debug the end-to-end QSPEC when embedded in >> > an extended >> > > > > > local QSPEC), but possibly no if we adopt a more layered=20 >> > > > > > encoding like QSPEC stacking (so that the parser=20 >has a known=20 >> > > > > > regular encoding structure to deal with). >> > > > > >=20 >> > > > > > Cheers, Dave. >> > > > > >=20 >> > > > > > > Best regards, Attila >> > > > > > > >> > > > > > > >> > > > > > >> -----Original Message----- >> > > > > > >> From: john.loughney@nokia.com=20 >> > > > > > >> [mailto:john.loughney@nokia.com] >> > > > > > >> Sent: Friday, January 05, 2007 1:54 PM >> > > > > > >> To: gash@att.com; nsis@ietf.org >> > > > > > >> Subject: [NSIS] Consensus on: Removed the QSPEC >> > > > control information >> > > > > > >> >> > > > > > >> >> > > > > > >>>> Point_1):Removed the QSPEC control information >> > > > > > >>>>=20 >> > > > --------------------------------------------------------------- >> > > > > > >>>> Jerry mentioned in a previous e-mail that this QSPEC=20 >> > > > > > >>>> control information concept is not removed but it is=20 >> > > > > > >>>> renamed >> > > > to Traffic >> > > > > > >>>> Handling Directives. >> > > > > > >>>> >> > > > > > >>>> If that is the case then Jerry will have to use the=20 >> > > > > > >>>> same >> > > > > > >> definitions >> > > > > > >>>> for the QSPEC control information as used in Section >> > > > 5.3.1 of: >> > > > > > >>>>=20 >> > > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt >> > > > > > >>>> >> > > > > > >>>> Thus my proposal is to change section 4.3.3=20 >as given in >> > > > > > v.13 of the >> > > > > > >>>> QSPEC template draft and include the general=20 >concept of >> > > > > > the QSPEC >> > > > > > >>>> control information that was given in Section 5.3.1 of >> > > > > > >> version 12 of >> > > > > > >>>> the QSPEC template draft. Note that the name can be >> > > > > > changed but the >> > > > > > >>>> semantics should remain the same. Thus please change=20 >> > > > > > >>>> Section >> > > > > > >>> 4.3.3 as >> > > > > > >>>> follows: >> > > > > > >>>> >> > > > > > >>>> FROM: >> > > > > > >>>> >> > > > > > >>>> 4.3.3 Traffic Handling Directives >> > > > > > >>>> >> > > > > > >>>> The parameter describes how >> > > > the QNE will >> > > > > > >> process >> > > > > > >>>> excess traffic, that is, out-of-profile traffic. =20 >> > > > > > Excess traffic >> > > > > > >> MAY >> > > > > > >>>> be dropped, shaped and/or remarked. The >> > excess treatment >> > > > > > >> parameter >> > > > > > >> is >> > > > > > >>>> initially set by the QNI and cannot be overwritten. >> > > > > > >>>> >> > > > > > >>>> INTO: >> > > > > > >>>> >> > > > > > >>>> 4.3.3 Traffic Handling Directives >> > > > > > >>>> >> > > > > > >>>> Traffic Handling Directives are used for >> > signaling QOSM >> > > > > > >>>> RMF functions >> > > > > > >>>> not defined in QoS NSLP. It enables building new=20 >> > > > > > >>>> RMF >> > > > > > functions >> > > > > > >>>> required by a QOSM within a QoS NSLP signaling >> > > > > > framework, such >> > > > > > >>>> as >> > > > > > >>>> specified, for example, in [RMD-QOSM] and >> > [Y.1541-QOSM]. >> > > > > > >>> >> > > > > > >>> I think most (perhaps all?) of us agree on this >> > > > point: the QOSM >> > > > > > >>> specification SHOULD NOT be allowed to define 'new >> > > > RMF functions >> > > > > > >>> required by a QOSM' UNLESS such NSIS signaling >> > functionality >> > > > > > >> is defined >> > > > > > >>> in QoS NSLP. I.e., a QOSM is not allowed to >> > extend QoS NSLP >> > > > > > >> signaling >> > > > > > >>> functionality. The above text seems to abide by >> > the premise >> > > > > > >> by stating >> > > > > > >>> that new RMF functions are specified only 'within >> > a QoS NSLP >> > > > > > >> signaling >> > > > > > >>> framework'. If so, I think we're in agreement. >> > > > > > >> >> > > > > > >> I agree with Jerry's text, and I believe we have rough >> > > > > > consensus on >> > > > > > >> this. >> > > > > > >> If anyone disagrees with consensus, a short mail >> > > > stating that you >> > > > > > >> disagree is needed. >> > > > > > >> >> > > > > > >> On point, in order to extend QoS NSLP signaling, a >> > > > Standards Track >> > > > > > >> RFC is needed. >> > > > > > >> >> > > > > > >> 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 >> > > > > >=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 >> > >=20 >> > >=20 >> > >=20 >> >=20 >>=20 >>=20 >>=20 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jan 06 10:18:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3DJ6-0004IP-MY; Sat, 06 Jan 2007 10:18:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3DJ5-0004IK-2B for nsis@ietf.org; Sat, 06 Jan 2007 10:18:03 -0500 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 1H3DJ1-0001PX-62 for nsis@ietf.org; Sat, 06 Jan 2007 10:18:03 -0500 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; Sat, 06 Jan 2007 17:17:49 +0200 id 000AFD29.459FBD9D.00001B94 Date: Sat, 6 Jan 2007 17:17:48 +0200 (EET) From: Jukka MJ Manner To: john.loughney@nokia.com Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_courier-7114-1168096679-0001-2" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 Cc: gash@att.com, karagian@cs.utwente.nl, oran@cisco.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 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-7114-1168096679-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 Hi John, That is actually a good point. So far I have hoped that we can clearly de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP implementation can run with all different RMFs and QOSMs. If a QOSM affects the common message processing, we need different implementations. Yet, I guess this also applies to various tunneling, session binding, and separate signaling sessions that might be used with= in a domain. Do we need to document how the RMF and QoS NSLP fit together, what is passed between the RMF and NSLP, what are the API issues, what kind on asymmetric triggers the RMF can send to the NSLP, etc. I think we need t= o write such a draft, and document all the interactions. If we have that written down, we can more easily define what is a standards-compliant implementation of a QOSM/RMF, and what is not. If you think that would be good, I could write a first draft. Jukka On Sat, 6 Jan 2007, john.loughney@nokia.com wrote: > Hi all, > > My bigger concern is - how will implementations work? Will we need 2 > completely different implementations to work in different scenarios? > What is the reuse of implementations conforming to the base Qos NSLP > spec? > > I agree with Dave's point: > > > I think the constraints are stronger than this, if you want the doma= in-local > > elements to be able to claim conformance to the QOS NSLP specificati= on. If not, > > the entire argument is moot, since then your domain-local signaling = is > > completely proprietary and non-standard. > > John > > > >-----Original Message----- > >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >Sent: 05 January, 2007 19:53 > >To: Georgios Karagiannis > >Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; Loughney John > >(Nokia-NRC/PaloAlto); 'Ash, Gerald R \\\(Jerry\\\), ALABS'; > >nsis@ietf.org > >Subject: RE: [NSIS] Consensus on: Removed the QSPEC control informati= on > > > > > >Good. Then I don't see what the problem is. The e2e semantics > >of the NSLP messaging are preserved, and the request by the > >QNI is supported (provided the resources are there). > > > >Jukka > > > >On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > > > >> Hi Jukka > >> > >> > I would expect the same goes with the NSLP, ie., if RMD > >changes the > >> > NSLP message processing in some way, it can do so, but > >only for the > >> > local domain, without affecting any QNEs (incld QNI and > >QNR) outside > >> > the RMD domain). And this must still preserve the e2e messaging > >> > semantics. > >> > >> Agreed, the change in the NSLP message processing holds only for th= e > >> QNEs within the local domain, not outside the domain. > >> > >> > >> Best regards, > >> Georgios > >> > >> > >> > -----Original Message----- > >> > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >> > Sent: vrijdag 5 januari 2007 18:33 > >> > To: Georgios Karagiannis > >> > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; 'John > >Loughney'; 'Ash, > >> > Gerald R \(Jerry\), ALABS'; nsis@ietf.org > >> > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > >> > information > >> > > >> > > >> > Hi Georgios, > >> > > >> > I guess new QSPEC objects could be allowed > >> > > >> > a) flexibly if their are only used within the local > >domain, and not > >> > e2e (which would require all QNEs to be upgraded), > >> > > >> > b) through NSLP standards action, if they need to be understood b= y > >> > all > >> > QNEs on the e2e path. > >> > > >> > > >> > I would expect the same goes with the NSLP, ie., if RMD > >changes the > >> > NSLP message processing in some way, it can do so, but > >only for the > >> > local domain, without affecting any QNEs (incld QNI and > >QNR) outside > >> > the RMD domain). And this must still preserve the e2e messaging > >> > semantics. > >> > > >> > Jukka > >> > > >> > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > >> > > >> > > Hi Jukka > >> > > > >> > > What I meant are your following statements: > >> > > " A certain domain running a QOSM X can well do certain > >> > optimizations, > >> > > incl. separate signaling sessions and aggregation, provided tha= t > >> > > > >> > > 1) it fulfils the original request of the QNIs, and > >> > > > >> > > 2) the end-to-end semantic and the end-to-end QoS NSLP > >> > messaging by the > >> > > QNI, or any peer QNE are preserved. > >> > > > >> > > Within those bounds a QOSM must operate, incl. any > >domain internal > >> > > optimized signaling." > >> > > > >> > > > >> > > Of course no additional QoS-NSLP messages and QOS-NSLP > >> > objects can be > >> > > defined by the QOS model. What a QOS model should be able > >> > to do is to > >> > > define new QSPEC objects and to define how the QOS-NSLP > >> > siganling in > >> > > the domains internal, as you suggested under certain bounds, ca= n > >> > > be optimized. > >> > > > >> > > Best Regards, > >> > > Georgios > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >> > > > Sent: vrijdag 5 januari 2007 18:06 > >> > > > To: Georgios Karagiannis > >> > > > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; John > >Loughney; Ash, > >> > > > Gerald R (Jerry), ALABS; nsis@ietf.org > >> > > > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > >> > > > information > >> > > > > >> > > > > >> > > > Hi Georgios, > >> > > > > >> > > > I didn't imply that the constraints would include > >> > defining some new > >> > > > NSLP messages, or other things that are not already > >part of the > >> > > > QSPEC, or the NSLP. > >> > > > > >> > > > Yet, a QOS Model might e.g., define new INFO_SPEC > >> > error/info codes, > >> > > > or a new object within the QSPEC, but I guess those would > >> > > > require standards action, and a standards track RFC. > >> > > > > >> > > > A QOS Model should not change the end-to-end semantics of > >> > the NSLP, > >> > > > or of the QSPEC - this is what I wrote. > >> > > > > >> > > > > >> > > > I haven't read lately the RMD spec, so I don't know > >what are the > >> > > > functionality that are introduced in addition to what is > >> > already in > >> > > > the QSPEC and the NSLP. > >> > > > > >> > > > Cheers, > >> > > > Jukka > >> > > > > >> > > > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > >> > > > > >> > > > > Hi Dave > >> > > > > > >> > > > > But I think that Jukka emphasized that it does not > >need to be > >> > > > > a standards track if it complies to: > >> > > > > * the constraints specified in the QOS-NSLP document (see > >> > > > Jukkas proposal), > >> > > > > and of course if the QOS model draft is approved by the > >> > IESG for > >> > > > > publication. > >> > > > > > >> > > > > > >> > > > > Best regards, > >> > > > > Georgios > >> > > > > > >> > > > > > >> > > > > > -----Original Message----- > >> > > > > > From: David R Oran [mailto:oran@cisco.com] > >> > > > > > Sent: vrijdag 5 januari 2007 16:02 > >> > > > > > To: Attila B=E1der (IJ/ETH) > >> > > > > > Cc: john.loughney@nokia.com; gash@att.com; nsis@ietf.org > >> > > > > > Subject: Re: [NSIS] Consensus on: Removed the > >QSPEC control > >> > > > > > information > >> > > > > > > >> > > > > > > >> > > > > > On Jan 5, 2007, at 9:02 AM, Attila B=E1der (IJ/ETH) wrote= : > >> > > > > > > >> > > > > > > Hi John, > >> > > > > > > > >> > > > > > > I disagree, I think the right approach is what > >Yukka sent. > >> > > > > > > > >> > > > > > >>> > >> > > > > > > "The end-to-end semantic and QoS NSLP messaging by the > >> > > > QNI, or any > >> > > > > > > peer QNE MUST BE preserved, and within those > >bounds a QOSM > >> > > > > > > must operate." > >> > > > > > > > >> > > > > > > This means that e.g., > >> > > > > > > a) The resource request by the QNI and response from > >> > > > the QNR must be > >> > > > > > > followed and passed through intact by a QOSM X domai= n, > >> > > > > > > b) confirmation requests must be answered, > >> > > > > > > c) tear-down must be followed, etc. " > >> > > > > > >>> > >> > > > > > > > >> > > > > > > I think QoS NSLP operation can be extended in a local > >> > > > QoS domain > >> > > > > > > without distroying e2e QoS-NSLP operation. > >> > > > > > > > >> > > > > > John L. seemed to be of the view that if a particular > >> > > > > > domain-loal QoS scheme (e.g. RMD) wants to use > >> > QoS-NSLP for its > >> > > > > > local scheme, then it is free to modify it if and > >> > only if there > >> > > > > > is a standards track RFC documenting the > >extensions/changes. > >> > > > > > This represents my view as well. > >> > > > > > This is the only way we can ascertain upwards/downwards > >> > > > > > compatibility and interoperability. Otherwise what > >you would > >> > > > > > have is a completely private signaling scheme which claim= s > >> > > > > > conformance to a standard. > >> > > > > > > >> > > > > > These QoS-NSLP extensions would have no effect on > >the QSPEC > >> > > > > > specification, unless the QSPEC itself is being > >extended, in > >> > > > > > which case I think it's still an open issue whether > >> > or not you > >> > > > > > need a standards track RFC for that. My guess would > >> > be yes if we > >> > > > > > adopt Yukka's encoding scheme (because otherwise you > >> > could not > >> > > > > > find or debug the end-to-end QSPEC when embedded in > >> > an extended > >> > > > > > local QSPEC), but possibly no if we adopt a more layered > >> > > > > > encoding like QSPEC stacking (so that the parser > >has a known > >> > > > > > regular encoding structure to deal with). > >> > > > > > > >> > > > > > Cheers, Dave. > >> > > > > > > >> > > > > > > Best regards, Attila > >> > > > > > > > >> > > > > > > > >> > > > > > >> -----Original Message----- > >> > > > > > >> From: john.loughney@nokia.com > >> > > > > > >> [mailto:john.loughney@nokia.com] > >> > > > > > >> Sent: Friday, January 05, 2007 1:54 PM > >> > > > > > >> To: gash@att.com; nsis@ietf.org > >> > > > > > >> Subject: [NSIS] Consensus on: Removed the QSPEC > >> > > > control information > >> > > > > > >> > >> > > > > > >> > >> > > > > > >>>> Point_1):Removed the QSPEC control information > >> > > > > > >>>> > >> > > > -------------------------------------------------------------= -- > >> > > > > > >>>> Jerry mentioned in a previous e-mail that this QSPEC= > >> > > > > > >>>> control information concept is not removed but it is= > >> > > > > > >>>> renamed > >> > > > to Traffic > >> > > > > > >>>> Handling Directives. > >> > > > > > >>>> > >> > > > > > >>>> If that is the case then Jerry will have to use the > >> > > > > > >>>> same > >> > > > > > >> definitions > >> > > > > > >>>> for the QSPEC control information as used in Section > >> > > > 5.3.1 of: > >> > > > > > >>>> > >> > > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.t= xt > >> > > > > > >>>> > >> > > > > > >>>> Thus my proposal is to change section 4.3.3 > >as given in > >> > > > > > v.13 of the > >> > > > > > >>>> QSPEC template draft and include the general > >concept of > >> > > > > > the QSPEC > >> > > > > > >>>> control information that was given in Section 5.3.1 = of > >> > > > > > >> version 12 of > >> > > > > > >>>> the QSPEC template draft. Note that the name can be > >> > > > > > changed but the > >> > > > > > >>>> semantics should remain the same. Thus please change= > >> > > > > > >>>> Section > >> > > > > > >>> 4.3.3 as > >> > > > > > >>>> follows: > >> > > > > > >>>> > >> > > > > > >>>> FROM: > >> > > > > > >>>> > >> > > > > > >>>> 4.3.3 Traffic Handling Directives > >> > > > > > >>>> > >> > > > > > >>>> The parameter describes how > >> > > > the QNE will > >> > > > > > >> process > >> > > > > > >>>> excess traffic, that is, out-of-profile traffic. = > >> > > > > > Excess traffic > >> > > > > > >> MAY > >> > > > > > >>>> be dropped, shaped and/or remarked. The > >> > excess treatment > >> > > > > > >> parameter > >> > > > > > >> is > >> > > > > > >>>> initially set by the QNI and cannot be overwritte= n. > >> > > > > > >>>> > >> > > > > > >>>> INTO: > >> > > > > > >>>> > >> > > > > > >>>> 4.3.3 Traffic Handling Directives > >> > > > > > >>>> > >> > > > > > >>>> Traffic Handling Directives are used for > >> > signaling QOSM > >> > > > > > >>>> RMF functions > >> > > > > > >>>> not defined in QoS NSLP. It enables building new= > >> > > > > > >>>> RMF > >> > > > > > functions > >> > > > > > >>>> required by a QOSM within a QoS NSLP signaling > >> > > > > > framework, such > >> > > > > > >>>> as > >> > > > > > >>>> specified, for example, in [RMD-QOSM] and > >> > [Y.1541-QOSM]. > >> > > > > > >>> > >> > > > > > >>> I think most (perhaps all?) of us agree on this > >> > > > point: the QOSM > >> > > > > > >>> specification SHOULD NOT be allowed to define 'new > >> > > > RMF functions > >> > > > > > >>> required by a QOSM' UNLESS such NSIS signaling > >> > functionality > >> > > > > > >> is defined > >> > > > > > >>> in QoS NSLP. I.e., a QOSM is not allowed to > >> > extend QoS NSLP > >> > > > > > >> signaling > >> > > > > > >>> functionality. The above text seems to abide by > >> > the premise > >> > > > > > >> by stating > >> > > > > > >>> that new RMF functions are specified only 'within > >> > a QoS NSLP > >> > > > > > >> signaling > >> > > > > > >>> framework'. If so, I think we're in agreement. > >> > > > > > >> > >> > > > > > >> I agree with Jerry's text, and I believe we have rough > >> > > > > > consensus on > >> > > > > > >> this. > >> > > > > > >> If anyone disagrees with consensus, a short mail > >> > > > stating that you > >> > > > > > >> disagree is needed. > >> > > > > > >> > >> > > > > > >> On point, in order to extend QoS NSLP signaling, a > >> > > > Standards Track > >> > > > > > >> RFC is needed. > >> > > > > > >> > >> > > > > > >> 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 > >> > > > > > > >> > > > > > _______________________________________________ > >> > > > > > 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 > >> > > > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > >> > >> > > > --=_courier-7114-1168096679-0001-2 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 --=_courier-7114-1168096679-0001-2-- From nsis-bounces@ietf.org Sun Jan 07 18:43:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3hf0-0003HK-0S; Sun, 07 Jan 2007 18:42:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3hey-0003HF-Tw for nsis@ietf.org; Sun, 07 Jan 2007 18:42:40 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3hex-0005Al-4S for nsis@ietf.org; Sun, 07 Jan 2007 18:42:40 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1H3hef-0005SR-Fy; Mon, 08 Jan 2007 00:42:26 +0100 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1H3hee-00030D-US; Mon, 08 Jan 2007 00:42:20 +0100 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 F0310B5A8; Mon, 8 Jan 2007 00:42:19 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1H3hed-0007xN-EK; Mon, 08 Jan 2007 00:42:19 +0100 Message-ID: <45A18575.4050806@tm.uka.de> Date: Mon, 08 Jan 2007 00:42:45 +0100 From: Roland Bless User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.9) Gecko/20061206 Thunderbird/1.5.0.9 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP v. "13-pre1" References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) 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.4 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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 and all, Jukka MJ Manner wrote: > I sent the following request for feedback two weeks ago. No comments have > been raised. I will wait until this Friday, then submit the draft. Sorry for being so late...here some comments (including nits). > 3.2.5. Reduced Refreshes > > For scalability, the QoS NSLP supports an abbreviated form of refresh > RESERVE message. In this case, the refresh RESERVE references the > reservation using the RSN and the SESSION_ID, and does not include > the full reservation specification (including QSPEC). By default > state refresh should be performed with reduced refreshes in order to > save bytes on the wire. Stateless QNEs will require full refresh ^^^^ because this is especially interesting for wireless users, I would prefer something like: "save bytes during transmission." > since they do not store the whole reservation information. > > If the QNE does not support reduced refreshes, or there is a mismatch > between the local and received RNS, the QNE must reply with an ^^^ RSN > RESPONSE carrying an INFO_SPEC indicating the error. and the QNE should stop sending reduced refreshes to this peer if the error indicates lacking support for this feature. > 3.2.6. Summary Refreshes and Summary Tear > > For limiting the number of individual messages, the QoS NSLP supports > a summary refresh and summary tear messages. When sending a > refreshing RESERVE for a certain (primary) session, a QNE may include > a SESSION_ID_LIST object where the QNE indicates (secondary) sessions > that are also refreshed. An RSN_LIST object must also be added. The > SESSION IDs and RSNs are stacked in the objects such that the index > in both stacks refer to the same reservation state, i.e., the > SESSION_ID and RSN at index i in both objects refers to the same > session. If the receiving QNE noticies unknown SESSION IDs or a ^^^^^^^^ notices > mismatch with RSNs for a session, it will reply back to the upstream > QNE with an error. > > In order to tear down several sessions at once, a QNE may include a > SESSION_ID_LIST object in a tearing reserve. The downstream QNE must > then also tear the other sessions indicated. No RSN_LIST is sent. The > downstream QNE must silently ignore any unknown SESSION IDs. [maybe a little more rationale why RSNs are useless for tearing reserves: in case of mismatching RSNs a resynchronization of reservation state prior to teardown is useless.] > GIST provides a SII_HANDLE for every downstream session. The > SII_HANDLE identifies a peer, and should be the same for all sessions > whose downstream peer is the same. The QoS NSLP uses this information > to decide when summary refresh messages can be sent, or when a ^^^^ better: if/whether ^^^^ (in contrast to the point in time) > summary tear is possible. > 5.1.1. Common Header > ... > Generic flags: 16 bits > > Generic flags have the same meaning for all message types. There > exists currently three generic flag, the (next hop) Scoping flag ^^^^^^exist ^^^^flags > (S), and the Proxy scope flag (P). > The ACK flag is usefull when a QNE wants to make sure the messages ^^^^^^^ was already mentioned by Andrew > received by the downstream QNE are truly processed, even when GIST > continues to work. This is usefull for faster dead peer diagnostics > on the NSLP layer. Reliable transmission of messages between two QoS > NSLP peer should be handled by GIST, not the NSLP by itself. [we must detail somewhere how a missing acknowledgment is detected, esp. how to determine the timeout] That means a missing acknowledgment is not used to trigger retransmissions but to detect a dead peer. > or MAY use the Ack-flag to request confirmation from the downstream This sounds like using ACKs for reliable transmission, and thus contradicts the previous statement. > peer. When the QNE sends out a tearing RESERVE, it MUST NOT send > 5.1.3.6. Information Object (INFO_SPEC) and Error Codes > * 0x04 - Congestion situation: Possible congestion situation > ocurred on downstream path. ^^^^^^^ occurred > * 0x06 - Mismatch in RSN in RSN LIST Should be (?): Mismatching RSN in RSN List > * 0x01 - Reservation succesful ^^^^^^^^^successful > * 0x02 - Tear down succesful ^^^^^^^^^successful > * 0x08 - Path truncated * 0x08 - Path truncated - Next Peer Dead > 5.2.4. Retransmissions > > Retransmissions may happen end-to-end, e.g., between QNI and QNR > (using an RII object), or peer-to-peer, between two adjacent QNEs. > When a QNE transmits a RESERVE with an RII object set, it waits for a > RESPONSE from the responding QNE. QoS NSLP messages for which a > response is requested by including an RII object, but fail to elicit > a response are retransmitted. Similarly, a QNE may include the ACK- > flag to request confirmation of message reception from its immediate > peer. > The initial retransmission occurs after a QOSNSLP_REQUEST_RETRY wait > period. Retransmissions MUST be made with exponentially increasing > wait intervals (doubling the wait each time). QoS NSLP messages > SHOULD be retransmitted until either a RESPONSE (which might be an > error) has been obtained, or until QOSNSLP_RETRY_MAX seconds after > the initial transmission. In the latter case, a failure SHOULD be > indicated to the signaling application. The default values for the > above-mentioned timers are: > > QOSNSLP_REQUEST_RETRY: 2 seconds Wait interval before initial > retransmit of the message > > QOSNSLP_RETRY_MAX: 30 seconds Give up retrying to send the > message > > Retransmissions SHOULD be disabled for tear messages. I'm not very lucky with this, esp. with respect to interference of e2e retransmission and peer to peer retransmission due to ACKs. I'm fine with the e2e RII mechanism. However, the ACK mechanism for dead peer detection will probably interfere with this. I'll see the following points: - if a msg with ACK flag set is sent, an acknowledgment (Success/0x03, usually without any QSPEC) is expected. A suitable timeout period must be determined. - the acknowledgment may not arrive within the expected time, either due to: - loss of the original msg - loss of the acknowledgment msg - high delay due to processing overload at the peer the first two possibilities will not apply if reliable transport is required from GIST. So in this case QOSNSLP_REQUEST_RETRY/2 may be fine to indicate a problem. False alarms may still occur due to the last issue, however. - In case of unreliable GIST transport, I'm not convinced that having another retransmission mechanism is the right thing... So, it would probably be a good idea to add an explicit liveliness test message (Hello) and either drop the ACK mechanism and use the liveliness test message instead, or, to keep the ACK mechanism and use an explicit liveliness test message if the acknowledgment didn't arrive within the expected time frame. For instance, if the acknowledgment did not arrive within 1s, the QNE will send a Hello message that should be answered immediately by the other peer. It may be retransmitted, too. As we discussed at the last meeting (not in the official WG meeting, but in the hallway) the original idea of the ACK was to detect a situation when a QNE keeps sending refresh messages but doesn't notice when the QoS NSLP at the next peer crashed (maybe we should described this situation as rationale). However, refreshes are not (usually) not sent end to end. So if we restrict the ACK flag usage to refreshing RESERVEs between peers only, we have no interference problem. > 5.3.1. Reservation Sequence Number (RSN) > the new reservation. If the RNS is greater than the current stored ^^^ RSN > value and the RESERVE was a reduced refresh, the QNE SHOULD send > upstream a error message "Full QSPEC required". ^ transient. Any suggestions? Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jan 07 23:46:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3mOl-00072N-4A; Sun, 07 Jan 2007 23:46:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3mOk-00072F-2a for nsis@ietf.org; Sun, 07 Jan 2007 23:46:14 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3mOi-0005N7-KV for nsis@ietf.org; Sun, 07 Jan 2007 23:46:14 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l084hvZ0020811; Mon, 8 Jan 2007 06:44:19 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 06:45:50 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 06:45:48 +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] Consensus on: Removed the QSPEC control information Date: Mon, 8 Jan 2007 06:45:48 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Consensus on: Removed the QSPEC control information Thread-Index: AccxpdhtpWIdTtk4TXWQGrT1v/0TdQBOeYyg From: To: X-OriginalArrivalTime: 08 Jan 2007 04:45:48.0980 (UTC) FILETIME=[DE2AEF40:01C732DF] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: gash@att.com, karagian@cs.utwente.nl, oran@cisco.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 Hi Jukka, >That is actually a good point. So far I have hoped that we can=20 >clearly de-couple QSPEC+RMF and the NSLP, and therefore a=20 >single NSLP implementation can run with all different RMFs and QOSMs. I think that is a good goal. >If a QOSM affects the common message processing, we need=20 >different implementations. Yet, I guess this also applies to=20 >various tunneling, session binding, and separate signaling=20 >sessions that might be used within a domain. I agree. >Do we need to document how the RMF and QoS NSLP fit together,=20 >what is passed between the RMF and NSLP, what are the API=20 >issues, what kind on asymmetric triggers the RMF can send to=20 >the NSLP, etc. I think we need to write such a draft, and=20 >document all the interactions. If we have that written down,=20 >we can more easily define what is a standards-compliant=20 >implementation of a QOSM/RMF, and what is not. > >If you think that would be good, I could write a first draft. I think this is a good idea for a draft, and probably QoSM documents might need to have some of this information, as it specifically=20 applies for the specific QoSM. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 08 03:45:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3q80-0000Ss-Od; Mon, 08 Jan 2007 03:45:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3q7z-0000Sn-Lr for nsis@ietf.org; Mon, 08 Jan 2007 03:45:11 -0500 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 1H3q7w-00083I-Tp for nsis@ietf.org; Mon, 08 Jan 2007 03:45:11 -0500 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; Mon, 08 Jan 2007 10:45:01 +0200 id 000AFDB5.45A2048D.00001654 Date: Mon, 8 Jan 2007 10:45:01 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] QoS NSLP v. "13-pre1" In-Reply-To: <45A18575.4050806@tm.uka.de> Message-ID: References: <45A18575.4050806@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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 Roland, thank you for the input. About the ack-functionality, I thought it was only meant between peers. If a peer receives a refresh with the ack-flag, it is a policy decision, whether it will also send its next own refresh with the ack-flag, thus, committing to checking the whole path is still intact. Yet, we do have the RII-mechanism, where by introducing the RII, a QNE can request confirmation for its message. This could also be used to make a separate e2e refresh and confirm the state reservation is valid e2e. Jukka On Mon, 8 Jan 2007, Roland Bless wrote: > Hi Jukka and all, > > Jukka MJ Manner wrote: > > I sent the following request for feedback two weeks ago. No comments have > > been raised. I will wait until this Friday, then submit the draft. > > Sorry for being so late...here some comments (including nits). > > > 3.2.5. Reduced Refreshes > > > > For scalability, the QoS NSLP supports an abbreviated form of refresh > > RESERVE message. In this case, the refresh RESERVE references the > > reservation using the RSN and the SESSION_ID, and does not include > > the full reservation specification (including QSPEC). By default > > state refresh should be performed with reduced refreshes in order to > > save bytes on the wire. Stateless QNEs will require full refresh > ^^^^ > because this is especially interesting for wireless users, I would > prefer something like: "save bytes during transmission." > > > since they do not store the whole reservation information. > > > > If the QNE does not support reduced refreshes, or there is a mismatch > > between the local and received RNS, the QNE must reply with an > ^^^ RSN > > RESPONSE carrying an INFO_SPEC indicating the error. > > and the QNE should stop sending reduced refreshes to this > peer if the error indicates lacking support for this feature. > > > > 3.2.6. Summary Refreshes and Summary Tear > > > > For limiting the number of individual messages, the QoS NSLP supports > > a summary refresh and summary tear messages. When sending a > > refreshing RESERVE for a certain (primary) session, a QNE may include > > a SESSION_ID_LIST object where the QNE indicates (secondary) sessions > > that are also refreshed. An RSN_LIST object must also be added. The > > SESSION IDs and RSNs are stacked in the objects such that the index > > in both stacks refer to the same reservation state, i.e., the > > SESSION_ID and RSN at index i in both objects refers to the same > > session. If the receiving QNE noticies unknown SESSION IDs or a > ^^^^^^^^ notices > > mismatch with RSNs for a session, it will reply back to the upstream > > QNE with an error. > > > > In order to tear down several sessions at once, a QNE may include a > > SESSION_ID_LIST object in a tearing reserve. The downstream QNE must > > then also tear the other sessions indicated. No RSN_LIST is sent. The > > downstream QNE must silently ignore any unknown SESSION IDs. > > [maybe a little more rationale why RSNs are useless for tearing > reserves: in case of mismatching RSNs a resynchronization of > reservation state prior to teardown is useless.] > > > GIST provides a SII_HANDLE for every downstream session. The > > SII_HANDLE identifies a peer, and should be the same for all sessions > > whose downstream peer is the same. The QoS NSLP uses this information > > to decide when summary refresh messages can be sent, or when a > ^^^^ better: if/whether ^^^^ > (in contrast to the point in time) > > summary tear is possible. > > > 5.1.1. Common Header > > ... > > Generic flags: 16 bits > > > > Generic flags have the same meaning for all message types. There > > exists currently three generic flag, the (next hop) Scoping flag > ^^^^^^exist ^^^^flags > > (S), and the Proxy scope flag (P). > > > > The ACK flag is usefull when a QNE wants to make sure the messages > ^^^^^^^ was already mentioned by Andrew > > received by the downstream QNE are truly processed, even when GIST > > continues to work. This is usefull for faster dead peer diagnostics > > on the NSLP layer. Reliable transmission of messages between two QoS > > NSLP peer should be handled by GIST, not the NSLP by itself. > > [we must detail somewhere how a missing acknowledgment is detected, > esp. how to determine the timeout] > That means a missing acknowledgment is not used to trigger > retransmissions but to detect a dead peer. > > > or MAY use the Ack-flag to request confirmation from the downstream > > This sounds like using ACKs for reliable transmission, and thus > contradicts the previous statement. > > peer. When the QNE sends out a tearing RESERVE, it MUST NOT send > > > 5.1.3.6. Information Object (INFO_SPEC) and Error Codes > > > * 0x04 - Congestion situation: Possible congestion situation > > ocurred on downstream path. > ^^^^^^^ occurred > > * 0x06 - Mismatch in RSN in RSN LIST > Should be (?): Mismatching RSN in RSN List > > > * 0x01 - Reservation succesful > ^^^^^^^^^successful > > * 0x02 - Tear down succesful > ^^^^^^^^^successful > > > * 0x08 - Path truncated > * 0x08 - Path truncated - Next Peer Dead > > > > 5.2.4. Retransmissions > > > > Retransmissions may happen end-to-end, e.g., between QNI and QNR > > (using an RII object), or peer-to-peer, between two adjacent QNEs. > > When a QNE transmits a RESERVE with an RII object set, it waits for a > > RESPONSE from the responding QNE. QoS NSLP messages for which a > > response is requested by including an RII object, but fail to elicit > > a response are retransmitted. Similarly, a QNE may include the ACK- > > flag to request confirmation of message reception from its immediate > > peer. > > > The initial retransmission occurs after a QOSNSLP_REQUEST_RETRY wait > > period. Retransmissions MUST be made with exponentially increasing > > wait intervals (doubling the wait each time). QoS NSLP messages > > SHOULD be retransmitted until either a RESPONSE (which might be an > > error) has been obtained, or until QOSNSLP_RETRY_MAX seconds after > > the initial transmission. In the latter case, a failure SHOULD be > > indicated to the signaling application. The default values for the > > above-mentioned timers are: > > > > QOSNSLP_REQUEST_RETRY: 2 seconds Wait interval before initial > > retransmit of the message > > > > QOSNSLP_RETRY_MAX: 30 seconds Give up retrying to send the > > message > > > > Retransmissions SHOULD be disabled for tear messages. > > I'm not very lucky with this, esp. with respect to > interference of e2e retransmission and peer to peer > retransmission due to ACKs. I'm fine with the e2e RII > mechanism. However, the ACK mechanism for dead peer > detection will probably interfere with this. > I'll see the following points: > - if a msg with ACK flag set is sent, an acknowledgment > (Success/0x03, usually without any QSPEC) is expected. > A suitable timeout period must be determined. > - the acknowledgment may not arrive within the expected > time, either due to: > - loss of the original msg > - loss of the acknowledgment msg > - high delay due to processing overload at the peer > the first two possibilities will not apply if > reliable transport is required from GIST. > So in this case QOSNSLP_REQUEST_RETRY/2 may be > fine to indicate a problem. False alarms may still > occur due to the last issue, however. > - In case of unreliable GIST transport, I'm not > convinced that having another retransmission > mechanism is the right thing... > > So, it would probably be a good idea to add > an explicit liveliness test message (Hello) and either > drop the ACK mechanism and use the liveliness test > message instead, or, to keep the ACK mechanism and > use an explicit liveliness test message if the > acknowledgment didn't arrive within the expected > time frame. For instance, if the acknowledgment > did not arrive within 1s, the QNE will send a > Hello message that should be answered immediately > by the other peer. It may be retransmitted, too. > > As we discussed at the last meeting (not in the official > WG meeting, but in the hallway) the original idea of the ACK > was to detect a situation when a QNE keeps sending refresh > messages but doesn't notice when the QoS NSLP at the next peer > crashed (maybe we should described this situation as rationale). > However, refreshes are not (usually) not sent end to > end. So if we restrict the ACK flag usage to refreshing RESERVEs > between peers only, we have no interference problem. > > > 5.3.1. Reservation Sequence Number (RSN) > > > the new reservation. If the RNS is greater than the current stored > ^^^ RSN > > value and the RESERVE was a reduced refresh, the QNE SHOULD send > > upstream a error message "Full QSPEC required". > ^ transient. > > Any suggestions? > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 08 04:32:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3qr3-0005Oq-4D; Mon, 08 Jan 2007 04:31:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3qr0-0005Oh-Km for nsis@ietf.org; Mon, 08 Jan 2007 04:31:42 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3qql-0005Ce-Fz for nsis@ietf.org; Mon, 08 Jan 2007 04:31:42 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l089UxBM016925; Mon, 8 Jan 2007 10:31:03 +0100 (MET) From: "Georgios Karagiannis" To: , Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Date: Mon, 8 Jan 2007 10:31:04 +0100 Message-ID: <000901c73307$bb20dff0$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccxpdhtpWIdTtk4TXWQGrT1v/0TdQBOeYygAAnI8mA= X-Spam-Score: 0.555 () AWL,FVGT_s_OBFU_Q1,J_CHICKENPOX_53 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 08 Jan 2007 10:31:04 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: gash@att.com, oran@cisco.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 Hi John and Jukka I think that the idea of writting such a draft is a very good point! As an example the RMD-QOSM affects the common message processing, and therefore we need different implementations. This applies to various tunneling, session binding, and separate signaling sessions (such as refresh, release, Unsuccessful resdervations, bi-directional reservations, severe congestion handling, congestion notification handling, etc.) that can be used within a domain. It will be great to have such a draft andf I would very much like to help Jukka, if Jukka agrees, on writting it! Best Regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: maandag 8 januari 2007 5:46 > To: jmanner@cs.Helsinki.FI > Cc: karagian@cs.utwente.nl; oran@cisco.com; > attila.bader@ericsson.com; gash@att.com; nsis@ietf.org > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > information > > Hi Jukka, > > >That is actually a good point. So far I have hoped that we > can clearly > >de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP > >implementation can run with all different RMFs and QOSMs. > > I think that is a good goal. > > >If a QOSM affects the common message processing, we need different > >implementations. Yet, I guess this also applies to various > tunneling, > >session binding, and separate signaling sessions that might be used > >within a domain. > > I agree. > > >Do we need to document how the RMF and QoS NSLP fit > together, what is > >passed between the RMF and NSLP, what are the API issues, > what kind on > >asymmetric triggers the RMF can send to the NSLP, etc. I > think we need > >to write such a draft, and document all the interactions. If we have > >that written down, we can more easily define what is a > >standards-compliant implementation of a QOSM/RMF, and what is not. > > > >If you think that would be good, I could write a first draft. > > I think this is a good idea for a draft, and probably QoSM > documents might need to have some of this information, as it > specifically applies for the specific QoSM. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 08 05:42:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3rxP-0004Ry-U9; Mon, 08 Jan 2007 05:42:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3rxP-0004Rt-2G for nsis@ietf.org; Mon, 08 Jan 2007 05:42:23 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3rxN-0007t9-L3 for nsis@ietf.org; Mon, 08 Jan 2007 05:42:23 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1H3rxG-0005ML-DO; Mon, 08 Jan 2007 11:42:21 +0100 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 053CFA810; Mon, 8 Jan 2007 11:42:14 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1H3rxF-0000W1-HS; Mon, 08 Jan 2007 11:42:13 +0100 Message-ID: <45A22005.2040603@tm.uka.de> Date: Mon, 08 Jan 2007 11:42:13 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP v. "13-pre1" References: <45A18575.4050806@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) 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.4 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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, Jukka MJ Manner wrote: > About the ack-functionality, I thought it was only meant between peers. If > a peer receives a refresh with the ack-flag, it is a policy decision, > whether it will also send its next own refresh with the ack-flag, thus, > committing to checking the whole path is still intact. I'm not questioning this behavior. It is clear that the ACK mechanism is only used between directly adjacent peers. What I'm asking is whether the ACK mechanism is limited to refreshes only. Otherwise we run into problems, e.g.: a non-refreshing RESERVE arrives with an RII at a QNE and is now forwarded with an additionally set ACK flag. Then the QNE must retransmit this message if it receives no acknowledgment for the ACK from its peer. Simultaneously, there is a retransmission mechanism at the QNI/QNE that will be triggered by the missing e2e response requested by the RII. And I see problems in this particular situation. > Yet, we do have the RII-mechanism, where by introducing the RII, a QNE can > request confirmation for its message. This could also be used to make a > separate e2e refresh and confirm the state reservation is valid e2e. If we restrict the ACK flag use to refreshing RESERVEs, this would be ok. Then we would IMHO have the following: If a QNE decides to set an ACK flag for a refreshing RESERVE (it need not be set for every refreshing message), it will trigger the same retransmission algorithm described in sec. 5.2.4, which is used by QNEs that set an RII. After QOSNSLP_RETRY_MAX it will give up and send the Path truncated notification upstream. The ACK flag must not be set for e2e refreshing RESERVEs that include already an RII. One further issue: I would like to see a different name for the ACK flag. Actually, it is an ACK _request_ flag since it asks the peer to send back an ACK. If you think about TCPs definition and use of an ACK flag people may get easily confused. So probably calling it ACR or AKR would be clearer. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 08 06:39:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3sqn-0002pS-Mz; Mon, 08 Jan 2007 06:39:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3sqm-0002pI-6X for nsis@ietf.org; Mon, 08 Jan 2007 06:39:36 -0500 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 1H3sqk-0007Vh-Ew for nsis@ietf.org; Mon, 08 Jan 2007 06:39:36 -0500 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; Mon, 08 Jan 2007 13:34:22 +0200 id 000AFF6C.45A22C3E.000009A4 Date: Mon, 8 Jan 2007 13:34:22 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] QoS NSLP v. "13-pre1" In-Reply-To: <45A22005.2040603@tm.uka.de> Message-ID: References: <45A18575.4050806@tm.uka.de> <45A22005.2040603@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Roland, thanks for clarifications and further suggestions. I agree with all of them. Jukka On Mon, 8 Jan 2007, Roland Bless wrote: > Hi Jukka, > > Jukka MJ Manner wrote: > > About the ack-functionality, I thought it was only meant between peers. If > > a peer receives a refresh with the ack-flag, it is a policy decision, > > whether it will also send its next own refresh with the ack-flag, thus, > > committing to checking the whole path is still intact. > > I'm not questioning this behavior. It is clear that the ACK mechanism is > only used between directly adjacent peers. What I'm asking is whether > the ACK mechanism is limited to refreshes only. Otherwise we run > into problems, e.g.: a non-refreshing RESERVE arrives with an RII > at a QNE and is now forwarded with an additionally set ACK flag. > Then the QNE must retransmit this message if it receives no > acknowledgment for the ACK from its peer. Simultaneously, there is > a retransmission mechanism at the QNI/QNE that will be triggered by the > missing e2e response requested by the RII. And I see problems > in this particular situation. > > > Yet, we do have the RII-mechanism, where by introducing the RII, a QNE can > > request confirmation for its message. This could also be used to make a > > separate e2e refresh and confirm the state reservation is valid e2e. > > If we restrict the ACK flag use to refreshing RESERVEs, this would > be ok. Then we would IMHO have the following: > If a QNE decides to set an ACK flag for a refreshing RESERVE > (it need not be set for every refreshing message), it will > trigger the same retransmission algorithm described in sec. 5.2.4, > which is used by QNEs that set an RII. After QOSNSLP_RETRY_MAX > it will give up and send the Path truncated notification upstream. > The ACK flag must not be set for e2e refreshing RESERVEs that > include already an RII. > > One further issue: > I would like to see a different name for the ACK flag. Actually, it is > an ACK _request_ flag since it asks the peer to send back an ACK. > If you think about TCPs definition and use of an ACK flag > people may get easily confused. So probably calling it ACR or AKR would > be clearer. > > Regards, > Roland > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 08 07:23:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3tX9-0007Pj-Il; Mon, 08 Jan 2007 07:23:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3tX8-0007Mt-AE; Mon, 08 Jan 2007 07:23:22 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3tX7-0001v3-18; Mon, 08 Jan 2007 07:23:22 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1H3tX4-0005gv-2Q; Mon, 08 Jan 2007 13:23:20 +0100 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 E4012B5B5; Mon, 8 Jan 2007 13:23:17 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1H3tX3-0001ED-L5; Mon, 08 Jan 2007 13:23:17 +0100 Message-ID: <45A237B5.6040603@tm.uka.de> Date: Mon, 08 Jan 2007 13:23:17 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: nsis-imp@ietf.org Subject: Re: [NSIS] RE: [Nsis-imp] Next Interop References: <200611141442.kAEEgNYc025279@smtp2.dei.uc.pt> <455B05B4.2090806@tm.uka.de> <459F65D9.4070609@tm.uka.de> In-Reply-To: <459F65D9.4070609@tm.uka.de> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) 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.4 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'NSIS Group' 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 wrote: > Roland Bless wrote: >> I just saw that the week from 19.2.-23.2.2007 would >> be indeed a good fit, since there is a conference > > Since the proposed date above is getting nearer I want to > hear peoples opinions once more. Maybe the implementers > need more time to finish their code? I got one request > to shift it after April 1st that would be after > the next IETF meeting. That would be ok for me, too. > What do others think? I just noticed that this is right before Easter, so it might not be a good idea to do it in the week from 2nd-5th of April. But maybe for other it is good (depends probably on your travel arrangements and plans for vacations...) I still want feedback about the proposed dates, either in the week 19.-23. February, or 2.-5. April Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 09 10:30:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Ivq-0004Hv-Qc; Tue, 09 Jan 2007 10:30:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Ivp-0004Fw-Pf; Tue, 09 Jan 2007 10:30:33 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Ivo-0006i8-EF; Tue, 09 Jan 2007 10:30:33 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1B2D320031E5; Tue, 9 Jan 2007 16:31:08 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) 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 ZAQ039TqF2vk; Tue, 9 Jan 2007 16:31:08 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 072F620001AF; Tue, 9 Jan 2007 16:31:08 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: [Nsis-imp] Next Interop Date: Tue, 9 Jan 2007 16:30:29 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD696983904@mx1.office> In-Reply-To: <45A237B5.6040603@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: [Nsis-imp] Next Interop Thread-Index: AcczH9RSqCS7K1ndRemcFZhSjK4xQQA4s/gg From: "Martin Stiemerling" To: "Roland Bless" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: NSIS Group 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, Thanks to Roland for organizing this.=20 Before talking about the date of the interop, I would like to get a poll on: - How many implementations we still have - How many implementators are willing to come this interop. Thanks, Martin=20 > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: Monday, January 08, 2007 1:23 PM > To: nsis-imp@ietf.org > Cc: 'NSIS Group' > Subject: Re: [NSIS] RE: [Nsis-imp] Next Interop >=20 > Hi, >=20 > Roland wrote: > > Roland Bless wrote: > >> I just saw that the week from 19.2.-23.2.2007 would be=20 > indeed a good=20 > >> fit, since there is a conference > >=20 > > Since the proposed date above is getting nearer I want to=20 > hear peoples=20 > > opinions once more. Maybe the implementers need more time to finish=20 > > their code? I got one request to shift it after April 1st=20 > that would=20 > > be after the next IETF meeting. That would be ok for me, too. > > What do others think? >=20 > I just noticed that this is right before Easter, so it might=20 > not be a good idea to do it in the week from 2nd-5th of=20 > April. But maybe for other it is good (depends probably on=20 > your travel arrangements and plans for vacations...) I still=20 > want feedback about the proposed dates, either in the week=20 > 19.-23. February, or 2.-5. April >=20 > Regards, > Roland >=20 > _______________________________________________ > NSIS-imp mailing list > NSIS-imp@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/nsis-imp >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 09 10:50:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JEX-0004Ee-4z; Tue, 09 Jan 2007 10:49:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JEV-0004Dp-9S for nsis@ietf.org; Tue, 09 Jan 2007 10:49:51 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4JER-000390-7g for nsis@ietf.org; Tue, 09 Jan 2007 10:49:51 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8249620031E5; Tue, 9 Jan 2007 16:50:24 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) 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 dCDp7QxqfUKt; Tue, 9 Jan 2007 16:50:24 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5E0092000293; Tue, 9 Jan 2007 16:50:24 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Date: Tue, 9 Jan 2007 16:49:45 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD696983910@mx1.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Consensus on: Removed the QSPEC control information Thread-Index: AccxplmurjLNyozOTBWtU2UjfafkqwCXojNQ From: "Martin Stiemerling" To: "Jukka MJ Manner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 Cc: gash@att.com, karagian@cs.utwente.nl, oran@cisco.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 Hi Jukka, all,=20 =20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: Saturday, January 06, 2007 4:18 PM > To: john.loughney@nokia.com > Cc: gash@att.com; karagian@cs.utwente.nl; oran@cisco.com;=20 > nsis@ietf.org; attila.bader@ericsson.com > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > information >=20 >=20 > Hi John, >=20 > That is actually a good point. So far I have hoped that we=20 > can clearly de-couple QSPEC+RMF and the NSLP, and therefore a=20 > single NSLP implementation can run with all different RMFs and QOSMs. I see the way of de-coupling the QSPEC+RMF and the NSLP as a fundamental = concept of NSIS. Otherwise, we really run into troubles if we need an = NSLP implementation per QSPEC+RMF.=20 >=20 > If a QOSM affects the common message processing, we need=20 > different implementations. Yet, I guess this also applies to=20 > various tunneling, session binding, and separate signaling=20 > sessions that might be used within a domain. If a QOSM affects the common message processing, aren't we in the need = for another NSLP? A different common message processing would be the = effect of a different semantics, isn't it? >=20 > Do we need to document how the RMF and QoS NSLP fit together,=20 > what is passed between the RMF and NSLP, what are the API=20 > issues, what kind on asymmetric triggers the RMF can send to=20 > the NSLP, etc. I think we need to write such a draft, and=20 > document all the interactions. If we have that written down,=20 > we can more easily define what is a standards-compliant=20 > implementation of a QOSM/RMF, and what is not. >=20 > If you think that would be good, I could write a first draft. I would be in favour of such an informational document, as implementors = and operators could benefit of it.=20 Martin >=20 > Jukka >=20 > On Sat, 6 Jan 2007, john.loughney@nokia.com wrote: >=20 > > Hi all, > >=20 > > My bigger concern is - how will implementations work? Will=20 > we need 2=20 > > completely different implementations to work in different scenarios? > > What is the reuse of implementations conforming to the base=20 > Qos NSLP=20 > > spec? > >=20 > > I agree with Dave's point: > >=20 > > > I think the constraints are stronger than this, if you want the=20 > > > domain-local elements to be able to claim conformance to the QOS=20 > > > NSLP specification. If not, the entire argument is moot,=20 > since then=20 > > > your domain-local signaling is completely proprietary and=20 > non-standard. > >=20 > > John > >=20 > >=20 > > >-----Original Message----- > > >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > >Sent: 05 January, 2007 19:53 > > >To: Georgios Karagiannis > > >Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; Loughney John=20 > > >(Nokia-NRC/PaloAlto); 'Ash, Gerald R \\\(Jerry\\\), ALABS';=20 > > >nsis@ietf.org > > >Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > > >information > > > > > > > > >Good. Then I don't see what the problem is. The e2e=20 > semantics of the=20 > > >NSLP messaging are preserved, and the request by the QNI=20 > is supported=20 > > >(provided the resources are there). > > > > > >Jukka > > > > > >On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > > > > > >> Hi Jukka > > >>=20 > > >> > I would expect the same goes with the NSLP, ie., if RMD > > >changes the > > >> > NSLP message processing in some way, it can do so, but > > >only for the > > >> > local domain, without affecting any QNEs (incld QNI and > > >QNR) outside > > >> > the RMD domain). And this must still preserve the e2e=20 > messaging=20 > > >> > semantics. > > >>=20 > > >> Agreed, the change in the NSLP message processing holds only for=20 > > >> the QNEs within the local domain, not outside the domain. > > >>=20 > > >>=20 > > >> Best regards, > > >> Georgios > > >> =20 > > >>=20 > > >> > -----Original Message----- > > >> > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > >> > Sent: vrijdag 5 januari 2007 18:33 > > >> > To: Georgios Karagiannis > > >> > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; 'John > > >Loughney'; 'Ash, > > >> > Gerald R \(Jerry\), ALABS'; nsis@ietf.org > > >> > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > > >> > information > > >> >=20 > > >> >=20 > > >> > Hi Georgios, > > >> >=20 > > >> > I guess new QSPEC objects could be allowed > > >> >=20 > > >> > a) flexibly if their are only used within the local > > >domain, and not > > >> > e2e (which would require all QNEs to be upgraded), > > >> >=20 > > >> > b) through NSLP standards action, if they need to be=20 > understood=20 > > >> > by all > > >> > QNEs on the e2e path. > > >> >=20 > > >> >=20 > > >> > I would expect the same goes with the NSLP, ie., if RMD > > >changes the > > >> > NSLP message processing in some way, it can do so, but > > >only for the > > >> > local domain, without affecting any QNEs (incld QNI and > > >QNR) outside > > >> > the RMD domain). And this must still preserve the e2e=20 > messaging=20 > > >> > semantics. > > >> >=20 > > >> > Jukka > > >> >=20 > > >> > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > > >> >=20 > > >> > > Hi Jukka > > >> > >=20 > > >> > > What I meant are your following statements: > > >> > > " A certain domain running a QOSM X can well do certain > > >> > optimizations, > > >> > > incl. separate signaling sessions and aggregation, provided=20 > > >> > > that > > >> > >=20 > > >> > > 1) it fulfils the original request of the QNIs, and > > >> > >=20 > > >> > > 2) the end-to-end semantic and the end-to-end QoS NSLP > > >> > messaging by the > > >> > > QNI, or any peer QNE are preserved. > > >> > >=20 > > >> > > Within those bounds a QOSM must operate, incl. any > > >domain internal > > >> > > optimized signaling." > > >> > >=20 > > >> > >=20 > > >> > > Of course no additional QoS-NSLP messages and QOS-NSLP > > >> > objects can be > > >> > > defined by the QOS model. What a QOS model should be able > > >> > to do is to > > >> > > define new QSPEC objects and to define how the QOS-NSLP > > >> > siganling in > > >> > > the domains internal, as you suggested under certain bounds,=20 > > >> > > can be optimized. > > >> > >=20 > > >> > > Best Regards, > > >> > > Georgios > > >> > >=20 > > >> > >=20 > > >> > >=20 > > >> > > =20 > > >> > >=20 > > >> > > > -----Original Message----- > > >> > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > >> > > > Sent: vrijdag 5 januari 2007 18:06 > > >> > > > To: Georgios Karagiannis > > >> > > > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; John > > >Loughney; Ash, > > >> > > > Gerald R (Jerry), ALABS; nsis@ietf.org > > >> > > > Subject: RE: [NSIS] Consensus on: Removed the=20 > QSPEC control=20 > > >> > > > information > > >> > > >=20 > > >> > > >=20 > > >> > > > Hi Georgios, > > >> > > >=20 > > >> > > > I didn't imply that the constraints would include > > >> > defining some new > > >> > > > NSLP messages, or other things that are not already > > >part of the > > >> > > > QSPEC, or the NSLP. > > >> > > >=20 > > >> > > > Yet, a QOS Model might e.g., define new INFO_SPEC > > >> > error/info codes, > > >> > > > or a new object within the QSPEC, but I guess those would=20 > > >> > > > require standards action, and a standards track RFC. > > >> > > >=20 > > >> > > > A QOS Model should not change the end-to-end semantics of > > >> > the NSLP, > > >> > > > or of the QSPEC - this is what I wrote. > > >> > > >=20 > > >> > > >=20 > > >> > > > I haven't read lately the RMD spec, so I don't know > > >what are the > > >> > > > functionality that are introduced in addition to what is > > >> > already in > > >> > > > the QSPEC and the NSLP. > > >> > > >=20 > > >> > > > Cheers, > > >> > > > Jukka > > >> > > >=20 > > >> > > > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > > >> > > >=20 > > >> > > > > Hi Dave > > >> > > > >=20 > > >> > > > > But I think that Jukka emphasized that it does not > > >need to be > > >> > > > > a standards track if it complies to: > > >> > > > > * the constraints specified in the QOS-NSLP document (see > > >> > > > Jukkas proposal), > > >> > > > > and of course if the QOS model draft is approved by the > > >> > IESG for > > >> > > > > publication. > > >> > > > >=20 > > >> > > > >=20 > > >> > > > > Best regards, > > >> > > > > Georgios > > >> > > > > =20 > > >> > > > >=20 > > >> > > > > > -----Original Message----- > > >> > > > > > From: David R Oran [mailto:oran@cisco.com] > > >> > > > > > Sent: vrijdag 5 januari 2007 16:02 > > >> > > > > > To: Attila B=E1der (IJ/ETH) > > >> > > > > > Cc: john.loughney@nokia.com; gash@att.com;=20 > nsis@ietf.org > > >> > > > > > Subject: Re: [NSIS] Consensus on: Removed the > > >QSPEC control > > >> > > > > > information > > >> > > > > >=20 > > >> > > > > >=20 > > >> > > > > > On Jan 5, 2007, at 9:02 AM, Attila B=E1der=20 > (IJ/ETH) wrote: > > >> > > > > >=20 > > >> > > > > > > Hi John, > > >> > > > > > > > > >> > > > > > > I disagree, I think the right approach is what > > >Yukka sent. > > >> > > > > > > > > >> > > > > > >>> > > >> > > > > > > "The end-to-end semantic and QoS NSLP=20 > messaging by the > > >> > > > QNI, or any > > >> > > > > > > peer QNE MUST BE preserved, and within those > > >bounds a QOSM > > >> > > > > > > must operate." > > >> > > > > > > > > >> > > > > > > This means that e.g., > > >> > > > > > > a) The resource request by the QNI and response from > > >> > > > the QNR must be > > >> > > > > > > followed and passed through intact by a QOSM X=20 > > >> > > > > > > domain, > > >> > > > > > > b) confirmation requests must be answered, > > >> > > > > > > c) tear-down must be followed, etc. " > > >> > > > > > >>> > > >> > > > > > > > > >> > > > > > > I think QoS NSLP operation can be extended in a local > > >> > > > QoS domain > > >> > > > > > > without distroying e2e QoS-NSLP operation. > > >> > > > > > > > > >> > > > > > John L. seemed to be of the view that if a particular=20 > > >> > > > > > domain-loal QoS scheme (e.g. RMD) wants to use > > >> > QoS-NSLP for its > > >> > > > > > local scheme, then it is free to modify it if and > > >> > only if there > > >> > > > > > is a standards track RFC documenting the > > >extensions/changes.=20 > > >> > > > > > This represents my view as well. > > >> > > > > > This is the only way we can ascertain=20 > upwards/downwards=20 > > >> > > > > > compatibility and interoperability. Otherwise what > > >you would > > >> > > > > > have is a completely private signaling scheme which=20 > > >> > > > > > claims conformance to a standard. > > >> > > > > >=20 > > >> > > > > > These QoS-NSLP extensions would have no effect on > > >the QSPEC > > >> > > > > > specification, unless the QSPEC itself is being > > >extended, in > > >> > > > > > which case I think it's still an open issue whether > > >> > or not you > > >> > > > > > need a standards track RFC for that. My guess would > > >> > be yes if we > > >> > > > > > adopt Yukka's encoding scheme (because otherwise you > > >> > could not > > >> > > > > > find or debug the end-to-end QSPEC when embedded in > > >> > an extended > > >> > > > > > local QSPEC), but possibly no if we adopt a=20 > more layered=20 > > >> > > > > > encoding like QSPEC stacking (so that the parser > > >has a known > > >> > > > > > regular encoding structure to deal with). > > >> > > > > >=20 > > >> > > > > > Cheers, Dave. > > >> > > > > >=20 > > >> > > > > > > Best regards, Attila > > >> > > > > > > > > >> > > > > > > > > >> > > > > > >> -----Original Message----- > > >> > > > > > >> From: john.loughney@nokia.com=20 > > >> > > > > > >> [mailto:john.loughney@nokia.com] > > >> > > > > > >> Sent: Friday, January 05, 2007 1:54 PM > > >> > > > > > >> To: gash@att.com; nsis@ietf.org > > >> > > > > > >> Subject: [NSIS] Consensus on: Removed the QSPEC > > >> > > > control information > > >> > > > > > >> > > >> > > > > > >> > > >> > > > > > >>>> Point_1):Removed the QSPEC control information > > >> > > > > > >>>>=20 > > >> > > >=20 > ------------------------------------------------------------- > > >> > > > -- > > >> > > > > > >>>> Jerry mentioned in a previous e-mail that=20 > this QSPEC=20 > > >> > > > > > >>>> control information concept is not=20 > removed but it is=20 > > >> > > > > > >>>> renamed > > >> > > > to Traffic > > >> > > > > > >>>> Handling Directives. > > >> > > > > > >>>> > > >> > > > > > >>>> If that is the case then Jerry will have=20 > to use the=20 > > >> > > > > > >>>> same > > >> > > > > > >> definitions > > >> > > > > > >>>> for the QSPEC control information as used=20 > in Section > > >> > > > 5.3.1 of: > > >> > > > > > >>>>=20 > > >> > > >=20 > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.t > > >> > > > xt > > >> > > > > > >>>> > > >> > > > > > >>>> Thus my proposal is to change section 4.3.3 > > >as given in > > >> > > > > > v.13 of the > > >> > > > > > >>>> QSPEC template draft and include the general > > >concept of > > >> > > > > > the QSPEC > > >> > > > > > >>>> control information that was given in=20 > Section 5.3.1=20 > > >> > > > > > >>>> of > > >> > > > > > >> version 12 of > > >> > > > > > >>>> the QSPEC template draft. Note that the=20 > name can be > > >> > > > > > changed but the > > >> > > > > > >>>> semantics should remain the same. Thus=20 > please change=20 > > >> > > > > > >>>> Section > > >> > > > > > >>> 4.3.3 as > > >> > > > > > >>>> follows: > > >> > > > > > >>>> > > >> > > > > > >>>> FROM: > > >> > > > > > >>>> > > >> > > > > > >>>> 4.3.3 Traffic Handling Directives > > >> > > > > > >>>> > > >> > > > > > >>>> The parameter describes how > > >> > > > the QNE will > > >> > > > > > >> process > > >> > > > > > >>>> excess traffic, that is,=20 > out-of-profile traffic.=20 > > >> > > > > > Excess traffic > > >> > > > > > >> MAY > > >> > > > > > >>>> be dropped, shaped and/or remarked. The > > >> > excess treatment > > >> > > > > > >> parameter > > >> > > > > > >> is > > >> > > > > > >>>> initially set by the QNI and cannot be=20 > overwritten. > > >> > > > > > >>>> > > >> > > > > > >>>> INTO: > > >> > > > > > >>>> > > >> > > > > > >>>> 4.3.3 Traffic Handling Directives > > >> > > > > > >>>> > > >> > > > > > >>>> Traffic Handling Directives are used for > > >> > signaling QOSM > > >> > > > > > >>>> RMF functions > > >> > > > > > >>>> not defined in QoS NSLP. It enables=20 > building new=20 > > >> > > > > > >>>> RMF > > >> > > > > > functions > > >> > > > > > >>>> required by a QOSM within a QoS NSLP signaling > > >> > > > > > framework, such > > >> > > > > > >>>> as > > >> > > > > > >>>> specified, for example, in [RMD-QOSM] and > > >> > [Y.1541-QOSM]. > > >> > > > > > >>> > > >> > > > > > >>> I think most (perhaps all?) of us agree on this > > >> > > > point: the QOSM > > >> > > > > > >>> specification SHOULD NOT be allowed to define 'new > > >> > > > RMF functions > > >> > > > > > >>> required by a QOSM' UNLESS such NSIS signaling > > >> > functionality > > >> > > > > > >> is defined > > >> > > > > > >>> in QoS NSLP. I.e., a QOSM is not allowed to > > >> > extend QoS NSLP > > >> > > > > > >> signaling > > >> > > > > > >>> functionality. The above text seems to abide by > > >> > the premise > > >> > > > > > >> by stating > > >> > > > > > >>> that new RMF functions are specified only 'within > > >> > a QoS NSLP > > >> > > > > > >> signaling > > >> > > > > > >>> framework'. If so, I think we're in agreement. > > >> > > > > > >> > > >> > > > > > >> I agree with Jerry's text, and I believe we=20 > have rough > > >> > > > > > consensus on > > >> > > > > > >> this. > > >> > > > > > >> If anyone disagrees with consensus, a short mail > > >> > > > stating that you > > >> > > > > > >> disagree is needed. > > >> > > > > > >> > > >> > > > > > >> On point, in order to extend QoS NSLP signaling, a > > >> > > > Standards Track > > >> > > > > > >> RFC is needed. > > >> > > > > > >> > > >> > > > > > >> 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 > > >> > > > > >=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 > > >> > >=20 > > >> > >=20 > > >> > >=20 > > >> >=20 > > >>=20 > > >>=20 > > >>=20 > > > > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 09 10:54:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JIH-0004xA-Bz; Tue, 09 Jan 2007 10:53:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JIF-0004w0-Oa; Tue, 09 Jan 2007 10:53:43 -0500 Received: from smtp2.dei.uc.pt ([193.137.203.231] helo=smtp.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4JI0-00043w-6O; Tue, 09 Jan 2007 10:53:43 -0500 Received: from zoing (dhcp-eucpii-12.ci.uc.pt [193.136.207.12]) (authenticated bits=0) by smtp.dei.uc.pt (8.13.8/8.13.8) with ESMTP id l09Fqiek000937 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 9 Jan 2007 15:52:44 GMT From: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= To: "'Martin Stiemerling'" , "'Roland Bless'" , Subject: RE: [NSIS] RE: [Nsis-imp] Next Interop Date: Tue, 9 Jan 2007 15:52:33 -0000 Message-ID: <007d01c73406$305ae5a0$8203030a@zoing> 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.3028 Thread-Index: AcczH9RSqCS7K1ndRemcFZhSjK4xQQA4s/ggAABNPhA= In-Reply-To: <113091BD57179D4491C19DA7E10CD696983904@mx1.office> X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-49.77, required 3, autolearn=not spam, ALL_TRUSTED -1.80, AWL 2.03, L_SMTP_AUTH -50.00) X-FCTUC-DEI-SIC-MailScanner-From: cordeiro@dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 'NSIS Group' 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, University of Coimbra implementation is here to stay :D We want to participate in the next interop, but we are still discussing = with the implementation team the best date. Probably April, just before = easter would be better for us, but as soon as we have a final agreement I will inform everyone. We are currently working in the following NSIS implementations (using = the last draft version): - GIST - QoS-NSLP - NAT/FW - HyPath I look forward for the next interop. BR, Lu=EDs Cordeiro -----Original Message----- From: Martin Stiemerling [mailto:Stiemerling@netlab.nec.de]=20 Sent: ter=E7a-feira, 9 de Janeiro de 2007 15:30 To: Roland Bless; nsis-imp@ietf.org Cc: NSIS Group Subject: RE: [NSIS] RE: [Nsis-imp] Next Interop Hi all, Thanks to Roland for organizing this.=20 Before talking about the date of the interop, I would like to get a poll on: - How many implementations we still have - How many implementators are willing to come this interop. Thanks, Martin=20 > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: Monday, January 08, 2007 1:23 PM > To: nsis-imp@ietf.org > Cc: 'NSIS Group' > Subject: Re: [NSIS] RE: [Nsis-imp] Next Interop >=20 > Hi, >=20 > Roland wrote: > > Roland Bless wrote: > >> I just saw that the week from 19.2.-23.2.2007 would be=20 > indeed a good=20 > >> fit, since there is a conference > >=20 > > Since the proposed date above is getting nearer I want to=20 > hear peoples=20 > > opinions once more. Maybe the implementers need more time to finish=20 > > their code? I got one request to shift it after April 1st=20 > that would=20 > > be after the next IETF meeting. That would be ok for me, too. > > What do others think? >=20 > I just noticed that this is right before Easter, so it might=20 > not be a good idea to do it in the week from 2nd-5th of=20 > April. But maybe for other it is good (depends probably on=20 > your travel arrangements and plans for vacations...) I still=20 > want feedback about the proposed dates, either in the week=20 > 19.-23. February, or 2.-5. April >=20 > Regards, > Roland >=20 > _______________________________________________ > NSIS-imp mailing list > NSIS-imp@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/nsis-imp >=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 Jan 09 10:56:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JKN-0006HR-W9; Tue, 09 Jan 2007 10:55:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JKL-0006HA-D7 for nsis@ietf.org; Tue, 09 Jan 2007 10:55:53 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4JKJ-0004up-IM for nsis@ietf.org; Tue, 09 Jan 2007 10:55:53 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 36DB02004BF7; Tue, 9 Jan 2007 16:56:29 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) 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 w7-p3dQ2BCm0; Tue, 9 Jan 2007 16:56:29 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 081292000293; Tue, 9 Jan 2007 16:56:29 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Change proposal for Mobility Applicability draft Date: Tue, 9 Jan 2007 16:55:50 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD696983911@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD6968C8554@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Change proposal for Mobility Applicability draft Thread-Index: AccgQ7zP3vIf2wRzQsGCiGG2yXRWqQDF/m5QBCqltvA= From: "Martin Stiemerling" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Jukka MJ Manner , Hannes Tschofenig , Xiaoming Fu , Sung-Hyuck Lee , Takako Sanda , Seong-Ho Jeong 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, Nobody has objected to the proposed changes of the mobility draft by January 8th. I assume the silence as consent to go forward with the changes, as proposed by the authors.=20 Martin > -----Original Message----- > From: Martin Stiemerling [mailto:Stiemerling@netlab.nec.de]=20 > Sent: Tuesday, December 19, 2006 11:58 AM > To: nsis@ietf.org > Cc: Seong-Ho Jeong; Hannes Tschofenig; Xiaoming Fu;=20 > Sung-Hyuck Lee; Takako Sanda; Jukka MJ Manner > Subject: RE: [NSIS] Change proposal for Mobility Applicability draft >=20 > Dear all, >=20 > Thanks to the authors for pushing this forward on time! >=20 > Please review the proposed changes and comment on them=20 > whether they are are to the WG or not. >=20 > Do send your comments (good, bad, etc) to the mailing list by=20 > January 8th latest (to fit with the holiday schedules :). By=20 > January 8th we should have a clear view if the proposed=20 > changes can go in the draft. >=20 > Thanks, >=20 > Martin >=20 > -----Original Message----- > From: Takako Sanda [mailto:sanda.takako@jp.panasonic.com] > Sent: Friday, December 15, 2006 1:24 PM > To: nsis@ietf.org > Cc: Xiaoming Fu; Seong-Ho Jeong; Sung-Hyuck Lee; Jukka MJ=20 > Manner; Hannes Tschofenig > Subject: [NSIS] Change proposal for Mobility Applicability draft >=20 > Dear all, >=20 > After the last IETF meeting, authors of NSIS Mobility=20 > Applicability draft=20 > (draft-ietf-nsis-applicability-mobility-signaling-05.txt)=20 > have discussed how the draft should be cleaned up and which=20 > topics are still missing. >=20 > The followings are discussion result for proposed changes.=20 > Please review them and give your comments by 5th Jan 2007. If=20 > no discussion has been made, authors will start editing text=20 > based on the decision below. >=20 >=20 > 1. Section 4 and 5 ("Basic Operations for Mobility Support"=20 > and "Applicability Statement") should be divided into two parts and > rewritten:- >=20 > o "Main" part, which is focusing on examples and describing how > mobility is handled by the NSIS protocols. Topics here will be > route change handling and NSIS interwork with MIP v4/v6 > (including tunneling management). This part must not include > "should work" or "may work" sort of description. >=20 > o "Further Study" part, which introduces summary of potential > issues and possible approaches for other topics. These topics are > out-of-scope for discussing details, such as interwork with other > mobility protocols, multihoming, peer failure (and frequent > path change, may be) >=20 > 2. Description of mobility objects should be removed. >=20 > 3. Security part needs to be cleaned up. Concrete change plan=20 > is still under discussions. >=20 > 4. As for new open issue, NAT/FW should be raised > "If a MN moves, IP addresses and routing change so that the=20 > packets enter and leave the network through a new NAT/FW node. > We need to open the old ports on this new NAT/FW node, and remove > the ones on the previous NAT/FW." > How would this work in real like? > The main difference for the NAT/FW work with respect is two-fold: > * We only use e2e refreshes. This makes things easier.=20 > * Most firewalls drop packets if a pinhole does not exist.=20 > We need to capture these two things. >=20 > 5. Detailed Operations in current texts should be moved to=20 > Appendix or discussed in separate draft. >=20 > 6. Section 3 (Problem Statement) may need to be cleaned up=20 > based on changes in main body. >=20 > BR, > Takako >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 09 11:10:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JYU-0004kj-Ll; Tue, 09 Jan 2007 11:10:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JYT-0004ke-QQ for nsis@ietf.org; Tue, 09 Jan 2007 11:10:29 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4JYR-0002Iv-B1 for nsis@ietf.org; Tue, 09 Jan 2007 11:10:29 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1168359023!5945544!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 31843 invoked from network); 9 Jan 2007 16:10:23 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-120.messagelabs.com with SMTP; 9 Jan 2007 16:10:23 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l09GAMQB028372; Tue, 9 Jan 2007 11:10:23 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l09GAIUm028322; Tue, 9 Jan 2007 11:10:18 -0500 (EST) 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] Consensus on: Removed the QSPEC control information Date: Tue, 9 Jan 2007 10:10:17 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC80B9@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <113091BD57179D4491C19DA7E10CD696983910@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Consensus on: Removed the QSPEC control information Thread-Index: AccxplmurjLNyozOTBWtU2UjfafkqwCXojNQAACUTyA= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Martin Stiemerling" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Martin, All, > -----Original Message----- > From: Martin Stiemerling [mailto:Stiemerling@netlab.nec.de]=20 > Sent: Tuesday, January 09, 2007 10:50 AM > To: Jukka MJ Manner; john.loughney@nokia.com > Cc: Ash, Gerald R (Jerry), ALABS; karagian@cs.utwente.nl;=20 > oran@cisco.com; nsis@ietf.org; attila.bader@ericsson.com > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > information >=20 > Hi Jukka, all,=20 > =20 > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > > Sent: Saturday, January 06, 2007 4:18 PM > > To: john.loughney@nokia.com > > Cc: gash@att.com; karagian@cs.utwente.nl; oran@cisco.com;=20 > > nsis@ietf.org; attila.bader@ericsson.com > > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > > information > >=20 > >=20 > > Hi John, > >=20 > > That is actually a good point. So far I have hoped that we=20 > > can clearly de-couple QSPEC+RMF and the NSLP, and therefore a=20 > > single NSLP implementation can run with all different RMFs=20 > > and QOSMs. >=20 > I see the way of de-coupling the QSPEC+RMF and the NSLP as a=20 > fundamental concept of NSIS. Otherwise, we really run into=20 > troubles if we need an NSLP implementation per QSPEC+RMF.=20 Agreed. =20 > >=20 > > If a QOSM affects the common message processing, we need=20 > > different implementations. Yet, I guess this also applies to=20 > > various tunneling, session binding, and separate signaling=20 > > sessions that might be used within a domain. >=20 > If a QOSM affects the common message processing, aren't we in=20 > the need for another NSLP? A different common message=20 > processing would be the effect of a different semantics, isn't it? Right. Your statement is consistent with the consensus stated at http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html: "the QOSM specification SHOULD NOT be allowed to define 'new RMF functions required by a QOSM' UNLESS such NSIS signaling functionality is defined in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP signaling functionality...new RMF functions are specified only 'within a QoS NSLP signaling framework'." Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 09 11:25:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JmQ-0002WH-9G; Tue, 09 Jan 2007 11:24:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JmO-0002WC-Pm for nsis@ietf.org; Tue, 09 Jan 2007 11:24:52 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4JmN-00066G-TL for nsis@ietf.org; Tue, 09 Jan 2007 11:24:52 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l09GNGVB019843; Tue, 9 Jan 2007 17:23:22 +0100 (MET) From: "Georgios Karagiannis" To: "'Martin Stiemerling'" , "'Jukka MJ Manner'" , Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Date: Tue, 9 Jan 2007 17:23:21 +0100 Message-ID: <003201c7340a$7e1e70f0$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.3028 In-Reply-To: <113091BD57179D4491C19DA7E10CD696983910@mx1.office> Thread-Index: AccxplmurjLNyozOTBWtU2UjfafkqwCXojNQAAE0eIA= X-Spam-Score: 0.595 () AWL, FVGT_s_OBFU_Q1, FVGT_u_HAS_2LETTERFLDR, J_CHICKENPOX_53 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 09 Jan 2007 17:23:24 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: f2a5dc784731617f446f668f2c529db6 Cc: gash@att.com, oran@cisco.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 Hi Martin Regarding the following: > If a QOSM affects the common message processing, aren't we in=20 > the need for another NSLP? A different common message=20 > processing would be the effect of a different semantics, isn't it? =20 Well this relates to what you define as common message processing! As Jukka already emphasized in a previous message: If a QOSM, e.g., RMD changes the NSLP message processing in some way,=20 it can do so, but only for the local (RMD) domain, without affecting any = QNEs (incld QNI and QNR) outside the local (RMD) domain).=20 And this must still preserve the e2e messaging semantics. Best regards, Georgios > -----Original Message----- > From: Martin Stiemerling [mailto:Stiemerling@netlab.nec.de]=20 > Sent: dinsdag 9 januari 2007 16:50 > To: Jukka MJ Manner; john.loughney@nokia.com > Cc: gash@att.com; karagian@cs.utwente.nl; oran@cisco.com;=20 > nsis@ietf.org; attila.bader@ericsson.com > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > information >=20 > Hi Jukka, all,=20 > =20 >=20 > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: Saturday, January 06, 2007 4:18 PM > > To: john.loughney@nokia.com > > Cc: gash@att.com; karagian@cs.utwente.nl; oran@cisco.com;=20 > > nsis@ietf.org; attila.bader@ericsson.com > > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > > information > >=20 > >=20 > > Hi John, > >=20 > > That is actually a good point. So far I have hoped that we=20 > can clearly=20 > > de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP=20 > > implementation can run with all different RMFs and QOSMs. >=20 > I see the way of de-coupling the QSPEC+RMF and the NSLP as a=20 > fundamental concept of NSIS. Otherwise, we really run into=20 > troubles if we need an NSLP implementation per QSPEC+RMF.=20 >=20 > >=20 > > If a QOSM affects the common message processing, we need different=20 > > implementations. Yet, I guess this also applies to various=20 > tunneling,=20 > > session binding, and separate signaling sessions that might be used=20 > > within a domain. >=20 > If a QOSM affects the common message processing, aren't we in=20 > the need for another NSLP? A different common message=20 > processing would be the effect of a different semantics, isn't it? >=20 > >=20 > > Do we need to document how the RMF and QoS NSLP fit=20 > together, what is=20 > > passed between the RMF and NSLP, what are the API issues,=20 > what kind on=20 > > asymmetric triggers the RMF can send to the NSLP, etc. I=20 > think we need=20 > > to write such a draft, and document all the interactions.=20 > If we have=20 > > that written down, we can more easily define what is a=20 > > standards-compliant implementation of a QOSM/RMF, and what is not. > >=20 > > If you think that would be good, I could write a first draft. >=20 > I would be in favour of such an informational document, as=20 > implementors and operators could benefit of it.=20 >=20 > Martin >=20 > >=20 > > Jukka > >=20 > > On Sat, 6 Jan 2007, john.loughney@nokia.com wrote: > >=20 > > > Hi all, > > >=20 > > > My bigger concern is - how will implementations work? Will > > we need 2 > > > completely different implementations to work in different=20 > scenarios? > > > What is the reuse of implementations conforming to the base > > Qos NSLP > > > spec? > > >=20 > > > I agree with Dave's point: > > >=20 > > > > I think the constraints are stronger than this, if you want the=20 > > > > domain-local elements to be able to claim conformance=20 > to the QOS=20 > > > > NSLP specification. If not, the entire argument is moot, > > since then > > > > your domain-local signaling is completely proprietary and > > non-standard. > > >=20 > > > John > > >=20 > > >=20 > > > >-----Original Message----- > > > >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > >Sent: 05 January, 2007 19:53 > > > >To: Georgios Karagiannis > > > >Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; Loughney John=20 > > > >(Nokia-NRC/PaloAlto); 'Ash, Gerald R \\\(Jerry\\\), ALABS';=20 > > > >nsis@ietf.org > > > >Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > > > >information > > > > > > > > > > > >Good. Then I don't see what the problem is. The e2e > > semantics of the > > > >NSLP messaging are preserved, and the request by the QNI > > is supported > > > >(provided the resources are there). > > > > > > > >Jukka > > > > > > > >On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > > > > > > > >> Hi Jukka > > > >>=20 > > > >> > I would expect the same goes with the NSLP, ie., if RMD > > > >changes the > > > >> > NSLP message processing in some way, it can do so, but > > > >only for the > > > >> > local domain, without affecting any QNEs (incld QNI and > > > >QNR) outside > > > >> > the RMD domain). And this must still preserve the e2e > > messaging > > > >> > semantics. > > > >>=20 > > > >> Agreed, the change in the NSLP message processing=20 > holds only for=20 > > > >> the QNEs within the local domain, not outside the domain. > > > >>=20 > > > >>=20 > > > >> Best regards, > > > >> Georgios > > > >> =20 > > > >>=20 > > > >> > -----Original Message----- > > > >> > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > >> > Sent: vrijdag 5 januari 2007 18:33 > > > >> > To: Georgios Karagiannis > > > >> > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; 'John > > > >Loughney'; 'Ash, > > > >> > Gerald R \(Jerry\), ALABS'; nsis@ietf.org > > > >> > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > > > >> > information > > > >> >=20 > > > >> >=20 > > > >> > Hi Georgios, > > > >> >=20 > > > >> > I guess new QSPEC objects could be allowed > > > >> >=20 > > > >> > a) flexibly if their are only used within the local > > > >domain, and not > > > >> > e2e (which would require all QNEs to be upgraded), > > > >> >=20 > > > >> > b) through NSLP standards action, if they need to be > > understood > > > >> > by all > > > >> > QNEs on the e2e path. > > > >> >=20 > > > >> >=20 > > > >> > I would expect the same goes with the NSLP, ie., if RMD > > > >changes the > > > >> > NSLP message processing in some way, it can do so, but > > > >only for the > > > >> > local domain, without affecting any QNEs (incld QNI and > > > >QNR) outside > > > >> > the RMD domain). And this must still preserve the e2e > > messaging > > > >> > semantics. > > > >> >=20 > > > >> > Jukka > > > >> >=20 > > > >> > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > > > >> >=20 > > > >> > > Hi Jukka > > > >> > >=20 > > > >> > > What I meant are your following statements: > > > >> > > " A certain domain running a QOSM X can well do certain > > > >> > optimizations, > > > >> > > incl. separate signaling sessions and aggregation,=20 > provided=20 > > > >> > > that > > > >> > >=20 > > > >> > > 1) it fulfils the original request of the QNIs, and > > > >> > >=20 > > > >> > > 2) the end-to-end semantic and the end-to-end QoS NSLP > > > >> > messaging by the > > > >> > > QNI, or any peer QNE are preserved. > > > >> > >=20 > > > >> > > Within those bounds a QOSM must operate, incl. any > > > >domain internal > > > >> > > optimized signaling." > > > >> > >=20 > > > >> > >=20 > > > >> > > Of course no additional QoS-NSLP messages and QOS-NSLP > > > >> > objects can be > > > >> > > defined by the QOS model. What a QOS model should be able > > > >> > to do is to > > > >> > > define new QSPEC objects and to define how the QOS-NSLP > > > >> > siganling in > > > >> > > the domains internal, as you suggested under=20 > certain bounds,=20 > > > >> > > can be optimized. > > > >> > >=20 > > > >> > > Best Regards, > > > >> > > Georgios > > > >> > >=20 > > > >> > >=20 > > > >> > >=20 > > > >> > > =20 > > > >> > >=20 > > > >> > > > -----Original Message----- > > > >> > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > >> > > > Sent: vrijdag 5 januari 2007 18:06 > > > >> > > > To: Georgios Karagiannis > > > >> > > > Cc: 'David R Oran'; 'Attila B=E1der (IJ/ETH)'; John > > > >Loughney; Ash, > > > >> > > > Gerald R (Jerry), ALABS; nsis@ietf.org > > > >> > > > Subject: RE: [NSIS] Consensus on: Removed the > > QSPEC control > > > >> > > > information > > > >> > > >=20 > > > >> > > >=20 > > > >> > > > Hi Georgios, > > > >> > > >=20 > > > >> > > > I didn't imply that the constraints would include > > > >> > defining some new > > > >> > > > NSLP messages, or other things that are not already > > > >part of the > > > >> > > > QSPEC, or the NSLP. > > > >> > > >=20 > > > >> > > > Yet, a QOS Model might e.g., define new INFO_SPEC > > > >> > error/info codes, > > > >> > > > or a new object within the QSPEC, but I guess=20 > those would=20 > > > >> > > > require standards action, and a standards track RFC. > > > >> > > >=20 > > > >> > > > A QOS Model should not change the end-to-end semantics of > > > >> > the NSLP, > > > >> > > > or of the QSPEC - this is what I wrote. > > > >> > > >=20 > > > >> > > >=20 > > > >> > > > I haven't read lately the RMD spec, so I don't know > > > >what are the > > > >> > > > functionality that are introduced in addition to what is > > > >> > already in > > > >> > > > the QSPEC and the NSLP. > > > >> > > >=20 > > > >> > > > Cheers, > > > >> > > > Jukka > > > >> > > >=20 > > > >> > > > On Fri, 5 Jan 2007, Georgios Karagiannis wrote: > > > >> > > >=20 > > > >> > > > > Hi Dave > > > >> > > > >=20 > > > >> > > > > But I think that Jukka emphasized that it does not > > > >need to be > > > >> > > > > a standards track if it complies to: > > > >> > > > > * the constraints specified in the QOS-NSLP=20 > document (see > > > >> > > > Jukkas proposal), > > > >> > > > > and of course if the QOS model draft is approved by the > > > >> > IESG for > > > >> > > > > publication. > > > >> > > > >=20 > > > >> > > > >=20 > > > >> > > > > Best regards, > > > >> > > > > Georgios > > > >> > > > > =20 > > > >> > > > >=20 > > > >> > > > > > -----Original Message----- > > > >> > > > > > From: David R Oran [mailto:oran@cisco.com] > > > >> > > > > > Sent: vrijdag 5 januari 2007 16:02 > > > >> > > > > > To: Attila B=E1der (IJ/ETH) > > > >> > > > > > Cc: john.loughney@nokia.com; gash@att.com; > > nsis@ietf.org > > > >> > > > > > Subject: Re: [NSIS] Consensus on: Removed the > > > >QSPEC control > > > >> > > > > > information > > > >> > > > > >=20 > > > >> > > > > >=20 > > > >> > > > > > On Jan 5, 2007, at 9:02 AM, Attila B=E1der > > (IJ/ETH) wrote: > > > >> > > > > >=20 > > > >> > > > > > > Hi John, > > > >> > > > > > > > > > >> > > > > > > I disagree, I think the right approach is what > > > >Yukka sent. > > > >> > > > > > > > > > >> > > > > > >>> > > > >> > > > > > > "The end-to-end semantic and QoS NSLP > > messaging by the > > > >> > > > QNI, or any > > > >> > > > > > > peer QNE MUST BE preserved, and within those > > > >bounds a QOSM > > > >> > > > > > > must operate." > > > >> > > > > > > > > > >> > > > > > > This means that e.g., > > > >> > > > > > > a) The resource request by the QNI and=20 > response from > > > >> > > > the QNR must be > > > >> > > > > > > followed and passed through intact by a QOSM X=20 > > > >> > > > > > > domain, > > > >> > > > > > > b) confirmation requests must be answered, > > > >> > > > > > > c) tear-down must be followed, etc. " > > > >> > > > > > >>> > > > >> > > > > > > > > > >> > > > > > > I think QoS NSLP operation can be extended=20 > in a local > > > >> > > > QoS domain > > > >> > > > > > > without distroying e2e QoS-NSLP operation. > > > >> > > > > > > > > > >> > > > > > John L. seemed to be of the view that if a=20 > particular=20 > > > >> > > > > > domain-loal QoS scheme (e.g. RMD) wants to use > > > >> > QoS-NSLP for its > > > >> > > > > > local scheme, then it is free to modify it if and > > > >> > only if there > > > >> > > > > > is a standards track RFC documenting the > > > >extensions/changes.=20 > > > >> > > > > > This represents my view as well. > > > >> > > > > > This is the only way we can ascertain > > upwards/downwards > > > >> > > > > > compatibility and interoperability. Otherwise what > > > >you would > > > >> > > > > > have is a completely private signaling scheme which=20 > > > >> > > > > > claims conformance to a standard. > > > >> > > > > >=20 > > > >> > > > > > These QoS-NSLP extensions would have no effect on > > > >the QSPEC > > > >> > > > > > specification, unless the QSPEC itself is being > > > >extended, in > > > >> > > > > > which case I think it's still an open issue whether > > > >> > or not you > > > >> > > > > > need a standards track RFC for that. My guess would > > > >> > be yes if we > > > >> > > > > > adopt Yukka's encoding scheme (because otherwise you > > > >> > could not > > > >> > > > > > find or debug the end-to-end QSPEC when embedded in > > > >> > an extended > > > >> > > > > > local QSPEC), but possibly no if we adopt a > > more layered > > > >> > > > > > encoding like QSPEC stacking (so that the parser > > > >has a known > > > >> > > > > > regular encoding structure to deal with). > > > >> > > > > >=20 > > > >> > > > > > Cheers, Dave. > > > >> > > > > >=20 > > > >> > > > > > > Best regards, Attila > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > >> -----Original Message----- > > > >> > > > > > >> From: john.loughney@nokia.com=20 > > > >> > > > > > >> [mailto:john.loughney@nokia.com] > > > >> > > > > > >> Sent: Friday, January 05, 2007 1:54 PM > > > >> > > > > > >> To: gash@att.com; nsis@ietf.org > > > >> > > > > > >> Subject: [NSIS] Consensus on: Removed the QSPEC > > > >> > > > control information > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > > > >>>> Point_1):Removed the QSPEC control information > > > >> > > > > > >>>>=20 > > > >> > > >=20 > > ------------------------------------------------------------- > > > >> > > > -- > > > >> > > > > > >>>> Jerry mentioned in a previous e-mail that > > this QSPEC > > > >> > > > > > >>>> control information concept is not > > removed but it is > > > >> > > > > > >>>> renamed > > > >> > > > to Traffic > > > >> > > > > > >>>> Handling Directives. > > > >> > > > > > >>>> > > > >> > > > > > >>>> If that is the case then Jerry will have > > to use the > > > >> > > > > > >>>> same > > > >> > > > > > >> definitions > > > >> > > > > > >>>> for the QSPEC control information as used > > in Section > > > >> > > > 5.3.1 of: > > > >> > > > > > >>>>=20 > > > >> > > >=20 > > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.t > > > >> > > > xt > > > >> > > > > > >>>> > > > >> > > > > > >>>> Thus my proposal is to change section 4.3.3 > > > >as given in > > > >> > > > > > v.13 of the > > > >> > > > > > >>>> QSPEC template draft and include the general > > > >concept of > > > >> > > > > > the QSPEC > > > >> > > > > > >>>> control information that was given in > > Section 5.3.1 > > > >> > > > > > >>>> of > > > >> > > > > > >> version 12 of > > > >> > > > > > >>>> the QSPEC template draft. Note that the > > name can be > > > >> > > > > > changed but the > > > >> > > > > > >>>> semantics should remain the same. Thus > > please change > > > >> > > > > > >>>> Section > > > >> > > > > > >>> 4.3.3 as > > > >> > > > > > >>>> follows: > > > >> > > > > > >>>> > > > >> > > > > > >>>> FROM: > > > >> > > > > > >>>> > > > >> > > > > > >>>> 4.3.3 Traffic Handling Directives > > > >> > > > > > >>>> > > > >> > > > > > >>>> The parameter=20 > describes how > > > >> > > > the QNE will > > > >> > > > > > >> process > > > >> > > > > > >>>> excess traffic, that is, > > out-of-profile traffic.=20 > > > >> > > > > > Excess traffic > > > >> > > > > > >> MAY > > > >> > > > > > >>>> be dropped, shaped and/or remarked. The > > > >> > excess treatment > > > >> > > > > > >> parameter > > > >> > > > > > >> is > > > >> > > > > > >>>> initially set by the QNI and cannot be > > overwritten. > > > >> > > > > > >>>> > > > >> > > > > > >>>> INTO: > > > >> > > > > > >>>> > > > >> > > > > > >>>> 4.3.3 Traffic Handling Directives > > > >> > > > > > >>>> > > > >> > > > > > >>>> Traffic Handling Directives are used for > > > >> > signaling QOSM > > > >> > > > > > >>>> RMF functions > > > >> > > > > > >>>> not defined in QoS NSLP. It enables > > building new > > > >> > > > > > >>>> RMF > > > >> > > > > > functions > > > >> > > > > > >>>> required by a QOSM within a QoS NSLP=20 > signaling > > > >> > > > > > framework, such > > > >> > > > > > >>>> as > > > >> > > > > > >>>> specified, for example, in [RMD-QOSM] and > > > >> > [Y.1541-QOSM]. > > > >> > > > > > >>> > > > >> > > > > > >>> I think most (perhaps all?) of us agree on this > > > >> > > > point: the QOSM > > > >> > > > > > >>> specification SHOULD NOT be allowed to=20 > define 'new > > > >> > > > RMF functions > > > >> > > > > > >>> required by a QOSM' UNLESS such NSIS signaling > > > >> > functionality > > > >> > > > > > >> is defined > > > >> > > > > > >>> in QoS NSLP. I.e., a QOSM is not allowed to > > > >> > extend QoS NSLP > > > >> > > > > > >> signaling > > > >> > > > > > >>> functionality. The above text seems to abide by > > > >> > the premise > > > >> > > > > > >> by stating > > > >> > > > > > >>> that new RMF functions are specified only 'within > > > >> > a QoS NSLP > > > >> > > > > > >> signaling > > > >> > > > > > >>> framework'. If so, I think we're in agreement. > > > >> > > > > > >> > > > >> > > > > > >> I agree with Jerry's text, and I believe we > > have rough > > > >> > > > > > consensus on > > > >> > > > > > >> this. > > > >> > > > > > >> If anyone disagrees with consensus, a short mail > > > >> > > > stating that you > > > >> > > > > > >> disagree is needed. > > > >> > > > > > >> > > > >> > > > > > >> On point, in order to extend QoS NSLP signaling, a > > > >> > > > Standards Track > > > >> > > > > > >> RFC is needed. > > > >> > > > > > >> > > > >> > > > > > >> 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 > > > >> > > > > >=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 > > > >> > >=20 > > > >> > >=20 > > > >> > >=20 > > > >> >=20 > > > >>=20 > > > >>=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 Jan 09 12:00:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4KKw-0000t2-7b; Tue, 09 Jan 2007 12:00:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4KKu-0000sJ-Cn; Tue, 09 Jan 2007 12:00:32 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4KKr-00017l-Vx; Tue, 09 Jan 2007 12:00:32 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1H4KKe-0004Zc-MA; Tue, 09 Jan 2007 18:00:20 +0100 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1H4KKd-0005VM-BE; Tue, 09 Jan 2007 18:00:15 +0100 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 5E3E0B5B3; Tue, 9 Jan 2007 18:00:14 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1H4KKc-0003xx-19; Tue, 09 Jan 2007 18:00:14 +0100 Message-ID: <45A3CA41.4090504@tm.uka.de> Date: Tue, 09 Jan 2007 18:00:49 +0100 From: Roland Bless User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.9) Gecko/20061206 Thunderbird/1.5.0.9 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= , 'Martin Stiemerling' Subject: Re: [NSIS] RE: [Nsis-imp] Next Interop References: <007d01c73406$305ae5a0$8203030a@zoing> In-Reply-To: <007d01c73406$305ae5a0$8203030a@zoing> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.0 (----) 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.4 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: nsis-imp@ietf.org, 'NSIS Group' 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 Luís and Martin, Luís Cordeiro wrote: > We want to participate in the next interop, but we are still discussing with > the implementation team the best date. Probably April, just before easter > would be better for us, but as soon as we have a final agreement I will > inform everyone. We like to participate :-) and have: * GIST * NAT/FW NSLP * QoS NSLP to test. Unfortunately, April before Easter seems to be not a viable option anymore, because I got an announcement _today_ for a meeting that I must attend. :-( Sorry for that short notice. So April after Easter is probably still possible. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 09 14:09:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ML1-0001dC-EF; Tue, 09 Jan 2007 14:08:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ML0-0001cQ-3W for nsis@ietf.org; Tue, 09 Jan 2007 14:08:46 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4MKy-0000f6-R8 for nsis@ietf.org; Tue, 09 Jan 2007 14:08:46 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1168369723!16820991!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 24891 invoked from network); 9 Jan 2007 19:08:43 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-121.messagelabs.com with SMTP; 9 Jan 2007 19:08:43 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l09J8giS023932; Tue, 9 Jan 2007 14:08:43 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l09J8ZOd023860; Tue, 9 Jan 2007 14:08:36 -0500 (EST) 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] Consensus on: Removed the QSPEC control information Date: Tue, 9 Jan 2007 13:08:35 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC80BC@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <003201c7340a$7e1e70f0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Consensus on: Removed the QSPEC control information Thread-Index: AccxplmurjLNyozOTBWtU2UjfafkqwCXojNQAAE0eIAAA07tUA== From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" , "Martin Stiemerling" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 All, See below.=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Tuesday, January 09, 2007 11:23 AM > To: 'Martin Stiemerling'; 'Jukka MJ Manner'; john.loughney@nokia.com > Cc: Ash, Gerald R (Jerry), ALABS; oran@cisco.com;=20 > nsis@ietf.org; attila.bader@ericsson.com > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 > information >=20 > Hi Martin >=20 > Regarding the following: > > If a QOSM affects the common message processing, aren't we in=20 > > the need for another NSLP? A different common message=20 > > processing would be the effect of a different semantics, isn't it? > =20 > Well this relates to what you define as common message processing! > As Jukka already emphasized in a previous message: > If a QOSM, e.g., RMD changes the NSLP message processing in some way,=20 > it can do so, but only for the local (RMD) domain, without=20 > affecting any=20 > QNEs (incld QNI and QNR) outside the local (RMD) domain).=20 > And this must still preserve the e2e messaging semantics. Per the consensus stated at http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html: "the QOSM specification SHOULD NOT be allowed to define 'new RMF functions required by a QOSM' UNLESS such NSIS signaling functionality is defined in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP signaling functionality...new RMF functions are specified only 'within a QoS NSLP signaling framework'." Hence a QOSM must not be allowed to change QoS NSLP message processing in some local domain that is somehow inconsistent with what is specified in QoS NSLP; that would be contrary to the consensus above. John and Dave stated this pretty clearly, see http://www1.ietf.org/mail-archive/web/nsis/current/msg07427.html: "the constraints are stronger than this, if you want the domain-local elements to be able to claim conformance to the QOS NSLP specification. If not... then your domain-local signaling is completely proprietary and non-standard." Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 09 15:31:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Ncf-0000yN-Vn; Tue, 09 Jan 2007 15:31:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Ncd-0000yI-Vb for nsis@ietf.org; Tue, 09 Jan 2007 15:31:03 -0500 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 1H4Ncc-0007WP-Fv for nsis@ietf.org; Tue, 09 Jan 2007 15:31:03 -0500 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; Tue, 09 Jan 2007 22:30:59 +0200 id 000AFDDD.45A3FB83.000013B7 Date: Tue, 9 Jan 2007 22:30:59 +0200 (EET) From: Jukka MJ Manner To: "Ash, Gerald R \\(Jerry\\), ALABS" Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC80BC@KCCLUST06EVS1.ugd.att.com> Message-ID: References: <9473683187ADC049A855ED2DA739ABCA0DDC80BC@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: 00e94c813bef7832af255170dca19e36 Cc: Martin Stiemerling , 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 all, I agree on this, too. I think John wrote it well when saying that we should only need a single QoS NSLP implementation. If the common implementation can not work with a QOSM or RMF, then there is a problem with the QOSM/RMF. Changing the QOSM deployed in a domain should only involve changing the RMF. To me that would be the ideal case. (but probably that would be too simple, since e.g. a new QOSM might involve the discussed parallel intra-domain sessions being bound to the e2e sessions) Jukka On Tue, 9 Jan 2007, Ash, Gerald R \(Jerry\), ALABS wrote: > Hi All, > > See below. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Tuesday, January 09, 2007 11:23 AM > > To: 'Martin Stiemerling'; 'Jukka MJ Manner'; john.loughney@nokia.com > > Cc: Ash, Gerald R (Jerry), ALABS; oran@cisco.com; > > nsis@ietf.org; attila.bader@ericsson.com > > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > > information > > > > Hi Martin > > > > Regarding the following: > > > If a QOSM affects the common message processing, aren't we in > > > the need for another NSLP? A different common message > > > processing would be the effect of a different semantics, isn't it? > > > > Well this relates to what you define as common message processing! > > As Jukka already emphasized in a previous message: > > If a QOSM, e.g., RMD changes the NSLP message processing in some way, > > it can do so, but only for the local (RMD) domain, without > > affecting any > > QNEs (incld QNI and QNR) outside the local (RMD) domain). > > And this must still preserve the e2e messaging semantics. > > Per the consensus stated at > http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html: > > "the QOSM specification SHOULD NOT be allowed to define 'new RMF > functions required by a QOSM' UNLESS such NSIS signaling functionality > is defined in QoS NSLP. I.e., a QOSM is not allowed to extend QoS NSLP > signaling functionality...new RMF functions are specified only 'within a > QoS NSLP signaling framework'." > > Hence a QOSM must not be allowed to change QoS NSLP message processing > in some local domain that is somehow inconsistent with what is specified > in QoS NSLP; that would be contrary to the consensus above. > > John and Dave stated this pretty clearly, see > http://www1.ietf.org/mail-archive/web/nsis/current/msg07427.html: > > "the constraints are stronger than this, if you want the domain-local > elements to be able to claim conformance to the QOS NSLP specification. > If not... then your domain-local signaling is completely proprietary and > non-standard." > > Thanks, > Jerry > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 09 17:19:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4PIp-0000ao-6t; Tue, 09 Jan 2007 17:18:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4PIn-0000Yk-E9; Tue, 09 Jan 2007 17:18:41 -0500 Received: from tmailer.gwdg.de ([134.76.10.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4PIm-0007rW-4q; Tue, 09 Jan 2007 17:18:41 -0500 Received: from p5484c007.dip0.t-ipconnect.de ([84.132.192.7] helo=[192.168.0.188]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1H4PIe-0008RW-BC; Tue, 09 Jan 2007 23:18:32 +0100 Message-ID: <45A414B6.9020903@cs.uni-goettingen.de> Date: Tue, 09 Jan 2007 23:18:30 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] RE: [Nsis-imp] Next Interop References: <007d01c73406$305ae5a0$8203030a@zoing> <45A3CA41.4090504@tm.uka.de> In-Reply-To: <45A3CA41.4090504@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: 'Martin Stiemerling' , nsis-imp@ietf.org, 'NSIS Group' , =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= 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, We are interested in participation with our implementation of GIST, NAT/FW NSLP, QoS NSLP, ping/diagnostics etc and under discussion on possible timing (likely, April is better than February). Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 09 23:01:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UeH-0002IS-N1; Tue, 09 Jan 2007 23:01:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UeG-0002Ht-63 for nsis@ietf.org; Tue, 09 Jan 2007 23:01:12 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4UeE-0003Kq-Mu for nsis@ietf.org; Tue, 09 Jan 2007 23:01:12 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0A3x6jO018618; Wed, 10 Jan 2007 05:59:12 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 06:00:56 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 22:00:54 -0600 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] Consensus on: Removed the QSPEC control information Date: Tue, 9 Jan 2007 22:00:54 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F0ADD8D@daebe103.NOE.Nokia.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC80B9@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Consensus on: Removed the QSPEC control information Thread-Index: AccxplmurjLNyozOTBWtU2UjfafkqwCXojNQAACUTyAADq/gkA== From: To: , X-OriginalArrivalTime: 10 Jan 2007 04:00:54.0193 (UTC) FILETIME=[ECC69210:01C7346B] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 believe we can move forward on this now. John=20 >-----Original Message----- >From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 >Sent: 09 January, 2007 18:10 >To: Martin Stiemerling >Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information > >Hi Martin, All, > >> -----Original Message----- >> From: Martin Stiemerling [mailto:Stiemerling@netlab.nec.de] >> Sent: Tuesday, January 09, 2007 10:50 AM >> To: Jukka MJ Manner; john.loughney@nokia.com >> Cc: Ash, Gerald R (Jerry), ALABS; karagian@cs.utwente.nl;=20 >> oran@cisco.com; nsis@ietf.org; attila.bader@ericsson.com >> Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 >> information >>=20 >> Hi Jukka, all, >> =20 >> > -----Original Message----- >> > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >> > Sent: Saturday, January 06, 2007 4:18 PM >> > To: john.loughney@nokia.com >> > Cc: gash@att.com; karagian@cs.utwente.nl; oran@cisco.com;=20 >> > nsis@ietf.org; attila.bader@ericsson.com >> > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 >> > information >> >=20 >> >=20 >> > Hi John, >> >=20 >> > That is actually a good point. So far I have hoped that we can=20 >> > clearly de-couple QSPEC+RMF and the NSLP, and therefore a single=20 >> > NSLP implementation can run with all different RMFs and QOSMs. >>=20 >> I see the way of de-coupling the QSPEC+RMF and the NSLP as a=20 >> fundamental concept of NSIS. Otherwise, we really run into=20 >troubles if=20 >> we need an NSLP implementation per QSPEC+RMF. > >Agreed. >=20 >> >=20 >> > If a QOSM affects the common message processing, we need different=20 >> > implementations. Yet, I guess this also applies to various=20 >> > tunneling, session binding, and separate signaling sessions that=20 >> > might be used within a domain. >>=20 >> If a QOSM affects the common message processing, aren't we=20 >in the need=20 >> for another NSLP? A different common message processing would be the=20 >> effect of a different semantics, isn't it? > >Right. Your statement is consistent with the consensus stated at >http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html: > >"the QOSM specification SHOULD NOT be allowed to define 'new=20 >RMF functions required by a QOSM' UNLESS such NSIS signaling=20 >functionality is defined in QoS NSLP. I.e., a QOSM is not=20 >allowed to extend QoS NSLP signaling functionality...new RMF=20 >functions are specified only 'within a QoS NSLP signaling framework'." > >Thanks, >Jerry > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 10 03:22:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Yip-0005v9-0k; Wed, 10 Jan 2007 03:22:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Yin-0005v0-HG for nsis@ietf.org; Wed, 10 Jan 2007 03:22:09 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Yil-0003Jq-2G for nsis@ietf.org; Wed, 10 Jan 2007 03:22:09 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l0A8Lhi9012411; Wed, 10 Jan 2007 09:21:53 +0100 (MET) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" , "'Martin Stiemerling'" Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Date: Wed, 10 Jan 2007 09:21:52 +0100 Message-ID: <000a01c73490$68d40990$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 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC80BC@KCCLUST06EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccxplmurjLNyozOTBWtU2UjfafkqwCXojNQAAE0eIAAA07tUAAeUGKw X-Spam-Score: 0.247 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 10 Jan 2007 09:21:53 +0100 (MET) X-Spam-Score: 0.0 (/) 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 Jerry Regarding the following: > > Per the consensus stated at > http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html: > > "the QOSM specification SHOULD NOT be allowed to define 'new > RMF functions required by a QOSM' UNLESS such NSIS signaling > functionality is defined in QoS NSLP. I.e., a QOSM is not > allowed to extend QoS NSLP signaling functionality...new RMF > functions are specified only 'within a QoS NSLP signaling framework'." > > Hence a QOSM must not be allowed to change QoS NSLP message > processing in some local domain that is somehow inconsistent > with what is specified in QoS NSLP; that would be contrary to > the consensus above. > > John and Dave stated this pretty clearly, see > http://www1.ietf.org/mail-archive/web/nsis/current/msg07427.html: > > "the constraints are stronger than this, if you want the > domain-local elements to be able to claim conformance to the > QOS NSLP specification. > If not... then your domain-local signaling is completely > proprietary and non-standard." I do not remember to had as consensus on the above! Best Regards, Georgios > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: dinsdag 9 januari 2007 20:09 > To: Georgios Karagiannis; Martin Stiemerling > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > information > > Hi All, > > See below. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Tuesday, January 09, 2007 11:23 AM > > To: 'Martin Stiemerling'; 'Jukka MJ Manner'; john.loughney@nokia.com > > Cc: Ash, Gerald R (Jerry), ALABS; oran@cisco.com; nsis@ietf.org; > > attila.bader@ericsson.com > > Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > > information > > > > Hi Martin > > > > Regarding the following: > > > If a QOSM affects the common message processing, aren't we in the > > > need for another NSLP? A different common message > processing would > > > be the effect of a different semantics, isn't it? > > > > Well this relates to what you define as common message processing! > > As Jukka already emphasized in a previous message: > > If a QOSM, e.g., RMD changes the NSLP message processing in > some way, > > it can do so, but only for the local (RMD) domain, without > affecting > > any QNEs (incld QNI and QNR) outside the local (RMD) domain). > > And this must still preserve the e2e messaging semantics. > > Per the consensus stated at > http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html: > > "the QOSM specification SHOULD NOT be allowed to define 'new > RMF functions required by a QOSM' UNLESS such NSIS signaling > functionality is defined in QoS NSLP. I.e., a QOSM is not > allowed to extend QoS NSLP signaling functionality...new RMF > functions are specified only 'within a QoS NSLP signaling framework'." > > Hence a QOSM must not be allowed to change QoS NSLP message > processing in some local domain that is somehow inconsistent > with what is specified in QoS NSLP; that would be contrary to > the consensus above. > > John and Dave stated this pretty clearly, see > http://www1.ietf.org/mail-archive/web/nsis/current/msg07427.html: > > "the constraints are stronger than this, if you want the > domain-local elements to be able to claim conformance to the > QOS NSLP specification. > If not... then your domain-local signaling is completely > proprietary and non-standard." > > Thanks, > Jerry > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 10 04:37:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ZtJ-0003Va-Ta; Wed, 10 Jan 2007 04:37:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ZtH-0003VU-NW for nsis@ietf.org; Wed, 10 Jan 2007 04:37:03 -0500 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 1H4ZtD-0001Ku-2x for nsis@ietf.org; Wed, 10 Jan 2007 04:37:02 -0500 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, 10 Jan 2007 11:36:58 +0200 id 000AFE29.45A4B3BA.00001D91 Date: Wed, 10 Jan 2007 11:36:57 +0200 (EET) From: Jukka MJ Manner To: Hong Cheng In-Reply-To: <4580CEAC.6000908@sg.panasonic.com> Message-ID: References: <20061213150313.5173.SANDA.TAKAKO@jp.panasonic.com> <4580CEAC.6000908@sg.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: nsis@ietf.org, Takako Sanda Subject: [NSIS] Re: Clarification: tearing down from intermediate node 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, After re-reading the QoS NSLP spec, I think the spec is quite accurate in how the NSLP supports mobility, and it seems to work properly. Tearing down the reservation on the old path from the cross-over QNE would be good to do, but not necessarily critical for the proper operation of the NSLP. Yet, the current QoS NSLP spec mentions the tear-down at the cross-over router. Consider the following scenario: [MN] [QNE1] --- [QNE2] ---\ | \ | [QNE3] --- [QNE6] --- [QNE7] --- | / V / [MN] [QNE4] --- [QNE5]---/ The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR and receiver" "MN as QNI and data sender": we could rely on just the soft-state to expire on the old path, and a new RESERVE on the new path, or use the following, based on the NSLP draft text. - MN moves from peer QNE1 to QNE4 - GIST gets a hint that routing has changed, triggers the NSLP - The NSLP then sends a new full RESERVE with a new RSN - The RESERVE hits QNE4, which makes reservation - Then the RESERVE is forwarded to QNE5, which also makes the reservation - Finally, the RESERVE hits QNE3, which makes a reservation and forwards the RESERVE to QNE6, and so on The tear-down part: - QNE3 also noticies that the SII-Handle has changed, and could basically send a NOTIFY to QNE2 and through the QNI's old path saying "Route Change" 0x02 - QNE2 will forward it to QNE1 - QNE1 would then at some point figure out QNI has disappeared, and will start removing the reservation using a tearing RESERVE - The tearing RESERVE will eventually hit QNE3, which noticies that it has an existing, and newer state (higher RSN), and will drop the tear "MN as QNR and data receiver": we could rely on routing changes to eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will then send back a RESPONSE saying "full QSPEC required". A subsequent full RESERVE will then set up the reservation on the new path. Or, in order to make it faster, we could use the following: - MN moves, gets a hint from GIST that routing has changed - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 - QNE4 will receive it, and forward it, same with QNE5 - The NOTIFY will hit QNE3, which notes that the message for a known session comes from a new SII-Handle. - QNE3 should then send a full RESERVE with a new RSN and an RII to QNE5 - QNE4 will receive the RESERVE, make the reservation, and forward it to the MN - The MN gets the RESERVE and replies with a RESPONSE The tear down: - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which again sends ti QNE1 Jukka On Thu, 14 Dec 2006, Hong Cheng wrote: > Hi Jukka, > > I would agree that the cross-over router should be left capable of tearing > down the unneeded reservations. Please see some comments inline below: > > cheers > > Cheng Hong > > > Jukka MJ Manner wrote: > > Hi all, > > > > If you look at how the NSIS protocols work, there is no way a node can > > make sure a tear-down was intiated by the QNI. A QNE receives a > > teardown from its upstream peer, but it can't tell whether that peer > > initiated the tear down in the first place, or the QNI. > > > > If I would do a "mobility enhanced QoS NSLP", I would tear down at the > > cross-over router the unnecessary reservation. Of course the spec can say > > "don't do it", but a QNE can not really confirm it isn't being done. And the > > QNI or the QNR can't see that either. > > > > The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to > > initiate a tear down", and thus leave the option open for a QNE to also do > > it. > > > > [Cheng] Agree. This should be left open. And I think the quoted text in > current QoS NSLP draft is reflecting this point. > > > Or we could make a new INFO_SPEC code for "reservation not need" which is a > > hint sent by the cross-over router to inform downstream QNEs on the old path > > that the MN has moved away. It is then up to each QNE to decide whether to > > remove the resources and state, or not. > > > > > > [Cheng] This option might lead to some problem though, since it could leave > the QNEs on the path unsynchronized should they decide to do different things > in response to the INFO_SPEC. > > > Jukka > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > Hi Jukka and all, > > > > > > I would like to clarify about tearing down operation. > > > > > > In section 3.2.11 (Rerouting), 5th paragraph, it is said, > > > "After the reservation on the new path is set up, the branching node > > > may want to tear down the reservation on the old path (sooner than > > > would result from normal soft-state time-out)." > > > > > > This means that the CRN will initiate the TEAR on the old path. > > > > > > At Munich Interim, It was discussed that tearing down from intermediate > > > node needs to be avoided because of session ownership issue. But I > > > cannot find any conclusion of this discussion. > > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > > > > > > Do we have any decision for "tearing down from intermediate node"? > > > > > > cheers, > > > Takako > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > Jukka MJ Manner wrote: > > > > > > > > > > Dear all, > > > > > > > > I sent the following request for feedback two weeks ago. No comments > > > > have been raised. I will wait until this Friday, then submit the draft. > > > > > > > > Jukka > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > I have done all the edits I had in my list to the QoS NSLP spec, the > > > > > main points are in recent thread with Roland. From the url below you > > > > > can find the current draft v. "13-pre1" and a diff to v. 12. > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > A direct link to the diff: > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > I would appreciate comments on the changes I did (what is wrong, what > > > > > I missed, etc.). > > > > > > > > > > > > > > > I still have one problem with the spec, namely the way the NSLP > > > > > suggests to handle mobility and path changes. I think we need to > > > > > review that statement, because it seems like a "hack" (playing with > > > > > the RSN value), and not really useful. And the interactions with GIST > > > > > look partly wrong. The folks working on the mobility draft (me > > > > > included) could comment. The section I'm talking about is 3.2.10, > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > BR, > > > > > Jukka > > > > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 10 05:32:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ak1-00010b-Ck; Wed, 10 Jan 2007 05:31:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ajq-0000ck-Q4 for nsis@ietf.org; Wed, 10 Jan 2007 05:31:22 -0500 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4agK-0002yt-VX for nsis@ietf.org; Wed, 10 Jan 2007 05:27:49 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id l0AARcgD029675; Wed, 10 Jan 2007 19:27:38 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l0AAReA20158; Wed, 10 Jan 2007 19:27:40 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id l0AARc717525; Wed, 10 Jan 2007 19:27:38 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 18:25:20 +0800 Message-ID: <45A4BEF2.5020109@sg.panasonic.com> Date: Wed, 10 Jan 2007 18:24:50 +0800 From: Hong Cheng User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jukka MJ Manner References: <20061213150313.5173.SANDA.TAKAKO@jp.panasonic.com> <4580CEAC.6000908@sg.panasonic.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2007 10:25:20.0945 (UTC) FILETIME=[A1A19A10:01C734A1] X-Spam-Score: 0.1 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: nsis@ietf.org, Takako Sanda Subject: [NSIS] Re: Clarification: tearing down from intermediate node 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, The operation is well analyzed. The text should be incorporated into the Mobility Applicability draft. I think generally a tear-down could be initiated by any QNE (e.g. the CRN), as long as it is along the direction from QNI to QNR. Please find a few more comments inline. cheers Cheng Hong Jukka MJ Manner wrote: > Hi Cheng, > > After re-reading the QoS NSLP spec, I think the spec is quite accurate in > how the NSLP supports mobility, and it seems to work properly. Tearing > down the reservation on the old path from the cross-over QNE would be good > to do, but not necessarily critical for the proper operation of the NSLP. > Yet, the current QoS NSLP spec mentions the tear-down at the cross-over > router. > > Consider the following scenario: > > > > [MN] [QNE1] --- [QNE2] ---\ > | \ > | [QNE3] --- [QNE6] --- [QNE7] --- > | / > V / > [MN] [QNE4] --- [QNE5]---/ > > > The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR > and receiver" > > "MN as QNI and data sender": we could rely on just the soft-state to > expire on the old path, and a new RESERVE on the new path, or use the > following, based on the NSLP draft text. > > - MN moves from peer QNE1 to QNE4 > - GIST gets a hint that routing has changed, triggers the NSLP > - The NSLP then sends a new full RESERVE with a new RSN > - The RESERVE hits QNE4, which makes reservation > - Then the RESERVE is forwarded to QNE5, which also makes the reservation > - Finally, the RESERVE hits QNE3, which makes a reservation and forwards > the RESERVE to QNE6, and so on > > The tear-down part: > - QNE3 also noticies that the SII-Handle has changed, and could basically > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > Change" 0x02 > - QNE2 will forward it to QNE1 > - QNE1 would then at some point figure out QNI has disappeared, and will > start removing the reservation using a tearing RESERVE How the QNE1 figure out the QNI has disappeared might require some enhancement. Maybe the "Route Change" indication from QNE3 could further identify whether it is upstream route changed or downstream route changed. It might help the QNE1 reach the conclusion faster. > - The tearing RESERVE will eventually hit QNE3, which noticies that it has > an existing, and newer state (higher RSN), and will drop the tear > > > "MN as QNR and data receiver": we could rely on routing changes to > eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will > then send back a RESPONSE saying "full QSPEC required". A subsequent > full RESERVE will then set up the reservation on the new path. Or, in > order to make it faster, we could use the following: > > - MN moves, gets a hint from GIST that routing has changed > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > - QNE4 will receive it, and forward it, same with QNE5 This is assuming the QNE4 has already been discovered. When the MN is QNR and data receiver, considering the discovery process, wouldn't sending a trigger to QNI directly result in a faster process? > - The NOTIFY will hit QNE3, which notes that the message for a known > session comes from a new SII-Handle. > - QNE3 should then send a full RESERVE with a new RSN and an RII to > QNE5 > - QNE4 will receive the RESERVE, make the reservation, and forward it to > the MN > - The MN gets the RESERVE and replies with a RESPONSE > > The tear down: > - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which > again sends ti QNE1 > > > Jukka > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > >> Hi Jukka, >> >> I would agree that the cross-over router should be left capable of tearing >> down the unneeded reservations. Please see some comments inline below: >> >> cheers >> >> Cheng Hong >> >> >> Jukka MJ Manner wrote: >>> Hi all, >>> >>> If you look at how the NSIS protocols work, there is no way a node can >>> make sure a tear-down was intiated by the QNI. A QNE receives a >>> teardown from its upstream peer, but it can't tell whether that peer >>> initiated the tear down in the first place, or the QNI. >>> >>> If I would do a "mobility enhanced QoS NSLP", I would tear down at the >>> cross-over router the unnecessary reservation. Of course the spec can say >>> "don't do it", but a QNE can not really confirm it isn't being done. And the >>> QNI or the QNR can't see that either. >>> >>> The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to >>> initiate a tear down", and thus leave the option open for a QNE to also do >>> it. >>> >> [Cheng] Agree. This should be left open. And I think the quoted text in >> current QoS NSLP draft is reflecting this point. >> >>> Or we could make a new INFO_SPEC code for "reservation not need" which is a >>> hint sent by the cross-over router to inform downstream QNEs on the old path >>> that the MN has moved away. It is then up to each QNE to decide whether to >>> remove the resources and state, or not. >>> >>> >> [Cheng] This option might lead to some problem though, since it could leave >> the QNEs on the path unsynchronized should they decide to do different things >> in response to the INFO_SPEC. >> >>> Jukka >>> >>> On Wed, 13 Dec 2006, Takako Sanda wrote: >>> >>> >>>> Hi Jukka and all, >>>> >>>> I would like to clarify about tearing down operation. >>>> >>>> In section 3.2.11 (Rerouting), 5th paragraph, it is said, >>>> "After the reservation on the new path is set up, the branching node >>>> may want to tear down the reservation on the old path (sooner than >>>> would result from normal soft-state time-out)." >>>> >>>> This means that the CRN will initiate the TEAR on the old path. >>>> >>>> At Munich Interim, It was discussed that tearing down from intermediate >>>> node needs to be avoided because of session ownership issue. But I >>>> cannot find any conclusion of this discussion. >>>> http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html >>>> >>>> Do we have any decision for "tearing down from intermediate node"? >>>> >>>> cheers, >>>> Takako >>>> >>>> >>>> >>>> On Wed, 06 Dec 2006 12:09:25 +0200 (EET) >>>> Jukka MJ Manner wrote: >>>> >>>> >>>>> Dear all, >>>>> >>>>> I sent the following request for feedback two weeks ago. No comments >>>>> have been raised. I will wait until this Friday, then submit the draft. >>>>> >>>>> Jukka >>>>> >>>>> On Tue, 21 Nov 2006, Jukka MJ Manner wrote: >>>>> >>>>> >>>>>> Hi all, >>>>>> >>>>>> I have done all the edits I had in my list to the QoS NSLP spec, the >>>>>> main points are in recent thread with Roland. From the url below you >>>>>> can find the current draft v. "13-pre1" and a diff to v. 12. >>>>>> >>>>>> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ >>>>>> >>>>>> A direct link to the diff: >>>>>> >>>>>> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html >>>>>> >>>>>> >>>>>> I would appreciate comments on the changes I did (what is wrong, what >>>>>> I missed, etc.). >>>>>> >>>>>> >>>>>> I still have one problem with the spec, namely the way the NSLP >>>>>> suggests to handle mobility and path changes. I think we need to >>>>>> review that statement, because it seems like a "hack" (playing with >>>>>> the RSN value), and not really useful. And the interactions with GIST >>>>>> look partly wrong. The folks working on the mobility draft (me >>>>>> included) could comment. The section I'm talking about is 3.2.10, >>>>>> especially 3.2.10.2, in the v.12 draft. >>>>>> >>>>>> BR, >>>>>> Jukka >>>>>> >>>>>> >> >> >> > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 10 05:35:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4anc-0002tl-Td; Wed, 10 Jan 2007 05:35:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4anb-0002t6-Ej for nsis@ietf.org; Wed, 10 Jan 2007 05:35:15 -0500 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 1H4anP-00058Q-I1 for nsis@ietf.org; Wed, 10 Jan 2007 05:35:15 -0500 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, 10 Jan 2007 12:35:00 +0200 id 000AFE15.45A4C154.00006BE7 Date: Wed, 10 Jan 2007 12:35:00 +0200 (EET) From: Jukka MJ Manner To: Hong Cheng In-Reply-To: <45A4BEF2.5020109@sg.panasonic.com> Message-ID: References: <20061213150313.5173.SANDA.TAKAKO@jp.panasonic.com> <4580CEAC.6000908@sg.panasonic.com> <45A4BEF2.5020109@sg.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: nsis@ietf.org, Takako Sanda Subject: [NSIS] Re: Clarification: tearing down from intermediate node 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 answers below. Jukka On Wed, 10 Jan 2007, Hong Cheng wrote: > Hi Jukka, > > The operation is well analyzed. The text should be incorporated into the > Mobility Applicability draft. I think generally a tear-down could be > initiated by any QNE (e.g. the CRN), as long as it is along the direction > from QNI to QNR. > > Please find a few more comments inline. > > cheers > > Cheng Hong > > > Jukka MJ Manner wrote: > > Hi Cheng, > > > > After re-reading the QoS NSLP spec, I think the spec is quite accurate in > > how the NSLP supports mobility, and it seems to work properly. Tearing down > > the reservation on the old path from the cross-over QNE would be good to > > do, but not necessarily critical for the proper operation of the NSLP. Yet, > > the current QoS NSLP spec mentions the tear-down at the cross-over router. > > > > Consider the following scenario: > > > > > > > > [MN] [QNE1] --- [QNE2] ---\ > > | \ > > | [QNE3] --- [QNE6] --- [QNE7] --- > > | / > > V / > > [MN] [QNE4] --- [QNE5]---/ > > > > > > The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR > > and receiver" > > > > "MN as QNI and data sender": we could rely on just the soft-state to expire > > on the old path, and a new RESERVE on the new path, or use the following, > > based on the NSLP draft text. > > > > - MN moves from peer QNE1 to QNE4 > > - GIST gets a hint that routing has changed, triggers the NSLP > > - The NSLP then sends a new full RESERVE with a new RSN > > - The RESERVE hits QNE4, which makes reservation > > - Then the RESERVE is forwarded to QNE5, which also makes the reservation > > - Finally, the RESERVE hits QNE3, which makes a reservation and forwards > > the RESERVE to QNE6, and so on > > > > The tear-down part: > > - QNE3 also noticies that the SII-Handle has changed, and could basically > > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > > Change" 0x02 > > - QNE2 will forward it to QNE1 > > - QNE1 would then at some point figure out QNI has disappeared, and will > > start removing the reservation using a tearing RESERVE > > How the QNE1 figure out the QNI has disappeared might require some > enhancement. Maybe the "Route Change" indication from QNE3 could further > identify whether it is upstream route changed or downstream route changed. It > might help the QNE1 reach the conclusion faster. JM: I believe this falls a bit down the path of security. What can a QNE trust? I would rather let the QNE1 figure by itself that the QNI has disappeared. The message sent is only a hint that tells QNE1 to verify if QNI is still there. It would only take a few seconds, basically once the retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce that the QNI is gone. > > > - The tearing RESERVE will eventually hit QNE3, which noticies that it has > > an existing, and newer state (higher RSN), and will drop the tear > > > > > > "MN as QNR and data receiver": we could rely on routing changes to > > eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will > > then send back a RESPONSE saying "full QSPEC required". A subsequent full > > RESERVE will then set up the reservation on the new path. Or, in order to > > make it faster, we could use the following: > > > > - MN moves, gets a hint from GIST that routing has changed > > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > > - QNE4 will receive it, and forward it, same with QNE5 > > This is assuming the QNE4 has already been discovered. When the MN is QNR and > data receiver, considering the discovery process, wouldn't sending a trigger > to QNI directly result in a faster process? JM: Once GIST tells a routing change has happened, the NSLP will ask GIST to send the NOTIFY towards the QNI. For doing that, GIST must find the next peer QNE node, which is QNE4 in this case. Since the NSLP works hop-by-hop, you can't really send a message directly to the QNI, without going through all the intermediate nodes. > > > - The NOTIFY will hit QNE3, which notes that the message for a known > > session comes from a new SII-Handle. > > - QNE3 should then send a full RESERVE with a new RSN and an RII to > > QNE5 > > - QNE4 will receive the RESERVE, make the reservation, and forward it to > > the MN > > - The MN gets the RESERVE and replies with a RESPONSE > > > > The tear down: > > - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which > > again sends ti QNE1 > > > > > > Jukka > > > > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > > > > > Hi Jukka, > > > > > > I would agree that the cross-over router should be left capable of > > > tearing > > > down the unneeded reservations. Please see some comments inline below: > > > > > > cheers > > > > > > Cheng Hong > > > > > > > > > Jukka MJ Manner wrote: > > > > Hi all, > > > > > > > > If you look at how the NSIS protocols work, there is no way a node can > > > > make sure a tear-down was intiated by the QNI. A QNE receives a > > > > teardown from its upstream peer, but it can't tell whether that peer > > > > initiated the tear down in the first place, or the QNI. > > > > > > > > If I would do a "mobility enhanced QoS NSLP", I would tear down at the > > > > cross-over router the unnecessary reservation. Of course the spec can > > > > say > > > > "don't do it", but a QNE can not really confirm it isn't being done. > > > > And the > > > > QNI or the QNR can't see that either. > > > > > > > > The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to > > > > initiate a tear down", and thus leave the option open for a QNE to also > > > > do > > > > it. > > > > > > > [Cheng] Agree. This should be left open. And I think the quoted text in > > > current QoS NSLP draft is reflecting this point. > > > > > > > Or we could make a new INFO_SPEC code for "reservation not need" which > > > > is a > > > > hint sent by the cross-over router to inform downstream QNEs on the old > > > > path > > > > that the MN has moved away. It is then up to each QNE to decide whether > > > > to > > > > remove the resources and state, or not. > > > > > > > > > > > [Cheng] This option might lead to some problem though, since it could > > > leave > > > the QNEs on the path unsynchronized should they decide to do different > > > things > > > in response to the INFO_SPEC. > > > > > > > Jukka > > > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > > > > > > > Hi Jukka and all, > > > > > > > > > > I would like to clarify about tearing down operation. > > > > > > > > > > In section 3.2.11 (Rerouting), 5th paragraph, it is said, > > > > > "After the reservation on the new path is set up, the branching > > > > > node > > > > > may want to tear down the reservation on the old path (sooner than > > > > > would result from normal soft-state time-out)." > > > > > > > > > > This means that the CRN will initiate the TEAR on the old path. > > > > > > > > > > At Munich Interim, It was discussed that tearing down from > > > > > intermediate > > > > > node needs to be avoided because of session ownership issue. But I > > > > > cannot find any conclusion of this discussion. > > > > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > > > > > > > > > > Do we have any decision for "tearing down from intermediate node"? > > > > > > > > > > cheers, > > > > > Takako > > > > > > > > > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > I sent the following request for feedback two weeks ago. No > > > > > > comments > > > > > > have been raised. I will wait until this Friday, then submit the > > > > > > draft. > > > > > > > > > > > > Jukka > > > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I have done all the edits I had in my list to the QoS NSLP spec, > > > > > > > the > > > > > > > main points are in recent thread with Roland. From the url below > > > > > > > you > > > > > > > can find the current draft v. "13-pre1" and a diff to v. 12. > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > > > > > A direct link to the diff: > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > > > > > > > I would appreciate comments on the changes I did (what is wrong, > > > > > > > what > > > > > > > I missed, etc.). > > > > > > > > > > > > > > > > > > > > > I still have one problem with the spec, namely the way the NSLP > > > > > > > suggests to handle mobility and path changes. I think we need to > > > > > > > review that statement, because it seems like a "hack" (playing > > > > > > > with > > > > > > > the RSN value), and not really useful. And the interactions with > > > > > > > GIST > > > > > > > look partly wrong. The folks working on the mobility draft (me > > > > > > > included) could comment. The section I'm talking about is 3.2.10, > > > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > > > > > BR, > > > > > > > Jukka > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 10 07:14:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4cKv-0003da-3P; Wed, 10 Jan 2007 07:13:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4cKu-0003dU-9O for nsis@ietf.org; Wed, 10 Jan 2007 07:13:44 -0500 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 1H4cKp-0006ni-Uu for nsis@ietf.org; Wed, 10 Jan 2007 07:13:44 -0500 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; Wed, 10 Jan 2007 14:13:34 +0200 id 000AFE1C.45A4D86E.00001C4C Date: Wed, 10 Jan 2007 14:13:34 +0200 (EET) 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: 8abaac9e10c826e8252866cbe6766464 Subject: [NSIS] QoS NSLP: RSN + tear down 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 now have the QoS NSLP spec updated with the recent comments. One issue remains, that I'd like a confirmation before sending out to you for review v. "13-pre2". Issue: RSN + tear down We have earlier decided that RSNs would not be interpreted when tearing down a reservation. However, we actually need to interpret them, otherwise the path change mechanism currently specified will not work (see my previous email about the mobility work today). Thus, I propose that when a node receives a tearing RESERVE, it MUST interpret and compare the RSN in the message to the stored RSN. 1. If the RSN values match, the QNE MUST perform the tear down and send out a tearing RESERVE with the RSN object. 2. If the received RSN is greater than the stored RSN, the QNE MUST perform the tear down, and send out a tearing RESERVE with the received greater RSN value. 3. If the received RSN is less than the stored RSN, the QNE MUST silently drop the tearing RESERVE, and not perform any tear down, nor send out any tearing RESERVE. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 12 06:00:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5K8j-0004Nb-VI; Fri, 12 Jan 2007 06:00:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5K8i-0004Mh-9K for nsis@ietf.org; Fri, 12 Jan 2007 06:00:04 -0500 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5K8e-0003No-Bf for nsis@ietf.org; Fri, 12 Jan 2007 06:00:04 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id l0CAxnTf007418; Fri, 12 Jan 2007 19:59:49 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l0CAxmG22859; Fri, 12 Jan 2007 19:59:48 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id l0CAxok26068; Fri, 12 Jan 2007 19:59:50 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml25) id l0CAxnkJ025368; Fri, 12 Jan 2007 19:59:49 +0900 (JST) Received: from [10.68.136.53] by soml25.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id l0CAxd5m025184; Fri, 12 Jan 2007 19:59:39 +0900 (JST) Date: Fri, 12 Jan 2007 20:03:33 +0900 From: Takako Sanda To: Jukka MJ Manner Subject: Re: [NSIS] Re: Clarification: tearing down from intermediate node In-Reply-To: References: <45A4BEF2.5020109@sg.panasonic.com> Message-Id: <20070112195212.1121.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: Hong Cheng , 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, I still have a question for the operation below. > > > The tear-down part: > > > - QNE3 also noticies that the SII-Handle has changed, and could basically > > > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > > > Change" 0x02 > > > - QNE2 will forward it to QNE1 > > > - QNE1 would then at some point figure out QNI has disappeared, and will > > > start removing the reservation using a tearing RESERVE > > > > How the QNE1 figure out the QNI has disappeared might require some > > enhancement. Maybe the "Route Change" indication from QNE3 could further > > identify whether it is upstream route changed or downstream route changed. It > > might help the QNE1 reach the conclusion faster. > > JM: I believe this falls a bit down the path of security. What can a QNE > trust? I would rather let the QNE1 figure by itself that the QNI has > disappeared. The message sent is only a hint that tells QNE1 to verify if > QNI is still there. It would only take a few seconds, basically once the > retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce > that the QNI is gone. How does QNE1 know the next peer was NI? In order to know this, I guess, QNE1 needs to have received an explicit notification from NI in advance. cheers, Takako On Wed, 10 Jan 2007 12:35:00 +0200 (EET) Jukka MJ Manner wrote: > > Hi, > > some answers below. > > Jukka > > On Wed, 10 Jan 2007, Hong Cheng wrote: > > > Hi Jukka, > > > > The operation is well analyzed. The text should be incorporated into the > > Mobility Applicability draft. I think generally a tear-down could be > > initiated by any QNE (e.g. the CRN), as long as it is along the direction > > from QNI to QNR. > > > > Please find a few more comments inline. > > > > cheers > > > > Cheng Hong > > > > > > Jukka MJ Manner wrote: > > > Hi Cheng, > > > > > > After re-reading the QoS NSLP spec, I think the spec is quite accurate in > > > how the NSLP supports mobility, and it seems to work properly. Tearing down > > > the reservation on the old path from the cross-over QNE would be good to > > > do, but not necessarily critical for the proper operation of the NSLP. Yet, > > > the current QoS NSLP spec mentions the tear-down at the cross-over router. > > > > > > Consider the following scenario: > > > > > > > > > > > > [MN] [QNE1] --- [QNE2] ---\ > > > | \ > > > | [QNE3] --- [QNE6] --- [QNE7] --- > > > | / > > > V / > > > [MN] [QNE4] --- [QNE5]---/ > > > > > > > > > The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR > > > and receiver" > > > > > > "MN as QNI and data sender": we could rely on just the soft-state to expire > > > on the old path, and a new RESERVE on the new path, or use the following, > > > based on the NSLP draft text. > > > > > > - MN moves from peer QNE1 to QNE4 > > > - GIST gets a hint that routing has changed, triggers the NSLP > > > - The NSLP then sends a new full RESERVE with a new RSN > > > - The RESERVE hits QNE4, which makes reservation > > > - Then the RESERVE is forwarded to QNE5, which also makes the reservation > > > - Finally, the RESERVE hits QNE3, which makes a reservation and forwards > > > the RESERVE to QNE6, and so on > > > > > > The tear-down part: > > > - QNE3 also noticies that the SII-Handle has changed, and could basically > > > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > > > Change" 0x02 > > > - QNE2 will forward it to QNE1 > > > - QNE1 would then at some point figure out QNI has disappeared, and will > > > start removing the reservation using a tearing RESERVE > > > > How the QNE1 figure out the QNI has disappeared might require some > > enhancement. Maybe the "Route Change" indication from QNE3 could further > > identify whether it is upstream route changed or downstream route changed. It > > might help the QNE1 reach the conclusion faster. > > JM: I believe this falls a bit down the path of security. What can a QNE > trust? I would rather let the QNE1 figure by itself that the QNI has > disappeared. The message sent is only a hint that tells QNE1 to verify if > QNI is still there. It would only take a few seconds, basically once the > retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce > that the QNI is gone. > > > > > > - The tearing RESERVE will eventually hit QNE3, which noticies that it has > > > an existing, and newer state (higher RSN), and will drop the tear > > > > > > > > > "MN as QNR and data receiver": we could rely on routing changes to > > > eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will > > > then send back a RESPONSE saying "full QSPEC required". A subsequent full > > > RESERVE will then set up the reservation on the new path. Or, in order to > > > make it faster, we could use the following: > > > > > > - MN moves, gets a hint from GIST that routing has changed > > > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > > > - QNE4 will receive it, and forward it, same with QNE5 > > > > This is assuming the QNE4 has already been discovered. When the MN is QNR and > > data receiver, considering the discovery process, wouldn't sending a trigger > > to QNI directly result in a faster process? > > JM: Once GIST tells a routing change has happened, the NSLP will ask GIST > to send the NOTIFY towards the QNI. For doing that, GIST must find the > next peer QNE node, which is QNE4 in this case. Since the NSLP works > hop-by-hop, you can't really send a message directly to the QNI, without > going through all the intermediate nodes. > > > > > > - The NOTIFY will hit QNE3, which notes that the message for a known > > > session comes from a new SII-Handle. > > > - QNE3 should then send a full RESERVE with a new RSN and an RII to > > > QNE5 > > > - QNE4 will receive the RESERVE, make the reservation, and forward it to > > > the MN > > > - The MN gets the RESERVE and replies with a RESPONSE > > > > > > The tear down: > > > - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which > > > again sends ti QNE1 > > > > > > > > > Jukka > > > > > > > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > > > > > > > Hi Jukka, > > > > > > > > I would agree that the cross-over router should be left capable of > > > > tearing > > > > down the unneeded reservations. Please see some comments inline below: > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > Hi all, > > > > > > > > > > If you look at how the NSIS protocols work, there is no way a node can > > > > > make sure a tear-down was intiated by the QNI. A QNE receives a > > > > > teardown from its upstream peer, but it can't tell whether that peer > > > > > initiated the tear down in the first place, or the QNI. > > > > > > > > > > If I would do a "mobility enhanced QoS NSLP", I would tear down at the > > > > > cross-over router the unnecessary reservation. Of course the spec can > > > > > say > > > > > "don't do it", but a QNE can not really confirm it isn't being done. > > > > > And the > > > > > QNI or the QNR can't see that either. > > > > > > > > > > The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to > > > > > initiate a tear down", and thus leave the option open for a QNE to also > > > > > do > > > > > it. > > > > > > > > > [Cheng] Agree. This should be left open. And I think the quoted text in > > > > current QoS NSLP draft is reflecting this point. > > > > > > > > > Or we could make a new INFO_SPEC code for "reservation not need" which > > > > > is a > > > > > hint sent by the cross-over router to inform downstream QNEs on the old > > > > > path > > > > > that the MN has moved away. It is then up to each QNE to decide whether > > > > > to > > > > > remove the resources and state, or not. > > > > > > > > > > > > > > [Cheng] This option might lead to some problem though, since it could > > > > leave > > > > the QNEs on the path unsynchronized should they decide to do different > > > > things > > > > in response to the INFO_SPEC. > > > > > > > > > Jukka > > > > > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > > > > > > > > > > Hi Jukka and all, > > > > > > > > > > > > I would like to clarify about tearing down operation. > > > > > > > > > > > > In section 3.2.11 (Rerouting), 5th paragraph, it is said, > > > > > > "After the reservation on the new path is set up, the branching > > > > > > node > > > > > > may want to tear down the reservation on the old path (sooner than > > > > > > would result from normal soft-state time-out)." > > > > > > > > > > > > This means that the CRN will initiate the TEAR on the old path. > > > > > > > > > > > > At Munich Interim, It was discussed that tearing down from > > > > > > intermediate > > > > > > node needs to be avoided because of session ownership issue. But I > > > > > > cannot find any conclusion of this discussion. > > > > > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > > > > > > > > > > > > Do we have any decision for "tearing down from intermediate node"? > > > > > > > > > > > > cheers, > > > > > > Takako > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > I sent the following request for feedback two weeks ago. No > > > > > > > comments > > > > > > > have been raised. I will wait until this Friday, then submit the > > > > > > > draft. > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I have done all the edits I had in my list to the QoS NSLP spec, > > > > > > > > the > > > > > > > > main points are in recent thread with Roland. From the url below > > > > > > > > you > > > > > > > > can find the current draft v. "13-pre1" and a diff to v. 12. > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > > > > > > > A direct link to the diff: > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > > > > > > > > > > I would appreciate comments on the changes I did (what is wrong, > > > > > > > > what > > > > > > > > I missed, etc.). > > > > > > > > > > > > > > > > > > > > > > > > I still have one problem with the spec, namely the way the NSLP > > > > > > > > suggests to handle mobility and path changes. I think we need to > > > > > > > > review that statement, because it seems like a "hack" (playing > > > > > > > > with > > > > > > > > the RSN value), and not really useful. And the interactions with > > > > > > > > GIST > > > > > > > > look partly wrong. The folks working on the mobility draft (me > > > > > > > > included) could comment. The section I'm talking about is 3.2.10, > > > > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > > > > > > > BR, > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis ----- Takako SANDA Next-Generation Mobile Communications Development Center, Matsushita Electric Industrial Co., Ltd. (Panasonic) Phone: +81 46 840 5764 Fax: +81 46 840 5122 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 12 06:46:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5KrR-0004Bn-E2; Fri, 12 Jan 2007 06:46:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5KrP-0004Ba-TB for nsis@ietf.org; Fri, 12 Jan 2007 06:46:15 -0500 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5KrL-0003px-1d for nsis@ietf.org; Fri, 12 Jan 2007 06:46:15 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id l0CBk4rF012096; Fri, 12 Jan 2007 20:46:04 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id l0CBk7V02959; Fri, 12 Jan 2007 20:46:07 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id l0CBk6607349; Fri, 12 Jan 2007 20:46:06 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml21) id l0CBk6qF011868; Fri, 12 Jan 2007 20:46:06 +0900 (JST) Received: from [10.68.136.53] by soml21.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id l0CBk0XJ011724; Fri, 12 Jan 2007 20:46:00 +0900 (JST) Date: Fri, 12 Jan 2007 20:49:54 +0900 From: Takako Sanda To: Jukka MJ Manner Subject: Re: [NSIS] Re: Clarification: tearing down from intermediate node In-Reply-To: References: <4580CEAC.6000908@sg.panasonic.com> Message-Id: <20070112201001.1124.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: Hong Cheng , 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, I have another concern about the operation for overlapping section, (i.e. [QNE3] --- [QNE6] --- [QNE7] --- ). If MN's CoA is changed after it's movement, MRI and packet classifier is also changed. Therefore reservation for the overlapping section also must be new. In the "MN as QNI and data sender" scenario below, old reservation in the overlapping section is not removed because QNE3 drops tearing RESERVE. Therfore, some mechanisms may be necessary:- - QNE3 perform both RESERVE for new state and tear RESERVE for old state when it receives RESERVE from QNE5. Or, - QNE3 forwards tear RESERVE to QNE6 when it receives tear RESERVE from QNE2. (Although it remains so called "double resource reservation issue"...) In the "MN as QNR and data receiver" scenario below, new reservation for overlapping is not performed. Therfore, operation may need to be changed, such as:- - NOTIFY form MN goes to QNI (i.e. QNE3 does not stop it), and QNI sends both RESERVE and tear RESERVE to MN and QNE1, respectively. Or, - QNE3 performs localized RESERVE and tear RESERVE as shown below, but NOTFY also goes to NI, and NI performs "scoping" RESERVE and tear RESERVE. cheers, Takako On Wed, 10 Jan 2007 11:36:57 +0200 (EET) Jukka MJ Manner wrote: > > Hi Cheng, > > After re-reading the QoS NSLP spec, I think the spec is quite accurate in > how the NSLP supports mobility, and it seems to work properly. Tearing > down the reservation on the old path from the cross-over QNE would be good > to do, but not necessarily critical for the proper operation of the NSLP. > Yet, the current QoS NSLP spec mentions the tear-down at the cross-over > router. > > Consider the following scenario: > > > > [MN] [QNE1] --- [QNE2] ---\ > | \ > | [QNE3] --- [QNE6] --- [QNE7] --- > | / > V / > [MN] [QNE4] --- [QNE5]---/ > > > The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR > and receiver" > > "MN as QNI and data sender": we could rely on just the soft-state to > expire on the old path, and a new RESERVE on the new path, or use the > following, based on the NSLP draft text. > > - MN moves from peer QNE1 to QNE4 > - GIST gets a hint that routing has changed, triggers the NSLP > - The NSLP then sends a new full RESERVE with a new RSN > - The RESERVE hits QNE4, which makes reservation > - Then the RESERVE is forwarded to QNE5, which also makes the reservation > - Finally, the RESERVE hits QNE3, which makes a reservation and forwards > the RESERVE to QNE6, and so on > > The tear-down part: > - QNE3 also noticies that the SII-Handle has changed, and could basically > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > Change" 0x02 > - QNE2 will forward it to QNE1 > - QNE1 would then at some point figure out QNI has disappeared, and will > start removing the reservation using a tearing RESERVE > - The tearing RESERVE will eventually hit QNE3, which noticies that it has > an existing, and newer state (higher RSN), and will drop the tear > > > "MN as QNR and data receiver": we could rely on routing changes to > eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will > then send back a RESPONSE saying "full QSPEC required". A subsequent > full RESERVE will then set up the reservation on the new path. Or, in > order to make it faster, we could use the following: > > - MN moves, gets a hint from GIST that routing has changed > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > - QNE4 will receive it, and forward it, same with QNE5 > - The NOTIFY will hit QNE3, which notes that the message for a known > session comes from a new SII-Handle. > - QNE3 should then send a full RESERVE with a new RSN and an RII to > QNE5 > - QNE4 will receive the RESERVE, make the reservation, and forward it to > the MN > - The MN gets the RESERVE and replies with a RESPONSE > > The tear down: > - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which > again sends ti QNE1 > > > Jukka > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > > > Hi Jukka, > > > > I would agree that the cross-over router should be left capable of tearing > > down the unneeded reservations. Please see some comments inline below: > > > > cheers > > > > Cheng Hong > > > > > > Jukka MJ Manner wrote: > > > Hi all, > > > > > > If you look at how the NSIS protocols work, there is no way a node can > > > make sure a tear-down was intiated by the QNI. A QNE receives a > > > teardown from its upstream peer, but it can't tell whether that peer > > > initiated the tear down in the first place, or the QNI. > > > > > > If I would do a "mobility enhanced QoS NSLP", I would tear down at the > > > cross-over router the unnecessary reservation. Of course the spec can say > > > "don't do it", but a QNE can not really confirm it isn't being done. And the > > > QNI or the QNR can't see that either. > > > > > > The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to > > > initiate a tear down", and thus leave the option open for a QNE to also do > > > it. > > > > > > > [Cheng] Agree. This should be left open. And I think the quoted text in > > current QoS NSLP draft is reflecting this point. > > > > > Or we could make a new INFO_SPEC code for "reservation not need" which is a > > > hint sent by the cross-over router to inform downstream QNEs on the old path > > > that the MN has moved away. It is then up to each QNE to decide whether to > > > remove the resources and state, or not. > > > > > > > > > > [Cheng] This option might lead to some problem though, since it could leave > > the QNEs on the path unsynchronized should they decide to do different things > > in response to the INFO_SPEC. > > > > > Jukka > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > > > > Hi Jukka and all, > > > > > > > > I would like to clarify about tearing down operation. > > > > > > > > In section 3.2.11 (Rerouting), 5th paragraph, it is said, > > > > "After the reservation on the new path is set up, the branching node > > > > may want to tear down the reservation on the old path (sooner than > > > > would result from normal soft-state time-out)." > > > > > > > > This means that the CRN will initiate the TEAR on the old path. > > > > > > > > At Munich Interim, It was discussed that tearing down from intermediate > > > > node needs to be avoided because of session ownership issue. But I > > > > cannot find any conclusion of this discussion. > > > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > > > > > > > > Do we have any decision for "tearing down from intermediate node"? > > > > > > > > cheers, > > > > Takako > > > > > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > > Jukka MJ Manner wrote: > > > > > > > > > > > > > Dear all, > > > > > > > > > > I sent the following request for feedback two weeks ago. No comments > > > > > have been raised. I will wait until this Friday, then submit the draft. > > > > > > > > > > Jukka > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > I have done all the edits I had in my list to the QoS NSLP spec, the > > > > > > main points are in recent thread with Roland. From the url below you > > > > > > can find the current draft v. "13-pre1" and a diff to v. 12. > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > > > A direct link to the diff: > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > > > > I would appreciate comments on the changes I did (what is wrong, what > > > > > > I missed, etc.). > > > > > > > > > > > > > > > > > > I still have one problem with the spec, namely the way the NSLP > > > > > > suggests to handle mobility and path changes. I think we need to > > > > > > review that statement, because it seems like a "hack" (playing with > > > > > > the RSN value), and not really useful. And the interactions with GIST > > > > > > look partly wrong. The folks working on the mobility draft (me > > > > > > included) could comment. The section I'm talking about is 3.2.10, > > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > > > BR, > > > > > > 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 Jan 12 12:45:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QTI-0007cz-57; Fri, 12 Jan 2007 12:45:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QTH-0007bs-Io for nsis@ietf.org; Fri, 12 Jan 2007 12:45:43 -0500 Received: from mo-p00-ob.rzone.de ([81.169.146.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5QTG-0005wJ-7Y for nsis@ietf.org; Fri, 12 Jan 2007 12:45:43 -0500 Received: from [192.168.178.89] (p5484C059.dip0.t-ipconnect.de [84.132.192.89]) by post.webmailer.de (mrclete mo21) (RZmta 3.11) with ESMTP id j0CEBddC0023b9; Fri, 12 Jan 2007 18:45:37 +0100 (MET) Date: Fri, 12 Jan 2007 18:45:37 +0100 (MET) Message-ID: <45A7C894.6010402@cs.uni-goettingen.de> From: Bernd Schloer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] Consensus on: Removed the QSPEC control information References: <000901c73307$bb20dff0$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <000901c73307$bb20dff0$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RZG-AUTH: gNvC5ZWVA5d1mEPfeXALj6w= X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: john.loughney@nokia.com, gash@att.com, jmanner@cs.Helsinki.FI, nsis@ietf.org, oran@cisco.com, 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 Hi, I also think that such a draft is very useful. It is preferable to have a single QoS NSLP implementation which operates with the different QOSMs. Implementing a QOSM gets easier. I would like to contribute to it. Best Regards, Bernd Georgios Karagiannis wrote: > Hi John and Jukka > > I think that the idea of writting such a draft is a very good point! > As an example the RMD-QOSM affects the common message processing, and > therefore we need different implementations. This applies to various > tunneling, session binding, and separate signaling sessions (such as > refresh, release, > Unsuccessful resdervations, bi-directional reservations, severe congestion > handling, > congestion notification handling, etc.) that can be used > within a domain. > > It will be great to have such a draft andf I would very > much like to help Jukka, if Jukka agrees, on writting it! > > > Best Regards, > Georgios > > > > >>-----Original Message----- >>From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>Sent: maandag 8 januari 2007 5:46 >>To: jmanner@cs.Helsinki.FI >>Cc: karagian@cs.utwente.nl; oran@cisco.com; >>attila.bader@ericsson.com; gash@att.com; nsis@ietf.org >>Subject: RE: [NSIS] Consensus on: Removed the QSPEC control >>information >> >>Hi Jukka, >> >> >>>That is actually a good point. So far I have hoped that we >> >>can clearly >> >>>de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP >>>implementation can run with all different RMFs and QOSMs. >> >>I think that is a good goal. >> >> >>>If a QOSM affects the common message processing, we need different >>>implementations. Yet, I guess this also applies to various >> >>tunneling, >> >>>session binding, and separate signaling sessions that might be used >>>within a domain. >> >>I agree. >> >> >>>Do we need to document how the RMF and QoS NSLP fit >> >>together, what is >> >>>passed between the RMF and NSLP, what are the API issues, >> >>what kind on >> >>>asymmetric triggers the RMF can send to the NSLP, etc. I >> >>think we need >> >>>to write such a draft, and document all the interactions. If we have >>>that written down, we can more easily define what is a >>>standards-compliant implementation of a QOSM/RMF, and what is not. >>> >>>If you think that would be good, I could write a first draft. >> >>I think this is a good idea for a draft, and probably QoSM >>documents might need to have some of this information, as it >>specifically applies for the specific QoSM. >> >>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 Fri Jan 12 13:02:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qjc-00034Q-PX; Fri, 12 Jan 2007 13:02:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qjc-00034K-3o for nsis@ietf.org; Fri, 12 Jan 2007 13:02:36 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5QjZ-0000rD-Jp for nsis@ietf.org; Fri, 12 Jan 2007 13:02:36 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l0CI29jI008621 for ; Fri, 12 Jan 2007 19:02:21 +0100 (MET) From: "Georgios Karagiannis" To: References: <000901c73307$bb20dff0$4c0d5982@dynamic.ewi.utwente.nl> <45A7C894.6010402@cs.uni-goettingen.de> Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Date: Fri, 12 Jan 2007 19:02:14 +0100 Message-ID: <004901c73673$cddf7060$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.3028 Thread-Index: Acc2cZybN4fh3vQERC+KCr7DEJaOjwAARZkg In-Reply-To: <45A7C894.6010402@cs.uni-goettingen.de> X-Spam-Score: 0.542 () AWL,FVGT_s_OBFU_Q1,J_CHICKENPOX_53 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 12 Jan 2007 19:02:22 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 Lets clarify some issues. According to the previous discussions I could conclude that a common QOS-NSLP message processing will mean in this case that the QOS-NSLP has to support all features that are related to various signaling features such as: * tunneling, * stateless and bypassing, * session binding, * and separate and parallel signaling sessions that support the edge-to-edge and end-to-edge signaling (such as refresh, release, Unsuccessful resdervations, modification of reservations severe congestion handling, congestion notification handling, etc. for unidirectional and bi-directional reservations) that can be used within a domain. Thus this will mean that the QOS-NSLP specification should provide signaling means for all the above. Best Regards, Georgios > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] > Sent: vrijdag 12 januari 2007 18:46 > To: Georgios Karagiannis > Cc: john.loughney@nokia.com; gash@att.com; > jmanner@cs.Helsinki.FI; nsis@ietf.org; oran@cisco.com; > attila.bader@ericsson.com > Subject: Re: [NSIS] Consensus on: Removed the QSPEC control > information > > Hi, > > I also think that such a draft is very useful. It is > preferable to have a single QoS NSLP implementation which > operates with the different QOSMs. Implementing a QOSM gets > easier. I would like to contribute to it. > > Best Regards, > Bernd > > > > Georgios Karagiannis wrote: > > Hi John and Jukka > > > > I think that the idea of writting such a draft is a very good point! > > As an example the RMD-QOSM affects the common message > processing, and > > therefore we need different implementations. This applies > to various > > tunneling, session binding, and separate signaling sessions > (such as > > refresh, release, Unsuccessful resdervations, bi-directional > > reservations, severe congestion handling, congestion notification > > handling, etc.) that can be used within a domain. > > > > It will be great to have such a draft andf I would very > much like to > > help Jukka, if Jukka agrees, on writting it! > > > > > > Best Regards, > > Georgios > > > > > > > > > >>-----Original Message----- > >>From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >>Sent: maandag 8 januari 2007 5:46 > >>To: jmanner@cs.Helsinki.FI > >>Cc: karagian@cs.utwente.nl; oran@cisco.com; > attila.bader@ericsson.com; > >>gash@att.com; nsis@ietf.org > >>Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > >>information > >> > >>Hi Jukka, > >> > >> > >>>That is actually a good point. So far I have hoped that we > >> > >>can clearly > >> > >>>de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP > >>>implementation can run with all different RMFs and QOSMs. > >> > >>I think that is a good goal. > >> > >> > >>>If a QOSM affects the common message processing, we need different > >>>implementations. Yet, I guess this also applies to various > >> > >>tunneling, > >> > >>>session binding, and separate signaling sessions that > might be used > >>>within a domain. > >> > >>I agree. > >> > >> > >>>Do we need to document how the RMF and QoS NSLP fit > >> > >>together, what is > >> > >>>passed between the RMF and NSLP, what are the API issues, > >> > >>what kind on > >> > >>>asymmetric triggers the RMF can send to the NSLP, etc. I > >> > >>think we need > >> > >>>to write such a draft, and document all the interactions. > If we have > >>>that written down, we can more easily define what is a > >>>standards-compliant implementation of a QOSM/RMF, and what is not. > >>> > >>>If you think that would be good, I could write a first draft. > >> > >>I think this is a good idea for a draft, and probably QoSM > documents > >>might need to have some of this information, as it specifically > >>applies for the specific QoSM. > >> > >>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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jan 14 12:02:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H68js-00007c-GP; Sun, 14 Jan 2007 12:01:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H68jq-00007I-OU for nsis@ietf.org; Sun, 14 Jan 2007 12:01:46 -0500 Received: from mo-p00-ob.rzone.de ([81.169.146.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H68jp-0001hb-CC for nsis@ietf.org; Sun, 14 Jan 2007 12:01:46 -0500 Received: from [192.168.178.101] (p5484B306.dip0.t-ipconnect.de [84.132.179.6]) by post.webmailer.de (klopstock mo4) (RZmta 3.11) with ESMTP id j0EADNp8002b8O for ; Sun, 14 Jan 2007 18:01:41 +0100 (MET) Date: Sun, 14 Jan 2007 18:01:41 +0100 (MET) Message-ID: <45AA6141.40702@cs.uni-goettingen.de> From: Bernd Schloer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] Consensus on: Removed the QSPEC control information References: <000901c73307$bb20dff0$4c0d5982@dynamic.ewi.utwente.nl> <45A7C894.6010402@cs.uni-goettingen.de> In-Reply-To: <45A7C894.6010402@cs.uni-goettingen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RZG-AUTH: gNvC5ZWVA5d1mEPfeXALj6w= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 comments to some of the recent consensus calls: I agree, that the QOSM specification SHOULD NOT be allowed to define new RMF functions and extend signaling functionality. Either tunneling a QSPEC or encapsulating it makes sense in my opinion. Where additional information in a local domain are needed the QOSM specification could define additional parameters. Which QoS NSLP signaling feature is used by QOSMs should be defined in the QoS NSLP draft rather than in the QSPEC draft. I agree here. Best Regards, Bernd Bernd Schloer wrote: > Hi, > > I also think that such a draft is very useful. It is preferable to > have a single QoS NSLP implementation which operates with the different > QOSMs. Implementing a QOSM gets easier. I would like to contribute to it. > > Best Regards, > Bernd > > > > Georgios Karagiannis wrote: > >> Hi John and Jukka >> >> I think that the idea of writting such a draft is a very good point! >> As an example the RMD-QOSM affects the common message processing, and >> therefore we need different implementations. This applies to various >> tunneling, session binding, and separate signaling sessions (such as >> refresh, release, Unsuccessful resdervations, bi-directional >> reservations, severe congestion >> handling, congestion notification handling, etc.) that can be used >> within a domain. >> >> It will be great to have such a draft andf I would very much like to >> help Jukka, if Jukka agrees, on writting it! >> >> >> Best Regards, >> Georgios >> >> >> >> >>> -----Original Message----- >>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: >>> maandag 8 januari 2007 5:46 >>> To: jmanner@cs.Helsinki.FI >>> Cc: karagian@cs.utwente.nl; oran@cisco.com; >>> attila.bader@ericsson.com; gash@att.com; nsis@ietf.org >>> Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information >>> >>> Hi Jukka, >>> >>> >>>> That is actually a good point. So far I have hoped that we >>> >>> >>> can clearly >>> >>>> de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP >>>> implementation can run with all different RMFs and QOSMs. >>> >>> >>> I think that is a good goal. >>> >>> >>>> If a QOSM affects the common message processing, we need different >>>> implementations. Yet, I guess this also applies to various >>> >>> >>> tunneling, >>> >>>> session binding, and separate signaling sessions that might be used >>>> within a domain. >>> >>> >>> I agree. >>> >>> >>>> Do we need to document how the RMF and QoS NSLP fit >>> >>> >>> together, what is >>> >>>> passed between the RMF and NSLP, what are the API issues, >>> >>> >>> what kind on >>> >>>> asymmetric triggers the RMF can send to the NSLP, etc. I >>> >>> >>> think we need >>> >>>> to write such a draft, and document all the interactions. If we have >>>> that written down, we can more easily define what is a >>>> standards-compliant implementation of a QOSM/RMF, and what is not. >>>> >>>> If you think that would be good, I could write a first draft. >>> >>> >>> I think this is a good idea for a draft, and probably QoSM documents >>> might need to have some of this information, as it specifically >>> applies for the specific QoSM. >>> >>> 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 15 03:45:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6NSz-0004FB-3m; Mon, 15 Jan 2007 03:45:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6NSy-0004F6-GM for nsis@ietf.org; Mon, 15 Jan 2007 03:45:20 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6NSx-0006PO-0e for nsis@ietf.org; Mon, 15 Jan 2007 03:45:20 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l0F8imYF009040; Mon, 15 Jan 2007 09:44:54 +0100 (MET) From: "Georgios Karagiannis" To: "'Bernd Schloer'" , References: <000901c73307$bb20dff0$4c0d5982@dynamic.ewi.utwente.nl><45A7C894.6010402@cs.uni-goettingen.de> <45AA6141.40702@cs.uni-goettingen.de> Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Date: Mon, 15 Jan 2007 09:44:58 +0100 Message-ID: <000201c73881$734aff60$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.3028 In-Reply-To: <45AA6141.40702@cs.uni-goettingen.de> Thread-Index: Acc3/fFsfVHan5VoSDKQFyLHqu4sNAAgrJWQ X-Spam-Score: 0.544 () AWL,FVGT_s_OBFU_Q1,J_CHICKENPOX_53 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 15 Jan 2007 09:44:55 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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 Thus you also agree with the below: According to the previous discussions I could conclude that a common QOS-NSLP message processing will mean in this case that the QOS-NSLP has to support all features that are related to various signaling features such as: * tunneling, * proxy functionality * aggregation functionality * stateless and bypassing, * session binding, * and separate and parallel signaling sessions that support the end-to-end, edge-to-edge and end-to-edge signaling such as: reservation initiation (ssuccessful reservation), refresh, release, unsuccessful resdervations, modification of reservations, severe congestion (or pre-emption) handling, congestion notification handling, etc. for sender initiated and receiver initiated unidirectional and bi-directional reservations that can be used end-to- end and within a domain. Thus this will mean that the QOS-NSLP specification should provide signaling means for all the above. Best Regards, Georgios > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] > Sent: zondag 14 januari 2007 18:02 > To: nsis@ietf.org > Subject: Re: [NSIS] Consensus on: Removed the QSPEC control > information > > Hi, > > a few comments to some of the recent consensus calls: > > I agree, that the QOSM specification SHOULD NOT be allowed to > define new RMF functions and extend signaling functionality. > > Either tunneling a QSPEC or encapsulating it makes sense in > my opinion. > Where additional information in a local domain are needed the > QOSM specification could define additional parameters. > > Which QoS NSLP signaling feature is used by QOSMs should be > defined in the QoS NSLP draft rather than in the QSPEC draft. > I agree here. > > Best Regards, > Bernd > > > Bernd Schloer wrote: > > Hi, > > > > I also think that such a draft is very useful. It is preferable to > > have a single QoS NSLP implementation which operates with the > > different QOSMs. Implementing a QOSM gets easier. I would > like to contribute to it. > > > > Best Regards, > > Bernd > > > > > > > > Georgios Karagiannis wrote: > > > >> Hi John and Jukka > >> > >> I think that the idea of writting such a draft is a very > good point! > >> As an example the RMD-QOSM affects the common message > processing, and > >> therefore we need different implementations. This applies > to various > >> tunneling, session binding, and separate signaling > sessions (such as > >> refresh, release, Unsuccessful resdervations, bi-directional > >> reservations, severe congestion handling, congestion notification > >> handling, etc.) that can be used within a domain. > >> > >> It will be great to have such a draft andf I would very > much like to > >> help Jukka, if Jukka agrees, on writting it! > >> > >> > >> Best Regards, > >> Georgios > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: john.loughney@nokia.com > [mailto:john.loughney@nokia.com] Sent: > >>> maandag 8 januari 2007 5:46 > >>> To: jmanner@cs.Helsinki.FI > >>> Cc: karagian@cs.utwente.nl; oran@cisco.com; > >>> attila.bader@ericsson.com; gash@att.com; nsis@ietf.org > >>> Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > >>> information > >>> > >>> Hi Jukka, > >>> > >>> > >>>> That is actually a good point. So far I have hoped that we > >>> > >>> > >>> can clearly > >>> > >>>> de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP > >>>> implementation can run with all different RMFs and QOSMs. > >>> > >>> > >>> I think that is a good goal. > >>> > >>> > >>>> If a QOSM affects the common message processing, we need > different > >>>> implementations. Yet, I guess this also applies to various > >>> > >>> > >>> tunneling, > >>> > >>>> session binding, and separate signaling sessions that > might be used > >>>> within a domain. > >>> > >>> > >>> I agree. > >>> > >>> > >>>> Do we need to document how the RMF and QoS NSLP fit > >>> > >>> > >>> together, what is > >>> > >>>> passed between the RMF and NSLP, what are the API issues, > >>> > >>> > >>> what kind on > >>> > >>>> asymmetric triggers the RMF can send to the NSLP, etc. I > >>> > >>> > >>> think we need > >>> > >>>> to write such a draft, and document all the interactions. If we > >>>> have that written down, we can more easily define what is a > >>>> standards-compliant implementation of a QOSM/RMF, and > what is not. > >>>> > >>>> If you think that would be good, I could write a first draft. > >>> > >>> > >>> I think this is a good idea for a draft, and probably > QoSM documents > >>> might need to have some of this information, as it specifically > >>> applies for the specific QoSM. > >>> > >>> 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 > > _______________________________________________ > 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 Jan 15 04:13:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Ntt-00023f-R1; Mon, 15 Jan 2007 04:13:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Nts-000220-Rl for nsis@ietf.org; Mon, 15 Jan 2007 04:13:08 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Nto-0002GJ-Ke for nsis@ietf.org; Mon, 15 Jan 2007 04:13:08 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ED3734F0002; Mon, 15 Jan 2007 10:09:41 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 10:09:40 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 10:09:38 +0100 Message-ID: <45AB44D2.7000307@ericsson.com> Date: Mon, 15 Jan 2007 10:09:38 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] Consensus on: Removed the QSPEC control information References: <000901c73307$bb20dff0$4c0d5982@dynamic.ewi.utwente.nl><45A7C894.6010402@cs.uni-goettingen.de><45AA6141.40702@cs.uni-goettingen.de> <000201c73881$734aff60$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <000201c73881$734aff60$4c0d5982@dynamic.ewi.utwente.nl> X-OriginalArrivalTime: 15 Jan 2007 09:09:38.0833 (UTC) FILETIME=[E2631010:01C73884] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: c375f2012a4f820b0c0fd6fb14a28357 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: , Content-Type: multipart/mixed; boundary="===============0762914986==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0762914986== Content-Type: multipart/alternative; boundary="------------090508020103070208090806" This is a multi-part message in MIME format. --------------090508020103070208090806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree that we should have these features then. regards Lasse Georgios Karagiannis wrote: > Hi Bernd > > Thus you also agree with the below: > According to the previous discussions I could conclude that a common > QOS-NSLP message processing will mean in this case that the QOS-NSLP > has to > support all features that are related to various signaling features > such as: > > * tunneling, > * proxy functionality > * aggregation functionality > * stateless and bypassing, > * session binding, > * and separate and parallel signaling sessions that support the > end-to-end, edge-to-edge and end-to-edge signaling such as: > reservation initiation (ssuccessful reservation), refresh, release, > unsuccessful resdervations, modification > of reservations, severe congestion (or pre-emption) handling, > congestion notification handling, etc. for sender initiated and receiver > initiated > unidirectional and bi-directional reservations > that can be used end-to- end and within a domain. > > > Thus this will mean that the QOS-NSLP specification should > provide signaling means for all the above. > > > Best Regards, > Georgios > > > > > -----Original Message----- > > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] > > Sent: zondag 14 januari 2007 18:02 > > To: nsis@ietf.org > > Subject: Re: [NSIS] Consensus on: Removed the QSPEC control > > information > > > > Hi, > > > > a few comments to some of the recent consensus calls: > > > > I agree, that the QOSM specification SHOULD NOT be allowed to > > define new RMF functions and extend signaling functionality. > > > > Either tunneling a QSPEC or encapsulating it makes sense in > > my opinion. > > Where additional information in a local domain are needed the > > QOSM specification could define additional parameters. > > > > Which QoS NSLP signaling feature is used by QOSMs should be > > defined in the QoS NSLP draft rather than in the QSPEC draft. > > I agree here. > > > > Best Regards, > > Bernd > > > > > > Bernd Schloer wrote: > > > Hi, > > > > > > I also think that such a draft is very useful. It is preferable to > > > have a single QoS NSLP implementation which operates with the > > > different QOSMs. Implementing a QOSM gets easier. I would > > like to contribute to it. > > > > > > Best Regards, > > > Bernd > > > > > > > > > > > > Georgios Karagiannis wrote: > > > > > >> Hi John and Jukka > > >> > > >> I think that the idea of writting such a draft is a very > > good point! > > >> As an example the RMD-QOSM affects the common message > > processing, and > > >> therefore we need different implementations. This applies > > to various > > >> tunneling, session binding, and separate signaling > > sessions (such as > > >> refresh, release, Unsuccessful resdervations, bi-directional > > >> reservations, severe congestion handling, congestion notification > > >> handling, etc.) that can be used within a domain. > > >> > > >> It will be great to have such a draft andf I would very > > much like to > > >> help Jukka, if Jukka agrees, on writting it! > > >> > > >> > > >> Best Regards, > > >> Georgios > > >> > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: john.loughney@nokia.com > > [mailto:john.loughney@nokia.com] Sent: > > >>> maandag 8 januari 2007 5:46 > > >>> To: jmanner@cs.Helsinki.FI > > >>> Cc: karagian@cs.utwente.nl; oran@cisco.com; > > >>> attila.bader@ericsson.com; gash@att.com; nsis@ietf.org > > >>> Subject: RE: [NSIS] Consensus on: Removed the QSPEC control > > >>> information > > >>> > > >>> Hi Jukka, > > >>> > > >>> > > >>>> That is actually a good point. So far I have hoped that we > > >>> > > >>> > > >>> can clearly > > >>> > > >>>> de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP > > >>>> implementation can run with all different RMFs and QOSMs. > > >>> > > >>> > > >>> I think that is a good goal. > > >>> > > >>> > > >>>> If a QOSM affects the common message processing, we need > > different > > >>>> implementations. Yet, I guess this also applies to various > > >>> > > >>> > > >>> tunneling, > > >>> > > >>>> session binding, and separate signaling sessions that > > might be used > > >>>> within a domain. > > >>> > > >>> > > >>> I agree. > > >>> > > >>> > > >>>> Do we need to document how the RMF and QoS NSLP fit > > >>> > > >>> > > >>> together, what is > > >>> > > >>>> passed between the RMF and NSLP, what are the API issues, > > >>> > > >>> > > >>> what kind on > > >>> > > >>>> asymmetric triggers the RMF can send to the NSLP, etc. I > > >>> > > >>> > > >>> think we need > > >>> > > >>>> to write such a draft, and document all the interactions. If we > > >>>> have that written down, we can more easily define what is a > > >>>> standards-compliant implementation of a QOSM/RMF, and > > what is not. > > >>>> > > >>>> If you think that would be good, I could write a first draft. > > >>> > > >>> > > >>> I think this is a good idea for a draft, and probably > > QoSM documents > > >>> might need to have some of this information, as it specifically > > >>> applies for the specific QoSM. > > >>> > > >>> 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 > > > > _______________________________________________ > > 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 > --------------090508020103070208090806 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree that we should have these features then.

regards Lasse

Georgios Karagiannis wrote:
RE: [NSIS] Consensus on: Removed the QSPEC control information

Hi Bernd

Thus you also agree with the below:
According to the previous discussions I could conclude that a common
QOS-NSLP message processing will mean in this case that the QOS-NSLP has to
support all features that are related to various signaling features such as:

* tunneling,
* proxy functionality
* aggregation functionality
* stateless and bypassing,
* session binding,
* and separate and parallel signaling sessions that support the
  end-to-end, edge-to-edge and end-to-edge signaling such as:
  reservation initiation (ssuccessful reservation), refresh, release,
  unsuccessful resdervations,  modification
  of reservations, severe congestion (or pre-emption) handling,
  congestion notification handling, etc. for sender initiated and receiver
initiated
  unidirectional and bi-directional reservations
  that can  be used end-to- end and within a domain.


Thus this will mean that the QOS-NSLP specification should
provide signaling means for all the above.


Best Regards,
Georgios



> -----Original Message-----
> From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]
> Sent: zondag 14 januari 2007 18:02
> To: nsis@ietf.org
> Subject: Re: [NSIS] Consensus on: Removed the QSPEC control
> information
>
> Hi,
>
> a few comments to some of the recent consensus calls:
>
> I agree, that the QOSM specification SHOULD NOT be allowed to
> define new RMF functions and extend signaling functionality.
>
> Either tunneling a QSPEC or encapsulating it makes sense in
> my opinion.
> Where additional information in a local domain are needed the
> QOSM specification could define additional parameters.
>
> Which QoS NSLP signaling feature is used by QOSMs should be
> defined in the QoS NSLP draft rather than in the QSPEC draft.
> I agree here.
>
> Best Regards,
> Bernd
>
>
> Bernd Schloer wrote:
> > Hi,
> >
> > I also think that such a draft is very useful. It is preferable to
> > have a single QoS NSLP implementation which operates with the
> > different QOSMs. Implementing a QOSM gets easier. I would
> like to contribute to it.
> >
> > Best Regards,
> > Bernd
> >
> >
> >
> > Georgios Karagiannis wrote:
> >
> >> Hi John and Jukka
> >>
> >> I think that the idea of writting such a draft is a very
> good point!
> >> As an example the RMD-QOSM affects the common message
> processing, and
> >> therefore we need different implementations. This applies
> to various
> >> tunneling, session binding, and separate signaling
> sessions (such as
> >> refresh, release, Unsuccessful resdervations, bi-directional
> >> reservations, severe congestion handling, congestion notification
> >> handling, etc.) that can  be used within a domain.
> >>
> >> It will be great to have such a draft andf I would very
> much like to
> >> help Jukka, if Jukka agrees, on writting it!
> >>
> >>
> >> Best Regards,
> >> Georgios
> >>
> >> 
> >>
> >>
> >>> -----Original Message-----
> >>> From: john.loughney@nokia.com
> [mailto:john.loughney@nokia.com] Sent:
> >>> maandag 8 januari 2007 5:46
> >>> To: jmanner@cs.Helsinki.FI
> >>> Cc: karagian@cs.utwente.nl; oran@cisco.com;
> >>> attila.bader@ericsson.com; gash@att.com; nsis@ietf.org
> >>> Subject: RE: [NSIS] Consensus on: Removed the QSPEC control
> >>> information
> >>>
> >>> Hi Jukka,
> >>>
> >>>
> >>>> That is actually a good point. So far I have hoped that we
> >>>
> >>>
> >>> can clearly
> >>>
> >>>> de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP
> >>>> implementation can run with all different RMFs and QOSMs.
> >>>
> >>>
> >>> I think that is a good goal.
> >>>
> >>>
> >>>> If a QOSM affects the common message processing, we need
> different
> >>>> implementations. Yet, I guess this also applies to various
> >>>
> >>>
> >>> tunneling,
> >>>
> >>>> session binding, and separate signaling sessions that
> might be used
> >>>> within a domain.
> >>>
> >>>
> >>> I agree.
> >>>
> >>>
> >>>> Do we need to document how the RMF and QoS NSLP fit
> >>>
> >>>
> >>> together, what is
> >>>
> >>>> passed between the RMF and NSLP, what are the API issues,
> >>>
> >>>
> >>> what kind on
> >>>
> >>>> asymmetric triggers the RMF can send to the NSLP, etc. I
> >>>
> >>>
> >>> think we need
> >>>
> >>>> to write such a draft, and document all the interactions. If we
> >>>> have that written down, we can more easily define what is a
> >>>> standards-compliant implementation of a QOSM/RMF, and
> what is not.
> >>>>
> >>>> If you think that would be good, I could write a first draft.
> >>>
> >>>
> >>> I think this is a good idea for a draft, and probably
> QoSM documents
> >>> might need to have some of this information, as it specifically
> >>> applies for the specific QoSM.
> >>>
> >>> 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
>
> _______________________________________________
> 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

--------------090508020103070208090806-- --===============0762914986== 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 --===============0762914986==-- From nsis-bounces@ietf.org Mon Jan 15 04:31:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6OBB-00039v-1l; Mon, 15 Jan 2007 04:31:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6OBA-00039p-2X for nsis@ietf.org; Mon, 15 Jan 2007 04:31:00 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6OB5-0005Q0-Bd for nsis@ietf.org; Mon, 15 Jan 2007 04:31:00 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A375D4F004D; Mon, 15 Jan 2007 10:30:50 +0100 (CET) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 10:30: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] Consensus on: Removed the QSPEC control information Date: Mon, 15 Jan 2007 10:30:50 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E910F73CB@esealmw116.eemea.ericsson.se> In-Reply-To: <000201c73881$734aff60$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Consensus on: Removed the QSPEC control information Thread-Index: Acc3/fFsfVHan5VoSDKQFyLHqu4sNAAgrJWQAADgrTA= From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Georgios Karagiannis" , "Bernd Schloer" , X-OriginalArrivalTime: 15 Jan 2007 09:30:50.0501 (UTC) FILETIME=[D85C3350:01C73887] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 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,=20 I think these functions are important to support by QOS NSLP, and QSpec = Template should not contain restriction.=20 As far as the control info is concerned, I think that RMD control = information is similar to Excess Treatment. They control what to do with = the traffic in case of special conditions. Whether these parameters = should be standardized or not is another question. RMD document is an = informational doc. describing how to use NSIS in case of such signaling = cases. =20 Best regards, Attila >-----Original Message----- >From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >Sent: Monday, January 15, 2007 9:45 AM >To: 'Bernd Schloer'; nsis@ietf.org >Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information > >Hi Bernd > >Thus you also agree with the below: >According to the previous discussions I could conclude that a=20 >common QOS-NSLP message processing will mean in this case that=20 >the QOS-NSLP has to support all features that are related to=20 >various signaling features such as: > >* tunneling, >* proxy functionality >* aggregation functionality >* stateless and bypassing, >* session binding, >* and separate and parallel signaling sessions that support the > end-to-end, edge-to-edge and end-to-edge signaling such as: > reservation initiation (ssuccessful reservation), refresh, release, > unsuccessful resdervations, modification > of reservations, severe congestion (or pre-emption) handling, > congestion notification handling, etc. for sender initiated=20 >and receiver initiated > unidirectional and bi-directional reservations > that can be used end-to- end and within a domain. > > >Thus this will mean that the QOS-NSLP specification should=20 >provide signaling means for all the above. > > >Best Regards, >Georgios > >=20 > >> -----Original Message----- >> From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 >> Sent: zondag 14 januari 2007 18:02 >> To: nsis@ietf.org >> Subject: Re: [NSIS] Consensus on: Removed the QSPEC control=20 >> information >>=20 >> Hi, >>=20 >> a few comments to some of the recent consensus calls: >>=20 >> I agree, that the QOSM specification SHOULD NOT be allowed to=20 >> define new RMF functions and extend signaling functionality. >>=20 >> Either tunneling a QSPEC or encapsulating it makes sense in=20 >> my opinion. >> Where additional information in a local domain are needed the=20 >> QOSM specification could define additional parameters. >>=20 >> Which QoS NSLP signaling feature is used by QOSMs should be=20 >> defined in the QoS NSLP draft rather than in the QSPEC draft.=20 >> I agree here. >>=20 >> Best Regards, >> Bernd >>=20 >>=20 >> Bernd Schloer wrote: >> > Hi, >> >=20 >> > I also think that such a draft is very useful. It is preferable to=20 >> > have a single QoS NSLP implementation which operates with the=20 >> > different QOSMs. Implementing a QOSM gets easier. I would=20 >> like to contribute to it. >> >=20 >> > Best Regards, >> > Bernd >> >=20 >> >=20 >> >=20 >> > Georgios Karagiannis wrote: >> >=20 >> >> Hi John and Jukka >> >> >> >> I think that the idea of writting such a draft is a very=20 >> good point! >> >> As an example the RMD-QOSM affects the common message=20 >> processing, and=20 >> >> therefore we need different implementations. This applies=20 >> to various=20 >> >> tunneling, session binding, and separate signaling=20 >> sessions (such as=20 >> >> refresh, release, Unsuccessful resdervations, bi-directional=20 >> >> reservations, severe congestion handling, congestion notification=20 >> >> handling, etc.) that can be used within a domain. >> >> >> >> It will be great to have such a draft andf I would very=20 >> much like to=20 >> >> help Jukka, if Jukka agrees, on writting it! >> >> >> >> >> >> Best Regards, >> >> Georgios >> >> >> >> =20 >> >> >> >> >> >>> -----Original Message----- >> >>> From: john.loughney@nokia.com=20 >> [mailto:john.loughney@nokia.com] Sent:=20 >> >>> maandag 8 januari 2007 5:46 >> >>> To: jmanner@cs.Helsinki.FI >> >>> Cc: karagian@cs.utwente.nl; oran@cisco.com;=20 >> >>> attila.bader@ericsson.com; gash@att.com; nsis@ietf.org >> >>> Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 >> >>> information >> >>> >> >>> Hi Jukka, >> >>> >> >>> >> >>>> That is actually a good point. So far I have hoped that we >> >>> >> >>> >> >>> can clearly >> >>> >> >>>> de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP=20 >> >>>> implementation can run with all different RMFs and QOSMs. >> >>> >> >>> >> >>> I think that is a good goal. >> >>> >> >>> >> >>>> If a QOSM affects the common message processing, we need=20 >> different=20 >> >>>> implementations. Yet, I guess this also applies to various >> >>> >> >>> >> >>> tunneling, >> >>> >> >>>> session binding, and separate signaling sessions that=20 >> might be used=20 >> >>>> within a domain. >> >>> >> >>> >> >>> I agree. >> >>> >> >>> >> >>>> Do we need to document how the RMF and QoS NSLP fit >> >>> >> >>> >> >>> together, what is >> >>> >> >>>> passed between the RMF and NSLP, what are the API issues, >> >>> >> >>> >> >>> what kind on >> >>> >> >>>> asymmetric triggers the RMF can send to the NSLP, etc. I >> >>> >> >>> >> >>> think we need >> >>> >> >>>> to write such a draft, and document all the interactions. If we=20 >> >>>> have that written down, we can more easily define what is a=20 >> >>>> standards-compliant implementation of a QOSM/RMF, and=20 >> what is not. >> >>>> >> >>>> If you think that would be good, I could write a first draft. >> >>> >> >>> >> >>> I think this is a good idea for a draft, and probably=20 >> QoSM documents=20 >> >>> might need to have some of this information, as it specifically=20 >> >>> applies for the specific QoSM. >> >>> >> >>> John >> >>> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >>=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 Jan 15 04:34:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6OEL-0004jB-Qi; Mon, 15 Jan 2007 04:34:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6OEK-0004j5-H2 for nsis@ietf.org; Mon, 15 Jan 2007 04:34:16 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6OEJ-0005zX-63 for nsis@ietf.org; Mon, 15 Jan 2007 04:34:16 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4D6C513CF82; Mon, 15 Jan 2007 10:41:21 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] QoS NSLP: RSN + tear down Date: Mon, 15 Jan 2007 10:34:10 +0100 To: Jukka MJ Manner X-Mailer: Apple Mail (2.752.3) 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, The proposed text sounds good to me. Martin Am 10.01.2007 um 13:13 schrieb Jukka MJ Manner: > > Hi all, > > I now have the QoS NSLP spec updated with the recent comments. One > issue > remains, that I'd like a confirmation before sending out to you for > review > v. "13-pre2". > > Issue: RSN + tear down > > We have earlier decided that RSNs would not be interpreted when > tearing > down a reservation. However, we actually need to interpret them, > otherwise > the path change mechanism currently specified will not work (see my > previous email about the mobility work today). > > Thus, I propose that when a node receives a tearing RESERVE, it MUST > interpret and compare the RSN in the message to the stored RSN. > > 1. If the RSN values match, the QNE MUST perform the tear down and > send > out a tearing RESERVE with the RSN object. > > 2. If the received RSN is greater than the stored RSN, the QNE MUST > perform the tear down, and send out a tearing RESERVE with the > received > greater RSN value. > > 3. If the received RSN is less than the stored RSN, the QNE MUST > silently > drop the tearing RESERVE, and not perform any tear down, nor > send out > any tearing RESERVE. > > > > 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 Jan 15 16:43:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ZbH-0004uK-FH; Mon, 15 Jan 2007 16:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ZbG-0004r4-4I for nsis@ietf.org; Mon, 15 Jan 2007 16:42:42 -0500 Received: from smtp2.netcabo.co.mz ([196.46.0.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ZbC-0000g1-Lm for nsis@ietf.org; Mon, 15 Jan 2007 16:42:42 -0500 Received: (qmail 18198 invoked by uid 89); 15 Jan 2007 21:40:36 -0000 Received: by simscan 1.2.0 ppid: 18174, pid: 18195, t: 0.5445s scanners: attach: 1.2.0 clamav: 0.88.5/m:41/d:2300 Received: from unknown (HELO BOEMIUS7) (41.220.43.153) by smtp2.netcabo.co.mz with SMTP; 15 Jan 2007 21:40:35 -0000 From: "Edmundo Monteiro" To: Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Date: Mon, 15 Jan 2007 21:41:58 -0000 Organization: University of Coimbra Message-ID: <001001c738ee$15397f10$8a00a8c0@BOEMIUS7> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc3/fFsfVHan5VoSDKQFyLHqu4sNAAgrJWQAADgrTAAFBp44A== In-Reply-To: <53CCFDD6E346CB43994852666C210E910F73CB@esealmw116.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: =?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 All In my opinion we should not restrict QoS-NSLP functionality that should support end-to-end signaling. I agree with Attila, the QoS NSLP can be extended in a local QoS domain, preserving the end-to-end operation. Regards Edmundo Monteiro -----Original Message----- From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com]=20 Sent: segunda-feira, 15 de Janeiro de 2007 9:31 To: Georgios Karagiannis; Bernd Schloer; nsis@ietf.org Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information Hi All,=20 I think these functions are important to support by QOS NSLP, and QSpec Template should not contain restriction.=20 As far as the control info is concerned, I think that RMD control information is similar to Excess Treatment. They control what to do with = the traffic in case of special conditions. Whether these parameters should = be standardized or not is another question. RMD document is an = informational doc. describing how to use NSIS in case of such signaling cases. =20 Best regards, Attila >-----Original Message----- >From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >Sent: Monday, January 15, 2007 9:45 AM >To: 'Bernd Schloer'; nsis@ietf.org >Subject: RE: [NSIS] Consensus on: Removed the QSPEC control information > >Hi Bernd > >Thus you also agree with the below: >According to the previous discussions I could conclude that a=20 >common QOS-NSLP message processing will mean in this case that=20 >the QOS-NSLP has to support all features that are related to=20 >various signaling features such as: > >* tunneling, >* proxy functionality >* aggregation functionality >* stateless and bypassing, >* session binding, >* and separate and parallel signaling sessions that support the > end-to-end, edge-to-edge and end-to-edge signaling such as: > reservation initiation (ssuccessful reservation), refresh, release, > unsuccessful resdervations, modification > of reservations, severe congestion (or pre-emption) handling, > congestion notification handling, etc. for sender initiated=20 >and receiver initiated > unidirectional and bi-directional reservations > that can be used end-to- end and within a domain. > > >Thus this will mean that the QOS-NSLP specification should=20 >provide signaling means for all the above. > > >Best Regards, >Georgios > >=20 > >> -----Original Message----- >> From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 >> Sent: zondag 14 januari 2007 18:02 >> To: nsis@ietf.org >> Subject: Re: [NSIS] Consensus on: Removed the QSPEC control=20 >> information >>=20 >> Hi, >>=20 >> a few comments to some of the recent consensus calls: >>=20 >> I agree, that the QOSM specification SHOULD NOT be allowed to=20 >> define new RMF functions and extend signaling functionality. >>=20 >> Either tunneling a QSPEC or encapsulating it makes sense in=20 >> my opinion. >> Where additional information in a local domain are needed the=20 >> QOSM specification could define additional parameters. >>=20 >> Which QoS NSLP signaling feature is used by QOSMs should be=20 >> defined in the QoS NSLP draft rather than in the QSPEC draft.=20 >> I agree here. >>=20 >> Best Regards, >> Bernd >>=20 >>=20 >> Bernd Schloer wrote: >> > Hi, >> >=20 >> > I also think that such a draft is very useful. It is preferable to=20 >> > have a single QoS NSLP implementation which operates with the=20 >> > different QOSMs. Implementing a QOSM gets easier. I would=20 >> like to contribute to it. >> >=20 >> > Best Regards, >> > Bernd >> >=20 >> >=20 >> >=20 >> > Georgios Karagiannis wrote: >> >=20 >> >> Hi John and Jukka >> >> >> >> I think that the idea of writting such a draft is a very=20 >> good point! >> >> As an example the RMD-QOSM affects the common message=20 >> processing, and=20 >> >> therefore we need different implementations. This applies=20 >> to various=20 >> >> tunneling, session binding, and separate signaling=20 >> sessions (such as=20 >> >> refresh, release, Unsuccessful resdervations, bi-directional=20 >> >> reservations, severe congestion handling, congestion notification=20 >> >> handling, etc.) that can be used within a domain. >> >> >> >> It will be great to have such a draft andf I would very=20 >> much like to=20 >> >> help Jukka, if Jukka agrees, on writting it! >> >> >> >> >> >> Best Regards, >> >> Georgios >> >> >> >> =20 >> >> >> >> >> >>> -----Original Message----- >> >>> From: john.loughney@nokia.com=20 >> [mailto:john.loughney@nokia.com] Sent:=20 >> >>> maandag 8 januari 2007 5:46 >> >>> To: jmanner@cs.Helsinki.FI >> >>> Cc: karagian@cs.utwente.nl; oran@cisco.com;=20 >> >>> attila.bader@ericsson.com; gash@att.com; nsis@ietf.org >> >>> Subject: RE: [NSIS] Consensus on: Removed the QSPEC control=20 >> >>> information >> >>> >> >>> Hi Jukka, >> >>> >> >>> >> >>>> That is actually a good point. So far I have hoped that we >> >>> >> >>> >> >>> can clearly >> >>> >> >>>> de-couple QSPEC+RMF and the NSLP, and therefore a single NSLP=20 >> >>>> implementation can run with all different RMFs and QOSMs. >> >>> >> >>> >> >>> I think that is a good goal. >> >>> >> >>> >> >>>> If a QOSM affects the common message processing, we need=20 >> different=20 >> >>>> implementations. Yet, I guess this also applies to various >> >>> >> >>> >> >>> tunneling, >> >>> >> >>>> session binding, and separate signaling sessions that=20 >> might be used=20 >> >>>> within a domain. >> >>> >> >>> >> >>> I agree. >> >>> >> >>> >> >>>> Do we need to document how the RMF and QoS NSLP fit >> >>> >> >>> >> >>> together, what is >> >>> >> >>>> passed between the RMF and NSLP, what are the API issues, >> >>> >> >>> >> >>> what kind on >> >>> >> >>>> asymmetric triggers the RMF can send to the NSLP, etc. I >> >>> >> >>> >> >>> think we need >> >>> >> >>>> to write such a draft, and document all the interactions. If we=20 >> >>>> have that written down, we can more easily define what is a=20 >> >>>> standards-compliant implementation of a QOSM/RMF, and=20 >> what is not. >> >>>> >> >>>> If you think that would be good, I could write a first draft. >> >>> >> >>> >> >>> I think this is a good idea for a draft, and probably=20 >> QoSM documents=20 >> >>> might need to have some of this information, as it specifically=20 >> >>> applies for the specific QoSM. >> >>> >> >>> John >> >>> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >>=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 ---- If you feel this message is spam, please address complaints to abuse@tvcabo.co.mz. Full e-mail headers and the message will help us process the problem more swiftly. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 16 04:56:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6l2z-0007ME-Il; Tue, 16 Jan 2007 04:56:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6l2z-0007M5-6V for nsis@ietf.org; Tue, 16 Jan 2007 04:56:05 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6l2w-0007V1-UN for nsis@ietf.org; Tue, 16 Jan 2007 04:56:05 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1H6l2r-00044M-LZ; Tue, 16 Jan 2007 10:56:00 +0100 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 1AE25A813; Tue, 16 Jan 2007 10:55:55 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1H6l2o-00066f-OJ; Tue, 16 Jan 2007 10:55:54 +0100 Message-ID: <45ACA12A.9090807@tm.uka.de> Date: Tue, 16 Jan 2007 10:55:54 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP: RSN + tear down References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) 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.4 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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, Jukka MJ Manner wrote: > I now have the QoS NSLP spec updated with the recent comments. One issue > remains, that I'd like a confirmation before sending out to you for review > v. "13-pre2". > > Issue: RSN + tear down > > We have earlier decided that RSNs would not be interpreted when tearing > down a reservation. However, we actually need to interpret them, otherwise > the path change mechanism currently specified will not work (see my > previous email about the mobility work today). Ok, we overlooked that. I guess that you are right in this respect. What about the RSN-1 hack in section 3.2.11.2. (the last sentence seems to be messed up somehow: "This in the peer from which it was receiving RESERVE messages.")? > Thus, I propose that when a node receives a tearing RESERVE, it MUST > interpret and compare the RSN in the message to the stored RSN. > > 1. If the RSN values match, the QNE MUST perform the tear down and send > out a tearing RESERVE with the RSN object. > > 2. If the received RSN is greater than the stored RSN, the QNE MUST > perform the tear down, and send out a tearing RESERVE with the received > greater RSN value. > > 3. If the received RSN is less than the stored RSN, the QNE MUST silently > drop the tearing RESERVE, and not perform any tear down, nor send out > any tearing RESERVE. Ok, sounds fine to me, too. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 16 10:34:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qK8-0000lH-Ob; Tue, 16 Jan 2007 10:34:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qK7-0000lB-Dq for nsis@ietf.org; Tue, 16 Jan 2007 10:34:07 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qK5-00024p-Q0 for nsis@ietf.org; Tue, 16 Jan 2007 10:34:07 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 1851213CF82 for ; Tue, 16 Jan 2007 16:41:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <99481184-89C3-43DC-BE1E-579837A1A300@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Tue, 16 Jan 2007 16:33:51 +0100 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.2 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Subject: [NSIS] Fwd: Internet-Draft Boilerplate Reminder 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 Just FYI when updating your drafts or for new ones. Martin Anfang der weitergeleiteten E-Mail: > Von: IETF Secretariat > Datum: 15. Januar 2007 17:51:16 MEZ > An: IETF Announcement list > Kopie: iesg@ietf.org > Betreff: Internet-Draft Boilerplate Reminder > > This message is to remind you that as of February 1, 2007 the IETF > Secretariat will no longer accept Internet-Drafts with the old > (i.e. pre RFC 4748) boilerplate. For your convenience, below is > the text of the message that was sent to the IETF Announcement > List by the IETF Chair on October 26, 2006 with Subject: Update to > Internet Draft and RFC Boilerplate. > > The IETF Secretariat. > -------------------------------------------------------------- > A small update to BCP 78 was recently approved by the IESG as RFC > 4748, > to update the boilerplate (i.e., standard legal text) in RFCs and > Internet-Drafts to recognize the IETF Trust as a rights holder, > instead of ISOC. > > The actual boilerplate changes are given below this message. > > Starting as soon as reasonably possible, all authors of Internet- > Drafts > are requested to use the new boilerplate. The RFC Editor will in any > case be inserting it in all RFCs issued from 2006-11-01. (The rights > held by ISOC in older RFCs will be administratively transferred to > the IETF Trust.) > > The public ID Nits checker already accepts I-Ds with old or new > boilerplate. The Secretariat has started accepting I-Ds with old or > new boilerplate. > > XML2RFC version 1.32 will generate the new boilerplate. > Users of I-D templates are requested to update them appropriately. > > http://www.ietf.org/ID-Checklist.html and > http://www.ietf.org/ietf/1id-guidelines.html are being updated. > > Starting December, the public ID Nits checker will issue warnings > for old > boilerplate. > > Starting February 2007, the Secretariat will refuse the old > boilerplate > in Internet-Drafts. > > We are sorry for the inconvenience, but this change cannot be avoided. > > IETF Chair > IETF Secretariat > TOOLS Team > > -------- > > Copyright Notice (required for all IETF Documents) > > (Normally placed at the end of the IETF Document.) > > NOTE: by convention, the first line of the copyright statement is > usually > placed near the beginning of each document. This must also be updated. > > OLD > "Copyright (C) The Internet Society (year). > > This document is subject to the rights, licenses and > restrictions > contained in BCP 78, and except as set forth therein, the > authors > retain all their rights. > > NEW > "Copyright (C) The IETF Trust (year). > > This document is subject to the rights, licenses and > restrictions > contained in BCP 78, and except as set forth therein, the > authors > retain all their rights. > > > Disclaimer (required in all IETF Documents) > > (Normally placed at the end of the IETF Document after the > copyright > notice.) > > > OLD > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, > EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY > THAT > THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY > RIGHTS OR > ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE." > > > NEW > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, > THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT > INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR > FITNESS > FOR A PARTICULAR PURPOSE." > > Exceptions > > In MIB modules, PIB modules and similar material commonly > extracted from IETF Documents, except for material that is being > placed under IANA maintenance, the following abbreviated notice > shall be included in the body of the material that will be > extracted in lieu of the notices otherwise required by > Section 5: > > OLD > "Copyright (C) The Internet Society . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > > NEW > "Copyright (C) The IETF Trust . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > > When the MIB or PIB module is the initial version of a module > that > is to be maintained by the IANA, the following abbreviated > notice > shall be included: > > OLD > "Copyright (C) The Internet Society . The initial > version of this MIB module was published in RFC XXXX; for > full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > > NEW > "Copyright (C) The IETF Trust . The initial > version of this MIB module was published in RFC XXXX; for > full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 17 11:03:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DGD-0004FS-8N; Wed, 17 Jan 2007 11:03:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DGC-0004FL-HW for nsis@ietf.org; Wed, 17 Jan 2007 11:03:36 -0500 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 1H7DGA-0004jQ-31 for nsis@ietf.org; Wed, 17 Jan 2007 11:03:36 -0500 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; Wed, 17 Jan 2007 18:03:29 +0200 id 000AFDD7.45AE48D1.0000535B Date: Wed, 17 Jan 2007 18:03:29 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] QoS NSLP: RSN + tear down In-Reply-To: <45ACA12A.9090807@tm.uka.de> Message-ID: References: <45ACA12A.9090807@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Roland, all, My only small concern is with how to update the RSN numbers. As I put in an earlier email with the example of mobility with the QoS NSLP, the main point is that the reservation on the _new_ path must have a higher RSN than the old path, which is to be torn down. The NSLP draft currently has the same point, but goes a bit further, in that the reservation on the new path has an RSN that is greater by two compared to the old RSN, and the tear-down is also one higher than the old. I think it is enough that the new reservation is simply with a higher RSN value than the RSN used for the existing reservation. However, we have another problem here. I will reply using my previous email with the network scenario. Jukka On Tue, 16 Jan 2007, Roland Bless wrote: > Hi Jukka, > > Jukka MJ Manner wrote: > > I now have the QoS NSLP spec updated with the recent comments. One issue > > remains, that I'd like a confirmation before sending out to you for review > > v. "13-pre2". > > > > Issue: RSN + tear down > > > > We have earlier decided that RSNs would not be interpreted when tearing > > down a reservation. However, we actually need to interpret them, otherwise > > the path change mechanism currently specified will not work (see my > > previous email about the mobility work today). > > Ok, we overlooked that. I guess that you are right in this respect. > What about the RSN-1 hack in section 3.2.11.2. (the last sentence seems > to be messed up somehow: "This in the peer from which it was receiving > RESERVE messages.")? > > > Thus, I propose that when a node receives a tearing RESERVE, it MUST > > interpret and compare the RSN in the message to the stored RSN. > > > > 1. If the RSN values match, the QNE MUST perform the tear down and send > > out a tearing RESERVE with the RSN object. > > > > 2. If the received RSN is greater than the stored RSN, the QNE MUST > > perform the tear down, and send out a tearing RESERVE with the received > > greater RSN value. > > > > 3. If the received RSN is less than the stored RSN, the QNE MUST silently > > drop the tearing RESERVE, and not perform any tear down, nor send out > > any tearing RESERVE. > > Ok, sounds fine to me, too. > > Regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 17 11:06:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DIg-0005vI-Pb; Wed, 17 Jan 2007 11:06:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DIf-0005v7-Rg for nsis@ietf.org; Wed, 17 Jan 2007 11:06:09 -0500 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 1H7DIb-00050a-UG for nsis@ietf.org; Wed, 17 Jan 2007 11:06:09 -0500 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; Wed, 17 Jan 2007 18:06:05 +0200 id 000AFD93.45AE496D.000044A3 Date: Wed, 17 Jan 2007 18:06:05 +0200 (EET) From: Jukka MJ Manner To: Takako Sanda Subject: Re: [NSIS] Re: Clarification: tearing down from intermediate node In-Reply-To: <20070112195212.1121.SANDA.TAKAKO@jp.panasonic.com> Message-ID: References: <45A4BEF2.5020109@sg.panasonic.com> <20070112195212.1121.SANDA.TAKAKO@jp.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: Hong Cheng , 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, QNE1 does not need to know that the next peer is the QNI. QNE1 just figures out that its next peer for the session is not there anymore, thus, the reservation can be torn down. Jukka On Fri, 12 Jan 2007, Takako Sanda wrote: > Hi Jukka, > > I still have a question for the operation below. > > > > > > The tear-down part: > > > > - QNE3 also noticies that the SII-Handle has changed, and could basically > > > > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > > > > Change" 0x02 > > > > - QNE2 will forward it to QNE1 > > > > - QNE1 would then at some point figure out QNI has disappeared, and will > > > > start removing the reservation using a tearing RESERVE > > > > > > How the QNE1 figure out the QNI has disappeared might require some > > > enhancement. Maybe the "Route Change" indication from QNE3 could further > > > identify whether it is upstream route changed or downstream route changed. It > > > might help the QNE1 reach the conclusion faster. > > > > JM: I believe this falls a bit down the path of security. What can a QNE > > trust? I would rather let the QNE1 figure by itself that the QNI has > > disappeared. The message sent is only a hint that tells QNE1 to verify if > > QNI is still there. It would only take a few seconds, basically once the > > retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce > > that the QNI is gone. > > How does QNE1 know the next peer was NI? > In order to know this, I guess, QNE1 needs to have received an explicit > notification from NI in advance. > > cheers, > Takako > > On Wed, 10 Jan 2007 12:35:00 +0200 (EET) > Jukka MJ Manner wrote: > > > > > Hi, > > > > some answers below. > > > > Jukka > > > > On Wed, 10 Jan 2007, Hong Cheng wrote: > > > > > Hi Jukka, > > > > > > The operation is well analyzed. The text should be incorporated into the > > > Mobility Applicability draft. I think generally a tear-down could be > > > initiated by any QNE (e.g. the CRN), as long as it is along the direction > > > from QNI to QNR. > > > > > > Please find a few more comments inline. > > > > > > cheers > > > > > > Cheng Hong > > > > > > > > > Jukka MJ Manner wrote: > > > > Hi Cheng, > > > > > > > > After re-reading the QoS NSLP spec, I think the spec is quite accurate in > > > > how the NSLP supports mobility, and it seems to work properly. Tearing down > > > > the reservation on the old path from the cross-over QNE would be good to > > > > do, but not necessarily critical for the proper operation of the NSLP. Yet, > > > > the current QoS NSLP spec mentions the tear-down at the cross-over router. > > > > > > > > Consider the following scenario: > > > > > > > > > > > > > > > > [MN] [QNE1] --- [QNE2] ---\ > > > > | \ > > > > | [QNE3] --- [QNE6] --- [QNE7] --- > > > > | / > > > > V / > > > > [MN] [QNE4] --- [QNE5]---/ > > > > > > > > > > > > The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR > > > > and receiver" > > > > > > > > "MN as QNI and data sender": we could rely on just the soft-state to expire > > > > on the old path, and a new RESERVE on the new path, or use the following, > > > > based on the NSLP draft text. > > > > > > > > - MN moves from peer QNE1 to QNE4 > > > > - GIST gets a hint that routing has changed, triggers the NSLP > > > > - The NSLP then sends a new full RESERVE with a new RSN > > > > - The RESERVE hits QNE4, which makes reservation > > > > - Then the RESERVE is forwarded to QNE5, which also makes the reservation > > > > - Finally, the RESERVE hits QNE3, which makes a reservation and forwards > > > > the RESERVE to QNE6, and so on > > > > > > > > The tear-down part: > > > > - QNE3 also noticies that the SII-Handle has changed, and could basically > > > > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > > > > Change" 0x02 > > > > - QNE2 will forward it to QNE1 > > > > - QNE1 would then at some point figure out QNI has disappeared, and will > > > > start removing the reservation using a tearing RESERVE > > > > > > How the QNE1 figure out the QNI has disappeared might require some > > > enhancement. Maybe the "Route Change" indication from QNE3 could further > > > identify whether it is upstream route changed or downstream route changed. It > > > might help the QNE1 reach the conclusion faster. > > > > JM: I believe this falls a bit down the path of security. What can a QNE > > trust? I would rather let the QNE1 figure by itself that the QNI has > > disappeared. The message sent is only a hint that tells QNE1 to verify if > > QNI is still there. It would only take a few seconds, basically once the > > retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce > > that the QNI is gone. > > > > > > > > > - The tearing RESERVE will eventually hit QNE3, which noticies that it has > > > > an existing, and newer state (higher RSN), and will drop the tear > > > > > > > > > > > > "MN as QNR and data receiver": we could rely on routing changes to > > > > eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will > > > > then send back a RESPONSE saying "full QSPEC required". A subsequent full > > > > RESERVE will then set up the reservation on the new path. Or, in order to > > > > make it faster, we could use the following: > > > > > > > > - MN moves, gets a hint from GIST that routing has changed > > > > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > > > > - QNE4 will receive it, and forward it, same with QNE5 > > > > > > This is assuming the QNE4 has already been discovered. When the MN is QNR and > > > data receiver, considering the discovery process, wouldn't sending a trigger > > > to QNI directly result in a faster process? > > > > JM: Once GIST tells a routing change has happened, the NSLP will ask GIST > > to send the NOTIFY towards the QNI. For doing that, GIST must find the > > next peer QNE node, which is QNE4 in this case. Since the NSLP works > > hop-by-hop, you can't really send a message directly to the QNI, without > > going through all the intermediate nodes. > > > > > > > > > - The NOTIFY will hit QNE3, which notes that the message for a known > > > > session comes from a new SII-Handle. > > > > - QNE3 should then send a full RESERVE with a new RSN and an RII to > > > > QNE5 > > > > - QNE4 will receive the RESERVE, make the reservation, and forward it to > > > > the MN > > > > - The MN gets the RESERVE and replies with a RESPONSE > > > > > > > > The tear down: > > > > - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which > > > > again sends ti QNE1 > > > > > > > > > > > > Jukka > > > > > > > > > > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > > > > > > > > > Hi Jukka, > > > > > > > > > > I would agree that the cross-over router should be left capable of > > > > > tearing > > > > > down the unneeded reservations. Please see some comments inline below: > > > > > > > > > > cheers > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > > Hi all, > > > > > > > > > > > > If you look at how the NSIS protocols work, there is no way a node can > > > > > > make sure a tear-down was intiated by the QNI. A QNE receives a > > > > > > teardown from its upstream peer, but it can't tell whether that peer > > > > > > initiated the tear down in the first place, or the QNI. > > > > > > > > > > > > If I would do a "mobility enhanced QoS NSLP", I would tear down at the > > > > > > cross-over router the unnecessary reservation. Of course the spec can > > > > > > say > > > > > > "don't do it", but a QNE can not really confirm it isn't being done. > > > > > > And the > > > > > > QNI or the QNR can't see that either. > > > > > > > > > > > > The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to > > > > > > initiate a tear down", and thus leave the option open for a QNE to also > > > > > > do > > > > > > it. > > > > > > > > > > > [Cheng] Agree. This should be left open. And I think the quoted text in > > > > > current QoS NSLP draft is reflecting this point. > > > > > > > > > > > Or we could make a new INFO_SPEC code for "reservation not need" which > > > > > > is a > > > > > > hint sent by the cross-over router to inform downstream QNEs on the old > > > > > > path > > > > > > that the MN has moved away. It is then up to each QNE to decide whether > > > > > > to > > > > > > remove the resources and state, or not. > > > > > > > > > > > > > > > > > [Cheng] This option might lead to some problem though, since it could > > > > > leave > > > > > the QNEs on the path unsynchronized should they decide to do different > > > > > things > > > > > in response to the INFO_SPEC. > > > > > > > > > > > Jukka > > > > > > > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > > > > > > > > > > > > > Hi Jukka and all, > > > > > > > > > > > > > > I would like to clarify about tearing down operation. > > > > > > > > > > > > > > In section 3.2.11 (Rerouting), 5th paragraph, it is said, > > > > > > > "After the reservation on the new path is set up, the branching > > > > > > > node > > > > > > > may want to tear down the reservation on the old path (sooner than > > > > > > > would result from normal soft-state time-out)." > > > > > > > > > > > > > > This means that the CRN will initiate the TEAR on the old path. > > > > > > > > > > > > > > At Munich Interim, It was discussed that tearing down from > > > > > > > intermediate > > > > > > > node needs to be avoided because of session ownership issue. But I > > > > > > > cannot find any conclusion of this discussion. > > > > > > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > > > > > > > > > > > > > > Do we have any decision for "tearing down from intermediate node"? > > > > > > > > > > > > > > cheers, > > > > > > > Takako > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > > > I sent the following request for feedback two weeks ago. No > > > > > > > > comments > > > > > > > > have been raised. I will wait until this Friday, then submit the > > > > > > > > draft. > > > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > I have done all the edits I had in my list to the QoS NSLP spec, > > > > > > > > > the > > > > > > > > > main points are in recent thread with Roland. From the url below > > > > > > > > > you > > > > > > > > > can find the current draft v. "13-pre1" and a diff to v. 12. > > > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > > > > > > > > > A direct link to the diff: > > > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > > > > > > > > > > > > > I would appreciate comments on the changes I did (what is wrong, > > > > > > > > > what > > > > > > > > > I missed, etc.). > > > > > > > > > > > > > > > > > > > > > > > > > > > I still have one problem with the spec, namely the way the NSLP > > > > > > > > > suggests to handle mobility and path changes. I think we need to > > > > > > > > > review that statement, because it seems like a "hack" (playing > > > > > > > > > with > > > > > > > > > the RSN value), and not really useful. And the interactions with > > > > > > > > > GIST > > > > > > > > > look partly wrong. The folks working on the mobility draft (me > > > > > > > > > included) could comment. The section I'm talking about is 3.2.10, > > > > > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > > > > > > > > > BR, > > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > ----- > Takako SANDA > Next-Generation Mobile Communications Development Center, > Matsushita Electric Industrial Co., Ltd. (Panasonic) > Phone: +81 46 840 5764 Fax: +81 46 840 5122 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 17 11:11:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DNR-00080b-O6; Wed, 17 Jan 2007 11:11:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DNQ-00080W-MF for nsis@ietf.org; Wed, 17 Jan 2007 11:11:04 -0500 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 1H7DNN-0005vB-Qi for nsis@ietf.org; Wed, 17 Jan 2007 11:11:04 -0500 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; Wed, 17 Jan 2007 18:11:01 +0200 id 000AFD06.45AE4A95.00002920 Date: Wed, 17 Jan 2007 18:11:01 +0200 (EET) From: Jukka MJ Manner To: Takako Sanda Subject: Re: [NSIS] Re: Clarification: tearing down from intermediate node In-Reply-To: <20070112201001.1124.SANDA.TAKAKO@jp.panasonic.com> Message-ID: References: <4580CEAC.6000908@sg.panasonic.com> <20070112201001.1124.SANDA.TAKAKO@jp.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: Hong Cheng , 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, if the IP addresses change, then we have to make a full end-to-end refresh with a new MRI. Forcing an e2e refresh can be done by adding an RII into the refresh. Furthermore, if a refresh arriving at a QNE is a so-called full refresh, and the MRI is different, this is an indication to the QNE that the whole reservation must be refreshed end-to-end. When sending the NOTIFY, it will include a new MRI. This can be used as an indication that the NOTIFY should be forwarded up to the QNI, which will then send back a full new refresh with a new MRI. Jukka On Fri, 12 Jan 2007, Takako Sanda wrote: > Hi Jukka, > > I have another concern about the operation for overlapping section, (i.e. > [QNE3] --- [QNE6] --- [QNE7] --- ). > > If MN's CoA is changed after it's movement, MRI and packet classifier is > also changed. Therefore reservation for the overlapping section also > must be new. > > > In the "MN as QNI and data sender" scenario below, old reservation in the > overlapping section is not removed because QNE3 drops tearing RESERVE. > Therfore, some mechanisms may be necessary:- > - QNE3 perform both RESERVE for new state and tear RESERVE for old > state when it receives RESERVE from QNE5. > Or, > - QNE3 forwards tear RESERVE to QNE6 when it receives tear RESERVE from > QNE2. (Although it remains so called "double resource reservation issue"...) > > > In the "MN as QNR and data receiver" scenario below, new reservation for > overlapping is not performed. > Therfore, operation may need to be changed, such as:- > - NOTIFY form MN goes to QNI (i.e. QNE3 does not stop it), and QNI > sends both RESERVE and tear RESERVE to MN and QNE1, respectively. > Or, > - QNE3 performs localized RESERVE and tear RESERVE as shown below, but > NOTFY also goes to NI, and NI performs "scoping" RESERVE and tear > RESERVE. > > > cheers, > Takako > > > On Wed, 10 Jan 2007 11:36:57 +0200 (EET) > Jukka MJ Manner wrote: > > > > > Hi Cheng, > > > > After re-reading the QoS NSLP spec, I think the spec is quite accurate in > > how the NSLP supports mobility, and it seems to work properly. Tearing > > down the reservation on the old path from the cross-over QNE would be good > > to do, but not necessarily critical for the proper operation of the NSLP. > > Yet, the current QoS NSLP spec mentions the tear-down at the cross-over > > router. > > > > Consider the following scenario: > > > > > > > > [MN] [QNE1] --- [QNE2] ---\ > > | \ > > | [QNE3] --- [QNE6] --- [QNE7] --- > > | / > > V / > > [MN] [QNE4] --- [QNE5]---/ > > > > > > The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR > > and receiver" > > > > "MN as QNI and data sender": we could rely on just the soft-state to > > expire on the old path, and a new RESERVE on the new path, or use the > > following, based on the NSLP draft text. > > > > - MN moves from peer QNE1 to QNE4 > > - GIST gets a hint that routing has changed, triggers the NSLP > > - The NSLP then sends a new full RESERVE with a new RSN > > - The RESERVE hits QNE4, which makes reservation > > - Then the RESERVE is forwarded to QNE5, which also makes the reservation > > - Finally, the RESERVE hits QNE3, which makes a reservation and forwards > > the RESERVE to QNE6, and so on > > > > The tear-down part: > > - QNE3 also noticies that the SII-Handle has changed, and could basically > > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > > Change" 0x02 > > - QNE2 will forward it to QNE1 > > - QNE1 would then at some point figure out QNI has disappeared, and will > > start removing the reservation using a tearing RESERVE > > - The tearing RESERVE will eventually hit QNE3, which noticies that it has > > an existing, and newer state (higher RSN), and will drop the tear > > > > > > "MN as QNR and data receiver": we could rely on routing changes to > > eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will > > then send back a RESPONSE saying "full QSPEC required". A subsequent > > full RESERVE will then set up the reservation on the new path. Or, in > > order to make it faster, we could use the following: > > > > - MN moves, gets a hint from GIST that routing has changed > > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > > - QNE4 will receive it, and forward it, same with QNE5 > > - The NOTIFY will hit QNE3, which notes that the message for a known > > session comes from a new SII-Handle. > > - QNE3 should then send a full RESERVE with a new RSN and an RII to > > QNE5 > > - QNE4 will receive the RESERVE, make the reservation, and forward it to > > the MN > > - The MN gets the RESERVE and replies with a RESPONSE > > > > The tear down: > > - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which > > again sends ti QNE1 > > > > > > Jukka > > > > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > > > > > Hi Jukka, > > > > > > I would agree that the cross-over router should be left capable of tearing > > > down the unneeded reservations. Please see some comments inline below: > > > > > > cheers > > > > > > Cheng Hong > > > > > > > > > Jukka MJ Manner wrote: > > > > Hi all, > > > > > > > > If you look at how the NSIS protocols work, there is no way a node can > > > > make sure a tear-down was intiated by the QNI. A QNE receives a > > > > teardown from its upstream peer, but it can't tell whether that peer > > > > initiated the tear down in the first place, or the QNI. > > > > > > > > If I would do a "mobility enhanced QoS NSLP", I would tear down at the > > > > cross-over router the unnecessary reservation. Of course the spec can say > > > > "don't do it", but a QNE can not really confirm it isn't being done. And the > > > > QNI or the QNR can't see that either. > > > > > > > > The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to > > > > initiate a tear down", and thus leave the option open for a QNE to also do > > > > it. > > > > > > > > > > [Cheng] Agree. This should be left open. And I think the quoted text in > > > current QoS NSLP draft is reflecting this point. > > > > > > > Or we could make a new INFO_SPEC code for "reservation not need" which is a > > > > hint sent by the cross-over router to inform downstream QNEs on the old path > > > > that the MN has moved away. It is then up to each QNE to decide whether to > > > > remove the resources and state, or not. > > > > > > > > > > > > > > [Cheng] This option might lead to some problem though, since it could leave > > > the QNEs on the path unsynchronized should they decide to do different things > > > in response to the INFO_SPEC. > > > > > > > Jukka > > > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > > > > > > > Hi Jukka and all, > > > > > > > > > > I would like to clarify about tearing down operation. > > > > > > > > > > In section 3.2.11 (Rerouting), 5th paragraph, it is said, > > > > > "After the reservation on the new path is set up, the branching node > > > > > may want to tear down the reservation on the old path (sooner than > > > > > would result from normal soft-state time-out)." > > > > > > > > > > This means that the CRN will initiate the TEAR on the old path. > > > > > > > > > > At Munich Interim, It was discussed that tearing down from intermediate > > > > > node needs to be avoided because of session ownership issue. But I > > > > > cannot find any conclusion of this discussion. > > > > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > > > > > > > > > > Do we have any decision for "tearing down from intermediate node"? > > > > > > > > > > cheers, > > > > > Takako > > > > > > > > > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > I sent the following request for feedback two weeks ago. No comments > > > > > > have been raised. I will wait until this Friday, then submit the draft. > > > > > > > > > > > > Jukka > > > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I have done all the edits I had in my list to the QoS NSLP spec, the > > > > > > > main points are in recent thread with Roland. From the url below you > > > > > > > can find the current draft v. "13-pre1" and a diff to v. 12. > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > > > > > A direct link to the diff: > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > > > > > > > I would appreciate comments on the changes I did (what is wrong, what > > > > > > > I missed, etc.). > > > > > > > > > > > > > > > > > > > > > I still have one problem with the spec, namely the way the NSLP > > > > > > > suggests to handle mobility and path changes. I think we need to > > > > > > > review that statement, because it seems like a "hack" (playing with > > > > > > > the RSN value), and not really useful. And the interactions with GIST > > > > > > > look partly wrong. The folks working on the mobility draft (me > > > > > > > included) could comment. The section I'm talking about is 3.2.10, > > > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > > > > > BR, > > > > > > > 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 Wed Jan 17 11:17:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DSt-0003rJ-Hk; Wed, 17 Jan 2007 11:16:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DSr-0003qr-TV for nsis@ietf.org; Wed, 17 Jan 2007 11:16:41 -0500 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 1H7DSr-0007QD-1V for nsis@ietf.org; Wed, 17 Jan 2007 11:16:41 -0500 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; Wed, 17 Jan 2007 18:16:38 +0200 id 000AFD54.45AE4BE6.00007B9A Date: Wed, 17 Jan 2007 18:16:38 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: Re: [NSIS] Re: Clarification: tearing down from intermediate node In-Reply-To: <20070112195212.1121.SANDA.TAKAKO@jp.panasonic.com> Message-ID: References: <45A4BEF2.5020109@sg.panasonic.com> <20070112195212.1121.SANDA.TAKAKO@jp.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: Roland Bless , Hong Cheng , 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, There is actually another problem with the RSN. Consider the case "MN as QNR and data receiver" When QNE3 gets the notify, it replies back with a RESERVE towards QNR which has "RSN=old-RSN +1". But all nodes from QNI up to QNE3 will still be sending refresh messages using the old RSN. Thus, we need some further mechanism to inform the QNI that it should use a new RSN value in further refreshes, right? E.g. a NOTIFY towards the QNI that says "Path changed, new RSN" and include the new RSN? Sounds like a hack, any suggestions? Jukka On Fri, 12 Jan 2007, Takako Sanda wrote: > Hi Jukka, > > I still have a question for the operation below. > > > > > > The tear-down part: > > > > - QNE3 also noticies that the SII-Handle has changed, and could basically > > > > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > > > > Change" 0x02 > > > > - QNE2 will forward it to QNE1 > > > > - QNE1 would then at some point figure out QNI has disappeared, and will > > > > start removing the reservation using a tearing RESERVE > > > > > > How the QNE1 figure out the QNI has disappeared might require some > > > enhancement. Maybe the "Route Change" indication from QNE3 could further > > > identify whether it is upstream route changed or downstream route changed. It > > > might help the QNE1 reach the conclusion faster. > > > > JM: I believe this falls a bit down the path of security. What can a QNE > > trust? I would rather let the QNE1 figure by itself that the QNI has > > disappeared. The message sent is only a hint that tells QNE1 to verify if > > QNI is still there. It would only take a few seconds, basically once the > > retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce > > that the QNI is gone. > > How does QNE1 know the next peer was NI? > In order to know this, I guess, QNE1 needs to have received an explicit > notification from NI in advance. > > cheers, > Takako > > On Wed, 10 Jan 2007 12:35:00 +0200 (EET) > Jukka MJ Manner wrote: > > > > > Hi, > > > > some answers below. > > > > Jukka > > > > On Wed, 10 Jan 2007, Hong Cheng wrote: > > > > > Hi Jukka, > > > > > > The operation is well analyzed. The text should be incorporated into the > > > Mobility Applicability draft. I think generally a tear-down could be > > > initiated by any QNE (e.g. the CRN), as long as it is along the direction > > > from QNI to QNR. > > > > > > Please find a few more comments inline. > > > > > > cheers > > > > > > Cheng Hong > > > > > > > > > Jukka MJ Manner wrote: > > > > Hi Cheng, > > > > > > > > After re-reading the QoS NSLP spec, I think the spec is quite accurate in > > > > how the NSLP supports mobility, and it seems to work properly. Tearing down > > > > the reservation on the old path from the cross-over QNE would be good to > > > > do, but not necessarily critical for the proper operation of the NSLP. Yet, > > > > the current QoS NSLP spec mentions the tear-down at the cross-over router. > > > > > > > > Consider the following scenario: > > > > > > > > > > > > > > > > [MN] [QNE1] --- [QNE2] ---\ > > > > | \ > > > > | [QNE3] --- [QNE6] --- [QNE7] --- > > > > | / > > > > V / > > > > [MN] [QNE4] --- [QNE5]---/ > > > > > > > > > > > > The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR > > > > and receiver" > > > > > > > > "MN as QNI and data sender": we could rely on just the soft-state to expire > > > > on the old path, and a new RESERVE on the new path, or use the following, > > > > based on the NSLP draft text. > > > > > > > > - MN moves from peer QNE1 to QNE4 > > > > - GIST gets a hint that routing has changed, triggers the NSLP > > > > - The NSLP then sends a new full RESERVE with a new RSN > > > > - The RESERVE hits QNE4, which makes reservation > > > > - Then the RESERVE is forwarded to QNE5, which also makes the reservation > > > > - Finally, the RESERVE hits QNE3, which makes a reservation and forwards > > > > the RESERVE to QNE6, and so on > > > > > > > > The tear-down part: > > > > - QNE3 also noticies that the SII-Handle has changed, and could basically > > > > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > > > > Change" 0x02 > > > > - QNE2 will forward it to QNE1 > > > > - QNE1 would then at some point figure out QNI has disappeared, and will > > > > start removing the reservation using a tearing RESERVE > > > > > > How the QNE1 figure out the QNI has disappeared might require some > > > enhancement. Maybe the "Route Change" indication from QNE3 could further > > > identify whether it is upstream route changed or downstream route changed. It > > > might help the QNE1 reach the conclusion faster. > > > > JM: I believe this falls a bit down the path of security. What can a QNE > > trust? I would rather let the QNE1 figure by itself that the QNI has > > disappeared. The message sent is only a hint that tells QNE1 to verify if > > QNI is still there. It would only take a few seconds, basically once the > > retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce > > that the QNI is gone. > > > > > > > > > - The tearing RESERVE will eventually hit QNE3, which noticies that it has > > > > an existing, and newer state (higher RSN), and will drop the tear > > > > > > > > > > > > "MN as QNR and data receiver": we could rely on routing changes to > > > > eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will > > > > then send back a RESPONSE saying "full QSPEC required". A subsequent full > > > > RESERVE will then set up the reservation on the new path. Or, in order to > > > > make it faster, we could use the following: > > > > > > > > - MN moves, gets a hint from GIST that routing has changed > > > > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > > > > - QNE4 will receive it, and forward it, same with QNE5 > > > > > > This is assuming the QNE4 has already been discovered. When the MN is QNR and > > > data receiver, considering the discovery process, wouldn't sending a trigger > > > to QNI directly result in a faster process? > > > > JM: Once GIST tells a routing change has happened, the NSLP will ask GIST > > to send the NOTIFY towards the QNI. For doing that, GIST must find the > > next peer QNE node, which is QNE4 in this case. Since the NSLP works > > hop-by-hop, you can't really send a message directly to the QNI, without > > going through all the intermediate nodes. > > > > > > > > > - The NOTIFY will hit QNE3, which notes that the message for a known > > > > session comes from a new SII-Handle. > > > > - QNE3 should then send a full RESERVE with a new RSN and an RII to > > > > QNE5 > > > > - QNE4 will receive the RESERVE, make the reservation, and forward it to > > > > the MN > > > > - The MN gets the RESERVE and replies with a RESPONSE > > > > > > > > The tear down: > > > > - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which > > > > again sends ti QNE1 > > > > > > > > > > > > Jukka > > > > > > > > > > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > > > > > > > > > Hi Jukka, > > > > > > > > > > I would agree that the cross-over router should be left capable of > > > > > tearing > > > > > down the unneeded reservations. Please see some comments inline below: > > > > > > > > > > cheers > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > > Hi all, > > > > > > > > > > > > If you look at how the NSIS protocols work, there is no way a node can > > > > > > make sure a tear-down was intiated by the QNI. A QNE receives a > > > > > > teardown from its upstream peer, but it can't tell whether that peer > > > > > > initiated the tear down in the first place, or the QNI. > > > > > > > > > > > > If I would do a "mobility enhanced QoS NSLP", I would tear down at the > > > > > > cross-over router the unnecessary reservation. Of course the spec can > > > > > > say > > > > > > "don't do it", but a QNE can not really confirm it isn't being done. > > > > > > And the > > > > > > QNI or the QNR can't see that either. > > > > > > > > > > > > The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to > > > > > > initiate a tear down", and thus leave the option open for a QNE to also > > > > > > do > > > > > > it. > > > > > > > > > > > [Cheng] Agree. This should be left open. And I think the quoted text in > > > > > current QoS NSLP draft is reflecting this point. > > > > > > > > > > > Or we could make a new INFO_SPEC code for "reservation not need" which > > > > > > is a > > > > > > hint sent by the cross-over router to inform downstream QNEs on the old > > > > > > path > > > > > > that the MN has moved away. It is then up to each QNE to decide whether > > > > > > to > > > > > > remove the resources and state, or not. > > > > > > > > > > > > > > > > > [Cheng] This option might lead to some problem though, since it could > > > > > leave > > > > > the QNEs on the path unsynchronized should they decide to do different > > > > > things > > > > > in response to the INFO_SPEC. > > > > > > > > > > > Jukka > > > > > > > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > > > > > > > > > > > > > Hi Jukka and all, > > > > > > > > > > > > > > I would like to clarify about tearing down operation. > > > > > > > > > > > > > > In section 3.2.11 (Rerouting), 5th paragraph, it is said, > > > > > > > "After the reservation on the new path is set up, the branching > > > > > > > node > > > > > > > may want to tear down the reservation on the old path (sooner than > > > > > > > would result from normal soft-state time-out)." > > > > > > > > > > > > > > This means that the CRN will initiate the TEAR on the old path. > > > > > > > > > > > > > > At Munich Interim, It was discussed that tearing down from > > > > > > > intermediate > > > > > > > node needs to be avoided because of session ownership issue. But I > > > > > > > cannot find any conclusion of this discussion. > > > > > > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > > > > > > > > > > > > > > Do we have any decision for "tearing down from intermediate node"? > > > > > > > > > > > > > > cheers, > > > > > > > Takako > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > > > I sent the following request for feedback two weeks ago. No > > > > > > > > comments > > > > > > > > have been raised. I will wait until this Friday, then submit the > > > > > > > > draft. > > > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > I have done all the edits I had in my list to the QoS NSLP spec, > > > > > > > > > the > > > > > > > > > main points are in recent thread with Roland. From the url below > > > > > > > > > you > > > > > > > > > can find the current draft v. "13-pre1" and a diff to v. 12. > > > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > > > > > > > > > A direct link to the diff: > > > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > > > > > > > > > > > > > I would appreciate comments on the changes I did (what is wrong, > > > > > > > > > what > > > > > > > > > I missed, etc.). > > > > > > > > > > > > > > > > > > > > > > > > > > > I still have one problem with the spec, namely the way the NSLP > > > > > > > > > suggests to handle mobility and path changes. I think we need to > > > > > > > > > review that statement, because it seems like a "hack" (playing > > > > > > > > > with > > > > > > > > > the RSN value), and not really useful. And the interactions with > > > > > > > > > GIST > > > > > > > > > look partly wrong. The folks working on the mobility draft (me > > > > > > > > > included) could comment. The section I'm talking about is 3.2.10, > > > > > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > > > > > > > > > BR, > > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > ----- > Takako SANDA > Next-Generation Mobile Communications Development Center, > Matsushita Electric Industrial Co., Ltd. (Panasonic) > Phone: +81 46 840 5764 Fax: +81 46 840 5122 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 19 07:17:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7sfw-0004xs-Ge; Fri, 19 Jan 2007 07:16:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7sfv-0004x9-0d for nsis@ietf.org; Fri, 19 Jan 2007 07:16:55 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7sfs-0003Tm-Fk for nsis@ietf.org; Fri, 19 Jan 2007 07:16:54 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0JCDpJa032536 for ; Fri, 19 Jan 2007 14:14:31 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 14:16:30 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 06:16:21 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Jan 2007 06:16:19 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F12BD1F@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QSPEC document Thread-Index: Acc7w5/5TSLbKXCMRsyyzUuujLWw3Q== From: To: X-OriginalArrivalTime: 19 Jan 2007 12:16:21.0465 (UTC) FILETIME=[A1540C90:01C73BC3] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [NSIS] QSPEC document 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="===============1527199741==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1527199741== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73BC3.A295D515" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73BC3.A295D515 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jerry, Could you send an update on the current status on the QSPEC? I think we were wrapping up most of the open issues, but it might be good to have a summary of where we stand on this. When do you think that you can update the document? thanks, John ------_=_NextPart_001_01C73BC3.A295D515 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable QSPEC document

Jerry,

Could you send an update on the = current status on the QSPEC? I think we were wrapping up most of the = open issues, but it might be good to have a summary of where we stand on = this.  When do you think that you can update the = document?

thanks,
John

------_=_NextPart_001_01C73BC3.A295D515-- --===============1527199741== 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 --===============1527199741==-- From nsis-bounces@ietf.org Fri Jan 19 07:20:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7siq-0006gO-9F; Fri, 19 Jan 2007 07:19:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7sip-0006gG-1e for nsis@ietf.org; Fri, 19 Jan 2007 07:19:55 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7sin-0004BS-AC for nsis@ietf.org; Fri, 19 Jan 2007 07:19:54 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0JCHQNg007834 for ; Fri, 19 Jan 2007 14:17:36 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 14:19:17 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 06:19:07 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Jan 2007 06:19:05 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F12BD20@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of GIST DISCUSSes Thread-Index: Acc7xALo4vy3iZbkRlK4xu5T7C0vFA== From: To: X-OriginalArrivalTime: 19 Jan 2007 12:19:07.0480 (UTC) FILETIME=[0447ED80:01C73BC4] X-eXpurgate-Category: 1/4 X-eXpurgate-ID: 149371::070119141736-1E823BB0-6297AA85/0-0/0-17 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [NSIS] Status of GIST DISCUSSes 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="===============1102952782==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1102952782== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73BC4.0585D936" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73BC4.0585D936 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert / Henning, Can you update the working group on the status of the DISCUSSes on GIST? We are very late on this document, we need to wrap this up as soon as possible. thanks, John ------_=_NextPart_001_01C73BC4.0585D936 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Status of GIST DISCUSSes

Robert / Henning,

Can you update the working group on = the status of the DISCUSSes on GIST?  We are very late on this = document, we need to wrap this up as soon as possible.

thanks,
John

------_=_NextPart_001_01C73BC4.0585D936-- --===============1102952782== 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 --===============1102952782==-- From nsis-bounces@ietf.org Fri Jan 19 09:16:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7uXU-00017b-A8; Fri, 19 Jan 2007 09:16:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7uXS-00017W-Va for nsis@ietf.org; Fri, 19 Jan 2007 09:16:18 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7uXN-000680-VH for nsis@ietf.org; Fri, 19 Jan 2007 09:16:18 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1H7uX1-00079a-J7; Fri, 19 Jan 2007 15:15:58 +0100 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1H7uX0-0006hm-0d; Fri, 19 Jan 2007 15:15:50 +0100 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 1402CB600; Fri, 19 Jan 2007 15:15:49 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1H7uWy-0005te-2I; Fri, 19 Jan 2007 15:15:48 +0100 Message-ID: <45B0D293.1030409@tm.uka.de> Date: Fri, 19 Jan 2007 15:15:47 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Re: Clarification: tearing down from intermediate node References: <45A4BEF2.5020109@sg.panasonic.com> <20070112195212.1121.SANDA.TAKAKO@jp.panasonic.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.0 (----) 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.4 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: Takako Sanda , Hong Cheng , 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, Jukka MJ Manner wrote: > There is actually another problem with the RSN. > > Consider the case "MN as QNR and data receiver" > > When QNE3 gets the notify, it replies back with a RESERVE towards QNR > which has "RSN=old-RSN +1". But all nodes from QNI up to QNE3 will still > be sending refresh messages using the old RSN. > > Thus, we need some further mechanism to inform the QNI that it should use > a new RSN value in further refreshes, right? E.g. a NOTIFY towards the QNI No, not really. Maybe I'm completely off-track, but IIRC RSNs have only local significance between directly adjacent QNEs. Thus there is simply no need to notify other nodes upstream of a new RSN value. > that says "Path changed, new RSN" and include the new RSN? Sounds like a > hack, any suggestions? Maybe I need to dig into a scenario down below before I understand the problem, but the above suggestion doesn't make sense to me. Roland > Jukka > > On Fri, 12 Jan 2007, Takako Sanda wrote: > >> Hi Jukka, >> >> I still have a question for the operation below. >> >> >>>>> The tear-down part: >>>>> - QNE3 also noticies that the SII-Handle has changed, and could basically >>>>> send a NOTIFY to QNE2 and through the QNI's old path saying "Route >>>>> Change" 0x02 >>>>> - QNE2 will forward it to QNE1 >>>>> - QNE1 would then at some point figure out QNI has disappeared, and will >>>>> start removing the reservation using a tearing RESERVE >>>> How the QNE1 figure out the QNI has disappeared might require some >>>> enhancement. Maybe the "Route Change" indication from QNE3 could further >>>> identify whether it is upstream route changed or downstream route changed. It >>>> might help the QNE1 reach the conclusion faster. >>> JM: I believe this falls a bit down the path of security. What can a QNE >>> trust? I would rather let the QNE1 figure by itself that the QNI has >>> disappeared. The message sent is only a hint that tells QNE1 to verify if >>> QNI is still there. It would only take a few seconds, basically once the >>> retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce >>> that the QNI is gone. >> How does QNE1 know the next peer was NI? >> In order to know this, I guess, QNE1 needs to have received an explicit >> notification from NI in advance. >> >> cheers, >> Takako >> >> On Wed, 10 Jan 2007 12:35:00 +0200 (EET) >> Jukka MJ Manner wrote: >> >>> Hi, >>> >>> some answers below. >>> >>> Jukka >>> >>> On Wed, 10 Jan 2007, Hong Cheng wrote: >>> >>>> Hi Jukka, >>>> >>>> The operation is well analyzed. The text should be incorporated into the >>>> Mobility Applicability draft. I think generally a tear-down could be >>>> initiated by any QNE (e.g. the CRN), as long as it is along the direction >>>> from QNI to QNR. >>>> >>>> Please find a few more comments inline. >>>> >>>> cheers >>>> >>>> Cheng Hong >>>> >>>> >>>> Jukka MJ Manner wrote: >>>>> Hi Cheng, >>>>> >>>>> After re-reading the QoS NSLP spec, I think the spec is quite accurate in >>>>> how the NSLP supports mobility, and it seems to work properly. Tearing down >>>>> the reservation on the old path from the cross-over QNE would be good to >>>>> do, but not necessarily critical for the proper operation of the NSLP. Yet, >>>>> the current QoS NSLP spec mentions the tear-down at the cross-over router. >>>>> >>>>> Consider the following scenario: >>>>> >>>>> >>>>> >>>>> [MN] [QNE1] --- [QNE2] ---\ >>>>> | \ >>>>> | [QNE3] --- [QNE6] --- [QNE7] --- >>>>> | / >>>>> V / >>>>> [MN] [QNE4] --- [QNE5]---/ >>>>> >>>>> >>>>> The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR >>>>> and receiver" >>>>> >>>>> "MN as QNI and data sender": we could rely on just the soft-state to expire >>>>> on the old path, and a new RESERVE on the new path, or use the following, >>>>> based on the NSLP draft text. >>>>> >>>>> - MN moves from peer QNE1 to QNE4 >>>>> - GIST gets a hint that routing has changed, triggers the NSLP >>>>> - The NSLP then sends a new full RESERVE with a new RSN >>>>> - The RESERVE hits QNE4, which makes reservation >>>>> - Then the RESERVE is forwarded to QNE5, which also makes the reservation >>>>> - Finally, the RESERVE hits QNE3, which makes a reservation and forwards >>>>> the RESERVE to QNE6, and so on >>>>> >>>>> The tear-down part: >>>>> - QNE3 also noticies that the SII-Handle has changed, and could basically >>>>> send a NOTIFY to QNE2 and through the QNI's old path saying "Route >>>>> Change" 0x02 >>>>> - QNE2 will forward it to QNE1 >>>>> - QNE1 would then at some point figure out QNI has disappeared, and will >>>>> start removing the reservation using a tearing RESERVE >>>> How the QNE1 figure out the QNI has disappeared might require some >>>> enhancement. Maybe the "Route Change" indication from QNE3 could further >>>> identify whether it is upstream route changed or downstream route changed. It >>>> might help the QNE1 reach the conclusion faster. >>> JM: I believe this falls a bit down the path of security. What can a QNE >>> trust? I would rather let the QNE1 figure by itself that the QNI has >>> disappeared. The message sent is only a hint that tells QNE1 to verify if >>> QNI is still there. It would only take a few seconds, basically once the >>> retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce >>> that the QNI is gone. >>> >>>>> - The tearing RESERVE will eventually hit QNE3, which noticies that it has >>>>> an existing, and newer state (higher RSN), and will drop the tear >>>>> >>>>> >>>>> "MN as QNR and data receiver": we could rely on routing changes to >>>>> eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will >>>>> then send back a RESPONSE saying "full QSPEC required". A subsequent full >>>>> RESERVE will then set up the reservation on the new path. Or, in order to >>>>> make it faster, we could use the following: >>>>> >>>>> - MN moves, gets a hint from GIST that routing has changed >>>>> - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 >>>>> - QNE4 will receive it, and forward it, same with QNE5 >>>> This is assuming the QNE4 has already been discovered. When the MN is QNR and >>>> data receiver, considering the discovery process, wouldn't sending a trigger >>>> to QNI directly result in a faster process? >>> JM: Once GIST tells a routing change has happened, the NSLP will ask GIST >>> to send the NOTIFY towards the QNI. For doing that, GIST must find the >>> next peer QNE node, which is QNE4 in this case. Since the NSLP works >>> hop-by-hop, you can't really send a message directly to the QNI, without >>> going through all the intermediate nodes. >>> >>>>> - The NOTIFY will hit QNE3, which notes that the message for a known >>>>> session comes from a new SII-Handle. >>>>> - QNE3 should then send a full RESERVE with a new RSN and an RII to >>>>> QNE5 >>>>> - QNE4 will receive the RESERVE, make the reservation, and forward it to >>>>> the MN >>>>> - The MN gets the RESERVE and replies with a RESPONSE >>>>> >>>>> The tear down: >>>>> - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which >>>>> again sends ti QNE1 >>>>> >>>>> >>>>> Jukka >>>>> >>>>> >>>>> On Thu, 14 Dec 2006, Hong Cheng wrote: >>>>> >>>>>> Hi Jukka, >>>>>> >>>>>> I would agree that the cross-over router should be left capable of >>>>>> tearing >>>>>> down the unneeded reservations. Please see some comments inline below: >>>>>> >>>>>> cheers >>>>>> >>>>>> Cheng Hong >>>>>> >>>>>> >>>>>> Jukka MJ Manner wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> If you look at how the NSIS protocols work, there is no way a node can >>>>>>> make sure a tear-down was intiated by the QNI. A QNE receives a >>>>>>> teardown from its upstream peer, but it can't tell whether that peer >>>>>>> initiated the tear down in the first place, or the QNI. >>>>>>> >>>>>>> If I would do a "mobility enhanced QoS NSLP", I would tear down at the >>>>>>> cross-over router the unnecessary reservation. Of course the spec can >>>>>>> say >>>>>>> "don't do it", but a QNE can not really confirm it isn't being done. >>>>>>> And the >>>>>>> QNI or the QNR can't see that either. >>>>>>> >>>>>>> The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to >>>>>>> initiate a tear down", and thus leave the option open for a QNE to also >>>>>>> do >>>>>>> it. >>>>>>> >>>>>> [Cheng] Agree. This should be left open. And I think the quoted text in >>>>>> current QoS NSLP draft is reflecting this point. >>>>>> >>>>>>> Or we could make a new INFO_SPEC code for "reservation not need" which >>>>>>> is a >>>>>>> hint sent by the cross-over router to inform downstream QNEs on the old >>>>>>> path >>>>>>> that the MN has moved away. It is then up to each QNE to decide whether >>>>>>> to >>>>>>> remove the resources and state, or not. >>>>>>> >>>>>>> >>>>>> [Cheng] This option might lead to some problem though, since it could >>>>>> leave >>>>>> the QNEs on the path unsynchronized should they decide to do different >>>>>> things >>>>>> in response to the INFO_SPEC. >>>>>> >>>>>>> Jukka >>>>>>> >>>>>>> On Wed, 13 Dec 2006, Takako Sanda wrote: >>>>>>> >>>>>>> >>>>>>>> Hi Jukka and all, >>>>>>>> >>>>>>>> I would like to clarify about tearing down operation. >>>>>>>> >>>>>>>> In section 3.2.11 (Rerouting), 5th paragraph, it is said, >>>>>>>> "After the reservation on the new path is set up, the branching >>>>>>>> node >>>>>>>> may want to tear down the reservation on the old path (sooner than >>>>>>>> would result from normal soft-state time-out)." >>>>>>>> >>>>>>>> This means that the CRN will initiate the TEAR on the old path. >>>>>>>> >>>>>>>> At Munich Interim, It was discussed that tearing down from >>>>>>>> intermediate >>>>>>>> node needs to be avoided because of session ownership issue. But I >>>>>>>> cannot find any conclusion of this discussion. >>>>>>>> http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html >>>>>>>> >>>>>>>> Do we have any decision for "tearing down from intermediate node"? >>>>>>>> >>>>>>>> cheers, >>>>>>>> Takako >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, 06 Dec 2006 12:09:25 +0200 (EET) >>>>>>>> Jukka MJ Manner wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> I sent the following request for feedback two weeks ago. No >>>>>>>>> comments >>>>>>>>> have been raised. I will wait until this Friday, then submit the >>>>>>>>> draft. >>>>>>>>> >>>>>>>>> Jukka >>>>>>>>> >>>>>>>>> On Tue, 21 Nov 2006, Jukka MJ Manner wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I have done all the edits I had in my list to the QoS NSLP spec, >>>>>>>>>> the >>>>>>>>>> main points are in recent thread with Roland. From the url below >>>>>>>>>> you >>>>>>>>>> can find the current draft v. "13-pre1" and a diff to v. 12. >>>>>>>>>> >>>>>>>>>> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ >>>>>>>>>> >>>>>>>>>> A direct link to the diff: >>>>>>>>>> >>>>>>>>>> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I would appreciate comments on the changes I did (what is wrong, >>>>>>>>>> what >>>>>>>>>> I missed, etc.). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I still have one problem with the spec, namely the way the NSLP >>>>>>>>>> suggests to handle mobility and path changes. I think we need to >>>>>>>>>> review that statement, because it seems like a "hack" (playing >>>>>>>>>> with >>>>>>>>>> the RSN value), and not really useful. And the interactions with >>>>>>>>>> GIST >>>>>>>>>> look partly wrong. The folks working on the mobility draft (me >>>>>>>>>> included) could comment. The section I'm talking about is 3.2.10, >>>>>>>>>> especially 3.2.10.2, in the v.12 draft. >>>>>>>>>> >>>>>>>>>> BR, >>>>>>>>>> Jukka >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >> ----- >> Takako SANDA >> Next-Generation Mobile Communications Development Center, >> Matsushita Electric Industrial Co., Ltd. (Panasonic) >> Phone: +81 46 840 5764 Fax: +81 46 840 5122 >> >> >> > -- Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless Institut für Telematik, Universität Karlsruhe (TH), Germany Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 19 10:04:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vHc-0001jx-DS; Fri, 19 Jan 2007 10:04:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vHb-0001js-2y for nsis@ietf.org; Fri, 19 Jan 2007 10:03:59 -0500 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 1H7vHY-0005hh-6h for nsis@ietf.org; Fri, 19 Jan 2007 10:03:59 -0500 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; Fri, 19 Jan 2007 17:03:52 +0200 id 000808C7.45B0DDD8.000010E2 Date: Fri, 19 Jan 2007 17:03:50 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] Re: Clarification: tearing down from intermediate node In-Reply-To: <45B0D293.1030409@tm.uka.de> Message-ID: References: <45A4BEF2.5020109@sg.panasonic.com> <20070112195212.1121.SANDA.TAKAKO@jp.panasonic.com> <45B0D293.1030409@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: Takako Sanda , Hong Cheng , 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 Right... True. Even though the RSN changes on some hops of the e2e path, this doesn't really need to be propagated anywhere. The only case where we need to do e2e signaling is when the MRI changes, e.g., the CoA of the MN. Jukka On Fri, 19 Jan 2007, Roland Bless wrote: > Hi Jukka, > > Jukka MJ Manner wrote: > > There is actually another problem with the RSN. > > > > Consider the case "MN as QNR and data receiver" > > > > When QNE3 gets the notify, it replies back with a RESERVE towards QNR > > which has "RSN=old-RSN +1". But all nodes from QNI up to QNE3 will still > > be sending refresh messages using the old RSN. > > > > Thus, we need some further mechanism to inform the QNI that it should use > > a new RSN value in further refreshes, right? E.g. a NOTIFY towards the QNI > > No, not really. Maybe I'm completely off-track, but IIRC RSNs have only > local significance between directly adjacent QNEs. Thus there is simply > no need to notify other nodes upstream of a new RSN value. > > > that says "Path changed, new RSN" and include the new RSN? Sounds like a > > hack, any suggestions? > > Maybe I need to dig into a scenario down below before I understand > the problem, but the above suggestion doesn't make sense to me. > > Roland > > > Jukka > > > > On Fri, 12 Jan 2007, Takako Sanda wrote: > > > >> Hi Jukka, > >> > >> I still have a question for the operation below. > >> > >> > >>>>> The tear-down part: > >>>>> - QNE3 also noticies that the SII-Handle has changed, and could basically > >>>>> send a NOTIFY to QNE2 and through the QNI's old path saying "Route > >>>>> Change" 0x02 > >>>>> - QNE2 will forward it to QNE1 > >>>>> - QNE1 would then at some point figure out QNI has disappeared, and will > >>>>> start removing the reservation using a tearing RESERVE > >>>> How the QNE1 figure out the QNI has disappeared might require some > >>>> enhancement. Maybe the "Route Change" indication from QNE3 could further > >>>> identify whether it is upstream route changed or downstream route changed. It > >>>> might help the QNE1 reach the conclusion faster. > >>> JM: I believe this falls a bit down the path of security. What can a QNE > >>> trust? I would rather let the QNE1 figure by itself that the QNI has > >>> disappeared. The message sent is only a hint that tells QNE1 to verify if > >>> QNI is still there. It would only take a few seconds, basically once the > >>> retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce > >>> that the QNI is gone. > >> How does QNE1 know the next peer was NI? > >> In order to know this, I guess, QNE1 needs to have received an explicit > >> notification from NI in advance. > >> > >> cheers, > >> Takako > >> > >> On Wed, 10 Jan 2007 12:35:00 +0200 (EET) > >> Jukka MJ Manner wrote: > >> > >>> Hi, > >>> > >>> some answers below. > >>> > >>> Jukka > >>> > >>> On Wed, 10 Jan 2007, Hong Cheng wrote: > >>> > >>>> Hi Jukka, > >>>> > >>>> The operation is well analyzed. The text should be incorporated into the > >>>> Mobility Applicability draft. I think generally a tear-down could be > >>>> initiated by any QNE (e.g. the CRN), as long as it is along the direction > >>>> from QNI to QNR. > >>>> > >>>> Please find a few more comments inline. > >>>> > >>>> cheers > >>>> > >>>> Cheng Hong > >>>> > >>>> > >>>> Jukka MJ Manner wrote: > >>>>> Hi Cheng, > >>>>> > >>>>> After re-reading the QoS NSLP spec, I think the spec is quite accurate in > >>>>> how the NSLP supports mobility, and it seems to work properly. Tearing down > >>>>> the reservation on the old path from the cross-over QNE would be good to > >>>>> do, but not necessarily critical for the proper operation of the NSLP. Yet, > >>>>> the current QoS NSLP spec mentions the tear-down at the cross-over router. > >>>>> > >>>>> Consider the following scenario: > >>>>> > >>>>> > >>>>> > >>>>> [MN] [QNE1] --- [QNE2] ---\ > >>>>> | \ > >>>>> | [QNE3] --- [QNE6] --- [QNE7] --- > >>>>> | / > >>>>> V / > >>>>> [MN] [QNE4] --- [QNE5]---/ > >>>>> > >>>>> > >>>>> The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR > >>>>> and receiver" > >>>>> > >>>>> "MN as QNI and data sender": we could rely on just the soft-state to expire > >>>>> on the old path, and a new RESERVE on the new path, or use the following, > >>>>> based on the NSLP draft text. > >>>>> > >>>>> - MN moves from peer QNE1 to QNE4 > >>>>> - GIST gets a hint that routing has changed, triggers the NSLP > >>>>> - The NSLP then sends a new full RESERVE with a new RSN > >>>>> - The RESERVE hits QNE4, which makes reservation > >>>>> - Then the RESERVE is forwarded to QNE5, which also makes the reservation > >>>>> - Finally, the RESERVE hits QNE3, which makes a reservation and forwards > >>>>> the RESERVE to QNE6, and so on > >>>>> > >>>>> The tear-down part: > >>>>> - QNE3 also noticies that the SII-Handle has changed, and could basically > >>>>> send a NOTIFY to QNE2 and through the QNI's old path saying "Route > >>>>> Change" 0x02 > >>>>> - QNE2 will forward it to QNE1 > >>>>> - QNE1 would then at some point figure out QNI has disappeared, and will > >>>>> start removing the reservation using a tearing RESERVE > >>>> How the QNE1 figure out the QNI has disappeared might require some > >>>> enhancement. Maybe the "Route Change" indication from QNE3 could further > >>>> identify whether it is upstream route changed or downstream route changed. It > >>>> might help the QNE1 reach the conclusion faster. > >>> JM: I believe this falls a bit down the path of security. What can a QNE > >>> trust? I would rather let the QNE1 figure by itself that the QNI has > >>> disappeared. The message sent is only a hint that tells QNE1 to verify if > >>> QNI is still there. It would only take a few seconds, basically once the > >>> retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce > >>> that the QNI is gone. > >>> > >>>>> - The tearing RESERVE will eventually hit QNE3, which noticies that it has > >>>>> an existing, and newer state (higher RSN), and will drop the tear > >>>>> > >>>>> > >>>>> "MN as QNR and data receiver": we could rely on routing changes to > >>>>> eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will > >>>>> then send back a RESPONSE saying "full QSPEC required". A subsequent full > >>>>> RESERVE will then set up the reservation on the new path. Or, in order to > >>>>> make it faster, we could use the following: > >>>>> > >>>>> - MN moves, gets a hint from GIST that routing has changed > >>>>> - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > >>>>> - QNE4 will receive it, and forward it, same with QNE5 > >>>> This is assuming the QNE4 has already been discovered. When the MN is QNR and > >>>> data receiver, considering the discovery process, wouldn't sending a trigger > >>>> to QNI directly result in a faster process? > >>> JM: Once GIST tells a routing change has happened, the NSLP will ask GIST > >>> to send the NOTIFY towards the QNI. For doing that, GIST must find the > >>> next peer QNE node, which is QNE4 in this case. Since the NSLP works > >>> hop-by-hop, you can't really send a message directly to the QNI, without > >>> going through all the intermediate nodes. > >>> > >>>>> - The NOTIFY will hit QNE3, which notes that the message for a known > >>>>> session comes from a new SII-Handle. > >>>>> - QNE3 should then send a full RESERVE with a new RSN and an RII to > >>>>> QNE5 > >>>>> - QNE4 will receive the RESERVE, make the reservation, and forward it to > >>>>> the MN > >>>>> - The MN gets the RESERVE and replies with a RESPONSE > >>>>> > >>>>> The tear down: > >>>>> - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which > >>>>> again sends ti QNE1 > >>>>> > >>>>> > >>>>> Jukka > >>>>> > >>>>> > >>>>> On Thu, 14 Dec 2006, Hong Cheng wrote: > >>>>> > >>>>>> Hi Jukka, > >>>>>> > >>>>>> I would agree that the cross-over router should be left capable of > >>>>>> tearing > >>>>>> down the unneeded reservations. Please see some comments inline below: > >>>>>> > >>>>>> cheers > >>>>>> > >>>>>> Cheng Hong > >>>>>> > >>>>>> > >>>>>> Jukka MJ Manner wrote: > >>>>>>> Hi all, > >>>>>>> > >>>>>>> If you look at how the NSIS protocols work, there is no way a node can > >>>>>>> make sure a tear-down was intiated by the QNI. A QNE receives a > >>>>>>> teardown from its upstream peer, but it can't tell whether that peer > >>>>>>> initiated the tear down in the first place, or the QNI. > >>>>>>> > >>>>>>> If I would do a "mobility enhanced QoS NSLP", I would tear down at the > >>>>>>> cross-over router the unnecessary reservation. Of course the spec can > >>>>>>> say > >>>>>>> "don't do it", but a QNE can not really confirm it isn't being done. > >>>>>>> And the > >>>>>>> QNI or the QNR can't see that either. > >>>>>>> > >>>>>>> The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to > >>>>>>> initiate a tear down", and thus leave the option open for a QNE to also > >>>>>>> do > >>>>>>> it. > >>>>>>> > >>>>>> [Cheng] Agree. This should be left open. And I think the quoted text in > >>>>>> current QoS NSLP draft is reflecting this point. > >>>>>> > >>>>>>> Or we could make a new INFO_SPEC code for "reservation not need" which > >>>>>>> is a > >>>>>>> hint sent by the cross-over router to inform downstream QNEs on the old > >>>>>>> path > >>>>>>> that the MN has moved away. It is then up to each QNE to decide whether > >>>>>>> to > >>>>>>> remove the resources and state, or not. > >>>>>>> > >>>>>>> > >>>>>> [Cheng] This option might lead to some problem though, since it could > >>>>>> leave > >>>>>> the QNEs on the path unsynchronized should they decide to do different > >>>>>> things > >>>>>> in response to the INFO_SPEC. > >>>>>> > >>>>>>> Jukka > >>>>>>> > >>>>>>> On Wed, 13 Dec 2006, Takako Sanda wrote: > >>>>>>> > >>>>>>> > >>>>>>>> Hi Jukka and all, > >>>>>>>> > >>>>>>>> I would like to clarify about tearing down operation. > >>>>>>>> > >>>>>>>> In section 3.2.11 (Rerouting), 5th paragraph, it is said, > >>>>>>>> "After the reservation on the new path is set up, the branching > >>>>>>>> node > >>>>>>>> may want to tear down the reservation on the old path (sooner than > >>>>>>>> would result from normal soft-state time-out)." > >>>>>>>> > >>>>>>>> This means that the CRN will initiate the TEAR on the old path. > >>>>>>>> > >>>>>>>> At Munich Interim, It was discussed that tearing down from > >>>>>>>> intermediate > >>>>>>>> node needs to be avoided because of session ownership issue. But I > >>>>>>>> cannot find any conclusion of this discussion. > >>>>>>>> http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > >>>>>>>> > >>>>>>>> Do we have any decision for "tearing down from intermediate node"? > >>>>>>>> > >>>>>>>> cheers, > >>>>>>>> Takako > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > >>>>>>>> Jukka MJ Manner wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> Dear all, > >>>>>>>>> > >>>>>>>>> I sent the following request for feedback two weeks ago. No > >>>>>>>>> comments > >>>>>>>>> have been raised. I will wait until this Friday, then submit the > >>>>>>>>> draft. > >>>>>>>>> > >>>>>>>>> Jukka > >>>>>>>>> > >>>>>>>>> On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> I have done all the edits I had in my list to the QoS NSLP spec, > >>>>>>>>>> the > >>>>>>>>>> main points are in recent thread with Roland. From the url below > >>>>>>>>>> you > >>>>>>>>>> can find the current draft v. "13-pre1" and a diff to v. 12. > >>>>>>>>>> > >>>>>>>>>> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > >>>>>>>>>> > >>>>>>>>>> A direct link to the diff: > >>>>>>>>>> > >>>>>>>>>> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I would appreciate comments on the changes I did (what is wrong, > >>>>>>>>>> what > >>>>>>>>>> I missed, etc.). > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I still have one problem with the spec, namely the way the NSLP > >>>>>>>>>> suggests to handle mobility and path changes. I think we need to > >>>>>>>>>> review that statement, because it seems like a "hack" (playing > >>>>>>>>>> with > >>>>>>>>>> the RSN value), and not really useful. And the interactions with > >>>>>>>>>> GIST > >>>>>>>>>> look partly wrong. The folks working on the mobility draft (me > >>>>>>>>>> included) could comment. The section I'm talking about is 3.2.10, > >>>>>>>>>> especially 3.2.10.2, in the v.12 draft. > >>>>>>>>>> > >>>>>>>>>> BR, > >>>>>>>>>> Jukka > >>>>>>>>>> > >>>>>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> nsis mailing list > >>> nsis@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/nsis > >> ----- > >> Takako SANDA > >> Next-Generation Mobile Communications Development Center, > >> Matsushita Electric Industrial Co., Ltd. (Panasonic) > >> Phone: +81 46 840 5764 Fax: +81 46 840 5122 > >> > >> > >> > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 19 16:32:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H81KO-0005mT-DO; Fri, 19 Jan 2007 16:31:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H81KN-0005mO-QV for nsis@ietf.org; Fri, 19 Jan 2007 16:31:15 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H81KM-00070K-Fg for nsis@ietf.org; Fri, 19 Jan 2007 16:31:15 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-121.messagelabs.com!1169242273!19530918!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 17969 invoked from network); 19 Jan 2007 21:31:13 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-121.messagelabs.com with SMTP; 19 Jan 2007 21:31:13 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0JLVDLT009359; Fri, 19 Jan 2007 16:31:13 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0JLV4NJ009277; Fri, 19 Jan 2007 16:31:07 -0500 (EST) 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] QSPEC document Date: Fri, 19 Jan 2007 15:31:01 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8103@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F12BD1F@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC document Thread-Index: Acc7w5/5TSLbKXCMRsyyzUuujLWw3QAPhuGQ From: "Ash, Gerald R \(Jerry\), ALABS" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 John, =20 Per your request, I provide below a summary of the agreed-to changes/updates to the QSPEC draft http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-13.txt, based on the list discussion over the last few weeks. I plan to update the draft according to these changes and submit in the next day or two. Hopefully then we'll be ready to go to WGLC on the document? Thanks, Regards, Jerry There were 3 issues being debated at length on the list, summarized here by Georgios: http://www1.ietf.org/mail-archive/web/nsis/current/msg07374.html Editor responses to these 3 issues are here: http://www1.ietf.org/mail-archive/web/nsis/current/msg07402.html to which you responded: http://www1.ietf.org/mail-archive/web/nsis/current/msg07407.html and further declared consensus on these 3 issues as follows: 1. http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html 2. http://www1.ietf.org/mail-archive/web/nsis/current/msg07409.html 3. http://www1.ietf.org/mail-archive/web/nsis/current/msg07410.html Based on the declared consensus in 1, 2, and 3 above the following changes are agreed to: 1. Add the following text to Section 4.3.3 (Traffic Handling Directives): "Note that QOSM specifications SHOULD NOT define new RMF functions required by a QOSM UNLESS such NSIS signaling functionality is defined in QoS NSLP [QoS-SIG]. That is, a QOSM is not allowed to extend QoS NSLP signaling functionality; new RMF functions are specified only within a QoS NSLP signaling framework." 2. Add the following text to Section 5.1 (Local QSPEC Definition & Processing): "Note that it is possible to use, at the same time, both a) tunneling a QSPEC through a local domain by initiating a new RESERVE at the domain edge, and b) defining a local QSPEC and encapsulating the initiator QSPEC, as defined above." 3. Add the following text to Section 4.1 (QoS Models): "Signaling functionality is only defined by the QoS NSLP document [QoS-SIG] and not by this document." Also based on list discussion, these changes have been agreed to: 4. Add the following text to Section 4.1 (QoS Models), and also reference specifically in Section 4.3.3 (Traffic Handling Directives): "QOSMs are free, subject to IANA registration and review rules, to extend QSPECs by adding parameters of any of the kinds supported by the standard QSPEC. This includes traffic description parameters, constraint parameters and traffic handling directives. QOSMs are not permitted, however, to reinterpret or redefine the standard QSPEC =20 parameters specified in this document." 5. In Section 5.1 (Local QSPEC Definition & Processing), last paragraph: =20 Change: "For example, RMD can define a local QSPEC that contains TMOD =3D bandwidth (sets r=3Dp, b/m to large)." Into: "For example, in RMD the TMOD parameters contained in the original initiator QSPEC are mapped into the equivalent TMOD parameter representing only the peak bandwidth in the local QSPEC." 6. In Section 6.1 (General QSPEC Formats): Remove the sentence "N Flag: Not-supported QSPEC parameter flag (see Section 5.2.2). For QSPEC parameters the value of this flag is always zero." ________________________________ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Friday, January 19, 2007 7:16 AM To: nsis@ietf.org Subject: [NSIS] QSPEC document Jerry,=20 Could you send an update on the current status on the QSPEC? I think we were wrapping up most of the open issues, but it might be good to have a summary of where we stand on this. When do you think that you can update the document? thanks,=20 John=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 19 16:41:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H81TI-0002BV-Sb; Fri, 19 Jan 2007 16:40:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H81TH-0002B4-RT for nsis@ietf.org; Fri, 19 Jan 2007 16:40:27 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H81TF-0000sH-Qn for nsis@ietf.org; Fri, 19 Jan 2007 16:40:27 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0JLcOE3026597; Fri, 19 Jan 2007 23:38:37 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 23:39:58 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 15:40:02 -0600 Received: from 172.21.138.143 ([172.21.138.143]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Fri, 19 Jan 2007 21:40:01 +0000 From: "Loughney John \(Nokia-NRC/PaloAlto\)" To: "ext Ash, Gerald R \\\(Jerry\\\), ALABS" , Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC document Date: Fri, 19 Jan 2007 21:37:31 +0200 Message-ID: thread-topic: [NSIS] QSPEC document thread-index: Acc7w5/5TSLbKXCMRsyyzUuujLWw3QAPhuGQAAQpAmw= X-MimeOLE: Produced By Microsoft Exchange V6.5 X-Mailer: EAS Version 1.00 MIME-Version: 1.0 Content-Language: i-default X-OriginalArrivalTime: 19 Jan 2007 21:40:02.0083 (UTC) FILETIME=[5FFCCF30:01C73C12] X-Nokia-AV: Clean X-Spam-Score: 3.1 (+++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 Jerry, That would be the plan. We'll run a tight last call. All changes will = need substantial support on the mailing list. Let's finish this up, = because having no standard is not a good solution John sent from my Nokia E61 --- original message --- From: "ext Ash, Gerald R \(Jerry\), ALABS" Subject: RE: [NSIS] QSPEC document Date: 19th January 2007 Time: 11:31:24 pm Hi John, =20 Per your request, I provide below a summary of the agreed-to changes/updates to the QSPEC draft http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-13.txt, based on the list discussion over the last few weeks. I plan to update the draft according to these changes and submit in the next day or two. Hopefully then we'll be ready to go to WGLC on the document? Thanks, Regards, Jerry There were 3 issues being debated at length on the list, summarized here by Georgios: http://www1.ietf.org/mail-archive/web/nsis/current/msg07374.html Editor responses to these 3 issues are here: http://www1.ietf.org/mail-archive/web/nsis/current/msg07402.html to which you responded: http://www1.ietf.org/mail-archive/web/nsis/current/msg07407.html and further declared consensus on these 3 issues as follows: 1. http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html 2. http://www1.ietf.org/mail-archive/web/nsis/current/msg07409.html 3. http://www1.ietf.org/mail-archive/web/nsis/current/msg07410.html Based on the declared consensus in 1, 2, and 3 above the following changes are agreed to: 1. Add the following text to Section 4.3.3 (Traffic Handling Directives): "Note that QOSM specifications SHOULD NOT define new RMF functions required by a QOSM UNLESS such NSIS signaling functionality is defined in QoS NSLP [QoS-SIG]. That is, a QOSM is not allowed to extend QoS NSLP signaling functionality; new RMF functions are specified only within a QoS NSLP signaling framework." 2. Add the following text to Section 5.1 (Local QSPEC Definition & Processing): "Note that it is possible to use, at the same time, both a) tunneling a QSPEC through a local domain by initiating a new RESERVE at the domain edge, and b) defining a local QSPEC and encapsulating the initiator QSPEC, as defined above." 3. Add the following text to Section 4.1 (QoS Models): "Signaling functionality is only defined by the QoS NSLP document [QoS-SIG] and not by this document." Also based on list discussion, these changes have been agreed to: 4. Add the following text to Section 4.1 (QoS Models), and also reference specifically in Section 4.3.3 (Traffic Handling Directives): "QOSMs are free, subject to IANA registration and review rules, to extend QSPECs by adding parameters of any of the kinds supported by the standard QSPEC. This includes traffic description parameters, constraint parameters and traffic handling directives. QOSMs are not permitted, however, to reinterpret or redefine the standard QSPEC =20 parameters specified in this document." 5. In Section 5.1 (Local QSPEC Definition & Processing), last paragraph: =20 Change: "For example, RMD can define a local QSPEC that contains TMOD =3D bandwidth (sets r=3Dp, b/m to large)." Into: "For example, in RMD the TMOD parameters contained in the original initiator QSPEC are mapped into the equivalent TMOD parameter representing only the peak bandwidth in the local QSPEC." 6. In Section 6.1 (General QSPEC Formats): Remove the sentence "N Flag: Not-supported QSPEC parameter flag (see Section 5.2.2). For QSPEC parameters the value of this flag is always zero." ________________________________ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Friday, January 19, 2007 7:16 AM To: nsis@ietf.org Subject: [NSIS] QSPEC document Jerry,=20 Could you send an update on the current status on the QSPEC? I think we were wrapping up most of the open issues, but it might be good to have a summary of where we stand on this. When do you think that you can update the document? thanks,=20 John=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 22 01:38:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8soD-0003Zh-VI; Mon, 22 Jan 2007 01:37:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8soD-0003Zc-4F for nsis@ietf.org; Mon, 22 Jan 2007 01:37:37 -0500 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8so9-0003O1-2K for nsis@ietf.org; Mon, 22 Jan 2007 01:37:37 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id l0M6bOEC021315; Mon, 22 Jan 2007 15:37:24 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l0M6bNO07482; Mon, 22 Jan 2007 15:37:23 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id l0M6bON08051; Mon, 22 Jan 2007 15:37:24 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 14:34:56 +0800 Message-ID: <45B45B11.4030805@sg.panasonic.com> Date: Mon, 22 Jan 2007 14:34:57 +0800 From: Hong Cheng User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Re: Clarification: tearing down from intermediate node References: <45A4BEF2.5020109@sg.panasonic.com> <20070112195212.1121.SANDA.TAKAKO@jp.panasonic.com> <45B0D293.1030409@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2007 06:34:56.0603 (UTC) FILETIME=[6EA36AB0:01C73DEF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Cc: Roland Bless , Takako Sanda , 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, The RSN is meant for adjacent QNEs only. It cannot be used for message/state management if the peer(/SII) is different. However, in mobility event handling, sometimes an e2e type of sequence number comes in handy, e.g. to detect the latest mobility event (as discussed in Mobility Applicability draft). I guess some of the confusion came from the tricks introduced in QoS NSLP draft section 3.2.10.2. It works fine with that particular scenario, but does not solve general problems (of identifying message sequences from different peers). Considering the scenario in your earlier mail (MN is sending and QNI case), the QNE3 has no way to tell if the message from QNE2 or QNE5 is newer, since the RSN doesn't apply here. cheers Cheng Hong Jukka MJ Manner wrote: > Right... True. Even though the RSN changes on some hops of the e2e > path, this doesn't really need to be propagated anywhere. > > The only case where we need to do e2e signaling is when the MRI changes, > e.g., the CoA of the MN. > > Jukka > > On Fri, 19 Jan 2007, Roland Bless wrote: > >> Hi Jukka, >> >> Jukka MJ Manner wrote: >>> There is actually another problem with the RSN. >>> >>> Consider the case "MN as QNR and data receiver" >>> >>> When QNE3 gets the notify, it replies back with a RESERVE towards QNR >>> which has "RSN=old-RSN +1". But all nodes from QNI up to QNE3 will still >>> be sending refresh messages using the old RSN. >>> >>> Thus, we need some further mechanism to inform the QNI that it should use >>> a new RSN value in further refreshes, right? E.g. a NOTIFY towards the QNI >> No, not really. Maybe I'm completely off-track, but IIRC RSNs have only >> local significance between directly adjacent QNEs. Thus there is simply >> no need to notify other nodes upstream of a new RSN value. >> >>> that says "Path changed, new RSN" and include the new RSN? Sounds like a >>> hack, any suggestions? >> Maybe I need to dig into a scenario down below before I understand >> the problem, but the above suggestion doesn't make sense to me. >> >> Roland >> >>> Jukka >>> >>> On Fri, 12 Jan 2007, Takako Sanda wrote: >>> >>>> Hi Jukka, >>>> >>>> I still have a question for the operation below. >>>> >>>> >>>>>>> The tear-down part: >>>>>>> - QNE3 also noticies that the SII-Handle has changed, and could basically >>>>>>> send a NOTIFY to QNE2 and through the QNI's old path saying "Route >>>>>>> Change" 0x02 >>>>>>> - QNE2 will forward it to QNE1 >>>>>>> - QNE1 would then at some point figure out QNI has disappeared, and will >>>>>>> start removing the reservation using a tearing RESERVE >>>>>> How the QNE1 figure out the QNI has disappeared might require some >>>>>> enhancement. Maybe the "Route Change" indication from QNE3 could further >>>>>> identify whether it is upstream route changed or downstream route changed. It >>>>>> might help the QNE1 reach the conclusion faster. >>>>> JM: I believe this falls a bit down the path of security. What can a QNE >>>>> trust? I would rather let the QNE1 figure by itself that the QNI has >>>>> disappeared. The message sent is only a hint that tells QNE1 to verify if >>>>> QNI is still there. It would only take a few seconds, basically once the >>>>> retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce >>>>> that the QNI is gone. >>>> How does QNE1 know the next peer was NI? >>>> In order to know this, I guess, QNE1 needs to have received an explicit >>>> notification from NI in advance. >>>> >>>> cheers, >>>> Takako >>>> >>>> On Wed, 10 Jan 2007 12:35:00 +0200 (EET) >>>> Jukka MJ Manner wrote: >>>> >>>>> Hi, >>>>> >>>>> some answers below. >>>>> >>>>> Jukka >>>>> >>>>> On Wed, 10 Jan 2007, Hong Cheng wrote: >>>>> >>>>>> Hi Jukka, >>>>>> >>>>>> The operation is well analyzed. The text should be incorporated into the >>>>>> Mobility Applicability draft. I think generally a tear-down could be >>>>>> initiated by any QNE (e.g. the CRN), as long as it is along the direction >>>>>> from QNI to QNR. >>>>>> >>>>>> Please find a few more comments inline. >>>>>> >>>>>> cheers >>>>>> >>>>>> Cheng Hong >>>>>> >>>>>> >>>>>> Jukka MJ Manner wrote: >>>>>>> Hi Cheng, >>>>>>> >>>>>>> After re-reading the QoS NSLP spec, I think the spec is quite accurate in >>>>>>> how the NSLP supports mobility, and it seems to work properly. Tearing down >>>>>>> the reservation on the old path from the cross-over QNE would be good to >>>>>>> do, but not necessarily critical for the proper operation of the NSLP. Yet, >>>>>>> the current QoS NSLP spec mentions the tear-down at the cross-over router. >>>>>>> >>>>>>> Consider the following scenario: >>>>>>> >>>>>>> >>>>>>> >>>>>>> [MN] [QNE1] --- [QNE2] ---\ >>>>>>> | \ >>>>>>> | [QNE3] --- [QNE6] --- [QNE7] --- >>>>>>> | / >>>>>>> V / >>>>>>> [MN] [QNE4] --- [QNE5]---/ >>>>>>> >>>>>>> >>>>>>> The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR >>>>>>> and receiver" >>>>>>> >>>>>>> "MN as QNI and data sender": we could rely on just the soft-state to expire >>>>>>> on the old path, and a new RESERVE on the new path, or use the following, >>>>>>> based on the NSLP draft text. >>>>>>> >>>>>>> - MN moves from peer QNE1 to QNE4 >>>>>>> - GIST gets a hint that routing has changed, triggers the NSLP >>>>>>> - The NSLP then sends a new full RESERVE with a new RSN >>>>>>> - The RESERVE hits QNE4, which makes reservation >>>>>>> - Then the RESERVE is forwarded to QNE5, which also makes the reservation >>>>>>> - Finally, the RESERVE hits QNE3, which makes a reservation and forwards >>>>>>> the RESERVE to QNE6, and so on >>>>>>> >>>>>>> The tear-down part: >>>>>>> - QNE3 also noticies that the SII-Handle has changed, and could basically >>>>>>> send a NOTIFY to QNE2 and through the QNI's old path saying "Route >>>>>>> Change" 0x02 >>>>>>> - QNE2 will forward it to QNE1 >>>>>>> - QNE1 would then at some point figure out QNI has disappeared, and will >>>>>>> start removing the reservation using a tearing RESERVE >>>>>> How the QNE1 figure out the QNI has disappeared might require some >>>>>> enhancement. Maybe the "Route Change" indication from QNE3 could further >>>>>> identify whether it is upstream route changed or downstream route changed. It >>>>>> might help the QNE1 reach the conclusion faster. >>>>> JM: I believe this falls a bit down the path of security. What can a QNE >>>>> trust? I would rather let the QNE1 figure by itself that the QNI has >>>>> disappeared. The message sent is only a hint that tells QNE1 to verify if >>>>> QNI is still there. It would only take a few seconds, basically once the >>>>> retransmission procudure of either GIST or the NSLP fails, QNE1 can deduce >>>>> that the QNI is gone. >>>>> >>>>>>> - The tearing RESERVE will eventually hit QNE3, which noticies that it has >>>>>>> an existing, and newer state (higher RSN), and will drop the tear >>>>>>> >>>>>>> >>>>>>> "MN as QNR and data receiver": we could rely on routing changes to >>>>>>> eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will >>>>>>> then send back a RESPONSE saying "full QSPEC required". A subsequent full >>>>>>> RESERVE will then set up the reservation on the new path. Or, in order to >>>>>>> make it faster, we could use the following: >>>>>>> >>>>>>> - MN moves, gets a hint from GIST that routing has changed >>>>>>> - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 >>>>>>> - QNE4 will receive it, and forward it, same with QNE5 >>>>>> This is assuming the QNE4 has already been discovered. When the MN is QNR and >>>>>> data receiver, considering the discovery process, wouldn't sending a trigger >>>>>> to QNI directly result in a faster process? >>>>> JM: Once GIST tells a routing change has happened, the NSLP will ask GIST >>>>> to send the NOTIFY towards the QNI. For doing that, GIST must find the >>>>> next peer QNE node, which is QNE4 in this case. Since the NSLP works >>>>> hop-by-hop, you can't really send a message directly to the QNI, without >>>>> going through all the intermediate nodes. >>>>> >>>>>>> - The NOTIFY will hit QNE3, which notes that the message for a known >>>>>>> session comes from a new SII-Handle. >>>>>>> - QNE3 should then send a full RESERVE with a new RSN and an RII to >>>>>>> QNE5 >>>>>>> - QNE4 will receive the RESERVE, make the reservation, and forward it to >>>>>>> the MN >>>>>>> - The MN gets the RESERVE and replies with a RESPONSE >>>>>>> >>>>>>> The tear down: >>>>>>> - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which >>>>>>> again sends ti QNE1 >>>>>>> >>>>>>> >>>>>>> Jukka >>>>>>> >>>>>>> >>>>>>> On Thu, 14 Dec 2006, Hong Cheng wrote: >>>>>>> >>>>>>>> Hi Jukka, >>>>>>>> >>>>>>>> I would agree that the cross-over router should be left capable of >>>>>>>> tearing >>>>>>>> down the unneeded reservations. Please see some comments inline below: >>>>>>>> >>>>>>>> cheers >>>>>>>> >>>>>>>> Cheng Hong >>>>>>>> >>>>>>>> >>>>>>>> Jukka MJ Manner wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> If you look at how the NSIS protocols work, there is no way a node can >>>>>>>>> make sure a tear-down was intiated by the QNI. A QNE receives a >>>>>>>>> teardown from its upstream peer, but it can't tell whether that peer >>>>>>>>> initiated the tear down in the first place, or the QNI. >>>>>>>>> >>>>>>>>> If I would do a "mobility enhanced QoS NSLP", I would tear down at the >>>>>>>>> cross-over router the unnecessary reservation. Of course the spec can >>>>>>>>> say >>>>>>>>> "don't do it", but a QNE can not really confirm it isn't being done. >>>>>>>>> And the >>>>>>>>> QNI or the QNR can't see that either. >>>>>>>>> >>>>>>>>> The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to >>>>>>>>> initiate a tear down", and thus leave the option open for a QNE to also >>>>>>>>> do >>>>>>>>> it. >>>>>>>>> >>>>>>>> [Cheng] Agree. This should be left open. And I think the quoted text in >>>>>>>> current QoS NSLP draft is reflecting this point. >>>>>>>> >>>>>>>>> Or we could make a new INFO_SPEC code for "reservation not need" which >>>>>>>>> is a >>>>>>>>> hint sent by the cross-over router to inform downstream QNEs on the old >>>>>>>>> path >>>>>>>>> that the MN has moved away. It is then up to each QNE to decide whether >>>>>>>>> to >>>>>>>>> remove the resources and state, or not. >>>>>>>>> >>>>>>>>> >>>>>>>> [Cheng] This option might lead to some problem though, since it could >>>>>>>> leave >>>>>>>> the QNEs on the path unsynchronized should they decide to do different >>>>>>>> things >>>>>>>> in response to the INFO_SPEC. >>>>>>>> >>>>>>>>> Jukka >>>>>>>>> >>>>>>>>> On Wed, 13 Dec 2006, Takako Sanda wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi Jukka and all, >>>>>>>>>> >>>>>>>>>> I would like to clarify about tearing down operation. >>>>>>>>>> >>>>>>>>>> In section 3.2.11 (Rerouting), 5th paragraph, it is said, >>>>>>>>>> "After the reservation on the new path is set up, the branching >>>>>>>>>> node >>>>>>>>>> may want to tear down the reservation on the old path (sooner than >>>>>>>>>> would result from normal soft-state time-out)." >>>>>>>>>> >>>>>>>>>> This means that the CRN will initiate the TEAR on the old path. >>>>>>>>>> >>>>>>>>>> At Munich Interim, It was discussed that tearing down from >>>>>>>>>> intermediate >>>>>>>>>> node needs to be avoided because of session ownership issue. But I >>>>>>>>>> cannot find any conclusion of this discussion. >>>>>>>>>> http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html >>>>>>>>>> >>>>>>>>>> Do we have any decision for "tearing down from intermediate node"? >>>>>>>>>> >>>>>>>>>> cheers, >>>>>>>>>> Takako >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, 06 Dec 2006 12:09:25 +0200 (EET) >>>>>>>>>> Jukka MJ Manner wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Dear all, >>>>>>>>>>> >>>>>>>>>>> I sent the following request for feedback two weeks ago. No >>>>>>>>>>> comments >>>>>>>>>>> have been raised. I will wait until this Friday, then submit the >>>>>>>>>>> draft. >>>>>>>>>>> >>>>>>>>>>> Jukka >>>>>>>>>>> >>>>>>>>>>> On Tue, 21 Nov 2006, Jukka MJ Manner wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I have done all the edits I had in my list to the QoS NSLP spec, >>>>>>>>>>>> the >>>>>>>>>>>> main points are in recent thread with Roland. From the url below >>>>>>>>>>>> you >>>>>>>>>>>> can find the current draft v. "13-pre1" and a diff to v. 12. >>>>>>>>>>>> >>>>>>>>>>>> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ >>>>>>>>>>>> >>>>>>>>>>>> A direct link to the diff: >>>>>>>>>>>> >>>>>>>>>>>> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I would appreciate comments on the changes I did (what is wrong, >>>>>>>>>>>> what >>>>>>>>>>>> I missed, etc.). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I still have one problem with the spec, namely the way the NSLP >>>>>>>>>>>> suggests to handle mobility and path changes. I think we need to >>>>>>>>>>>> review that statement, because it seems like a "hack" (playing >>>>>>>>>>>> with >>>>>>>>>>>> the RSN value), and not really useful. And the interactions with >>>>>>>>>>>> GIST >>>>>>>>>>>> look partly wrong. The folks working on the mobility draft (me >>>>>>>>>>>> included) could comment. The section I'm talking about is 3.2.10, >>>>>>>>>>>> especially 3.2.10.2, in the v.12 draft. >>>>>>>>>>>> >>>>>>>>>>>> BR, >>>>>>>>>>>> Jukka >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> nsis mailing list >>>>> nsis@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>> ----- >>>> Takako SANDA >>>> Next-Generation Mobile Communications Development Center, >>>> Matsushita Electric Industrial Co., Ltd. (Panasonic) >>>> Phone: +81 46 840 5764 Fax: +81 46 840 5122 >>>> >>>> >>>> >> >> > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 22 01:46:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8sw1-0007P7-Kv; Mon, 22 Jan 2007 01:45:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8sw0-0007Om-Hx for nsis@ietf.org; Mon, 22 Jan 2007 01:45:40 -0500 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8svz-0004t7-I5 for nsis@ietf.org; Mon, 22 Jan 2007 01:45:40 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id l0M6jYaC018524; Mon, 22 Jan 2007 15:45:34 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l0M6jZO12313; Mon, 22 Jan 2007 15:45:35 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with SMTP id l0M6jZH28748; Mon, 22 Jan 2007 15:45:35 +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] Re: Clarification: tearing down from intermediate node Date: Mon, 22 Jan 2007 14:43:01 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01768894@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Re: Clarification: tearing down from intermediate node Thread-Index: Acc6URvXOSSHu4h8SriUEOQiCN2MBgDno+oQ From: "Cheng Hong" To: "Jukka MJ Manner" , "Takako Sanda" X-Spam-Score: 0.1 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 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=20 > QNE1 just figures out that its next peer for the session is=20 > not there anymore, thus, the reservation can be torn down. If QNE1 doesn't know the next peer is QNI, would not it attempts some new path discovery/rerouting to find a new peer instead of immediately do a tear down? Although it is pretty much a local configuration issue, if no indication is available to help QNE1 making the decision, it may take quite long for it to decide tearing the old session down. Cheers Cheng Hong=20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: Thursday, January 18, 2007 12:06 AM > To: Takako Sanda > Cc: Cheng Hong; nsis@ietf.org > Subject: Re: [NSIS] Re: Clarification: tearing down from=20 > intermediate node >=20 >=20 > Hi, >=20 > QNE1 does not need to know that the next peer is the QNI.=20 > QNE1 just figures out that its next peer for the session is=20 > not there anymore, thus, the reservation can be torn down. >=20 > Jukka >=20 > On Fri, 12 Jan 2007, Takako Sanda wrote: >=20 > > Hi Jukka, > >=20 > > I still have a question for the operation below. > >=20 > >=20 > > > > > The tear-down part: > > > > > - QNE3 also noticies that the SII-Handle has changed,=20 > and could basically=20 > > > > > send a NOTIFY to QNE2 and through the QNI's old=20 > path saying "Route > > > > > Change" 0x02 > > > > > - QNE2 will forward it to QNE1 > > > > > - QNE1 would then at some point figure out QNI has=20 > disappeared, and will > > > > > start removing the reservation using a tearing RESERVE > > > >=20 > > > > How the QNE1 figure out the QNI has disappeared might=20 > require some=20 > > > > enhancement. Maybe the "Route Change" indication from=20 > QNE3 could=20 > > > > further identify whether it is upstream route changed or=20 > > > > downstream route changed. It might help the QNE1 reach=20 > the conclusion faster. > > >=20 > > > JM: I believe this falls a bit down the path of security.=20 > What can a=20 > > > QNE trust? I would rather let the QNE1 figure by itself=20 > that the QNI=20 > > > has disappeared. The message sent is only a hint that=20 > tells QNE1 to=20 > > > verify if QNI is still there. It would only take a few seconds,=20 > > > basically once the retransmission procudure of either GIST or the=20 > > > NSLP fails, QNE1 can deduce that the QNI is gone. > >=20 > > How does QNE1 know the next peer was NI? > > In order to know this, I guess, QNE1 needs to have received an=20 > > explicit notification from NI in advance. > >=20 > > cheers, > > Takako > >=20 > > On Wed, 10 Jan 2007 12:35:00 +0200 (EET) Jukka MJ Manner=20 > > wrote: > >=20 > > >=20 > > > Hi, > > >=20 > > > some answers below. > > >=20 > > > Jukka > > >=20 > > > On Wed, 10 Jan 2007, Hong Cheng wrote: > > >=20 > > > > Hi Jukka, > > > >=20 > > > > The operation is well analyzed. The text should be incorporated=20 > > > > into the Mobility Applicability draft. I think generally a=20 > > > > tear-down could be initiated by any QNE (e.g. the CRN),=20 > as long as=20 > > > > it is along the direction from QNI to QNR. > > > >=20 > > > > Please find a few more comments inline. > > > >=20 > > > > cheers > > > >=20 > > > > Cheng Hong > > > >=20 > > > >=20 > > > > Jukka MJ Manner wrote: > > > > > Hi Cheng, > > > > >=20 > > > > > After re-reading the QoS NSLP spec, I think the spec is quite=20 > > > > > accurate in how the NSLP supports mobility, and it=20 > seems to work=20 > > > > > properly. Tearing down the reservation on the old=20 > path from the=20 > > > > > cross-over QNE would be good to do, but not=20 > necessarily critical=20 > > > > > for the proper operation of the NSLP. Yet, the=20 > current QoS NSLP spec mentions the tear-down at the cross-over router. > > > > >=20 > > > > > Consider the following scenario: > > > > >=20 > > > > >=20 > > > > >=20 > > > > > [MN] [QNE1] --- [QNE2] ---\ > > > > > | \ > > > > > | [QNE3] --- [QNE6] --- [QNE7] --- > > > > > | / > > > > > V / > > > > > [MN] [QNE4] --- [QNE5]---/ > > > > >=20 > > > > >=20 > > > > > The two main (simple) cases are "MN as QNI and data=20 > sender" and=20 > > > > > "MN as QNR and receiver" > > > > >=20 > > > > > "MN as QNI and data sender": we could rely on just the=20 > > > > > soft-state to expire on the old path, and a new=20 > RESERVE on the=20 > > > > > new path, or use the following, based on the NSLP draft text. > > > > >=20 > > > > > - MN moves from peer QNE1 to QNE4 > > > > > - GIST gets a hint that routing has changed, triggers the NSLP > > > > > - The NSLP then sends a new full RESERVE with a new RSN > > > > > - The RESERVE hits QNE4, which makes reservation > > > > > - Then the RESERVE is forwarded to QNE5, which also makes the=20 > > > > > reservation > > > > > - Finally, the RESERVE hits QNE3, which makes a=20 > reservation and forwards=20 > > > > > the RESERVE to QNE6, and so on > > > > >=20 > > > > > The tear-down part: > > > > > - QNE3 also noticies that the SII-Handle has changed,=20 > and could basically=20 > > > > > send a NOTIFY to QNE2 and through the QNI's old=20 > path saying "Route > > > > > Change" 0x02 > > > > > - QNE2 will forward it to QNE1 > > > > > - QNE1 would then at some point figure out QNI has=20 > disappeared, and will > > > > > start removing the reservation using a tearing RESERVE > > > >=20 > > > > How the QNE1 figure out the QNI has disappeared might=20 > require some=20 > > > > enhancement. Maybe the "Route Change" indication from=20 > QNE3 could=20 > > > > further identify whether it is upstream route changed or=20 > > > > downstream route changed. It might help the QNE1 reach=20 > the conclusion faster. > > >=20 > > > JM: I believe this falls a bit down the path of security.=20 > What can a=20 > > > QNE trust? I would rather let the QNE1 figure by itself=20 > that the QNI=20 > > > has disappeared. The message sent is only a hint that=20 > tells QNE1 to=20 > > > verify if QNI is still there. It would only take a few seconds,=20 > > > basically once the retransmission procudure of either GIST or the=20 > > > NSLP fails, QNE1 can deduce that the QNI is gone. > > >=20 > > > >=20 > > > > > - The tearing RESERVE will eventually hit QNE3, which=20 > noticies that it has=20 > > > > > an existing, and newer state (higher RSN), and will=20 > drop the=20 > > > > > tear > > > > >=20 > > > > >=20 > > > > > "MN as QNR and data receiver": we could rely on=20 > routing changes=20 > > > > > to eventually lead to a refreshing RESERVE from QNE3 to hit=20 > > > > > QNE5, which will then send back a RESPONSE saying "full QSPEC=20 > > > > > required". A subsequent full RESERVE will then set up the=20 > > > > > reservation on the new path. Or, in order to make it=20 > faster, we could use the following: > > > > >=20 > > > > > - MN moves, gets a hint from GIST that routing has changed > > > > > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > > > > > - QNE4 will receive it, and forward it, same with QNE5 > > > >=20 > > > > This is assuming the QNE4 has already been discovered.=20 > When the MN=20 > > > > is QNR and data receiver, considering the discovery process,=20 > > > > wouldn't sending a trigger to QNI directly result in a=20 > faster process? > > >=20 > > > JM: Once GIST tells a routing change has happened, the=20 > NSLP will ask=20 > > > GIST to send the NOTIFY towards the QNI. For doing that,=20 > GIST must=20 > > > find the next peer QNE node, which is QNE4 in this case.=20 > Since the=20 > > > NSLP works hop-by-hop, you can't really send a message=20 > directly to=20 > > > the QNI, without going through all the intermediate nodes. > > >=20 > > > >=20 > > > > > - The NOTIFY will hit QNE3, which notes that the=20 > message for a known=20 > > > > > session comes from a new SII-Handle. > > > > > - QNE3 should then send a full RESERVE with a new RSN=20 > and an RII to=20 > > > > > QNE5 > > > > > - QNE4 will receive the RESERVE, make the=20 > reservation, and forward it to=20 > > > > > the MN > > > > > - The MN gets the RESERVE and replies with a RESPONSE > > > > >=20 > > > > > The tear down: > > > > > - QNE3 should also send a tearing RESERVE with the=20 > old RSN to QNE2, which=20 > > > > > again sends ti QNE1 > > > > >=20 > > > > >=20 > > > > > Jukka > > > > >=20 > > > > >=20 > > > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > > > > >=20 > > > > > > Hi Jukka, > > > > > > > > > > > > I would agree that the cross-over router should be left=20 > > > > > > capable of tearing down the unneeded reservations.=20 > Please see=20 > > > > > > some comments inline below: > > > > > > > > > > > > cheers > > > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > If you look at how the NSIS protocols work, there=20 > is no way=20 > > > > > > > a node can make sure a tear-down was intiated by=20 > the QNI. A=20 > > > > > > > QNE receives a teardown from its upstream peer,=20 > but it can't=20 > > > > > > > tell whether that peer initiated the tear down in=20 > the first place, or the QNI. > > > > > > > > > > > > > > If I would do a "mobility enhanced QoS NSLP", I=20 > would tear=20 > > > > > > > down at the cross-over router the unnecessary=20 > reservation.=20 > > > > > > > Of course the spec can say "don't do it", but a=20 > QNE can not=20 > > > > > > > really confirm it isn't being done. > > > > > > > And the > > > > > > > QNI or the QNR can't see that either. > > > > > > > > > > > > > > The QoS NSLP spec could say "only the QNI SHOULD=20 > (or MAY) be=20 > > > > > > > able to initiate a tear down", and thus leave the option=20 > > > > > > > open for a QNE to also do it. > > > > > > > =20 > > > > > > [Cheng] Agree. This should be left open. And I think the=20 > > > > > > quoted text in current QoS NSLP draft is reflecting=20 > this point. > > > > > > > > > > > > > Or we could make a new INFO_SPEC code for=20 > "reservation not=20 > > > > > > > need" which is a hint sent by the cross-over router to=20 > > > > > > > inform downstream QNEs on the old path that the=20 > MN has moved=20 > > > > > > > away. It is then up to each QNE to decide whether=20 > to remove=20 > > > > > > > the resources and state, or not. > > > > > > > > > > > > > > =20 > > > > > > [Cheng] This option might lead to some problem=20 > though, since=20 > > > > > > it could leave the QNEs on the path unsynchronized=20 > should they=20 > > > > > > decide to do different things in response to the INFO_SPEC. > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > > > > > > > > =20 > > > > > > > > Hi Jukka and all, > > > > > > > > > > > > > > > > I would like to clarify about tearing down operation. > > > > > > > > > > > > > > > > In section 3.2.11 (Rerouting), 5th paragraph,=20 > it is said, > > > > > > > > "After the reservation on the new path is=20 > set up, the branching > > > > > > > > node > > > > > > > > may want to tear down the reservation on the=20 > old path (sooner than > > > > > > > > would result from normal soft-state time-out)." > > > > > > > > > > > > > > > > This means that the CRN will initiate the TEAR=20 > on the old path. > > > > > > > > > > > > > > > > At Munich Interim, It was discussed that=20 > tearing down from > > > > > > > > intermediate > > > > > > > > node needs to be avoided because of session=20 > ownership issue. But I > > > > > > > > cannot find any conclusion of this discussion. > > > > > > > >=20 > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMi nutes.html > > > > > > > > > > > > > > > > Do we have any decision for "tearing down from=20 > intermediate node"? > > > > > > > > > > > > > > > > cheers, > > > > > > > > Takako > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > =20 > > > > > > > > > Dear all, > > > > > > > > > > > > > > > > > > I sent the following request for feedback two=20 > weeks ago. No > > > > > > > > > comments > > > > > > > > > have been raised. I will wait until this=20 > Friday, then submit the > > > > > > > > > draft. > > > > > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > =20 > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > I have done all the edits I had in my list=20 > to the QoS NSLP spec, > > > > > > > > > > the > > > > > > > > > > main points are in recent thread with=20 > Roland. From the url below > > > > > > > > > > you > > > > > > > > > > can find the current draft v. "13-pre1" and=20 > a diff to v. 12. > > > > > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > > > > > > > > > > > A direct link to the diff: > > > > > > > > > > > > > > > > > > > >=20 > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-q os-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would appreciate comments on the changes=20 > I did (what is wrong, > > > > > > > > > > what > > > > > > > > > > I missed, etc.). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I still have one problem with the spec,=20 > namely the way the NSLP > > > > > > > > > > suggests to handle mobility and path=20 > changes. I think we need to > > > > > > > > > > review that statement, because it seems=20 > like a "hack" (playing > > > > > > > > > > with > > > > > > > > > > the RSN value), and not really useful. And=20 > the interactions with > > > > > > > > > > GIST > > > > > > > > > > look partly wrong. The folks working on the=20 > mobility draft (me > > > > > > > > > > included) could comment. The section I'm=20 > talking about is 3.2.10, > > > > > > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > > > > > > > > > > > BR, > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > > > =20 > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > > -----=20 > > Takako SANDA > > Next-Generation Mobile Communications Development Center, > > Matsushita Electric Industrial Co., Ltd. (Panasonic) > > Phone: +81 46 840 5764 Fax: +81 46 840 5122 > >=20 > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 22 04:01:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8v37-0005SL-DG; Mon, 22 Jan 2007 04:01:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8v36-0005SD-72 for nsis@ietf.org; Mon, 22 Jan 2007 04:01:08 -0500 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8v32-00008v-5K for nsis@ietf.org; Mon, 22 Jan 2007 04:01:08 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id l0M90tPV029861; Mon, 22 Jan 2007 18:00:55 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id l0M90u801661; Mon, 22 Jan 2007 18:00:56 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id l0M90uN16637; Mon, 22 Jan 2007 18:00:56 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml23) id l0M90twI001658; Mon, 22 Jan 2007 18:00:55 +0900 (JST) Received: from [10.68.136.43] by soml23.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id l0M90ntj001394; Mon, 22 Jan 2007 18:00:50 +0900 (JST) Date: Mon, 22 Jan 2007 18:04:54 +0900 From: Takako Sanda To: Jukka MJ Manner Subject: Re: [NSIS] Re: Clarification: tearing down from intermediate node In-Reply-To: References: <20070112201001.1124.SANDA.TAKAKO@jp.panasonic.com> Message-Id: <20070122174137.99F1.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: Hong Cheng , 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, > if the IP addresses change, then we have to make a full end-to-end refresh > with a new MRI. Forcing an e2e refresh can be done by adding an RII into > the refresh. Furthermore, if a refresh arriving at a QNE is a so-called > full refresh, and the MRI is different, this is an indication to the QNE > that the whole reservation must be refreshed end-to-end. Does this mean, - MRI in GIST is also updated for overlapping section? - or a new independent end-to-end GIST routing state and MA are established with a new MRI/SID/NSLPID tuples? In former case, I wonder if GIST allows to change MRI. cheers, Takako On Wed, 17 Jan 2007 18:11:01 +0200 (EET) Jukka MJ Manner wrote: > > Hi, > > if the IP addresses change, then we have to make a full end-to-end refresh > with a new MRI. Forcing an e2e refresh can be done by adding an RII into > the refresh. Furthermore, if a refresh arriving at a QNE is a so-called > full refresh, and the MRI is different, this is an indication to the QNE > that the whole reservation must be refreshed end-to-end. > > When sending the NOTIFY, it will include a new MRI. This can be used as an > indication that the NOTIFY should be forwarded up to the QNI, which will > then send back a full new refresh with a new MRI. > > Jukka > > > On Fri, 12 Jan 2007, Takako Sanda wrote: > > > Hi Jukka, > > > > I have another concern about the operation for overlapping section, (i.e. > > [QNE3] --- [QNE6] --- [QNE7] --- ). > > > > If MN's CoA is changed after it's movement, MRI and packet classifier is > > also changed. Therefore reservation for the overlapping section also > > must be new. > > > > > > In the "MN as QNI and data sender" scenario below, old reservation in the > > overlapping section is not removed because QNE3 drops tearing RESERVE. > > Therfore, some mechanisms may be necessary:- > > - QNE3 perform both RESERVE for new state and tear RESERVE for old > > state when it receives RESERVE from QNE5. > > Or, > > - QNE3 forwards tear RESERVE to QNE6 when it receives tear RESERVE from > > QNE2. (Although it remains so called "double resource reservation issue"...) > > > > > > In the "MN as QNR and data receiver" scenario below, new reservation for > > overlapping is not performed. > > Therfore, operation may need to be changed, such as:- > > - NOTIFY form MN goes to QNI (i.e. QNE3 does not stop it), and QNI > > sends both RESERVE and tear RESERVE to MN and QNE1, respectively. > > Or, > > - QNE3 performs localized RESERVE and tear RESERVE as shown below, but > > NOTFY also goes to NI, and NI performs "scoping" RESERVE and tear > > RESERVE. > > > > > > cheers, > > Takako > > > > > > On Wed, 10 Jan 2007 11:36:57 +0200 (EET) > > Jukka MJ Manner wrote: > > > > > > > > Hi Cheng, > > > > > > After re-reading the QoS NSLP spec, I think the spec is quite accurate in > > > how the NSLP supports mobility, and it seems to work properly. Tearing > > > down the reservation on the old path from the cross-over QNE would be good > > > to do, but not necessarily critical for the proper operation of the NSLP. > > > Yet, the current QoS NSLP spec mentions the tear-down at the cross-over > > > router. > > > > > > Consider the following scenario: > > > > > > > > > > > > [MN] [QNE1] --- [QNE2] ---\ > > > | \ > > > | [QNE3] --- [QNE6] --- [QNE7] --- > > > | / > > > V / > > > [MN] [QNE4] --- [QNE5]---/ > > > > > > > > > The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR > > > and receiver" > > > > > > "MN as QNI and data sender": we could rely on just the soft-state to > > > expire on the old path, and a new RESERVE on the new path, or use the > > > following, based on the NSLP draft text. > > > > > > - MN moves from peer QNE1 to QNE4 > > > - GIST gets a hint that routing has changed, triggers the NSLP > > > - The NSLP then sends a new full RESERVE with a new RSN > > > - The RESERVE hits QNE4, which makes reservation > > > - Then the RESERVE is forwarded to QNE5, which also makes the reservation > > > - Finally, the RESERVE hits QNE3, which makes a reservation and forwards > > > the RESERVE to QNE6, and so on > > > > > > The tear-down part: > > > - QNE3 also noticies that the SII-Handle has changed, and could basically > > > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > > > Change" 0x02 > > > - QNE2 will forward it to QNE1 > > > - QNE1 would then at some point figure out QNI has disappeared, and will > > > start removing the reservation using a tearing RESERVE > > > - The tearing RESERVE will eventually hit QNE3, which noticies that it has > > > an existing, and newer state (higher RSN), and will drop the tear > > > > > > > > > "MN as QNR and data receiver": we could rely on routing changes to > > > eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will > > > then send back a RESPONSE saying "full QSPEC required". A subsequent > > > full RESERVE will then set up the reservation on the new path. Or, in > > > order to make it faster, we could use the following: > > > > > > - MN moves, gets a hint from GIST that routing has changed > > > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > > > - QNE4 will receive it, and forward it, same with QNE5 > > > - The NOTIFY will hit QNE3, which notes that the message for a known > > > session comes from a new SII-Handle. > > > - QNE3 should then send a full RESERVE with a new RSN and an RII to > > > QNE5 > > > - QNE4 will receive the RESERVE, make the reservation, and forward it to > > > the MN > > > - The MN gets the RESERVE and replies with a RESPONSE > > > > > > The tear down: > > > - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which > > > again sends ti QNE1 > > > > > > > > > Jukka > > > > > > > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > > > > > > > Hi Jukka, > > > > > > > > I would agree that the cross-over router should be left capable of tearing > > > > down the unneeded reservations. Please see some comments inline below: > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > Hi all, > > > > > > > > > > If you look at how the NSIS protocols work, there is no way a node can > > > > > make sure a tear-down was intiated by the QNI. A QNE receives a > > > > > teardown from its upstream peer, but it can't tell whether that peer > > > > > initiated the tear down in the first place, or the QNI. > > > > > > > > > > If I would do a "mobility enhanced QoS NSLP", I would tear down at the > > > > > cross-over router the unnecessary reservation. Of course the spec can say > > > > > "don't do it", but a QNE can not really confirm it isn't being done. And the > > > > > QNI or the QNR can't see that either. > > > > > > > > > > The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to > > > > > initiate a tear down", and thus leave the option open for a QNE to also do > > > > > it. > > > > > > > > > > > > > [Cheng] Agree. This should be left open. And I think the quoted text in > > > > current QoS NSLP draft is reflecting this point. > > > > > > > > > Or we could make a new INFO_SPEC code for "reservation not need" which is a > > > > > hint sent by the cross-over router to inform downstream QNEs on the old path > > > > > that the MN has moved away. It is then up to each QNE to decide whether to > > > > > remove the resources and state, or not. > > > > > > > > > > > > > > > > > > [Cheng] This option might lead to some problem though, since it could leave > > > > the QNEs on the path unsynchronized should they decide to do different things > > > > in response to the INFO_SPEC. > > > > > > > > > Jukka > > > > > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > > > > > > > > > > Hi Jukka and all, > > > > > > > > > > > > I would like to clarify about tearing down operation. > > > > > > > > > > > > In section 3.2.11 (Rerouting), 5th paragraph, it is said, > > > > > > "After the reservation on the new path is set up, the branching node > > > > > > may want to tear down the reservation on the old path (sooner than > > > > > > would result from normal soft-state time-out)." > > > > > > > > > > > > This means that the CRN will initiate the TEAR on the old path. > > > > > > > > > > > > At Munich Interim, It was discussed that tearing down from intermediate > > > > > > node needs to be avoided because of session ownership issue. But I > > > > > > cannot find any conclusion of this discussion. > > > > > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > > > > > > > > > > > > Do we have any decision for "tearing down from intermediate node"? > > > > > > > > > > > > cheers, > > > > > > Takako > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > I sent the following request for feedback two weeks ago. No comments > > > > > > > have been raised. I will wait until this Friday, then submit the draft. > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I have done all the edits I had in my list to the QoS NSLP spec, the > > > > > > > > main points are in recent thread with Roland. From the url below you > > > > > > > > can find the current draft v. "13-pre1" and a diff to v. 12. > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > > > > > > > A direct link to the diff: > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > > > > > > > > > > I would appreciate comments on the changes I did (what is wrong, what > > > > > > > > I missed, etc.). > > > > > > > > > > > > > > > > > > > > > > > > I still have one problem with the spec, namely the way the NSLP > > > > > > > > suggests to handle mobility and path changes. I think we need to > > > > > > > > review that statement, because it seems like a "hack" (playing with > > > > > > > > the RSN value), and not really useful. And the interactions with GIST > > > > > > > > look partly wrong. The folks working on the mobility draft (me > > > > > > > > included) could comment. The section I'm talking about is 3.2.10, > > > > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > > > > > > > BR, > > > > > > > > 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 Jan 22 04:09:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vAc-0008BS-42; Mon, 22 Jan 2007 04:08:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vAa-0008BN-UP for nsis@ietf.org; Mon, 22 Jan 2007 04:08:52 -0500 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 1H8vAX-0002PP-Vq for nsis@ietf.org; Mon, 22 Jan 2007 04:08:52 -0500 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, 22 Jan 2007 11:08:47 +0200 id 0008096E.45B47F1F.0000465F Date: Mon, 22 Jan 2007 11:08:46 +0200 (EET) From: Jukka MJ Manner To: Takako Sanda Subject: Re: [NSIS] Re: Clarification: tearing down from intermediate node In-Reply-To: <20070122174137.99F1.SANDA.TAKAKO@jp.panasonic.com> Message-ID: References: <20070112201001.1124.SANDA.TAKAKO@jp.panasonic.com> <20070122174137.99F1.SANDA.TAKAKO@jp.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: Hong Cheng , 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 MRI in GIST must be updated, of course. This is fine, as long as the SID remains. The state associated with the session is just updated. Jukka On Mon, 22 Jan 2007, Takako Sanda wrote: > Hi Jukka, > > > > if the IP addresses change, then we have to make a full end-to-end refresh > > with a new MRI. Forcing an e2e refresh can be done by adding an RII into > > the refresh. Furthermore, if a refresh arriving at a QNE is a so-called > > full refresh, and the MRI is different, this is an indication to the QNE > > that the whole reservation must be refreshed end-to-end. > > Does this mean, > - MRI in GIST is also updated for overlapping section? > - or a new independent end-to-end GIST routing state and MA are > established with a new MRI/SID/NSLPID tuples? > > In former case, I wonder if GIST allows to change MRI. > > cheers, > Takako > > > On Wed, 17 Jan 2007 18:11:01 +0200 (EET) > Jukka MJ Manner wrote: > > > > > Hi, > > > > if the IP addresses change, then we have to make a full end-to-end refresh > > with a new MRI. Forcing an e2e refresh can be done by adding an RII into > > the refresh. Furthermore, if a refresh arriving at a QNE is a so-called > > full refresh, and the MRI is different, this is an indication to the QNE > > that the whole reservation must be refreshed end-to-end. > > > > When sending the NOTIFY, it will include a new MRI. This can be used as an > > indication that the NOTIFY should be forwarded up to the QNI, which will > > then send back a full new refresh with a new MRI. > > > > Jukka > > > > > > On Fri, 12 Jan 2007, Takako Sanda wrote: > > > > > Hi Jukka, > > > > > > I have another concern about the operation for overlapping section, (i.e. > > > [QNE3] --- [QNE6] --- [QNE7] --- ). > > > > > > If MN's CoA is changed after it's movement, MRI and packet classifier is > > > also changed. Therefore reservation for the overlapping section also > > > must be new. > > > > > > > > > In the "MN as QNI and data sender" scenario below, old reservation in the > > > overlapping section is not removed because QNE3 drops tearing RESERVE. > > > Therfore, some mechanisms may be necessary:- > > > - QNE3 perform both RESERVE for new state and tear RESERVE for old > > > state when it receives RESERVE from QNE5. > > > Or, > > > - QNE3 forwards tear RESERVE to QNE6 when it receives tear RESERVE from > > > QNE2. (Although it remains so called "double resource reservation issue"...) > > > > > > > > > In the "MN as QNR and data receiver" scenario below, new reservation for > > > overlapping is not performed. > > > Therfore, operation may need to be changed, such as:- > > > - NOTIFY form MN goes to QNI (i.e. QNE3 does not stop it), and QNI > > > sends both RESERVE and tear RESERVE to MN and QNE1, respectively. > > > Or, > > > - QNE3 performs localized RESERVE and tear RESERVE as shown below, but > > > NOTFY also goes to NI, and NI performs "scoping" RESERVE and tear > > > RESERVE. > > > > > > > > > cheers, > > > Takako > > > > > > > > > On Wed, 10 Jan 2007 11:36:57 +0200 (EET) > > > Jukka MJ Manner wrote: > > > > > > > > > > > Hi Cheng, > > > > > > > > After re-reading the QoS NSLP spec, I think the spec is quite accurate in > > > > how the NSLP supports mobility, and it seems to work properly. Tearing > > > > down the reservation on the old path from the cross-over QNE would be good > > > > to do, but not necessarily critical for the proper operation of the NSLP. > > > > Yet, the current QoS NSLP spec mentions the tear-down at the cross-over > > > > router. > > > > > > > > Consider the following scenario: > > > > > > > > > > > > > > > > [MN] [QNE1] --- [QNE2] ---\ > > > > | \ > > > > | [QNE3] --- [QNE6] --- [QNE7] --- > > > > | / > > > > V / > > > > [MN] [QNE4] --- [QNE5]---/ > > > > > > > > > > > > The two main (simple) cases are "MN as QNI and data sender" and "MN as QNR > > > > and receiver" > > > > > > > > "MN as QNI and data sender": we could rely on just the soft-state to > > > > expire on the old path, and a new RESERVE on the new path, or use the > > > > following, based on the NSLP draft text. > > > > > > > > - MN moves from peer QNE1 to QNE4 > > > > - GIST gets a hint that routing has changed, triggers the NSLP > > > > - The NSLP then sends a new full RESERVE with a new RSN > > > > - The RESERVE hits QNE4, which makes reservation > > > > - Then the RESERVE is forwarded to QNE5, which also makes the reservation > > > > - Finally, the RESERVE hits QNE3, which makes a reservation and forwards > > > > the RESERVE to QNE6, and so on > > > > > > > > The tear-down part: > > > > - QNE3 also noticies that the SII-Handle has changed, and could basically > > > > send a NOTIFY to QNE2 and through the QNI's old path saying "Route > > > > Change" 0x02 > > > > - QNE2 will forward it to QNE1 > > > > - QNE1 would then at some point figure out QNI has disappeared, and will > > > > start removing the reservation using a tearing RESERVE > > > > - The tearing RESERVE will eventually hit QNE3, which noticies that it has > > > > an existing, and newer state (higher RSN), and will drop the tear > > > > > > > > > > > > "MN as QNR and data receiver": we could rely on routing changes to > > > > eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, which will > > > > then send back a RESPONSE saying "full QSPEC required". A subsequent > > > > full RESERVE will then set up the reservation on the new path. Or, in > > > > order to make it faster, we could use the following: > > > > > > > > - MN moves, gets a hint from GIST that routing has changed > > > > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > > > > - QNE4 will receive it, and forward it, same with QNE5 > > > > - The NOTIFY will hit QNE3, which notes that the message for a known > > > > session comes from a new SII-Handle. > > > > - QNE3 should then send a full RESERVE with a new RSN and an RII to > > > > QNE5 > > > > - QNE4 will receive the RESERVE, make the reservation, and forward it to > > > > the MN > > > > - The MN gets the RESERVE and replies with a RESPONSE > > > > > > > > The tear down: > > > > - QNE3 should also send a tearing RESERVE with the old RSN to QNE2, which > > > > again sends ti QNE1 > > > > > > > > > > > > Jukka > > > > > > > > > > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > > > > > > > > > Hi Jukka, > > > > > > > > > > I would agree that the cross-over router should be left capable of tearing > > > > > down the unneeded reservations. Please see some comments inline below: > > > > > > > > > > cheers > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > > Hi all, > > > > > > > > > > > > If you look at how the NSIS protocols work, there is no way a node can > > > > > > make sure a tear-down was intiated by the QNI. A QNE receives a > > > > > > teardown from its upstream peer, but it can't tell whether that peer > > > > > > initiated the tear down in the first place, or the QNI. > > > > > > > > > > > > If I would do a "mobility enhanced QoS NSLP", I would tear down at the > > > > > > cross-over router the unnecessary reservation. Of course the spec can say > > > > > > "don't do it", but a QNE can not really confirm it isn't being done. And the > > > > > > QNI or the QNR can't see that either. > > > > > > > > > > > > The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to > > > > > > initiate a tear down", and thus leave the option open for a QNE to also do > > > > > > it. > > > > > > > > > > > > > > > > [Cheng] Agree. This should be left open. And I think the quoted text in > > > > > current QoS NSLP draft is reflecting this point. > > > > > > > > > > > Or we could make a new INFO_SPEC code for "reservation not need" which is a > > > > > > hint sent by the cross-over router to inform downstream QNEs on the old path > > > > > > that the MN has moved away. It is then up to each QNE to decide whether to > > > > > > remove the resources and state, or not. > > > > > > > > > > > > > > > > > > > > > > [Cheng] This option might lead to some problem though, since it could leave > > > > > the QNEs on the path unsynchronized should they decide to do different things > > > > > in response to the INFO_SPEC. > > > > > > > > > > > Jukka > > > > > > > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > > > > > > > > > > > > > Hi Jukka and all, > > > > > > > > > > > > > > I would like to clarify about tearing down operation. > > > > > > > > > > > > > > In section 3.2.11 (Rerouting), 5th paragraph, it is said, > > > > > > > "After the reservation on the new path is set up, the branching node > > > > > > > may want to tear down the reservation on the old path (sooner than > > > > > > > would result from normal soft-state time-out)." > > > > > > > > > > > > > > This means that the CRN will initiate the TEAR on the old path. > > > > > > > > > > > > > > At Munich Interim, It was discussed that tearing down from intermediate > > > > > > > node needs to be avoided because of session ownership issue. But I > > > > > > > cannot find any conclusion of this discussion. > > > > > > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > > > > > > > > > > > > > > Do we have any decision for "tearing down from intermediate node"? > > > > > > > > > > > > > > cheers, > > > > > > > Takako > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > > > I sent the following request for feedback two weeks ago. No comments > > > > > > > > have been raised. I will wait until this Friday, then submit the draft. > > > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > I have done all the edits I had in my list to the QoS NSLP spec, the > > > > > > > > > main points are in recent thread with Roland. From the url below you > > > > > > > > > can find the current draft v. "13-pre1" and a diff to v. 12. > > > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > > > > > > > > > A direct link to the diff: > > > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > > > > > > > > > > > > > I would appreciate comments on the changes I did (what is wrong, what > > > > > > > > > I missed, etc.). > > > > > > > > > > > > > > > > > > > > > > > > > > > I still have one problem with the spec, namely the way the NSLP > > > > > > > > > suggests to handle mobility and path changes. I think we need to > > > > > > > > > review that statement, because it seems like a "hack" (playing with > > > > > > > > > the RSN value), and not really useful. And the interactions with GIST > > > > > > > > > look partly wrong. The folks working on the mobility draft (me > > > > > > > > > included) could comment. The section I'm talking about is 3.2.10, > > > > > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > > > > > > > > > BR, > > > > > > > > > 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 Jan 22 04:36:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vaZ-0001de-Uy; Mon, 22 Jan 2007 04:35:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vaY-0001dZ-Os for nsis@ietf.org; Mon, 22 Jan 2007 04:35:42 -0500 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 1H8vaV-0000nc-LI for nsis@ietf.org; Mon, 22 Jan 2007 04:35:42 -0500 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, 22 Jan 2007 11:35:38 +0200 id 00080940.45B4856A.00003AFB Date: Mon, 22 Jan 2007 11:35:35 +0200 (EET) From: Jukka MJ Manner To: Hong Cheng Subject: Re: [NSIS] Re: Clarification: tearing down from intermediate node In-Reply-To: <45B45B11.4030805@sg.panasonic.com> Message-ID: References: <45A4BEF2.5020109@sg.panasonic.com> <20070112195212.1121.SANDA.TAKAKO@jp.panasonic.com> <45B0D293.1030409@tm.uka.de> <45B45B11.4030805@sg.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7cb76adb986247703cbb5582da68b5fc Cc: Roland Bless , Takako Sanda , 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, AFAICT, QNE3 uses the same RSN for the next peer towards the MN, regardless of the actual next peer. If the peer changes, the RSN doesn't matter. Now, 1. if MN is QNI, then after handover, the GIST SII-Handle will change, which is an indication that the state has changed, and thus the RSN is in a way re-set. The RSN is not meaningfull here. 2. If MN is QNR, after handover, the next peer changes, and QNE3 is in charge of using the right RSN. I don't see any problems here. However... we may have potential problem in a certain case. Say, MN is QNI, and sends a full RESERVE, which arrives eventually at QNE3, the SII-Handle changes. QNE3 prepares to change the session state and send a tear down to the old SII-Handle. Now, at the same time, a refreshing (either partial or full) RESERVE comes from the old SII-Handle. What should QNE3 do now? It has received two RESERVEs from two different SII-Handles, which is the right one? Which should be torn down? (This is even more problematic, if the IP address of the MN changed, so we two different MRIs) Do we need some clear indication of what is a refreshing RESERVE, and what is an full RESERVE sent in the initial phase, and after a routing change? Jukka On Mon, 22 Jan 2007, Hong Cheng wrote: > Hi Jukka, > > The RSN is meant for adjacent QNEs only. It cannot be used for message/state > management if the peer(/SII) is different. However, in mobility event > handling, sometimes an e2e type of sequence number comes in handy, e.g. to > detect the latest mobility event (as discussed in Mobility Applicability > draft). > > I guess some of the confusion came from the tricks introduced in QoS NSLP > draft section 3.2.10.2. It works fine with that particular scenario, but does > not solve general problems (of identifying message sequences from different > peers). > > Considering the scenario in your earlier mail (MN is sending and QNI case), > the QNE3 has no way to tell if the message from QNE2 or QNE5 is newer, since > the RSN doesn't apply here. > > cheers > > Cheng Hong > > > > > > > > Jukka MJ Manner wrote: > > Right... True. Even though the RSN changes on some hops of the e2e path, > > this doesn't really need to be propagated anywhere. > > > > The only case where we need to do e2e signaling is when the MRI changes, > > e.g., the CoA of the MN. > > > > Jukka > > > > On Fri, 19 Jan 2007, Roland Bless wrote: > > > > > Hi Jukka, > > > > > > Jukka MJ Manner wrote: > > > > There is actually another problem with the RSN. > > > > > > > > Consider the case "MN as QNR and data receiver" > > > > > > > > When QNE3 gets the notify, it replies back with a RESERVE towards QNR > > > > which has "RSN=old-RSN +1". But all nodes from QNI up to QNE3 will still > > > > be sending refresh messages using the old RSN. > > > > > > > > Thus, we need some further mechanism to inform the QNI that it should > > > > use a new RSN value in further refreshes, right? E.g. a NOTIFY towards > > > > the QNI > > > No, not really. Maybe I'm completely off-track, but IIRC RSNs have only > > > local significance between directly adjacent QNEs. Thus there is simply > > > no need to notify other nodes upstream of a new RSN value. > > > > > > > that says "Path changed, new RSN" and include the new RSN? Sounds like a > > > > hack, any suggestions? > > > Maybe I need to dig into a scenario down below before I understand > > > the problem, but the above suggestion doesn't make sense to me. > > > > > > Roland > > > > > > > Jukka > > > > > > > > On Fri, 12 Jan 2007, Takako Sanda wrote: > > > > > > > > > Hi Jukka, > > > > > > > > > > I still have a question for the operation below. > > > > > > > > > > > > > > > > > > The tear-down part: > > > > > > > > - QNE3 also noticies that the SII-Handle has changed, and could > > > > > > > > basically > > > > > > > > send a NOTIFY to QNE2 and through the QNI's old path saying > > > > > > > > "Route > > > > > > > > Change" 0x02 > > > > > > > > - QNE2 will forward it to QNE1 > > > > > > > > - QNE1 would then at some point figure out QNI has disappeared, > > > > > > > > and will > > > > > > > > start removing the reservation using a tearing RESERVE > > > > > > > How the QNE1 figure out the QNI has disappeared might require some > > > > > > > enhancement. Maybe the "Route Change" indication from QNE3 could > > > > > > > further > > > > > > > identify whether it is upstream route changed or downstream route > > > > > > > changed. It > > > > > > > might help the QNE1 reach the conclusion faster. > > > > > > JM: I believe this falls a bit down the path of security. What can a > > > > > > QNE trust? I would rather let the QNE1 figure by itself that the QNI > > > > > > has disappeared. The message sent is only a hint that tells QNE1 to > > > > > > verify if QNI is still there. It would only take a few seconds, > > > > > > basically once the retransmission procudure of either GIST or the > > > > > > NSLP fails, QNE1 can deduce that the QNI is gone. > > > > > How does QNE1 know the next peer was NI? > > > > > In order to know this, I guess, QNE1 needs to have received an > > > > > explicit > > > > > notification from NI in advance. > > > > > > > > > > cheers, > > > > > Takako > > > > > > > > > > On Wed, 10 Jan 2007 12:35:00 +0200 (EET) > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > some answers below. > > > > > > > > > > > > Jukka > > > > > > > > > > > > On Wed, 10 Jan 2007, Hong Cheng wrote: > > > > > > > > > > > > > Hi Jukka, > > > > > > > > > > > > > > The operation is well analyzed. The text should be incorporated > > > > > > > into the > > > > > > > Mobility Applicability draft. I think generally a tear-down could > > > > > > > be > > > > > > > initiated by any QNE (e.g. the CRN), as long as it is along the > > > > > > > direction > > > > > > > from QNI to QNR. > > > > > > > > > > > > > > Please find a few more comments inline. > > > > > > > > > > > > > > cheers > > > > > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > > > > Hi Cheng, > > > > > > > > > > > > > > > > After re-reading the QoS NSLP spec, I think the spec is quite > > > > > > > > accurate in > > > > > > > > how the NSLP supports mobility, and it seems to work properly. > > > > > > > > Tearing down > > > > > > > > the reservation on the old path from the cross-over QNE would be > > > > > > > > good to > > > > > > > > do, but not necessarily critical for the proper operation of the > > > > > > > > NSLP. Yet, > > > > > > > > the current QoS NSLP spec mentions the tear-down at the > > > > > > > > cross-over router. > > > > > > > > > > > > > > > > Consider the following scenario: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [MN] [QNE1] --- [QNE2] ---\ > > > > > > > > | \ > > > > > > > > | [QNE3] --- [QNE6] --- [QNE7] --- > > > > > > > > | / > > > > > > > > V / > > > > > > > > [MN] [QNE4] --- [QNE5]---/ > > > > > > > > > > > > > > > > > > > > > > > > The two main (simple) cases are "MN as QNI and data sender" and > > > > > > > > "MN as QNR > > > > > > > > and receiver" > > > > > > > > > > > > > > > > "MN as QNI and data sender": we could rely on just the > > > > > > > > soft-state to expire > > > > > > > > on the old path, and a new RESERVE on the new path, or use the > > > > > > > > following, > > > > > > > > based on the NSLP draft text. > > > > > > > > > > > > > > > > - MN moves from peer QNE1 to QNE4 > > > > > > > > - GIST gets a hint that routing has changed, triggers the NSLP > > > > > > > > - The NSLP then sends a new full RESERVE with a new RSN > > > > > > > > - The RESERVE hits QNE4, which makes reservation > > > > > > > > - Then the RESERVE is forwarded to QNE5, which also makes the > > > > > > > > reservation > > > > > > > > - Finally, the RESERVE hits QNE3, which makes a reservation and > > > > > > > > forwards > > > > > > > > the RESERVE to QNE6, and so on > > > > > > > > > > > > > > > > The tear-down part: > > > > > > > > - QNE3 also noticies that the SII-Handle has changed, and could > > > > > > > > basically > > > > > > > > send a NOTIFY to QNE2 and through the QNI's old path saying > > > > > > > > "Route > > > > > > > > Change" 0x02 > > > > > > > > - QNE2 will forward it to QNE1 > > > > > > > > - QNE1 would then at some point figure out QNI has disappeared, > > > > > > > > and will > > > > > > > > start removing the reservation using a tearing RESERVE > > > > > > > How the QNE1 figure out the QNI has disappeared might require some > > > > > > > enhancement. Maybe the "Route Change" indication from QNE3 could > > > > > > > further > > > > > > > identify whether it is upstream route changed or downstream route > > > > > > > changed. It > > > > > > > might help the QNE1 reach the conclusion faster. > > > > > > JM: I believe this falls a bit down the path of security. What can a > > > > > > QNE trust? I would rather let the QNE1 figure by itself that the QNI > > > > > > has disappeared. The message sent is only a hint that tells QNE1 to > > > > > > verify if QNI is still there. It would only take a few seconds, > > > > > > basically once the retransmission procudure of either GIST or the > > > > > > NSLP fails, QNE1 can deduce that the QNI is gone. > > > > > > > > > > > > > > - The tearing RESERVE will eventually hit QNE3, which noticies > > > > > > > > that it has > > > > > > > > an existing, and newer state (higher RSN), and will drop the > > > > > > > > tear > > > > > > > > > > > > > > > > > > > > > > > > "MN as QNR and data receiver": we could rely on routing changes > > > > > > > > to > > > > > > > > eventually lead to a refreshing RESERVE from QNE3 to hit QNE5, > > > > > > > > which will > > > > > > > > then send back a RESPONSE saying "full QSPEC required". A > > > > > > > > subsequent full > > > > > > > > RESERVE will then set up the reservation on the new path. Or, in > > > > > > > > order to > > > > > > > > make it faster, we could use the following: > > > > > > > > > > > > > > > > - MN moves, gets a hint from GIST that routing has changed > > > > > > > > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > > > > > > > > - QNE4 will receive it, and forward it, same with QNE5 > > > > > > > This is assuming the QNE4 has already been discovered. When the MN > > > > > > > is QNR and > > > > > > > data receiver, considering the discovery process, wouldn't sending > > > > > > > a trigger > > > > > > > to QNI directly result in a faster process? > > > > > > JM: Once GIST tells a routing change has happened, the NSLP will ask > > > > > > GIST to send the NOTIFY towards the QNI. For doing that, GIST must > > > > > > find the next peer QNE node, which is QNE4 in this case. Since the > > > > > > NSLP works hop-by-hop, you can't really send a message directly to > > > > > > the QNI, without going through all the intermediate nodes. > > > > > > > > > > > > > > - The NOTIFY will hit QNE3, which notes that the message for a > > > > > > > > known > > > > > > > > session comes from a new SII-Handle. > > > > > > > > - QNE3 should then send a full RESERVE with a new RSN and an RII > > > > > > > > to > > > > > > > > QNE5 > > > > > > > > - QNE4 will receive the RESERVE, make the reservation, and > > > > > > > > forward it to > > > > > > > > the MN > > > > > > > > - The MN gets the RESERVE and replies with a RESPONSE > > > > > > > > > > > > > > > > The tear down: > > > > > > > > - QNE3 should also send a tearing RESERVE with the old RSN to > > > > > > > > QNE2, which > > > > > > > > again sends ti QNE1 > > > > > > > > > > > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > > > > > > > > > > > > > > > > > Hi Jukka, > > > > > > > > > > > > > > > > > > I would agree that the cross-over router should be left > > > > > > > > > capable of > > > > > > > > > tearing > > > > > > > > > down the unneeded reservations. Please see some comments > > > > > > > > > inline below: > > > > > > > > > > > > > > > > > > cheers > > > > > > > > > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > If you look at how the NSIS protocols work, there is no way > > > > > > > > > > a node can > > > > > > > > > > make sure a tear-down was intiated by the QNI. A QNE > > > > > > > > > > receives a > > > > > > > > > > teardown from its upstream peer, but it can't tell whether > > > > > > > > > > that peer > > > > > > > > > > initiated the tear down in the first place, or the QNI. > > > > > > > > > > > > > > > > > > > > If I would do a "mobility enhanced QoS NSLP", I would tear > > > > > > > > > > down at the > > > > > > > > > > cross-over router the unnecessary reservation. Of course the > > > > > > > > > > spec can > > > > > > > > > > say > > > > > > > > > > "don't do it", but a QNE can not really confirm it isn't > > > > > > > > > > being done. > > > > > > > > > > And the > > > > > > > > > > QNI or the QNR can't see that either. > > > > > > > > > > > > > > > > > > > > The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be > > > > > > > > > > able to > > > > > > > > > > initiate a tear down", and thus leave the option open for a > > > > > > > > > > QNE to also > > > > > > > > > > do > > > > > > > > > > it. > > > > > > > > > > > > > > > > > > > [Cheng] Agree. This should be left open. And I think the > > > > > > > > > quoted text in > > > > > > > > > current QoS NSLP draft is reflecting this point. > > > > > > > > > > > > > > > > > > > Or we could make a new INFO_SPEC code for "reservation not > > > > > > > > > > need" which > > > > > > > > > > is a > > > > > > > > > > hint sent by the cross-over router to inform downstream QNEs > > > > > > > > > > on the old > > > > > > > > > > path > > > > > > > > > > that the MN has moved away. It is then up to each QNE to > > > > > > > > > > decide whether > > > > > > > > > > to > > > > > > > > > > remove the resources and state, or not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Cheng] This option might lead to some problem though, since > > > > > > > > > it could > > > > > > > > > leave > > > > > > > > > the QNEs on the path unsynchronized should they decide to do > > > > > > > > > different > > > > > > > > > things > > > > > > > > > in response to the INFO_SPEC. > > > > > > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Jukka and all, > > > > > > > > > > > > > > > > > > > > > > I would like to clarify about tearing down operation. > > > > > > > > > > > > > > > > > > > > > > In section 3.2.11 (Rerouting), 5th paragraph, it is said, > > > > > > > > > > > "After the reservation on the new path is set up, the > > > > > > > > > > > branching > > > > > > > > > > > node > > > > > > > > > > > may want to tear down the reservation on the old path > > > > > > > > > > > (sooner than > > > > > > > > > > > would result from normal soft-state time-out)." > > > > > > > > > > > > > > > > > > > > > > This means that the CRN will initiate the TEAR on the old > > > > > > > > > > > path. > > > > > > > > > > > > > > > > > > > > > > At Munich Interim, It was discussed that tearing down from > > > > > > > > > > > intermediate > > > > > > > > > > > node needs to be avoided because of session ownership > > > > > > > > > > > issue. But I > > > > > > > > > > > cannot find any conclusion of this discussion. > > > > > > > > > > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > > > > > > > > > > > > > > > > > > > > > > Do we have any decision for "tearing down from > > > > > > > > > > > intermediate node"? > > > > > > > > > > > > > > > > > > > > > > cheers, > > > > > > > > > > > Takako > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > > > > > > > > > > > I sent the following request for feedback two weeks ago. > > > > > > > > > > > > No > > > > > > > > > > > > comments > > > > > > > > > > > > have been raised. I will wait until this Friday, then > > > > > > > > > > > > submit the > > > > > > > > > > > > draft. > > > > > > > > > > > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > I have done all the edits I had in my list to the QoS > > > > > > > > > > > > > NSLP spec, > > > > > > > > > > > > > the > > > > > > > > > > > > > main points are in recent thread with Roland. From the > > > > > > > > > > > > > url below > > > > > > > > > > > > > you > > > > > > > > > > > > > can find the current draft v. "13-pre1" and a diff to > > > > > > > > > > > > > v. 12. > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > > > > > > > > > > > > > > > > > A direct link to the diff: > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would appreciate comments on the changes I did (what > > > > > > > > > > > > > is wrong, > > > > > > > > > > > > > what > > > > > > > > > > > > > I missed, etc.). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I still have one problem with the spec, namely the way > > > > > > > > > > > > > the NSLP > > > > > > > > > > > > > suggests to handle mobility and path changes. I think > > > > > > > > > > > > > we need to > > > > > > > > > > > > > review that statement, because it seems like a "hack" > > > > > > > > > > > > > (playing > > > > > > > > > > > > > with > > > > > > > > > > > > > the RSN value), and not really useful. And the > > > > > > > > > > > > > interactions with > > > > > > > > > > > > > GIST > > > > > > > > > > > > > look partly wrong. The folks working on the mobility > > > > > > > > > > > > > draft (me > > > > > > > > > > > > > included) could comment. The section I'm talking about > > > > > > > > > > > > > is 3.2.10, > > > > > > > > > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > > > > > > > > > > > > > > > > > BR, > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > ----- Takako SANDA > > > > > Next-Generation Mobile Communications Development Center, > > > > > Matsushita Electric Industrial Co., Ltd. (Panasonic) > > > > > Phone: +81 46 840 5764 Fax: +81 46 840 5122 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 22 04:37:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vbh-0002do-RN; Mon, 22 Jan 2007 04:36:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vbf-0002dA-QL for nsis@ietf.org; Mon, 22 Jan 2007 04:36:51 -0500 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 1H8vbd-0000yj-TE for nsis@ietf.org; Mon, 22 Jan 2007 04:36:51 -0500 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, 22 Jan 2007 11:36:49 +0200 id 000808A2.45B485B1.00005C9D Date: Mon, 22 Jan 2007 11:36:49 +0200 (EET) From: Jukka MJ Manner To: Cheng Hong Subject: RE: [NSIS] Re: Clarification: tearing down from intermediate node In-Reply-To: <5F09D220B62F79418461A978CA0921BD01768894@pslexc01.psl.local> Message-ID: References: <5F09D220B62F79418461A978CA0921BD01768894@pslexc01.psl.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e Cc: nsis@ietf.org, 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 Yes, it will use the defined retransmission procedure before giving up, or GIST can indicate that there is no more QNEs on this path. Jukka On Mon, 22 Jan 2007, Cheng Hong wrote: > Hi Jukka > > > QNE1 just figures out that its next peer for the session is > > not there anymore, thus, the reservation can be torn down. > > If QNE1 doesn't know the next peer is QNI, would not it attempts some > new path discovery/rerouting to find a new peer instead of immediately > do a tear down? Although it is pretty much a local configuration issue, > if no indication is available to help QNE1 making the decision, it may > take quite long for it to decide tearing the old session down. > > Cheers > > Cheng Hong > > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: Thursday, January 18, 2007 12:06 AM > > To: Takako Sanda > > Cc: Cheng Hong; nsis@ietf.org > > Subject: Re: [NSIS] Re: Clarification: tearing down from > > intermediate node > > > > > > Hi, > > > > QNE1 does not need to know that the next peer is the QNI. > > QNE1 just figures out that its next peer for the session is > > not there anymore, thus, the reservation can be torn down. > > > > Jukka > > > > On Fri, 12 Jan 2007, Takako Sanda wrote: > > > > > Hi Jukka, > > > > > > I still have a question for the operation below. > > > > > > > > > > > > The tear-down part: > > > > > > - QNE3 also noticies that the SII-Handle has changed, > > and could basically > > > > > > send a NOTIFY to QNE2 and through the QNI's old > > path saying "Route > > > > > > Change" 0x02 > > > > > > - QNE2 will forward it to QNE1 > > > > > > - QNE1 would then at some point figure out QNI has > > disappeared, and will > > > > > > start removing the reservation using a tearing RESERVE > > > > > > > > > > How the QNE1 figure out the QNI has disappeared might > > require some > > > > > enhancement. Maybe the "Route Change" indication from > > QNE3 could > > > > > further identify whether it is upstream route changed or > > > > > downstream route changed. It might help the QNE1 reach > > the conclusion faster. > > > > > > > > JM: I believe this falls a bit down the path of security. > > What can a > > > > QNE trust? I would rather let the QNE1 figure by itself > > that the QNI > > > > has disappeared. The message sent is only a hint that > > tells QNE1 to > > > > verify if QNI is still there. It would only take a few seconds, > > > > basically once the retransmission procudure of either GIST or the > > > > NSLP fails, QNE1 can deduce that the QNI is gone. > > > > > > How does QNE1 know the next peer was NI? > > > In order to know this, I guess, QNE1 needs to have received an > > > explicit notification from NI in advance. > > > > > > cheers, > > > Takako > > > > > > On Wed, 10 Jan 2007 12:35:00 +0200 (EET) Jukka MJ Manner > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > some answers below. > > > > > > > > Jukka > > > > > > > > On Wed, 10 Jan 2007, Hong Cheng wrote: > > > > > > > > > Hi Jukka, > > > > > > > > > > The operation is well analyzed. The text should be incorporated > > > > > into the Mobility Applicability draft. I think generally a > > > > > tear-down could be initiated by any QNE (e.g. the CRN), > > as long as > > > > > it is along the direction from QNI to QNR. > > > > > > > > > > Please find a few more comments inline. > > > > > > > > > > cheers > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > > Hi Cheng, > > > > > > > > > > > > After re-reading the QoS NSLP spec, I think the spec is quite > > > > > > accurate in how the NSLP supports mobility, and it > > seems to work > > > > > > properly. Tearing down the reservation on the old > > path from the > > > > > > cross-over QNE would be good to do, but not > > necessarily critical > > > > > > for the proper operation of the NSLP. Yet, the > > current QoS NSLP spec mentions the tear-down at the cross-over router. > > > > > > > > > > > > Consider the following scenario: > > > > > > > > > > > > > > > > > > > > > > > > [MN] [QNE1] --- [QNE2] ---\ > > > > > > | \ > > > > > > | [QNE3] --- [QNE6] --- [QNE7] --- > > > > > > | / > > > > > > V / > > > > > > [MN] [QNE4] --- [QNE5]---/ > > > > > > > > > > > > > > > > > > The two main (simple) cases are "MN as QNI and data > > sender" and > > > > > > "MN as QNR and receiver" > > > > > > > > > > > > "MN as QNI and data sender": we could rely on just the > > > > > > soft-state to expire on the old path, and a new > > RESERVE on the > > > > > > new path, or use the following, based on the NSLP draft text. > > > > > > > > > > > > - MN moves from peer QNE1 to QNE4 > > > > > > - GIST gets a hint that routing has changed, triggers the NSLP > > > > > > - The NSLP then sends a new full RESERVE with a new RSN > > > > > > - The RESERVE hits QNE4, which makes reservation > > > > > > - Then the RESERVE is forwarded to QNE5, which also makes the > > > > > > reservation > > > > > > - Finally, the RESERVE hits QNE3, which makes a > > reservation and forwards > > > > > > the RESERVE to QNE6, and so on > > > > > > > > > > > > The tear-down part: > > > > > > - QNE3 also noticies that the SII-Handle has changed, > > and could basically > > > > > > send a NOTIFY to QNE2 and through the QNI's old > > path saying "Route > > > > > > Change" 0x02 > > > > > > - QNE2 will forward it to QNE1 > > > > > > - QNE1 would then at some point figure out QNI has > > disappeared, and will > > > > > > start removing the reservation using a tearing RESERVE > > > > > > > > > > How the QNE1 figure out the QNI has disappeared might > > require some > > > > > enhancement. Maybe the "Route Change" indication from > > QNE3 could > > > > > further identify whether it is upstream route changed or > > > > > downstream route changed. It might help the QNE1 reach > > the conclusion faster. > > > > > > > > JM: I believe this falls a bit down the path of security. > > What can a > > > > QNE trust? I would rather let the QNE1 figure by itself > > that the QNI > > > > has disappeared. The message sent is only a hint that > > tells QNE1 to > > > > verify if QNI is still there. It would only take a few seconds, > > > > basically once the retransmission procudure of either GIST or the > > > > NSLP fails, QNE1 can deduce that the QNI is gone. > > > > > > > > > > > > > > > - The tearing RESERVE will eventually hit QNE3, which > > noticies that it has > > > > > > an existing, and newer state (higher RSN), and will > > drop the > > > > > > tear > > > > > > > > > > > > > > > > > > "MN as QNR and data receiver": we could rely on > > routing changes > > > > > > to eventually lead to a refreshing RESERVE from QNE3 to hit > > > > > > QNE5, which will then send back a RESPONSE saying "full QSPEC > > > > > > required". A subsequent full RESERVE will then set up the > > > > > > reservation on the new path. Or, in order to make it > > faster, we could use the following: > > > > > > > > > > > > - MN moves, gets a hint from GIST that routing has changed > > > > > > - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > > > > > > - QNE4 will receive it, and forward it, same with QNE5 > > > > > > > > > > This is assuming the QNE4 has already been discovered. > > When the MN > > > > > is QNR and data receiver, considering the discovery process, > > > > > wouldn't sending a trigger to QNI directly result in a > > faster process? > > > > > > > > JM: Once GIST tells a routing change has happened, the > > NSLP will ask > > > > GIST to send the NOTIFY towards the QNI. For doing that, > > GIST must > > > > find the next peer QNE node, which is QNE4 in this case. > > Since the > > > > NSLP works hop-by-hop, you can't really send a message > > directly to > > > > the QNI, without going through all the intermediate nodes. > > > > > > > > > > > > > > > - The NOTIFY will hit QNE3, which notes that the > > message for a known > > > > > > session comes from a new SII-Handle. > > > > > > - QNE3 should then send a full RESERVE with a new RSN > > and an RII to > > > > > > QNE5 > > > > > > - QNE4 will receive the RESERVE, make the > > reservation, and forward it to > > > > > > the MN > > > > > > - The MN gets the RESERVE and replies with a RESPONSE > > > > > > > > > > > > The tear down: > > > > > > - QNE3 should also send a tearing RESERVE with the > > old RSN to QNE2, which > > > > > > again sends ti QNE1 > > > > > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > On Thu, 14 Dec 2006, Hong Cheng wrote: > > > > > > > > > > > > > Hi Jukka, > > > > > > > > > > > > > > I would agree that the cross-over router should be left > > > > > > > capable of tearing down the unneeded reservations. > > Please see > > > > > > > some comments inline below: > > > > > > > > > > > > > > cheers > > > > > > > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > > > > Hi all, > > > > > > > > > > > > > > > > If you look at how the NSIS protocols work, there > > is no way > > > > > > > > a node can make sure a tear-down was intiated by > > the QNI. A > > > > > > > > QNE receives a teardown from its upstream peer, > > but it can't > > > > > > > > tell whether that peer initiated the tear down in > > the first place, or the QNI. > > > > > > > > > > > > > > > > If I would do a "mobility enhanced QoS NSLP", I > > would tear > > > > > > > > down at the cross-over router the unnecessary > > reservation. > > > > > > > > Of course the spec can say "don't do it", but a > > QNE can not > > > > > > > > really confirm it isn't being done. > > > > > > > > And the > > > > > > > > QNI or the QNR can't see that either. > > > > > > > > > > > > > > > > The QoS NSLP spec could say "only the QNI SHOULD > > (or MAY) be > > > > > > > > able to initiate a tear down", and thus leave the option > > > > > > > > open for a QNE to also do it. > > > > > > > > > > > > > > > [Cheng] Agree. This should be left open. And I think the > > > > > > > quoted text in current QoS NSLP draft is reflecting > > this point. > > > > > > > > > > > > > > > Or we could make a new INFO_SPEC code for > > "reservation not > > > > > > > > need" which is a hint sent by the cross-over router to > > > > > > > > inform downstream QNEs on the old path that the > > MN has moved > > > > > > > > away. It is then up to each QNE to decide whether > > to remove > > > > > > > > the resources and state, or not. > > > > > > > > > > > > > > > > > > > > > > > [Cheng] This option might lead to some problem > > though, since > > > > > > > it could leave the QNEs on the path unsynchronized > > should they > > > > > > > decide to do different things in response to the INFO_SPEC. > > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi Jukka and all, > > > > > > > > > > > > > > > > > > I would like to clarify about tearing down operation. > > > > > > > > > > > > > > > > > > In section 3.2.11 (Rerouting), 5th paragraph, > > it is said, > > > > > > > > > "After the reservation on the new path is > > set up, the branching > > > > > > > > > node > > > > > > > > > may want to tear down the reservation on the > > old path (sooner than > > > > > > > > > would result from normal soft-state time-out)." > > > > > > > > > > > > > > > > > > This means that the CRN will initiate the TEAR > > on the old path. > > > > > > > > > > > > > > > > > > At Munich Interim, It was discussed that > > tearing down from > > > > > > > > > intermediate > > > > > > > > > node needs to be avoided because of session > > ownership issue. But I > > > > > > > > > cannot find any conclusion of this discussion. > > > > > > > > > > > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMi > nutes.html > > > > > > > > > > > > > > > > > > Do we have any decision for "tearing down from > > intermediate node"? > > > > > > > > > > > > > > > > > > cheers, > > > > > > > > > Takako > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 (EET) > > > > > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > > > > > > > I sent the following request for feedback two > > weeks ago. No > > > > > > > > > > comments > > > > > > > > > > have been raised. I will wait until this > > Friday, then submit the > > > > > > > > > > draft. > > > > > > > > > > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > I have done all the edits I had in my list > > to the QoS NSLP spec, > > > > > > > > > > > the > > > > > > > > > > > main points are in recent thread with > > Roland. From the url below > > > > > > > > > > > you > > > > > > > > > > > can find the current draft v. "13-pre1" and > > a diff to v. 12. > > > > > > > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ > > > > > > > > > > > > > > > > > > > > > > A direct link to the diff: > > > > > > > > > > > > > > > > > > > > > > > > http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-q > os-nslp-12-from-3-pre1.diff.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would appreciate comments on the changes > > I did (what is wrong, > > > > > > > > > > > what > > > > > > > > > > > I missed, etc.). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I still have one problem with the spec, > > namely the way the NSLP > > > > > > > > > > > suggests to handle mobility and path > > changes. I think we need to > > > > > > > > > > > review that statement, because it seems > > like a "hack" (playing > > > > > > > > > > > with > > > > > > > > > > > the RSN value), and not really useful. And > > the interactions with > > > > > > > > > > > GIST > > > > > > > > > > > look partly wrong. The folks working on the > > mobility draft (me > > > > > > > > > > > included) could comment. The section I'm > > talking about is 3.2.10, > > > > > > > > > > > especially 3.2.10.2, in the v.12 draft. > > > > > > > > > > > > > > > > > > > > > > BR, > > > > > > > > > > > Jukka > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > ----- > > > Takako SANDA > > > Next-Generation Mobile Communications Development Center, > > > Matsushita Electric Industrial Co., Ltd. (Panasonic) > > > Phone: +81 46 840 5764 Fax: +81 46 840 5122 > > > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 22 04:56:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vuC-0008Kv-6F; Mon, 22 Jan 2007 04:56:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vuB-0008Kq-1f for nsis@ietf.org; Mon, 22 Jan 2007 04:55:59 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8vu7-0003rY-Bu for nsis@ietf.org; Mon, 22 Jan 2007 04:55:59 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l0M9tLYd006392 for ; Mon, 22 Jan 2007 10:55:36 +0100 (MET) From: "Georgios Karagiannis" To: Date: Mon, 22 Jan 2007 10:55:34 +0100 Message-ID: <0a1b01c73e0b$79815570$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.3028 Thread-Index: Acc+C3WcrgOV4eIbTv6br4zJwt/vZA== X-Spam-Score: 0.287 () AWL,FVGT_s_OBFU_Q1,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 22 Jan 2007 10:55:38 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Subject: [NSIS] updated comments on draft-ietf-nsis-qspec-13.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 all After checking all the discussions that we have had in the nsis mailing list related to my comments on draft-ietf-nsis-qspec-13.txt that I have sent on the 20th December 2006, I concluded that Most of my concerns are not yet solved. Therefore, I will repeat my comments and I will try to provide a more detailed reasoning and argumentation. Comment_1: Concept of QSPEC control information is removed -------------- In my opinion the concept of the QSPEC control information has been removed from the current version of the QSPEC template draft. This concept was included up to the previous version of the QSPEC template draft and it is needed for the situations that this parameter is used for providing signaling support for QSPEC/QOSM specific RMF functions, such as initiation, refresh, release, modification for unidirectional and bi-directional per traffic class RMF reservation states, per flow RMF reservation states, per aggregated RMF reservation states, specified for example, in [RMD-QOSM]. QSPEC control information examples used in RMD-QOSM are: and = , ,, , ,