Re: [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05

Francois,
   
  A couple more comments.
   
  >> It would be good to motivate the rationale for the emergency-rsvp approach 
>> and why it makes sense to *not* ensure high end-to-end admission priority 
>> across domains for ETS/GETS services.
 
> The approach is the following:
> * the overall requirement for Emergency services is to achieve "elevated 
> probability of session establishment"
> 
> * there are multiple mechanisms (Admission Priority, Preemption, "Call 
> Queueing") that can be combined in different ways in a given network that 
> will ENSURE "elevated probability of session establishment" _through that 
> given network_
> * in addition, there is a mechanism allowing each operator to identify an 
> emergency session transiting their network and invoke the corresponding set 
> of mechanism in that network. As a result, the solution allows "elevated 
> probability of session establishment" _end-to-end_, which is the real 
> objective.
> 
> So, in a nutshell the approach focuses on allowing end-to-end "elevated 
> probability of session establishment" but it is felt that while this may 
> involve admission priority, this does not necessarily dictate end-to-end 
> admission priority.
> 
> This was discussed at length in the TSVWG. Some operators pointed out that 
> in their region/country Emergency services would use mechanism A while 
> others would use mechanism B, while other would use a combination of 
> mechanisms. Some pointed out that local regulations prevented use of a 
> particular mechanism in a geography while not in another. As agreed by the 
> WG, this discussion was captured in Appendix B illustrating various 
> combinations that an operator may use to achieve "elevated probability of 
> session establishment" .
> 
> More generally, I think it was felt that IETF was not chartered to mandate a 
> specific combination of mechanisms that MUST be deployed in each and every 
> network. Rather, the IETF needs to make available the mechanisms that can be 
> combined to achieve the end to end objective.
> [an analogy that comes to mind is the Voice QoS space. The IETF has defined 
> many QoS mechanisms : Diff-Serv, MPLS Traffic Engineering, MPLS FRR, MPLS 
> Diffserv-aware TE, .... However, the IETF does not mandate that a very 
> specific combination of those be used in each and every network carrying 
> voice.]
> 
> My perception is that the above approach is sufficiently described in the 
> current draft (section 2, appendix B,..). But if you have specific 
> suggestions on how to present it more clearly, we can certainly accommodate 
> that.
   
  Thanks for the explanation, it helps to clarify the intent.  However, IMO this intent does not come through in the text (abstract, Section 1, Section 2).  The draft focuses on admission priority, e.g., the abstract says:
   
  "This document specifies RSVP extensions that can be used to support 
   such an admission priority capability at the network layer...
     Other solution components, or other 
   solutions, are outside the scope of this document."
   
  And the example you give in Section 2 leaves one wondering how ETS achieves the elevated probability of session establishment when one domain gives low admission priority:
   
  "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."
   
  Presumably the second domain uses some other mechanism (e.g., call queueing) to achieve elevated probability of call establishment.  IMO this should be mentioned in the example.
   
  More generally, perhaps you can add some of your clarifying words somewhere in Section 1 and/or in the above example and/or perhaps add a sentence to the abstract.  E.g., extracting from your explanation you could add something like the following:
   
  "The overall requirement for ETS is to achieve an elevated probability of session establishment (EPSE) by applying multiple mechanisms (e.g., admission priority, preemption, "call queueing") that can be combined in different ways in a given network to achieve EPSE.  As such, each operator can identify an emergency session transiting their network and invoke the corresponding mechanism(s) in that network to achieve EPSE.  For example, some operators may use mechanism A while others would use mechanism B, while others would use a combination of mechanisms.  Appendix B illustrates various combinations that an operator may use to achieve EPSE."
   
  >> 3. The admission priority approach taken in nsis-qspec 
>> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) is 
>> consistent with today's practice of providing high admission priority for 
>> ETS/GETS end-to-end across administrative domains.  It does this by 
>> standardizing the admission priority values for the qspec object in an IANA 
>> registry, as specified in 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"
>> 
>> It has been agreed on the nsis list to rename <Admission Priority> to 
>> <Y.2171 Admission Priority> in the qspec draft.  To be consistent with this 
>> change, the emergency-rsvp approach should also be renamed (e.g., to <RSVP 
>> Admission Priority>) to distinguish it from <Y.2171 Admission Priority>, and 
>> so that neither approach should be considered a 'generic' approach.

  > I am not sure why the RSVP Admission is no longer generic (it can be used to 
> convey the Y.2171 values if an operator so desires, it can be used to carry 
> other values too).
   
  Let me make sure I have this straight.  In the NSIS discussion you insist that we change the name to <Y.2171 Admission Priority> in order to resolve the debate, while the NSIS admission priority approach is in fact as implemented today for ETS and has little to do with Y.2171 other than to populate the initial admission priority values in the registry.  OTOH, the rsvp admission priority approach uses a specific rsvp object, is populated from an rsvp-specific p-type, and AFAIK is not implemented anywhere as yet.  Yet this rsvp-specific admission priority approach is now declared the 'generic' admission priority mechanism?
   
  Hopefully you'll also respond to my comments 2 & 4:
   
  2. Presumably the emergency-rsvp admission priority approach is implemented (or planned to be implemented) in real network applications.  It would be nice to reference such implementations, existing or planned, if possible.
   
  4. Section 3.1 (Admission Priority Policy Element) of emergency-rsvp states:
   
    "Adm. Priority (Admission Priority): 8 bits (unsigned) 
   The admission control priority of the flow, in terms of access to 
   network bandwidth in order to provide higher probability of call 
   completion to selected flows. Higher values represent higher  
   Priority. 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-
   PARAM]. In other words, a given value inside the Admission Priority 
   information element defined in the present document, inside the 
   [NSIS-QSPEC] Admission Priority parameter or inside the [DIME-PARAM] 
   Admission Priority parameter, refers to the same Admission Priority."
   
  The text is very unclear as to what it means that admission priority values are encoded 'using the same value' in the 3 different drafts?  Perhaps an example would help, but in any case it should be clarified.  Further, the text should be updated to note that the <rsvp admission priority> field is not directly comparable to the <Y.2171 Admission Priority> field in the qspec draft so as to avoid confusion.
   
  Jerry

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