Re: Review of draft-ietf-nsis-qspec-18.txt
Gerald Ash <[email protected]>
| Newsgroups | gmane.ietf.nsis |
|---|---|
| Message-ID | <[email protected]> |
Percy,
> It is also my understanding that there really is no major issue in
> changing an IETF spec that is tied to an ITU-T spec. If for example,
> Y.2171 is updated some time in the future to add a 4th priority level,
> then IANA can accommodate this by an appropriate change in
> NSIS-QSPEC. Jerry can you please confirm this?
Right, there is no issue in having an IETF spec tied to an ITU spec. If ITU modifies their spec, IANA will make the corresponding changes in the IETF IANA assignments. E.g., if ITU later standardizes more priority levels, say in "Y.2171.bis', IANA will change the admission priority registry accordingly. I checked that out with IANA a while ago, IANA can tie into ITU specs in this way.
In fact, many IETF standards incorporate ITU standards. As you point out, NSIS/NSLP/QSPEC incorporates Y.1541, and there are lots of other examples. I don't think we can reject this approach to admission priority because it is based on an ITU standard, in fact, IMO it strengthens the approach in this case.
Thanks,
Jerry
"TARAPORE, PERCY S, ATTLABS" <[email protected]> wrote:
Francois,
If it is undesirable to tie in to specs from another SDO, then should we completely abandon all other efforts that are related? For example, should we drop the tie-in to Y.1541-QSPEC that NSIS is also working on?
Can you demonstrate how domain-specific priority assignments could possibly work? See Jerry's statement from the e-mail thread:
"...If we eliminate this standardization, as is proposed, then different admission priority values can be assigned in different Admin domains, and will have no end-to-end significance. For example, Admin-domain 1, Admin-domain 2, and Admin-domain 3 assign admission priority=2, admission priority=4, admission priority=10 for the highest level priority, respectively. Admin-domain 1 and Admin-domain 2 try to initiate end-to-end flows via Admin-domain 3 for a 'high priority' flow. However, Admin-domain 3 has no idea how to treat the flow admission priority since all 3 domains are using different encodings of high priority...."
Can you please indicate how this situation could be resolved without an accepted standardized set of priority levels that can be exchanged across domains?
It is also my understanding that there really is no major issue in changing an IETF spec that is tied to an ITU-T spec. If for example, Y.2171 is updated some time in the future to add a 4th priority level, then IANA can accommodate this by an appropriate change in NSIS-QSPEC. Jerry can you please confirm this?
I still do not see any merit in removing Y.2171 priority levels from NSIS-QSPEC.
Thanks
Percy
---------------------------------
From: Francois Le Faucheur IMAP [mailto:[email protected]]
Sent: Friday, February 22, 2008 1:52 PM
To: TARAPORE, PERCY S, ATTLABS
Cc: Francois Le Faucheur IMAP; Gerald Ash; Martin Stiemerling; [email protected]; nsis
Subject: Re: [NSIS] Review of draft-ietf-nsis-qspec-18.txt
Hello Percy,
Some of the considerations that led to the decision to not re-specify in <emergency-rsvp>, <dime-qos-parameters> and <nsis-qspec> the admission priority values that are already specified in Y.2171 specs included:
* they are already defined in this ITU spec
* if one wants to comply with the ITU way to do Admission Priority they can follow the ITU spec
* it is not 100% obvious that absolutely every network administrator will ever want to implement admission priority exactly as specified by ITU and by that particular spec. Maybe one administrator will want to use less priorities, maybe one will want to use more...
* the admission mechanism to be defined by IETF should be flexible and not tied to one single application of one single SDO.
* the admission priority mechanism defined in IETF should allow support of a particular application of a particular SDO. This can be achieved by deliberate choice of a network administrator to use the values of that application/SDO (but we don't have to mandate that everybody using the admission priority mechanisms use it in the same way)
* this is the approach already used for the "Preemption" mechanism supported by NSIS and RSVP (ie it is up to network administrator to decide which preemption priority value to use in their network and their semantic is not defined in the documents)
* as a side practical considerations: it is undesirable to have an IETF spec tied to specifications of another body (eg what happens if ITU defines Y.2171bis with one more value? do we have to immediately reissue <emergency-rsvp>, <dime-qos-parameters> and <nsis-qspec>)? For example, if those documents would have mandated the ITU values and have been standardised in 2006, they would have referred to Y.1571 (as I think Qspec used to do before Y.1571 got superseded by Y.2171...)
Cheers
Francois
On 22 Feb 2008, at 19:05, TARAPORE, PERCY S, ATTLABS wrote:
The purpose and intent for Y.2171 was to standardize a set of admission control priority levels that can be recognized across multiple admin domains - and acted upon appropriately to provide the necessary CAC within each domain. Further, Priority Level 1 - the highest CAC priority - is exclusively reserved for emergency telecommunications in Y.2171. Thus retaining these in the NSIS-QSPEC is appropriate. They should not be changed or removed.
Percy S. Tarapore
---------------------------------
From: [email protected] [mailto:[email protected]] On Behalf Of Gerald Ash
Sent: Thursday, February 21, 2008 11:56 AM
To: Francois Le Faucheur IMAP; Martin Stiemerling; [email protected]; nsis
Cc: [email protected]
Subject: Re: [NSIS] Review of draft-ietf-nsis-qspec-18.txt
Francois, Martin, John, All,
>>> 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 above proposed paragraph is really unclear. Which draft
>> is setting up IANA Registries to assign Admission Priority
>> parameters? The way it reads it sounds like all three drafts
>> are setting up registries but that somehow (magically) all refer
>> "to the same Admission Priority". How can that be if they
>> assign different values? Right now emergency-rsvp and
>> nsis-qspec set up registries for Admission Priority and
>> dime-qos-parameters is using the nsis-qspec registry as I
>> recall.
>>
>> Please clarify the proposal as to which draft is setting up a
>> registry for Admission Priority.
> No registry is setup.
> It is up to a network administrator to decide how many/which
> admission priority gets used for what. This is similar to how
> Preemption is used (ie each network administrator may decide
> to use it or not, may decide to use 2,3,4,...128,.. levels...).
> The statement above only says that the the same value of
> admission priority should be used in the three protocols to refer
> to same level of admission priority.
That's a fundamental change to NSIS/QSPEC and does away with standardized Admission Priority values. QSPEC is following Y.1571 (now Y.2171 according to An Nguyen) in standardizing 3 priority levels to have end-to-end cross-domain significance.
If we elimate this standardization, as is proposed, then different admission priority values can be assigned in different Admin domains, and will have no end-to-end significance. For example, Admin-domain 1, Admin-domain 2, and Admin-domain 3 assign admission priority=2, admission priority=4, admission priority=10 for the highest level priority, respectively. Admin-domain 1 and Admin-domain 2 try to initiate end-to-end flows via Admin-domain 3 for a 'high priority' flow. However, Admin-domain 3 has no idea how to treat the flow admission priority since all 3 domains are using different encodings of high priority.
Admission priority is not the same as preemption priority and should not be based on that model.
IMO we should retain the standardized admission priority levels based on Y.1571/Y.2171. Otherwise, how do we achieve end-to-end, cross-domain standardization of admission priority? In any case, we need to see some good justification for the change.
>> I saw no discussion of this proposed resolution on the NSIS list.
> which is why we've been assuming there was no issue with it.
It isn't sufficient to declare 'silence is agreement' on making such a fundamental change. People should weigh in *on the list* and give their technical justifications and confirm their agreement (or disagreement).
>> Who were the QSPEC co-authors who worked with you on the
>> proposed resolution?
> Attila, Cornelia and Dave Oran (+ NSIS WG chairs).
So far I've not been able to verify agreement from the QSPEC co-authors as yet. We saw no discussion of the issue on the list, and there needs to be some explanation/justification for the change.
Perhaps Francois could summarize the technical discussion amonst the co-authors, and also state who explicitly agreed (as opposed to who had no comment or active participation in the discussion).
It would be good if the co-authors who participated in the discussion of the 'proposed agreement' could weigh in on the list with their technical view.
Also, both NSIS chairs have said there is an agreement on the proposal, so perhaps they could weigh in on the list also with their technical view.
Jerry
Francois Le Faucheur IMAP <[email protected]> wrote:
Hello Jerry,
On 20 Feb 2008, at 16:58, Gerald Ash wrote:
Francois,
In your "Proposed Resolution" posting to NSIS on 3 December http://www.ietf.org/mail-archive/web/nsis/current/msg08155.html you say:
> 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.
I saw no discussion of this proposed resolution on the NSIS list.
which is why we've been assuming there was no issue with it.
Who were the QSPEC co-authors who worked with you on the proposed resolution?
Attila, Cornelia and Dave Oran (+ NSIS WG chairs).
> 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
OK.
> 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 above proposed paragraph is really unclear. Which draft is setting up IANA Registries to assign Admission Priority parameters? The way it reads it sounds like all three drafts are setting up registries but that somehow (magically) all refer "to the same Admission Priority". How can that be if they assign different values? Right now emergency-rsvp and nsis-qspec set up registries for Admission Priority and dime-qos-parameters is using the nsis-qspec registry as I recall.
Please clarify the proposal as to which draft is setting up a registry for Admission Priority.
No registry is setup.
It is up to a network administrator to decide how many/which admission priority gets used for what. This is similar to how Preemption is used (ie each network administrator may decide to use it or not, may decide to use 2,3,4,...128,.. levels...).
The statement above only says that the the same value of admission priority should be used in the three protocols to refer to same level of admission priority.
Cheers
Francois
Also, please provide clearer proposed text to include in the drafts.
It would be good to see some discussion of the proposal on the list, to confirm and validate agreement of the WG.
Jerry
Francois Le Faucheur IMAP <[email protected]> wrote:
Hello,
For memory, the next rev of nsis-qspec is also expected to be aligned
with the Resolution of the issue related to QoS Parameters encoding
in , & . For
convenience, I included below the recap on the corresponding
resolution as announced on NSIS, DIME and TSVWG lists.
Just to make sure this does not fall through the cracks.
Cheers
Francois
>
> Begin forwarded message:
>> From: Francois Le Faucheur IMAP
>> Date: 3 December 2007 12:05:42 GMT+01:00
>> To: [email protected], [email protected], tsvwg tsvwg
>> Cc: Francois Le Faucheur IMAP , David Oran R
>> , Hannes Tschofenig ,
>> ken carlberg , Magnus Westerlund
>> , James Polk ,
>> [email protected], "(IJ/ETH) Báder Attila"
>> , [email protected], Jukka
>> Manner MJ , tsvwg chair
>> [email protected]>, [email protected], dime-
>> [email protected], "[email protected]>"
>>
>> Subject: Resolution of issue QoS Parameters encoding in
>> parameters>, &
>>
>> 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
>>
---------------------------------
Never miss a thing. Make Yahoo your homepage.
_______________________________________________
nsis mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/nsis