Re: Review of draft-ietf-nsis-qspec-18.txt
Gerald Ash <[email protected]>
| Newsgroups | gmane.ietf.nsis |
|---|---|
| Message-ID | <[email protected]> |
Ken, > Jerry, >> This is confusing to me because admission priority has nothing to do with >> Y.1541. Y.1541 is associated with the <Y.1541.QoS Class> field (see Section >> 5.2.14 of the updated -19 QSPEC document or Section 6.2.14 of the >> current -18 QSPEC document). > mea culpa!!! in my ramblings, I meant Y.1571, so just swap all reference of > Y.1541 with Y.1571 from my previous postings There is no Y.1571, only Y.2171 (it was renumbered). >> QSPEC admission priority is simply using the 3 priority levels already >> standardized by Y.2171. Admission priority is a generic concept, not >> invented by the ITU, so this is not 'ITU admission priority', just plain >> ole' admission priority. > I beg to differ. We are in agreement that admission priority is a generic > concept, but in Section 6.2.9 of the QSPEC you have bound an Admission > Priority field with pre-existing values defined in Y.1571 as written in the > following: > > High priority flows, normal priority flows, and best-effort priority > flows can have access to resources depending on their admission > priority value, as described in [Y.1571], as follows: > > Admission Priority: > 0 - best-effort priority flow > 1 - normal priority flow > 2 - high priority flow > > And now we're told these values are to be updated by Y.2171. By the way, > could you tell us what these new values are? Some of the members of the > NSIS list are not members of the ITU, and so don't have that information on > hand. The values are unchanged. There is no Y.1571, it was renumbered Y.2171, the reference has been corrected in QSPEC -19. You don't have to be a member of ITU to get a recommendation, they are all freely available on the www.itu.int web-site. Y.2171 can be downloaded at http://www.itu.int/rec/T-REC-Y.2171/en. BTW, essentially all service providers and equipment vendors belong to and participate in the ITU. All these service providers and equipment vendors have unanimously agreed to Y.2171. >> What's missing here is an explanation of what the approach is in >> [EMERGENCY-RSVP]. As I posted earlier in >> http://www.ietf.org/mail-archive/web/nsis/current/msg08231.html: > as stated by francois: > > 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. > but to get to the specifics of what you ask below... The above "proposed agreement" doesn't at all describe the complex approach apparently being taken by [EMERGENCY-RSVP] to 'admission priority', as illustrated by your example below. It is a very different approach to 'admission priority' from what QSPEC is standardizing. >> "QSPEC is ... standardizing 3 priority levels to have end-to-end >> cross-domain significance. >> >> If we elimate this standardization, as is proposed (in [EMERGENCY-RSVP]), >> 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." >> >> I've not seen a response to the above example and/or an explanation of how >> the [EMERGENCY-RSVP] approach achieves end-to-end cross-domain >> standardization? > [emergency-rsvp] has a policy element that contains numeric-only namespace & > priority values that can be used as a standard cross-domain agreement of > sets of priorities. from this tuple, one can map to a locally defined > Admission Priority set. if we take an example namespace of "FOO-A", we'll > assume: (a) some set of domains have been contracted to support it, and (b) > initially, that set of domains choose to support the service models of > Y.1571. Here we have an exact end-to-end consistency that is agreed to on > a per-domain basis. > > later, a subset of these domains (AD-2, AD-3) decide to support another > namespace "FOO-B", which specifically calls for support of a service lower > than best effort. These set of domains then decide to support > SUPER-Admission-Priority-SET, which is not defined by the ITU but includes > the values defined Y.1571 along with lower-than-best-effort Admission > Priority in order to support FOO-B. > > policy decision points at the domain edges would do the mappings between > namespace.priority tuple to admission priority. and in the case of > rfc-3181, this would include preemption priority if so needed. This is a very different approach to 'admission priority' from what QSPEC is standardizing. You are introducing policy elements, PDPs doing 'mappings', preemption, and namespaces. AFAIK preemption priority doesn't have namespaces, are you perhaps referring to RPH namespaces here? In any case it appears that [EMERGENCY-RSVP] is doing something quite different from what QSPEC is doing. The "proposed agreement" should have fully described what the proposed change is. I.e., you want to scrap whatever *was* in QSPEC and replace it with something else being done in [EMERGENCY-RSVP], but undefined in the proposed agreement. >> Perhaps the [EMERGENCY-RSVP] approach should be called "RSVP-priority"? > why? Because, as above, it's a totally different approach from QSPEC. It doesn't look much like the approach agreed by all participating service providers/equipment vendors in Y.2171. BTW, the Y.2171 approach matches admission priority as implemented in some networks. > lets take a step back and see what you are requesting. you are taking > what we agree to be a generic named field of Admission Priority and asking > all of us to only populate it with values defined by the ITU. perhaps I see > things oddly, but to me, this field is no longer generic but rather > explicitly bound to an ITU document. and please note I have no qualms about > binding a field to an ITU document, but I don't consider that field to be > generic. > > now, I'll re-ask my question. if we follow your original approach > concerning the Admission Priority field, how do we know what priority set is > to be supported if the ITU comes back and updates Y.2171 with a different > set of values? the QSPEC document started with Y.1571, and now we have > Y.2171. Certainly a flag day is not what is expected as a solution to > support Y.<next-priority-set>. There is only Y.2171 and no Y.1571. If ITU modifies Y.2171 later, say adds more values, IANA tracks those changes into the admission priority registry defined in QSPEC. This is standard IANA policy; registries do not have to be based *only* on IETF standards, they can be based on standards from other SDOs. I pointed this out earlier based on my discussion with IANA a while ago. > ps, all is not lost from the original agreement back in Nov/Dec. All three > documents are (I believe :-) still in agreement about the Namespace.Priority > fields and their IANA registration. If we cannot come to consensus about > the Admission Priority, then we drop that from the agreement. That appears to be the case. However, it would be good to have other WG members weigh in on this issue. Jerry ken carlberg <[email protected]> wrote: Jerry, This is confusing to me because admission priority has nothing to do with Y.1541. Y.1541 is associated with the <Y.1541.QoS Class> field (see Section 5.2.14 of the updated -19 QSPEC document or Section 6.2.14 of the current -18 QSPEC document). mea culpa!!! in my ramblings, I meant Y.1571, so just swap all reference of Y.1541 with Y.1571 from my previous postings QSPEC admission priority is simply using the 3 priority levels already standardized by Y.2171. Admission priority is a generic concept, not invented by the ITU, so this is not 'ITU admission priority', just plain ole' admission priority. I beg to differ. We are in agreement that admission priority is a generic concept, but in Section 6.2.9 of the QSPEC you have bound an Admission Priority field with pre-existing values defined in Y.1571 as written in the following: High priority flows, normal priority flows, and best-effort priority flows can have access to resources depending on their admission priority value, as described in [Y.1571], as follows: Admission Priority: 0 - best-effort priority flow 1 - normal priority flow 2 - high priority flow And now we're told these values are to be updated by Y.2171. By the way, could you tell us what these new values are? Some of the members of the NSIS list are not members of the ITU, and so don't have that information on hand. What's missing here is an explanation of what the approach is in [EMERGENCY-RSVP]. As I posted earlier in http://www.ietf.org/mail-archive/web/nsis/current/msg08231.html: as stated by francois: >> 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. but to get to the specifics of what you ask below... "QSPEC is ... standardizing 3 priority levels to have end-to-end cross-domain significance. If we elimate this standardization, as is proposed (in [EMERGENCY-RSVP]), 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." I've not seen a response to the above example and/or an explanation of how the [EMERGENCY-RSVP] approach achieves end-to-end cross-domain standardization? [emergency-rsvp] has a policy element that contains numeric-only namespace & priority values that can be used as a standard cross-domain agreement of sets of priorities. from this tuple, one can map to a locally defined Admission Priority set. if we take an example namespace of "FOO-A", we'll assume: (a) some set of domains have been contracted to support it, and (b) initially, that set of domains choose to support the service models of Y.1571. Here we have an exact end-to-end consistency that is agreed to on a per-domain basis. later, a subset of these domains (AD-2, AD-3) decide to support another namespace "FOO-B", which specifically calls for support of a service lower than best effort. These set of domains then decide to support SUPER-Admission-Priority-SET, which is not defined by the ITU but includes the values defined Y.1571 along with lower-than-best-effort Admission Priority in order to support FOO-B. policy decision points at the domain edges would do the mappings between namespace.priority tuple to admission priority. and in the case of rfc-3181, this would include preemption priority if so needed. Perhaps it is some different approach to priority more like preemption priority? preemption and defending priority for RSVP is already covered by rfc-3181, as mentioned in [emergency-rsvp] Perhaps the [EMERGENCY-RSVP] approach should be called "RSVP-priority"? why? lets take a step back and see what you are requesting. you are taking what we agree to be a generic named field of Admission Priority and asking all of us to only populate it with values defined by the ITU. perhaps I see things oddly, but to me, this field is no longer generic but rather explicitly bound to an ITU document. and please note I have no qualms about binding a field to an ITU document, but I don't consider that field to be generic. now, I'll re-ask my question. if we follow your original approach concerning the Admission Priority field, how do we know what priority set is to be supported if the ITU comes back and updates Y.2171 with a different set of values? the QSPEC document started with Y.1571, and now we have Y.2171. Certainly a flag day is not what is expected as a solution to support Y.<next-priority-set>. -ken ps, all is not lost from the original agreement back in Nov/Dec. All three documents are (I believe :-) still in agreement about the Namespace.Priority fields and their IANA registration. If we cannot come to consensus about the Admission Priority, then we drop that from the agreement. --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. _______________________________________________ nsis mailing list [email protected] http://www.ietf.org/mailman/listinfo/nsis