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

[Francois Le Faucheur IMAP <[e-mail]>]

Hello Jerry,

Thanks for the comments. Some answers below:

On 5 Mar 2008, at 21:04, Gerald Ash wrote:

> All,
>
> Here are some last call comments on draft-ietf-tsvwg-emergency- 
> rsvp-05.
>
> General comments:
>
<clip>

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

Let me try clarify one more time.

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.


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

>
> 5. Sections A.1 and A.2 illustrate how the DSTE Maximum Allocation  
> Model (MAM) and the DSTE Russian Dolls Model (RDM) can be used for  
> support of rsvp admission priority.  http://www.amazon.com/Traffic- 
> Engineering-Optimization-Integrated-Networks/dp/0123706254/  
> presents extensive modeling & simulation analysis/case studies to  
> show how the DSTE maximum allocation with reservation (MAR) model  
> (http://www.ietf.org/rfc/rfc4126.txt?number=4126) performs for ETS/ 
> GETS services and how MAR performance compares very favorably to  
> MAM performance.  It would be appropriate to reference MAR as the  
> third DSTE bandwidth constraints model available for consideration  
> and perhaps also to reference the MAR/MAM performance analysis  
> pertinent to emergency services.

Yes. We will add a reference to MAR.

Francois

>
> Jerry
>
>
> Magnus Westerlund <[e-mail]> wrote:
> This announces the second WG last call on "Resource ReSerVation  
> Protovol
> (RSVP) Extensions for Emergency Services" with the intended status of
> proposed standard:
>
> http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt
>
> This is the second one due to changes and the interaction with  
> documents
> in the NSIS and DIME WG. Please provide any comments on the TSVWG
> mailing list no later than 28th of March. (Yes, it is long but that is
> due to the meeting and that we have several other WG last calls  
> ongoing).
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB | Phone [phone]
> Torshamsgatan 23 | Fax [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nsis
>
>
> Never miss a thing. Make Yahoo your homepage.
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nsis