Subject: Re: [NSIS] Review of draft-ietf-nsis-qspec-18.txt

From: ken carlberg <[email-masked]>
Date: Mon, 25 Feb 2008 14:50:24 -0500

Jerry,

 > 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.

if the Admission field in the QSPEC is to be so entwined with Y.1541  
values (and possibly Y.2171.bis), then perhaps the Admission field in  
QSPEC should be renamed as ITU-Admission?  Or possibly one could  
define a new field called ITU-admission that supports the Y.1541 pre- 
defined values.  It would also seem helpful to add another related  
field that indicates which Y.xxxx standard is being used since there  
may be some domains that only support Y.1541, others supporting Y. 
2171.bis, and whatever future iteration is defined by the ITU.  I  
assume  folks are not relying on a flag day change in support of new  
updates generated by the ITU?

and as far as the current values set by Y.1541, I wish there was  
support for Scavenger Service, which is considered less than Best  
Effort (already defined as "0" in Y.1541).  Since I'm not a member of  
the ITU, I can't advocate this position nor accomplish it if the  
Admission field of all three drafts <emergency-rsvp>, <dime-qos- 
parameters> and <nsis-qspec> are subject to values defined by the ITU.

and please note, I'm not saying that a field cannot reflect efforts  
put forth by the ITU, but rather if the need must exist, then I'd  
prefer that the QSPEC authors rename or create a new field for Y.1541  
or Y.2171.bis

regards,

-ken

_______________________________________________
nsis mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nsis

---

From: ken carlberg <[email-masked]>
Date: Mon, 25 Feb 2008 15:27:36 -0500

John,

> I think wee need to be able to support a few different scenarios and  
> usages for the admission priority.  Is there a way that we could  
> have a  common structure to hold the values, and the ability to set  
> the values accordingly?

we have one way, as described by Francois.

however, if there is a segment that is absolutely adamant in having a  
field reflect the defined values of Y.1541 or Y.2171bis in the QSPEC,  
then I think a new field should be defined in that document to contain  
those values.  The authors of the other documents can decide if they  
too wish to add an ITU dependent field.

the other option is to disregard any relation between the Admission  
Priority field of the QSPEC and tsvwg-emergency-rsvp, which would be a  
shame.

-ken

---

From: <[email-masked]>
Date: Mon, 25 Feb 2008 14:01:38 -0600

Hi all,
 
Just some background history.  There are 3 documents defining similar
fields
 
 tsvwg-emergency-rsvp 
 nsis-qspec 
 dime-qos-parameters
 
We discussed this on this list and at previous IETF meetings. My view of
consensus was that there should be some harmony and a common registry
between these documents.  
 
I think wee need to be able to support a few different scenarios and
usages for the admission priority.  Is there a way that we could have a
common structure to hold the values, and the ability to set the values
accordingly?
 
John
 
________________________________

From: ext ken carlberg [mailto:[email-masked]] 
Sent: 25 February, 2008 11:50
To: [email-masked]
Cc: nsis ((E-mail)); [email-masked]; Francois Le Faucheur IMAP;
Loughney John (Nokia-OCTO/PaloAlto)
Subject: Re: [NSIS] Review of draft-ietf-nsis-qspec-18.txt

	Jerry,

	> 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.

	if the Admission field in the QSPEC is to be so entwined with
Y.1541 values (and possibly Y.2171.bis), then perhaps the Admission
field in QSPEC should be renamed as ITU-Admission?  Or possibly one
could define a new field called ITU-admission that supports the Y.1541
pre-defined values.  It would also seem helpful to add another related
field that indicates which Y.xxxx standard is being used since there may
be some domains that only support Y.1541, others supporting Y.2171.bis,
and whatever future iteration is defined by the ITU.  I assume  folks
are not relying on a flag day change in support of new updates generated
by the ITU?

	and as far as the current values set by Y.1541, I wish there was
support for Scavenger Service, which is considered less than Best Effort
(already defined as "0" in Y.1541).  Since I'm not a member of the ITU,
I can't advocate this position nor accomplish it if the Admission field
of all three drafts <emergency-rsvp>, <dime-qos-parameters> and
<nsis-qspec> are subject to values defined by the ITU.

	and please note, I'm not saying that a field cannot reflect
efforts put forth by the ITU, but rather if the need must exist, then
I'd prefer that the QSPEC authors rename or create a new field for
Y.1541 or Y.2171.bis

	regards,

	-ken

---

From: Gerald Ash <[email-masked]>
Date: Mon, 25 Feb 2008 12:55:08 -0800 (PST)

Ken,
   
  >> 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.

  > values (and possibly Y.2171.bis), then perhaps the Admission field
  > in QSPEC should be renamed as ITU-Admission?
    > Or possibly one could define a new field called ITU-admission that
  > supports the Y.1541 pre-defined values.  It would also seem helpful to
  > add another related field that indicates which Y.xxxx standard is being
  > used since there may be some domains that only support Y.1541,
  > others supporting Y.2171.bis, and whatever future iteration is defined
  > by the ITU.  I assume  folks are not relying on a flag day change in
  > support of new updates generated by the ITU?

  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).  
   
  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.
   
  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:
   
  "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?
   
  Perhaps it is some different approach to priority more like preemption priority?  Perhaps the [EMERGENCY-RSVP] approach should be called "RSVP-priority"?

  > and as far as the current values set by Y.1541, I wish there was support
  > for Scavenger Service, which is considered less than Best Effort (already
  > defined as "0" in Y.1541).
   
  I'm not sure what your suggestion is here for Y.1541, but perhaps that should be discussed on a separate thread (perhaps associated with the Y.1541-QOSM draft http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-06.txt)?
   
  Thanks,
  Jerry

ken carlberg <[email-masked]> wrote:
    Jerry,

  > 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 

  if the Admission field in the QSPEC is to be so entwined with Y.1541 values (and possibly Y.2171.bis), then perhaps the Admission field in QSPEC should be renamed as ITU-Admission?  Or possibly one could define a new field called ITU-admission that supports the Y.1541 pre-defined values.  It would also seem helpful to add another related field that indicates which Y.xxxx standard is being used since there may be some domains that only support Y.1541, others supporting Y.2171.bis, and whatever future iteration is defined by the ITU.  I assume  folks are not relying on a flag day change in support of new updates generated by the ITU?

  and as far as the current values set by Y.1541, I wish there was support for Scavenger Service, which is considered less than Best Effort (already defined as "0" in Y.1541).  Since I'm not a member of the ITU, I can't advocate this position nor accomplish it if the Admission field of all three drafts <emergency-rsvp>, <dime-qos-parameters> and <nsis-qspec> are subject to values defined by the ITU.

  and please note, I'm not saying that a field cannot reflect efforts put forth by the ITU, but rather if the need must exist, then I'd prefer that the QSPEC authors rename or create a new field for Y.1541 or Y.2171.bis

  regards,

  -ken

---------------------------------
Never miss a thing.   Make Yahoo your homepage.

---

From: "TARAPORE, PERCY S, ATTLABS" <[email-masked]>
Date: Mon, 25 Feb 2008 16:49:58 -0600

Ken,
 
You state that Francois has "one way" that supposedly defines a "common
structure to hold the values and the ability to set the values
accordingly" as John desires. I am somewhat at a loss here - what
exactly has Francois described that takes an incoming CAC priority value
as desired by a customer at the initial domain which then passes it on
to the other domains in the path. After all, Y.2171 is simply a vehicle
for providing a CAC priority value. It does not mandate how that value
can be acted upon in each domain.
 
Thanks
 
Percy

From: ken carlberg [mailto:[email-masked]] 
Sent: Monday, February 25, 2008 3:28 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; TARAPORE, PERCY S, ATTLABS;
[email-masked]
Subject: Re: Admission field in QSPECRE: [NSIS] Review of
draft-ietf-nsis-qspec-18.txt

John,

	I think wee need to be able to support a few different scenarios
and usages for the admission priority.  Is there a way that we could
have a  common structure to hold the values, and the ability to set the
values accordingly?

however, if there is a segment that is absolutely adamant in having a
field reflect the defined values of Y.1541 or Y.2171bis in the QSPEC,
then I think a new field should be defined in that document to contain
those values.  The authors of the other documents can decide if they too
wish to add an ITU dependent field.

-ken

---

From: ken carlberg <[email-masked]>
Date: Tue, 26 Feb 2008 15:41:18 -0500

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...

> 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.

---

From: Gerald Ash <[email-masked]>
Date: Tue, 26 Feb 2008 14:38:57 -0800 (PST)

Ken,

>> 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:
> 
> 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.
  
>> [EMERGENCY-RSVP].  As I posted earlier in 
>> http://www.ietf.org/mail-archive/web/nsis/current/msg08231.html:
 
> 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.
   
>> 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.
> 
> 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-masked]> wrote:      Jerry,

  mea culpa!!!  in my ramblings, I meant Y.1571, so just swap all reference of Y.1541 with Y.1571 from my previous postings

  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:

  Admission Priority:

  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.

  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.

     

  [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.

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 26 Feb 2008 11:19:41 +0100

On 25 Feb 2008, at 23:49, TARAPORE, PERCY S, ATTLABS wrote:

> Ken,
>
> You state that Francois has "one way" that supposedly defines a  
> "common structure to hold the values and the ability to set the  
> values accordingly" as John desires.

As I said before, we are recommending that the Admission Priority  
value be handled in a similar way to how Preemption Priority is  
already handled today in NSIS and RSVP: it is up to the network  
administrator to decide what values should be used for what. If the  
network administrator wants to use values as defined in Y.2171, this  
is all fine and good. But if the network administrator decides to use  
different values, this is also fine too.

Francois

> I am somewhat at a loss here - what exactly has Francois described  
> that takes an incoming CAC priority value as desired by a customer  
> at the initial domain which then passes it on to the other domains  
> in the path. After all, Y.2171 is simply a vehicle for providing a  
> CAC priority value. It does not mandate how that value can be acted  
> upon in each domain.
>
> Thanks
>
> Percy
>
> Subject: Re: Admission field in QSPECRE: [NSIS] Review of draft- 
> ietf-nsis-qspec-18.txt
>
> John,
>
>> and usages for the admission priority.  Is there a way that we  
>> could have a  common structure to hold the values, and the ability  
>> to set the values accordingly?
>
> however, if there is a segment that is absolutely adamant in having  
> a field reflect the defined values of Y.1541 or Y.2171bis in the  
> QSPEC, then I think a new field should be defined in that document  
> to contain those values.  The authors of the other documents can  
> decide if they too wish to add an ITU dependent field.
>
> Priority field of the QSPEC and tsvwg-emergency-rsvp, which would  
> be a shame.
>
> -ken
>
>
>
>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 26 Feb 2008 11:23:25 +0100

> Priority field of the QSPEC and tsvwg-emergency-rsvp, which would  

Perhaps another option could be for the Qspec document to state that  
the Admission Priority values MAY be set according to Y.2171 (but not  
mandate those are the only valid assignment and not request creation  
of a Qspec-specific IANA registry for those)?

Francois

---

From: "TARAPORE, PERCY S, ATTLABS" <[email-masked]>
Date: Wed, 27 Feb 2008 11:54:11 -0600

Jerry correctly describes the situation re: Y.2171 versus Y.1571. Here
are some additional clarifications:
 
1. The correct ITU-T Recommendation is Y.2171. Unfortunately, the ITU-T
initially assigned Y.1571 to this Recommendation; only later on they
changed it to Y.2171. So Y.1571 is not superseded by Y.2171; in fact
they are the same document.
 
2. The total number of priority levels has not changed in the ongoing
Recommendation number change. There have always been 3 levels.
 
3. The total number of priority levels were agreed to involving
extensive discussions with a number of major service providers. The
intent was to ensure that Priority Level 1 - the highest admission
control priority - was exclusively reserved for emergency
telecommunications. The discussions then focused on how many other
levels were needed. There was agreement that:
    - There is a broad class of traffic that can be considered "Best
Effort". This is priority level 3.
    - There is a broad class of traffic that was not as critical as
emergency telecommunications but required better than "Best Effort".
This is priority level 2.
Thus 3 broad levels were agreed upon. With one caveat for flexibility:
Individual provider domains are free to assign additional sub-levels of
priority within these broad priority levels. The choice is up to
individual provider domains.
 
4. The above agreements were reached as I stated with several large
service providers participating: AT&T, Verizon, British Telecom, France
Telecom, Deutsche Telekom, NTT, KoreaTel, ZTE, China Tel.
 
Here is the relevant Clause (Clause 6) from Y.2171:
 
--------------------

Recommendation for admission control priority levels

Three admission control priority levels are recommended for
telecommunications services seeking entry into NGN:

*        Priority level 1: Traffic with this priority level receives the
highest assurance for admission to the network. This level is reserved
for emergency telecommunications over NGN. 

*        Priority level 2: Traffic with this priority level will not
receive the same assurance for admission as that given to priority level
1 traffic, but will receive higher assurance for admission than that
given to priority level 3 traffic. Examples include real-time services
(VoIP, video), VPN and data services. The selection of this priority
level is expected to be determined by appropriate service level
agreements (SLA) between network operators and customers for the desired
service.

*        Priority level 3: Traffic with this priority level receives the
least assurance for admission to the network. Examples include
"traditional" Internet service provider (ISP) services (e-mail, web
surfing). The selection of this priority level is expected to be
determined by appropriate SLA agreements between network operators and
customers for the desired service. 

Each network operator may adopt additional priority levels. The total
number of admission control priority levels may be extended in the
future.

The choice of priority implementation mechanisms in the transport
stratum is up to the network operator.
 
--------------------
 
Thanks,
 
Percy

From: Gerald Ash [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2008 5:39 PM
To: ken carlberg; nsis ((E-mail))
Cc: Jerry Ash; TARAPORE, PERCY S, ATTLABS; Francois Le Faucheur IMAP;
[email-masked]
Subject: Re: [NSIS] Review of draft-ietf-nsis-qspec-18.txt

Ken,

>> This is confusing to me because admission priority has nothing to do
with 
 
> mea culpa!!!  in my ramblings, I meant Y.1571, so just swap all
reference of 

>> QSPEC admission priority is simply using the 3 priority levels
already 

> I beg to differ.  We are in agreement that admission priority is a
generic 

> And now we're told these values are to be updated by Y.2171.  By the
way, 
> NSIS list are not members of the ITU, and so don't have that
information on 
 
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.

>> http://www.ietf.org/mail-archive/web/nsis/current/msg08231.html
<mhtml:{B096A9AC-8D5F-4D5A-AACE-EC56A1B5E65A}mid://00000015/!x-usc:http:
//www.ietf.org/mail-archive/web/nsis/current/msg08231.html> :

_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: Gerald Ash <[email-masked]>
Date: Wed, 27 Feb 2008 09:56:16 -0800 (PST)

All,
   
  John writes in http://www.ietf.org/mail-archive/web/nsis/current/msg08243.html:
   
  John> Just some background history.  There are 3 documents defining similar
  John> fields
  John>
  John> tsvwg-emergency-rsvp 
  John> nsis-qspec 
  John> dime-qos-parameters
  John>
  John> We discussed this on this list and at previous IETF meetings.
  John> My view of consensus was that...
   
  I've seen no discussion on the list either before or after the 'Proposed Resolution' was posted on 3 December at http://www.ietf.org/mail-archive/web/nsis/current/msg08155.html.  This is just presented and not explained.  AFAICT no co-authors of the QSPEC document participated actively in the off-line discussion or explicitly agreed to the proposed resolution.  So I don't see that there was any 'consensus'.
   
  John> ... there should be some harmony and
  John> a common registry between these documents. 
   
  The proposed resolution says:
   
  "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)"
   
  The above proposed resolution is very unclear and does not begin to explain that (apparently) what is proposed is to drop the QSPEC approach to admission priority and replace it with the emergency-rsvp approach.  
   
  Admission priority is a well defined concept supporting priority in flow admission control.  There are 3 priority levels defined in QSPEC, following the agreement standardized in Y.2171 http://www.itu.int/rec/T-REC-Y.2171/en.  The intent is that 'high admission priority' is reserved for emergency telecommunications.  'Normal admission priority' is reserved for traffic that is not as critical as emergency telecommunications but requires better than 'best effort admission priority'.  Examples include real-time services (VoIP, video), VPN and data services. 'Best effort admission' priority is reserved for a broad class of traffic that can be considered the lowest priority best effort flows.  Examples include “traditional” ISP services (e-mail, web surfing). 
   
  According to Francois (see http://www.ietf.org/mail-archive/web/nsis/current/msg08251.html), the emergency-rsvp approach is something aligned with preemption priority where no standard admission priority values are standardized in a registry.  However preemption priority works in a completely different way than admission priority; there are 2 values; 'defending priority' and 'preemption priority'.  These can be assigned somewhat arbitrarily since only the *relative* values have significance.  That is, the absolute values don't matter, it is only the relative value that matters.  In this way preemption can work across domains without standarding absolute values of defending priority and preemption priority.  It is unclear how such an approach can work for admission priority since the decision to admit or not admit a flow is done at the time of flow admission control and there is no prior 'defending priority' assigned to a flow when it first arrives for admission control. 
 So it unclear how the emergency-rsvp approach is aligned with the preemption priority approach.
   
  According to Ken (see http://www.ietf.org/mail-archive/web/nsis/current/msg08248.html), the emergency-rsvp approach involves using policy elements, PDPs doing 'mappings', preemption, and namespaces.  AFAIK preemption priority doesn't have namespaces, and what Ken describes looks different from what Francois describes.  
   
  In any case it appears that emergency-rsvp is doing something quite different from what QSPEC is doing.
   
  John> I think wee need to be able to support a few different scenarios and usages 
John> for the admission priority.
   
  I'm not sure what 'different scenarios' we're trying to support here?  As discussed above, admission priority is a well defined concept supporting priority in flow admission control.  I've seen no mention of any other 'different scenarios' for admission priority on the list.  Can you elaborate?
   
  John> Is there a way that we could have a  common structure to hold
  John> the values, and the ability to set the values accordingly?
 
Obviously one option is for emergency-rsvp to adopt the approach being taken all along in QSPEC.  We are not being told why this is not considered. 
  
Francois> Perhaps another option could be for the Qspec document to state
  Francois> that the Admission Priority values MAY be set according to Y.2171
  Francois> (but not mandate those are the only valid assignment and not
  Francois> request creation of a Qspec-specific IANA registry for those)?
   
  This is essentially the same as the 'proposed agreement', i.e. to drop the QSPEC approach to admission priority and do away with standardized admission priority values.  If we eliminate this standardization, then different admission priority values can be assigned in different Admin domains, and will have no end-to-end significance.  As such, each Admin domain has no idea how to treat the flow admission priority during flow admission since different domains are using different encodings of admission priority.

  IMO we should retain the standardized admission priority levels as included in QSPEC for a long time.  If emergency-rsvp cannot adopt the same approach, then for now retain 2 approaches.
   
  Jerry

---

From: ken carlberg <[email-masked]>
Date: Wed, 27 Feb 2008 14:13:26 -0500

> 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.

(i'll bite my tongue a bit).... but of those that do participate in  
the ITU, do they all support Y.2171 and provide it as a contracted  
service?  As written in QSPEC, the Admin Priority field is bound to  
those providers/vendors that offer the Y.2171 service, meaning that  
only those domains that support the 3 defined levels of Y.2171 can  
support the Admission Priority field of the QSPEC.  Also, there is a  
big difference between those that agree on a standard and those that  
support it as a service.

> 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?

I didn't suggest preemption priority has namespaces, I just said that  
the topic is discussed -- specifically in sections 1.1 and 2.0 of ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-05.txt

> 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.

I believe we are talking past each other at this point.  As I said  
before, I have _no_ qualms about tying the values of a field (and I'll  
explicitly say, a field placed in the IANA registry) to the values set  
by another standards body.  My concern is that you have a taken a  
field representing a (in your own words) "generic concept" (and most  
importantly _shared_ by two other documents) and constrained it to the  
output of another standards body.  Notice that neither I nor Francois  
has said any word about the field in Section 5.2.14 of the QSPEC  
titled "Y.1541 QoS Class".  The name says it all in that it is tied  
directly to Y.1541.

If the name of the field in Section 5.2.9 of the QSPEC is changed to  
"Y.2171 Admission Priority", I'll be more than happy to drop the  
subject altogether, and suggest we'll note in [emergency-rsvp] draft  
that Admission Priority field is not directly comparable with that in  
the QSPEC so as to avoid confusion.

But if the NSIS group and the QSPEC authors choose to keep the name  
Admission Priority as is, I'll beat the dead horse one last time and  
ask what will you do if the ITU updates Y.2171 with a new set of  
values (and IANA registers them) in light on an installed base that  
supports the original set of Y.2171?  Do you not lose the continuity  
in your approach with a flag day change by the installed base?

regards,

-ken

---

From: ken carlberg <[email-masked]>
Date: Wed, 27 Feb 2008 14:58:32 -0500

On Feb 27, 2008, at 12:56 PM, Gerald Ash wrote:

> Obviously one option is for emergency-rsvp to adopt the approach  
> being taken all along in QSPEC.  We are not being told why this is  
> not considered.

oh come on.  how many times must be said and in how many ways?  on  
February 25, 2008 2:50:24 PM EST I stated the following

"and as far as the current values set by Y.1541, I wish there was  
support for Scavenger Service, which is considered less than Best  
Effort (already defined as "0" in Y.1541).  Since I'm not a member of  
the ITU, I can't advocate this position nor accomplish it if the  
Admission field of all three drafts <emergency-rsvp>, <dime-qos- 
parameters> and <nsis-qspec> are subject to values defined by the ITU."

Put another way, Francois and I have said that we don't want an  
Admission Priority field to be constrained (limited, burdened,....pick  
the word of your choice) with pre-existing values, and in particular  
those that come from a different standards body.  And we are not  
condemning all other similar practices.  We are not even saying that  
those of Y.2171 cannot be used.

as for as the agreement that was passed around in nov/dec, you are not  
a newbie to think that agreements are etched in stone.  they exist to  
be commented on, hence our letting others on the diameter/tsvwg/nsis  
list know the results of private discussions.

> IMO we should retain the standardized admission priority levels as  
> included in QSPEC for a long time.  If emergency-rsvp cannot adopt  
> the same approach, then for now retain 2 approaches.

and I brought this up a while back as well.  we have no intention of  
steam rolling the agreement.  if part of the agreement breaks, it  
breaks and we'll go our separate ways.

and I apologize if this note is sounding a bit rude, but part of this  
is getting a bit much.

-ken

---

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 28 Feb 2008 13:44:56 +0100

Hi all,

I'm jumping late to this discussion -- the IETF deadline and the aftermath kept me busy. Sorry for that. 

First of all, John and me believed to have rough consensus for the proposed change to the QSPEC draft. The proposed changed has been first discussed offline in end of Nov 2007 between the document authors of the involved drafts. On Dec 3, Francois sent an email to the dime, tsvwg and nsis list announcing the proposed changed. Nobody objected here. 

However, I have checked again and noted that Jerry was actually not listed as one of the email recipients in the offline conversation. Sorry for that, I personally have not noticed that earlier.

Given the state right now, I would not call it consensus. The discussions latetly on the nsis list have not reached consensus and further discussions are needed. I propose to discuss the issue further on the NSIS list and to definitely discuss this during the NSIS session (if possible for Ken and Francois to participate, otherwise off-session on the hallway). 

  Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ken carlberg
> Sent: Wednesday, February 27, 2008 8:59 PM
> To: Gerald Ash
> Cc: John Loughney; nsis
> Subject: Re: [NSIS] Admission field in QSPEC -- was RE: 
> Review ofdraft-ietf-nsis-qspec-18.txt
> 
> 
> 	Obviously one option is for emergency-rsvp to adopt the 
> approach being taken all along in QSPEC.  We are not being 
> told why this is not considered. 
> 
> 
> oh come on.  how many times must be said and in how many 
> ways?  on February 25, 2008 2:50:24 PM EST I stated the following
> 
> "and as far as the current values set by Y.1541, I wish there 
> was support for Scavenger Service, which is considered less 
> than Best Effort (already defined as "0" in Y.1541).  Since 
> I'm not a member of the ITU, I can't advocate this position 
> nor accomplish it if the Admission field of all three drafts 
> <emergency-rsvp>, <dime-qos-parameters> and <nsis-qspec> are 
> subject to values defined by the ITU."
> 
> 
> Put another way, Francois and I have said that we don't want 
> an Admission Priority field to be constrained (limited, 
> burdened,....pick the word of your choice) with pre-existing 
> values, and in particular those that come from a different 
> standards body.  And we are not condemning all other similar 
> practices.  We are not even saying that those of Y.2171 
> cannot be used.
> 
> as for as the agreement that was passed around in nov/dec, 
> you are not a newbie to think that agreements are etched in 
> stone.  they exist to be commented on, hence our letting 
> others on the diameter/tsvwg/nsis list know the results of 
> private discussions.
> 
> 
> 	
> 	IMO we should retain the standardized admission 
> priority levels as included in QSPEC for a long time.  If 
> emergency-rsvp cannot adopt the same approach, then for now 
> retain 2 approaches.
> 
> 
> and I brought this up a while back as well.  we have no 
> intention of steam rolling the agreement.  if part of the 
> agreement breaks, it breaks and we'll go our separate ways.  
> 
> and I apologize if this note is sounding a bit rude, but part 
> of this is getting a bit much.
> 
> -ken
> 
> 

[email-masked]   <== 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-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Feb 2008 14:02:49 +0100

> Given the state right now, I would not call it consensus. The discussions latetly on the nsis list have not reached consensus and further discussions are needed. I propose to discuss the issue furt…

Please resolve this as quickly as possible. And if it effects 
draft-ietf-tsvwg-emergency-rsvp then you better raise those issues in 
the WG last call currently being run. The last call ends: 28th of March.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 28 Feb 2008 14:40:18 +0100

[writing as WG member, i.e. WG chair's hat off]

Hi,

I took a while to wrap my head around it, as this touches not only NSIS' business but also other WG's business. 

I see the benefits of the end-to-end approach in general and also in particular for the QSPEC draft. The IETF is good in doing end-to-end protocols but has some issues in defining end-to-end QoS solutions (note the diffence between 'protocols' and 'solutions'). Having end-to-end QoS and signalling of it, is definitetly beneficially but is also troublesome.

We are doing protocols and not architectures, so it is hard to mandate which QoS scheme is used in the Internet or any other closed deployment. This lead to the concept of local QSPEC in the QSPEC draft which solves this at least on the signalling side but not on the semantics side (i.e., what do different bits mean in different domains).

ITU Y.2171 (Admission control priority levels in Next Generation Networks) is manadated for the admission priority in QSPEC regardless of the used admission priority scheme in a single domain. It is intended for NGN networks (which is ITU specific) but does not apply IMHO to the whole Internet as such. This does not excluded in general, but I don't regard ITU Y.2171 as the single scheme for all deployments.

The current definition of the Admission Priority in the QSPEC draft contradicts also the local QSPEC mechanism. A local domain that uses ITU Y.2171 can do this by using a local QSPEC. However, the general Admission Priority in the QSPEC must be free of ITU semantics, as this is from an IETF perspective just one of the possible admission schemes that can be used. 

Long story short: I'm in favour of Francois' proposal for the Admission Priority, posted on Dec 3, 2007:
http://www.ietf.org/mail-archive/web/nsis/current/msg08155.html

  Martin

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Thu, 28 Feb 2008 09:14:21 -0500

Martin and all:

I believe that the part of the problems of the QSPEC draft is mixing of two things: 1. A generalized QOS scheme that does not specify and particular "values" used by Y.xxx (ITU-T), MPLS QOS (IETF), etc. and 2. Implementation-specific schemes that mandate some specific values by ITU-T Y.xxx, IETF MPLS QOS, etc.

In the beginning, I already raised the same issue and proposed that the draft needs to be split into two parts: Part I: A generalized QSPEC draft that does not mandate any values in any fields and Part II: Implementation-specific QSPEC draft - a. IETF MPLS QOS Model, b. IETF DiffServ QOS Model, c. ITU-T Y.xxx models, etc.

Now, we are seeing that the discussions and proposals are bouncing back and forth between the two parts: Part I and Part II.

In the past, I also suggested that Part I QSPEC draft can be a standard-track RFC while Part II may have several "Informational RFCs."

I suggest that we have still time to follow the above guidance by splitting the draft. I would be extremely glad if people would prove that my suggestion is the wrong one.

Best regards,
Radhika

----- Original Message -----
From: Martin Stiemerling 
Date: Thursday, February 28, 2008 8:41
Subject: Re: [NSIS] Admission field in QSPEC -- was RE: Review ofdraft-ietf-nsis-qspec-18.txt
To: ken carlberg , Gerald Ash 
Cc: John Loughney , nsis 

> I took a while to wrap my head around it, as this touches not only 
> NSIS' business but also other WG's business. 
> 
> I see the benefits of the end-to-end approach in general and also 
> in particular for the QSPEC draft. The IETF is good in doing end-
> to-end protocols but has some issues in defining end-to-end QoS 
> solutions (note the diffence between 'protocols' and 'solutions'). 
> Having end-to-end QoS and signalling of it, is definitetly 
> beneficially but is also troublesome.
> 
> We are doing protocols and not architectures, so it is hard to 
> mandate which QoS scheme is used in the Internet or any other 
> closed deployment. This lead to the concept of local QSPEC in the 
> QSPEC draft which solves this at least on the signalling side but 
> not on the semantics side (i.e., what do different bits mean in 
> different domains).
> 
> ITU Y.2171 (Admission control priority levels in Next Generation 
> Networks) is manadated for the admission priority in QSPEC 
> regardless of the used admission priority scheme in a single 
> domain. It is intended for NGN networks (which is ITU specific) 
> but does not apply IMHO to the whole Internet as such. This does 
> not excluded in general, but I don't regard ITU Y.2171 as the 
> single scheme for all deployments.
> 
> The current definition of the Admission Priority in the QSPEC 
> draft contradicts also the local QSPEC mechanism. A local domain 
> that uses ITU Y.2171 can do this by using a local QSPEC. However, 
> the general Admission Priority in the QSPEC must be free of ITU 
> semantics, as this is from an IETF perspective just one of the 
> possible admission schemes that can be used. 
> 
> Long story short: I'm in favour of Francois' proposal for the 
> Admission Priority, posted on Dec 3, 2007:
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014 
> 
> > , and are

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 29 Feb 2008 13:26:43 -0500

Hello Jerry,

On 27 Feb 2008, at 12:56, Gerald Ash wrote:

> I've seen no discussion on the list either before or after the  
> 'Proposed Resolution' was posted on 3 December at http:// 
> www.ietf.org/mail-archive/web/nsis/current/msg08155.html.

which suggested to us that the proposal was acceptable to the group.

> This is just presented and not explained.  AFAICT no co-authors of  
> the QSPEC document participated actively in the off-line discussion  
> or explicitly agreed to the proposed resolution.

Just for the records, all the qspec authors (but you) were part of  
the discussion that lead to this proposal. One of them (Dave)  
actually participated actively and contributed to the proposal. The  
only reason you were not in the list is because you were believed to  
be retired (and I think the only email address we had for you was no  
longer reaching you).

Have you considered the possible compromised approach to indicate in  
QSPEC that the ITU values/semantics  MAY be used (as opposed to MUST  
be used)?

Francois

---

From: Gerald Ash <[email-masked]>
Date: Fri, 29 Feb 2008 10:46:07 -0800 (PST)

All,
   
  I agree with Ken that we are talking past each other at this point.  Magnus has requested to resolve this issue quickly, so I also agree with Ken to resolve the issue based on his suggestion in http://www.ietf.org/mail-archive/web/nsis/current/msg08257.html:
   
  "If the name of the field in Section 5.2.9 of the QSPEC is changed to  
"Y.2171 Admission Priority", I'll be more than happy to drop the  
subject altogether, and suggest we'll note in [emergency-rsvp] draft  
that Admission Priority field is not directly comparable with that in  
the QSPEC so as to avoid confusion."
   
  I agree that the qspec approach and emergency-rsvp approach are not directly comparable, in fact, they are very different.  At the risk of (again) 'being a bit much', let me elaborate one more time on the differences as I see them:
   
  As I've stated before, IMO admission priority should apply end-to-end and across administrative domains, and the only way to do that is to standardize the admission priority values in an IANA registry.  This is the approach taken in qspec, where the initial values to populate the admission priority registry have been taken from Y.2171 since AFAIK this is the only SDO to standardize admission priority levels so far.  The process to standardize these has been rigorous and agreed to by essentially all service providers (and equipment vendors).  However, these are only initial values to populate the registry and it does *not* mean that only the ITU can change the registry to include more or changed values.  E.g., Ken can propose his 'Scavenger Service' (less than Best Effort) through the standard IANA procedure specified in qspec Section 7 (IANA considerations):
   
    "Admission Priority Parameter (8 bits):
   The following values are allocated by this specification:
   0-2: assigned as specified in Section 6.2.9:
   Admission Priority 0: best-effort priority flow
                      1: normal priority flow
                      2: high priority flow
   The allocation policies for further values are as follows:
   3-63: Standards Action
   64-255: Reserved"
   
  In addition, the qspec approach is the same as used in practice today for emergency telecommunications services (ETS, e.g., GETS) to achieve end-to-end admission priority across domains.  One reference as how this approach operates in practice today for ETS/GETS can be found in http://www.amazon.com/Traffic-Engineering-Optimization-Integrated-Networks/dp/0123706254/ (apologies for self reference, but I'd be very happy to hear other references to implementation examples).  The same reference also presents extensive modeling & simulation analysis to show how this approach can operate across domains in the Internet.
   
  OTOH, the emergency-rsvp approach is very different.  It does not prescribe end-to-end cross domain consist treatment of admission priority.  As stated in Section 2 of emergency-rsvp:
   
    "As an example of operation across multiple administrative domains, a 
   first domain might decide to provide network layer admission priority 
   to calls of a given Application Level Resource Priority and map it 
   into a high RSVP admission control priority inside the Admission 
   Priority Policy Element; while a second domain may decide to not 
   provide admission priority to calls of this same Application Level 
   Resource Priority and hence map it into a low RSVP admission control 
   priority."
   
  So in this RSVP approach an ETS/GETS service might *not* get uniformly high admission priority treatment across administrative domains (ADs), depending on how the policy decision points (PDPs) in each AD decide to populate the RSVP Admission Priority element.  Furthermore, my understanding is that the PDP in each AD is expected to always key off the Application Level Resource Priority (based on the SIP resource priority header).  These are 2 major differences with the qspec approach.  I presume, however, that the RSVP admission priority approach is implemented (or planned to be implemented) in real network applications.  It would be nice to be enlightened RE implementations, existing or planned, if possible.
   
  A further suggestion is to re-name the RSVP approach <RSVP Admission Priority> to distinguish it from <Y.2171 Admission Priority>, so that neither approach should be considered a 'generic' approach.
   
  Barring any objection, I'll go ahead and modify the qspec draft to rename <Admission Priority> to <Y.2171 Admission Priority>, as agreed.
   
  Jerry

Gerald Ash <[email-masked]> wrote: 
    All,

   

   

   

   

 

   
  Jerry