[NSIS] Resolution of issue QoS Parameters encoding in <dime-qos-parameters>, <nsis-qspec> & <tsvwg-emeregncy-rsvp>
Francois Le Faucheur IMAP <flefauch@cisco.com> Mon, 03 December 2007 13:44 UTC
Return-path: <nsis-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzBbN-0001C9-TF; Mon, 03 Dec 2007 08:44:49 -0500
Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Iz97y-0006Nj-82 for nsis-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 06:06:18 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz97x-0006NP-ID; Mon, 03 Dec 2007 06:06:17 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz97w-00073I-GC; Mon, 03 Dec 2007 06:06:17 -0500
X-IronPort-AV: E=Sophos;i="4.23,243,1194217200"; d="scan'208";a="159377828"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2007 12:06:12 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB3B6CFF019369; Mon, 3 Dec 2007 12:06:12 +0100
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB3B5t3h026772; Mon, 3 Dec 2007 11:06:04 GMT
Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 12:05:53 +0100
Received: from [10.13.7.53] ([10.61.66.23]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 12:05:52 +0100
In-Reply-To: <19EBBEC503C3B5469070E0A6674A533ACF9DD9@daebe104.NOE.Nokia.com>
References: <A444FACF-15B6-4DB4-A2EA-DBAE3FD9415F@g11.org.uk> <4710EDB4.7080306@gmx.net> <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> <471382F3.10101@gmx.net> <820D7225-8B7D-4B89-8858-9F4687F70360@g11.org.uk> <4713D654.4080703@gmx.net> <EB220E31-9894-41D4-9E06-CE2C06AB1E2B@cisco.com> <4714C026.9050008@gmx.net> <ADC36BD5-4198-48D0-A3E9-3B2F3B5DF8AB@cisco.com> <963D6672-0903-4F7B-B56C-963B4BFA3452@cisco.com> <474ABE9D.5030800@ericsson.com> <8E54EB46-B6CE-4051-A10D-FD119F6374FF@g11.org.uk> <19EBBEC503C3B5469070E0A6674A533AC94240@daebe104.NOE.Nokia.com> <474B1CEE.20207@gmx.net> <19EBBEC503C3B5469070E0A6674A533AC944F1@daebe104.NOE.Nokia.com> <9F78CF9E-33AF-4E29-A3AE-CCC2112AA726@cisco.com> <371A5217-CECC-4F3C-BB04-2E73F42E1DCC@cisco.com> <C04336C4-5C14-4535-BC17-FB5D6B4DA9F3@cisco.com> <219D02B1-D9F9-4953-97CC-C0464261684B@cisco.com> <19EBBEC503C3B5469070E0A6674A533ACF9DD9@daebe104.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <13195AD2-7CF0-4A74-80D1-9394F51A9D50@cisco.com>
Content-Transfer-Encoding: 7bit
From: Francois Le Faucheur IMAP <flefauch@cisco.com>
Date: Mon, 03 Dec 2007 03:05:42 -0800
To: dime@ietf.org, nsis@ietf.org, tsvwg tsvwg <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 03 Dec 2007 11:05:52.0425 (UTC) FILETIME=[77FC4190:01C8359C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7435; t=1196679972; x=1197543972; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20<flefauch@cisco.com> |Subject:=20Resolution=20of=20issue=20QoS=20Parameters=20encoding=20in=20 <dime-qos-parameters>,=20<nsis-qspec>=20&=20<tsvwg-emeregncy-rsvp> |Sender:=20; bh=A78RBi+qRoXiFBqYh5+VQBAM8xpWnme0FgY3w0c4ryU=; b=VxXfTlXFDBnqxmJeygakO3pA3+ynsvHPy3grPEJcvnc1NKX4UNYUnzWuTWj36KQgcviD/F5f U+k1VtSMLRHbPe5j2XuI89MkyJOfkm0HMjVZxKVyLG12FJZ8OhBv3XGd;
Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );
X-Spam-Score: 0.2 (/)
X-Scan-Signature: df9edf1223802dd4cf213867a3af6121
X-Mailman-Approved-At: Mon, 03 Dec 2007 08:44:48 -0500
Cc: "john.loughney@nokia.com>" <john.loughney@nokia.com>, James Polk <jmpolk@cisco.com>, Jukka Manner MJ <jmanner@cs.Helsinki.FI>, David Oran R <oran@cisco.com>, tsvwg chair <tsvwg-chairs@tools.ietf.org>, nsis-chairs@tools.ietf.org, ken carlberg <carlberg@g11.org.uk>, " (IJ/ETH) Báder Attila " <attila.bader@ericsson.com>, cornelia.kappler@nsn.com, dime-chairs@tools.ietf.org, jouni.korhonen@teliasonera.com
Subject: [NSIS] Resolution of issue QoS Parameters encoding in <dime-qos-parameters>, <nsis-qspec> & <tsvwg-emeregncy-rsvp>
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Errors-To: nsis-bounces@ietf.org
Hello, The Issue: ======= Three different documents (dime-qos-parameters, nsis-qos-nslp, tsvwg- emergency-rsvp) need to convey an overlapping set of QoS parameters (specifically RPH-Priority and Admission Priority) and currently do that in an inconsistent manner. This has been brought up and partially discussed on the WG mailing lists. The Proposed Resolution =================== Co-authors of the three I-Ds as well as WG chairs of the corresponding WGs converged on the following proposed resolution. Please let us know if you have an issue/concern with this. o Regarding RPH-Priority: * tsvwg-emergency-rsvp will go ahead with its requests to IANA to provide numerical registry for RPH priority (via extending existing RPH registry). See IANA Considerations section of tsvwg-emergency-rsvp. * nsis-qspec (in section 6.2.10) will point to this registry instead of defining its own values * dime-qos-parameters (in section 4.11) will point to this registry instead of defining its own values * tsvwg-emergency-rsvp (in section 3.2) will keep pointing to this registry. o Regarding Admission Priority: * every protocol spec will only indicate that "higher value means higher priority". * there is no attempt to define what specific values should be used for what. this is left outside the scope of the protocol specs. * each protocol spec will add a statement clarifying that a given Admission Priority is to be encoded with the same value in each of the three protocol spec. For example, in tsvwg-emergency-rsvp, under section 3.1. we will add: " A given Admission Priority is encoded in this information element using the same value as when encoded in the Admission Priority parameter defined in section 6.2.9 of [nsis-qspec], or in the Admission Priority parameter defined in section 4.10 of [dime-qos-parameters]. In other words, a given value in any of the [emergency-rsvp] Admission Priority information element, the [nsis-qspec] Admission Priority parameter or the [dime-qos-parameters] Admission Priority parameter, refers to the same Admission Priority. " * the mirror statement will be added in nsis-qspec (section 6.2.9) and dime-qos-parameters (section 4.10) Francois >> >> For example in "tsvwg-emergency-rsvp" under section 3.1., after : >> " Adm. Priority (Admission Priority): 8 bits (unsigned) >> The admission control priority of the flow, in terms of >> access >> to network bandwidth in order to provide higher >> probability of >> call completion to selected flows. Higher values represent >> higher Priority. >> " >> we could add something like this: >> " A given Admission Priority is encoded in this >> information element >> using the same value as when encoded in the Admission Priority >> parameter defined in section 6.2.9 of [nsis-qspec], or >> in the Admission >> Priority parameter defined in section 4.10 of >> [dime-qos-parameters]. >> In other words, a given value in any of the >> [emergency-rsvp] Admission >> Priority information element, the [nsis-qspec] >> Admission Priority parameter >> or the [dime-qos-parameters] Admission Priority >> parameter, refers to >> the same Admission Priority. >> " >> >> Francois >> >> >>> That way, when these protocols are used in combination, you >> can't get >>> into priority inversion problems and can resist the >> temptation to try >>> to map using a local function. >>> >>> DaveO. >>> >>>> As a practical example of an issue I see in B, consider the recent >>>> comment from An Nguyen as part of the WGLC on dime-qos-parameters. >>>> He explained that ITU-T changed the "recommendation" where they >>>> define Admission Priority semantic and therefore dime-qos- >> parameters >>>> needs to point to that new ITU-T document instead. So what happens >>>> when ITU change their spec again in 2 years if we go for B. What >>>> happens if some other SDO decides to make use of admission >> priorities >>>> and define different value sets? >>>> Approach A completely isolates IETF from any of these >> external events >>>> (that should indeed be completely transparent to IETF). >>>> >>>> If we can close that one by email, no need to meet face to face in >>>> Vancouver. >>>> >>>> Francois >>>> >>>> >>>> >>>> From: "Nguyen, An P" <An.P.Nguyen@dhs.gov> >>>> Date: 16 October 2007 15:20:35 GMT+02:00 >>>> To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, >> <dime@ietf.org>, >>>> "radext mailing list" <radiusext@ops.ietf.org>, <nsis@ietf.org>, >>>> "tsvwg IETF list" <tsvwg@ietf.org> >>>> Subject: [NSIS] RE: [Tsvwg] WGLC for draft-ietf-dime-qos- >>>> parameters-01 >>>> >>>> Hannes, >>>> >>>> Just a comment on a reference in Sect 4.10 - Admission Priority >>>> Parameter: >>>> >>>> Change the Y.1571 to Y.2171. The ITU SG-13 changed Y.1571 to Y. >>>> 2171 ( Admission Control Priority Levels in Next Generation >> Networks, >>>> Sept 2006) to reflect the NGN work. >>>> >>>> I think you should add Y.2171 to Sect 9.2 - Informative >> References as >>>> well. >>>> >>>> Regards, >>>> >>>> An >>>> >>>> >>>> >>>> >>>> On 26 Nov 2007, at 20:49, Francois Le Faucheur IMAP wrote: >>>> >>>>> >>>>> On 26 Nov 2007, at 20:23, <john.loughney@nokia.com> wrote: >>>>> >>>>>> So, all three documents are about at the same state. I think it >>>>>> makess sense if the tsvwg draft creates the registry, and all of >>>>>> the other drafts reference it. >>>>> >>>>> very well. >>>>> >>>>> Since we seem to have agreement across TSWG/NSIS/DIME about the >>>>> first point (ie use a shared registry for RPH priorities) >> then let's >>>>> move to the second point ie. the actual format of that >>>>> registry: >>>>> draft-ietf-tsvwg-emergency-rsvp-04.txt proposes to >> instantiate that >>>>> registry by extending the existing IANA registry that was created >>>>> based on RFC4412. See "IANA Considerations" section of >>>>> draft-ietf-tsvwg-emergency-rsvp-04.txt. >>>>> Please let us know if you see issues with this proposal. >>>>> >>>>> Thanks >>>>> >>>>> Francois >>>>> >>>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: 26 November, 2007 11:22 >>>>>>> To: Loughney John (Nokia-NRC/PaloAlto) >>>>>>> Cc: carlberg@g11.org.uk; magnus.westerlund@ericsson.com; >>>>>>> flefauch@cisco.com; jmpolk@cisco.com; cornelia.kappler@nsn.com; >>>>>>> oran@cisco.com; attila.bader@ericsson.com; >>>>>>> jouni.korhonen@teliasonera.com; jmanner@cs.Helsinki.FI; >>>>>>> tsvwg-chairs@tools.ietf.org; nsis-chairs@tools.ietf.org; >>>>>>> dime-chairs@tools.ietf.org >>>>>>> Subject: Re: QoS Parameters in dime-qos-parameters, >> nsis-qos-nlsp, >>>>>>> tsvwg-emeregncy-rsvp >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>>> First off, what is the status of the drafts? I am >> going to do a >>>>>>>> WG Chair write-up on the NSIS QSPEC document. DiME QoS >>>>>>> parameters might >>>>>>>> take a bit longer. >>>>>>> >>>>>>> The DIME QoS parameter document has finished WGLC already. The >>>>>>> only technical issue that has been raised for this document is >>>>>>> related to the registry. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> >>>>> >>>> >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis
- [NSIS] Resolution of issue QoS Parameters encodin… Francois Le Faucheur IMAP