Martin,
   
  > Thanks for your summary and the proposal to change the field.
   
  It wasn't my proposal, it was Ken's proposal who said that if adopted he would "be more than happy to drop the subject altogether."  However, it seems now that this agreement wasn't enough to drop the subject altogether after all.

> However, there current approach elimantes the idea of
  > having an object understood by all participating partners
  > (RSVP, NSIS, etc) in terms of the admission priority.
>
> The updated QSPEC will solely have the "Y.2171 Admission
  > Priority" but no general purpose admission priority (as in
  > draft-ietf-tsvwg-emergency-rsvp). 
   
  Note that the emergency-rsvp folks would prefer to call the rsvp admission priority "generic admission priority" (GAP).  The object used for GAP is as follows (see Section 3.1 of  http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-05.txt):
   
  3.1.  Admission Priority Policy Element 
    
   The format of the Admission Priority policy element is as follows: 
    
          0           0 0           1 1           2 2           3 
          0  . . .    7 8   . . .   5 6    . . .  3 4  . . .    1 
         +-------------+-------------+-------------+-------------+ 
         |     Length                | P-Type = ADMISSION_PRI    | 
         +-------------+-------------+-------------+-------------+ 
         | Flags       | M. Strategy | Error Code  | Reserved    | 
         +-------------+-------------+-------------+-------------+ 
         |              Reserved                   |Adm. Priority| 
         +---------------------------+---------------------------+ 

  This is an rsvp-specific object and if incorporated into qspec would lead to significant changes (probably also in qos-nslp).  IMO this would be a very bad approach.
  
> How about having the "Y.2171 Admission Priority" and the
  > general purpose admission priority in the QSPEC?
   
  A possible approach would be to add an L bit in the NSIS admission priority object, as follows (see Section 5.2.9 in http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt):
   
  5.2.9 <Admission Priority> Parameter [Y.2171]

   The coding for the <Admission Priority> parameter is as follows:

  
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r|           9           |r|r|r|r|          1            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Admis.Priority|L|                (Reserved)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.2171], as follows:

   Admission Priority:

   0 - best-effort priority flow
   1 - normal priority flow
   2 - high priority flow
   
     L bit:
   
     0 - admission priority field has end-to-end significance
         (above admission priority values in IANA registry apply)
     1 - admission priority field has local significance only
         (admission priority values set by local domain administrator)
   
  In order to have this understood by all participating partners, it would be best if emergency-rsvp would also adopt the L bit with the same semantics.
   
  It would be good to get some other opinions here, besides the 4 or 5 of us who have discussed this so far.
   
  Jerry
  

Martin Stiemerling <Stiemerling@nw.neclab.eu> wrote:
    Hi Jerry,

Thanks for your summary and the proposal to change the field.

However, there current approach elimantes the idea of having an object understood by all participating partners (RSVP, NSIS, etc) in terms of the admission priority.

The updated QSPEC will solely have the "Y.2171 Admission Priority" but no general purpose admission priority (as in draft-ietf-tsvwg-emergency-rsvp). 

How about having the "Y.2171 Admission Priority" and the general purpose admission priority in the QSPEC?

Thanks,

Martin

stiemerling@nw.neclab.eu <== 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 

> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On 
> Behalf Of Gerald Ash
> Sent: Friday, February 29, 2008 7:46 PM
> To: nsis
> Cc: John Loughney
> Subject: Re: [NSIS] Admission field in QSPEC -- was RE: 
> Review ofdraft-ietf-nsis-qspec-18.txt
> 
> 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-Integra
> ted-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 > Admission Priority> to distinguish it from > 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 to > Priority>, as agreed.
> 
> Jerry

       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www.ietf.org/mailman/listinfo/nsis