Re: [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05
Francois Le Faucheur IMAP <flefauch@cisco.com> Thu, 06 March 2008 09:37 UTC
Return-Path: <nsis-bounces@ietf.org>
X-Original-To: ietfarch-nsis-archive@core3.amsl.com
Delivered-To: ietfarch-nsis-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FAD28C878; Thu, 6 Mar 2008 01:37:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.477
X-Spam-Level:
X-Spam-Status: No, score=-100.477 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHimTfI+jrZe; Thu, 6 Mar 2008 01:37:07 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C655E28C489; Thu, 6 Mar 2008 01:37:07 -0800 (PST)
X-Original-To: nsis@core3.amsl.com
Delivered-To: nsis@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12E128C36D; Thu, 6 Mar 2008 01:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLe9Ao3Tn8pG; Thu, 6 Mar 2008 01:37:05 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0A98F3A68CD; Thu, 6 Mar 2008 01:37:03 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.25,455,1199660400"; d="scan'208,217";a="2677997"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2008 10:36:53 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m269arsX004045; Thu, 6 Mar 2008 10:36:53 +0100
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m269anHO002696; Thu, 6 Mar 2008 09:36:53 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 10:36:51 +0100
Received: from [10.0.0.92] ([10.61.65.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 10:36:47 +0100
In-Reply-To: <714233.34555.qm@web63610.mail.re1.yahoo.com>
References: <714233.34555.qm@web63610.mail.re1.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v753)
Message-Id: <508848E3-230B-40F9-8BFD-F10036348387@cisco.com>
From: Francois Le Faucheur IMAP <flefauch@cisco.com>
Date: Thu, 06 Mar 2008 10:36:43 +0100
To: Gerald Ash <gash5107@yahoo.com>
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 06 Mar 2008 09:36:47.0623 (UTC) FILETIME=[9910B170:01C87F6D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16940; t=1204796213; x=1205660213; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20<flefauch@cisco. com> |Subject:=20Re=3A=20[NSIS]=20WG=20last=20call=20on=20draft- ietf-tsvwg-emergency-rsvp-05 |Sender:=20; bh=pflwWxIUUOL59b6d46SxKMvx2MwS8oyZlxUvmEiURYY=; b=ZQmBviOAluPc70p1da7j/sdrcdRoHp+glVO3yDn9d+cjsieujjnUXVMGEh c7fBeNzBBMxZsU0wr41bVEoo/BRdRLZd3TdSO+hLErW5WSRfTt0C0N3+fKuv wVuZ7sFBKz;
Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );
Cc: dime@ietf.org, tsvwg <tsvwg@ietf.org>, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0818987536=="
Sender: nsis-bounces@ietf.org
Errors-To: nsis-bounces@ietf.org
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 <magnus.westerlund@ericsson.com> 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 +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis > > > Never miss a thing. Make Yahoo your homepage. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis
_______________________________________________ nsis mailing list nsis@ietf.org https://www.ietf.org/mailman/listinfo/nsis
- [NSIS] WG last call on draft-ietf-tsvwg-emergency… Magnus Westerlund
- Re: [NSIS] WG last call on draft-ietf-tsvwg-emerg… Gerald Ash
- Re: [NSIS] WG last call on draft-ietf-tsvwg-emerg… Francois Le Faucheur IMAP
- Re: [NSIS] WG last call on draft-ietf-tsvwg-emerg… Gerald Ash
- Re: [NSIS] WG last call on draft-ietf-tsvwg-emerg… ken carlberg
- Re: [NSIS] WG last call on draft-ietf-tsvwg-emerg… Magnus Westerlund
- Re: [NSIS] WG last call on draft-ietf-tsvwg-emerg… Magnus Westerlund
- Re: [NSIS] WG last call on draft-ietf-tsvwg-emerg… Janet P Gunn
- Re: [NSIS] WG last call on draft-ietf-tsvwg-emerg… Roy, Radhika R Dr CTR USA USAMC
- Re: [NSIS] [Dime] WG last call on draft-ietf-tsvw… Francois Le Faucheur IMAP