Re: Call for consensu on admission priority changes in QSPEC

On Mar 14, 2008, at 10:08 AM, Francois Le Faucheur IMAP wrote:

> Hi,
> My vote would go for 2 (or 4 as proposed by Roy below).
> I can live with 3.
> Francois
>
+1.
Dave Oran

>
> On 13 Mar 2008, at 12:57, Roy, Radhika R Dr CTR USA USAMC wrote:
>
>> Hi, Martin:
>>
>> I hum for choice 2.
>>
>> I do NOT hum for choice 1 or 3 for the following reasons because of
>> the serious technical problems:
>>
>> a. QSPEC is "NOT" ITU-T QOS-specific draft.
>>
>> b. Any reference to ITU-T QOS-specific definitions and/or any
>> "values" as Y.xxxx-series do, is out-of-scope in the "generic"
>> QSPEC draft. If someone wants ito nclude anything realted to ITU-T
>> QOS-specific things, it MAY only be done in the sections specific
>> to ITU-T Y.xxxx QOS "values." In fact, no "values" will be defined
>> directly or indirectly (e.g. providing references to Y.xxxx) in
>> this draft.
>>
>> c. It will be more appropriate, to make a separate draft (stand-
>> alone) of QSPEC that is specific to ITU-T QOS models, values, and
>> other things. So, it is better to DELETE all references specific to
>> ITU-T QOS fro mthe "generic: QSPEC draft. In this case, no "apples"
>> will be mixed with any "oranges." This would be taken as the 4th
>> "options" - as the best one.
>>
>> Best regards,
>> Radhika
>>
>> ----- Original Message -----
>> From: Martin Stiemerling
>> Date: Thursday, March 13, 2008 11:42
>> Subject: [NSIS] Call for consensu on admission priority changes in
>> QSPEC
>> To: nsis
>>
>>> Hi all,
>>>
>>> There have been discussions with respect to QoS NSLP QSPEC
>>> Template (draft-ietf-nsis-qspec-19.txt) on the nsis mailing list,
>>> offline between involved parties, and also during the NSIS session
>>> here at the IETF#71 in the NSIS session (see minutes).
>>>
>>> The QSPEC document shares the IANA registries for RPH priority and
>>> the admission priority with these drafts out of the DIME and TSVWG:
>>> - draft-ietf-dime-qos- parameters
>>> - draft-ietf-tsvwg-emergency-rsvp
>>>
>>> While the IANA registry for the RPH priority has not been
>>> disputed, the admission priority has been.
>>>
>>> Therefore we run a call for consensus on these three choices for
>>> the admission priority in the QSPEC. Note well, that the decision
>>> of this can have an impact to the still running IETF last call for
>>> draft-ietf-tsvwg-emergency-rsvp.
>>>
>>>
>>>
>>> Please hum on the NSIS list for one of the three options listed
>>> below until Monday, March 17th, 12pm UCT. This is to confirm the
>>> humming of the NSIS WG during the NSIS session at the IETF meeting.
>>>
>>> 1) Keep Y.2171 admission prioty in draft-ietf-nsis-qspec-19.txt as
>>> is:
>>>
>>> 2) Change in draft-ietf-nsis-qspec-19.txt to admission priority as
>>> in draft-ietf-tsvwg-emergency-rsvp-05.txt and remove Y.2171
>>> admission prioty;
>>>
>>> 3) Keep Y.2171 admission priority and add admission priority as in
>>> tsvwg-rsvp-emergency to draft-ietf-nsis-qspec-19.txt.
>>>
>>>
>>>
>>>
>>> For choice 3) these changes are currenlty proposed:
>>>
>>> 1) the emergency-RSVP draft should pretty much stay the same.
>>> There is no "L" bit addition, and its "Admission Priority" field
>>> has local significance within a domain, and no pre-existing values
>>> are defined for it, nor is there any associated IANA registry
>>> assigned to it.
>>>
>>> 2) The QSPEC draft will have a similar "Admission Priority" field
>>> with the same characteristics as that defined above in (1).
>>>
>>> 3) The QSPEC draft will add a new field, titled "Y.2171 Admission
>>> Priority", that will be associated with the current 3 values
>>> defined in the Y.2171. This field is considered globally
>>> significant on an end- to-end basis. Note that the emergency-RSVP
>>> document will NOT have this additional field.
>>>
>>> 4) Given the presence of two admin priority fields for the QSPEC,
>>> additional rules are added to clarify their application and usage
>>> for NSIS domains.
>>>
>>> 4.1) if the source domain does NOT support Y.2171, then it sets a
>>> locally significant value in the "Admission Priority" field, and
>>> places all "1"s in the "Y.2171 Admission Priority" to indicate
>>> that this field is to be ignored. Downstream domains MUST NOT
>>> alter the value of the "Y.2171 Admission Priority" field.
>>>
>>> 4.2) if the source domain DOES support Y.2171, then a value (eg,
>>> 0, 1, or 2) is placed in the "Y.2171 Admission Priority" field AND
>>> the "Admission Priority" field. Downstream NSIS domains MUST NOT
>>> change the value in the "Y.2171 Admission Priority" field so that
>>> end-to-end consistency is maintained. Downstream routers act upon
>>> the value placed in the "Admission Priority" field.
>>>
>>> 4.2.1) Furthermore, if a downstream NSIS domain does not support
>>> Y.
>>> 2171, it MAY place a locally significant different value in the
>>> "Admission Priority" field, which is used by downstream routers
>>> within its domain. Subsequent downstream domains that do support
>>> Y.2171 make sure that the "Admission Priority" field contains the
>>> same value as the "Y.2171 Admission Priority" field.
>>>
>>>
>>> Thanks,
>>>
>>> Martin
>>>
>>> [email protected] <== NEW ADDRESS
>>>
>>> NEC Laboratories Europe - Network Research Division
>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria
>>> Road, London W3 6BL | Registered in England 2832014
>>> _______________________________________________
>>> nsis mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/nsis
>>>
>> _______________________________________________
>> nsis mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis