From tsvwg-bounces@ietf.org Wed Mar 5 12:10:36 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEBFB28C894; Wed, 5 Mar 2008 12:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.089 X-Spam-Level: X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[AWL=1.176, BAYES_00=-2.599, HTML_MESSAGE=1, IP_NOT_FRIENDLY=0.334] 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 4ujic6DIGjVn; Wed, 5 Mar 2008 12:10:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2AB428C897; Wed, 5 Mar 2008 12:08:44 -0800 (PST) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4700B28C75B for ; Wed, 5 Mar 2008 12:08:43 -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 g1bthW99GyPU for ; Wed, 5 Mar 2008 12:08:41 -0800 (PST) Received: from web63610.mail.re1.yahoo.com (web63610.mail.re1.yahoo.com [69.147.97.80]) by core3.amsl.com (Postfix) with SMTP id 1A9EF28C893 for ; Wed, 5 Mar 2008 12:04:33 -0800 (PST) Received: (qmail 35176 invoked by uid 60001); 5 Mar 2008 20:04:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=q3lnlL2kj7Nj1TPmucySl7uoTbDw3oX6JEfOuf0wZsqWENbmdRk3n6BPvKmo2D1PVlVSjSIVKKs1FIRfcruMIq8qndEp+37LK/1BeRq6SxqdRlJXBfvVoTJtTPVgRvKjX3iDSjzkxBj/TbssUCSIHHw8oCYxfzD5cHyFa/bOraU=; X-YMail-OSG: A3jG0iwVM1nRcVlA8B8mbqSUuOESdV7WKR6x.hlt3uUUJ6t2Y6V26sQweSaLpd3qrQ-- Received: from [76.19.255.157] by web63610.mail.re1.yahoo.com via HTTP; Wed, 05 Mar 2008 12:04:22 PST Date: Wed, 5 Mar 2008 12:04:22 -0800 (PST) From: Gerald Ash To: Magnus Westerlund , tsvwg , dime@ietf.org, NSIS In-Reply-To: <47C58EB8.1000203@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1660934183-1204747462=:34555" Content-Transfer-Encoding: 8bit Message-ID: <714233.34555.qm@web63610.mail.re1.yahoo.com> Subject: Re: [Tsvwg] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --0-1660934183-1204747462=:34555 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit All, Here are some last call comments on draft-ietf-tsvwg-emergency-rsvp-05. General comments: 1. The emergency-rsvp approach does not prescribe end-to-end cross-domain consistent treatment of admission priority. As stated in Section 2 (Overview of RSVP extensions and Operations): "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 approach an emergency telecommunications service (ETS, e.g., GETS) 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. This is in sharp contrast to the approach used in practice today for ETS/GETS, where high admission priority is applied end-to-end across domains. One reference as to 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/ (Chapter 9 also presents extensive modeling & simulation analysis/case studies to show how today's end-to-end approach can operate across domains in the Internet). 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. 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. 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 to in the qspec draft. To be consistent with this change, the emergency-rsvp approach should also be renamed (e.g., to ) to distinguish it from , and so that neither approach should be considered a 'generic' approach. Specific comments: 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 field is not directly comparable to the field in the qspec draft so as to avoid confusion. 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. Jerry Magnus Westerlund 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. --0-1660934183-1204747462=:34555 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
All,
 
Here are some last call comments on draft-ietf-tsvwg-emergency-rsvp-05.
 
General comments:
 
1. The emergency-rsvp approach does not prescribe end-to-end cross-domain consistent treatment of admission priority.  As stated in Section 2 (Overview of RSVP extensions and Operations):
 
  "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 approach an emergency telecommunications service (ETS, e.g., GETS) 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. 
 
This is in sharp contrast to the approach used in practice today for ETS/GETS, where high admission priority is applied end-to-end across domains.  One reference as to 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/ (Chapter 9 also presents extensive modeling & simulation analysis/case studies to show how today's end-to-end approach can operate across domains in the Internet).
 
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.
 
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.
 
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.
 
Specific comments:
 
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.
 
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.
 
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. --0-1660934183-1204747462=:34555-- From tsvwg-bounces@ietf.org Thu Mar 6 01:37:10 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD8F28C880; Thu, 6 Mar 2008 01:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=2.087, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] 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 CIdj5F7RB6Dt; Thu, 6 Mar 2008 01:37:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36EF628C84F; Thu, 6 Mar 2008 01:37:08 -0800 (PST) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@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) Content-Type: multipart/alternative; boundary=Apple-Mail-11-1003221028 Message-Id: <508848E3-230B-40F9-8BFD-F10036348387@cisco.com> From: Francois Le Faucheur IMAP Date: Thu, 6 Mar 2008 10:36:43 +0100 To: Gerald Ash 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 |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: Magnus Westerlund , dime@ietf.org, tsvwg , NSIS Subject: Re: [Tsvwg] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-11-1003221028 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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: > > 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 > to in the qspec draft. To be > consistent with this change, the emergency-rsvp approach should > also be renamed (e.g., to ) to distinguish > it from , 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 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 --Apple-Mail-11-1003221028 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hello Jerry,

Thanks = for the comments. Some answers below:

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

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

It would be good to motivate the = rationale for the emergency-rsvp approach and why it makes sense = to=A0*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=A0"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=A0"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=A0would=A0use mechanism A while = others=A0would=A0use 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=A0"elevated = probability of session establishment" .

More generally, I think it = was felt that=A0IETF 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=A0accommodate=A0that.


=A0
3. The admission = priority=A0approach taken in nsis-qspec (= http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) = is=A0consistent with today's practice of providing high admission = priority=A0for ETS/GETS end-to-end=A0across administrative domains.=A0 = It does this by standardizing=A0the admission priority values=A0for the = qspec object in an IANA=A0registry, as specified in=A0Section 7 (IANA = considerations):
=A0
=A0=A0"Admission Priority = Parameter (8 bits):
=A0=A0 The following values are allocated by this = specification:
=A0=A0 0-2: assigned as specified in Section = 6.2.9:
=A0=A0 Admission Priority 0: best-effort priority = flow
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 1: normal priority flow
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 2: high priority flow
=A0=A0 The allocation policies = for further values are as follows:
=A0=A0 3-63: Standards = Action
=A0=A0 64-255: Reserved"
=A0
=
It has been agreed on the=A0nsis list=A0to rename = <Admission Priority> to <Y.2171 Admission Priority> in the = qspec draft.=A0=A0To be consistent with this change, the emergency-rsvp = approach should also=A0be renamed (e.g.,=A0to=A0<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).

=A0
=
5.=A0Sections A.1 and A.2=A0illustrate how the DSTE = Maximum=A0Allocation Model (MAM)=A0and the DSTE Russian Dolls Model = (RDM)=A0can be used for support of rsvp admission priority.=A0 http://www.amazon.com/Traffic-Engineering-Optimization-I= ntegrated-Networks/dp/0123706254/=A0presents extensive = modeling & simulation analysis/case studies=A0to show how the DSTE = maximum allocation with reservation (MAR) model (http://www.ietf= .org/rfc/rfc4126.txt?number=3D4126) performs=A0for ETS/GETS services = and how MAR performance=A0compares very favorably to=A0MAM performance.=A0= It would be appropriate to reference MAR as=A0the third DSTE bandwidth = constraints model available for consideration and=A0perhaps also to = reference the MAR/MAM performance analysis=A0pertinent to=A0emergency = services.

Yes. We will add a = reference to MAR.

Francois

=A0
=
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:

h= ttp://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
=

= --Apple-Mail-11-1003221028-- From tsvwg-bounces@ietf.org Thu Mar 6 08:57:47 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B2028C939; Thu, 6 Mar 2008 08:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_00=-2.599, HTML_MESSAGE=1, IP_NOT_FRIENDLY=0.334] 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 rf6okd70qBAh; Thu, 6 Mar 2008 08:57:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AC0528C92D; Thu, 6 Mar 2008 08:57:47 -0800 (PST) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0839D28C932 for ; Thu, 6 Mar 2008 08:57:46 -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 sDTew03H8Xgs for ; Thu, 6 Mar 2008 08:57:41 -0800 (PST) Received: from web63606.mail.re1.yahoo.com (web63606.mail.re1.yahoo.com [69.147.97.76]) by core3.amsl.com (Postfix) with SMTP id 9B58928C913 for ; Thu, 6 Mar 2008 08:57:40 -0800 (PST) Received: (qmail 387 invoked by uid 60001); 6 Mar 2008 16:57:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=qxDszBdfUdDqhaNZOxkjnko/y4w//F61DAipizn8gpugVZyQ1HAfmFJC8P5W0U0mDxasqrXtZvg7369rLCW2tDa6zMfKx6hHJkCSjkz+zDFzkp2rSu6bpRZwgImUbw8VFgO634u7+b2Hqw0JZo+5/moaIGYRRn7zMPg36tPgcvc=; X-YMail-OSG: r4k4Nl4VM1lTGyoUe.J_zIziXtIlIBIJ6mWJrxT4IaZKLvsK.gcHKcj14DR9S24DoXhldcIkHlqyEc0QSpPlFJsWQQ-- Received: from [76.19.255.157] by web63606.mail.re1.yahoo.com via HTTP; Thu, 06 Mar 2008 08:57:29 PST Date: Thu, 6 Mar 2008 08:57:29 -0800 (PST) From: Gerald Ash To: Francois Le Faucheur IMAP , tsvwg , dime@ietf.org, NSIS In-Reply-To: <508848E3-230B-40F9-8BFD-F10036348387@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-883187126-1204822649=:320" Content-Transfer-Encoding: 8bit Message-ID: <940378.320.qm@web63606.mail.re1.yahoo.com> Cc: Magnus Westerlund Subject: Re: [Tsvwg] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --0-883187126-1204822649=:320 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 to >> in the qspec draft. To be consistent with this >> change, the emergency-rsvp approach should also be renamed (e.g., to > Admission Priority>) to distinguish it from , 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 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 field is not directly comparable to the field in the qspec draft so as to avoid confusion. Jerry --------------------------------- Never miss a thing. Make Yahoo your homepage. --0-883187126-1204822649=:320 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
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. --0-883187126-1204822649=:320-- From tsvwg-bounces@ietf.org Fri Mar 7 08:04:54 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E140C28C5E2; Fri, 7 Mar 2008 08:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.238 X-Spam-Level: * X-Spam-Status: No, score=1.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_BAD_ID=2.837] 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 66yH8-HENlnN; Fri, 7 Mar 2008 08:04:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D3628C75B; Fri, 7 Mar 2008 08:04:51 -0800 (PST) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B66028C614; Fri, 7 Mar 2008 08:04:50 -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 WkB-KvVGHbhP; Fri, 7 Mar 2008 08:04:44 -0800 (PST) Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by core3.amsl.com (Postfix) with ESMTP id EFD2E3A6A17; Fri, 7 Mar 2008 08:03:39 -0800 (PST) Received: from emss01g01.ems.lmco.com (relay1.ems.lmco.com [137.249.139.141])by mailgw2a.lmco.com (LM-6) with ESMTP id m27G3R9m007519; Fri, 7 Mar 2008 11:03:27 -0500 (EST) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.3-x14 #31428) id <0JXD00501B9RO5@lmco.com>; Fri, 07 Mar 2008 08:03:27 -0800 (PST) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.3-x14 #31428) with ESMTP id <0JXD00DBDB9MPV@lmco.com>; Fri, 07 Mar 2008 08:03:22 -0800 (PST) Received: from emss09m07.us.lmco.com ([158.183.26.40]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 07 Mar 2008 11:03:22 -0500 Date: Fri, 07 Mar 2008 11:03:18 -0500 From: "Yegenoglu, Ferit" To: l3vpn@ietf.org, tsvwg@ietf.org Message-id: <79E4059BC98EAF48BBE42FCF392DAA520B10C24C@emss09m07.us.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="Boundary_(ID_CFt2mUPv4xRg6zYGoXFPxA)" Thread-Topic: Comments on draft-davie-tsvwg-rsvp-l3vpn-02 Thread-Index: AciAbME21/Ikm7jcSvuBzX/NXv4xmw== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Mar 2008 16:03:22.0186 (UTC) FILETIME=[C483E2A0:01C8806C] Subject: [Tsvwg] Comments on draft-davie-tsvwg-rsvp-l3vpn-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_CFt2mUPv4xRg6zYGoXFPxA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Bruce, Francois, and Ashok, I have a few comments on your draft: 1) Section 3.2, "The router...............determines the local VRF context by finding a matching VPN-IPv4 prefix with the specified RD that has been advertised by this router into BGP" - Can you clarify how the local VRF context is determined? Can the VRF context be determined directly from the RD or does the router search through advertised routes as described in the above sentence? 2) Section 3.3, "The Resv message is sent to the IP address contained within the RSVP_HOP object in the Path message." - I believe you mean the RSVP_HOP object in the Path state (not message). Note that you can actually delete this sentence (it is a repeat). 3) Section 5.2.2, paragraph starting with "When the upstream RSVP hop sends a Path message....." a. It is worth clarifying that just as there are upstream and downstream RSVP hops, there are upstream and downstream ASBRs in the description of how the Path messages are processed. b. The first Path message is processed by the ASBRs thus creating Path state; Resv messages and all subsequent Path messages are only processed by the upstream and downstream RSVP hops, causing eventually the ASBR Path state to expire. It may help to clearly state this in the paragraph. Also, are there any issues with this, i.e. the processing of the first Path message of all end-to-end reservations at the ASBRs? Regards, Ferit --Boundary_(ID_CFt2mUPv4xRg6zYGoXFPxA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Bruce, Francois, and Ashok,

 

I have a few comments on your draft:

 

1)      Section 3.2, “The router……………determines the local VRF context by finding a matching VPN-IPv4 prefix with the specified RD that has been advertised by this router into BGP”

- Can you clarify how the local VRF context is determined? Can the VRF context be determined directly from the RD or does the router search through advertised routes as described in the above sentence?

2)      Section 3.3, “The Resv message is sent to the IP address contained within the RSVP_HOP object in the Path message.”

- I believe you mean the RSVP_HOP object in the Path state (not message). Note that you can actually delete this sentence (it is a repeat).

3)      Section 5.2.2, paragraph starting with “When the upstream RSVP hop sends a Path message…..”

a.       It is worth clarifying that just as there are upstream and downstream RSVP hops, there are upstream and downstream ASBRs in the description of how the Path messages are processed.

b.       The first Path message is processed by the ASBRs thus creating Path state; Resv messages and all subsequent Path messages are only processed by the upstream and downstream RSVP hops, causing eventually the ASBR Path state to expire. It may help to clearly state this in the paragraph. Also, are there any issues with this, i.e. the processing of the first Path message of all end-to-end reservations at the ASBRs?

 

Regards,

Ferit

 

 

--Boundary_(ID_CFt2mUPv4xRg6zYGoXFPxA)-- From tsvwg-bounces@ietf.org Fri Mar 7 09:55:06 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C868328C566; Fri, 7 Mar 2008 09:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=1.239, BAYES_00=-2.599] 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 4ghLAvtQ4UTy; Fri, 7 Mar 2008 09:55:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F9728C4C7; Fri, 7 Mar 2008 09:55:05 -0800 (PST) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03AF3A69EE for ; Fri, 7 Mar 2008 09:55:02 -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 A1Ls9iAfCB1B for ; Fri, 7 Mar 2008 09:55:01 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 616A728C2E1 for ; Fri, 7 Mar 2008 09:55:01 -0800 (PST) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA05.westchester.pa.mail.comcast.net with comcast id yFfD1Y02x1GhbT85504F00; Fri, 07 Mar 2008 17:53:58 +0000 Received: from [192.168.1.120] ([69.255.66.123]) by OMTA07.westchester.pa.mail.comcast.net with comcast id yHum1Y0092fa1BZ3T00000; Fri, 07 Mar 2008 17:54:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=jiV82iFEX0Ru32177tkA:9 a=QDO9ycTJraVqsBOQFcgoKSnIdNYA:4 a=M3PvEdNFSBYA:10 Message-Id: From: ken carlberg To: Gerald Ash In-Reply-To: <940378.320.qm@web63606.mail.re1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 7 Mar 2008 12:54:46 -0500 References: <940378.320.qm@web63606.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.919.2) Cc: dime@ietf.org, tsvwg , NSIS Subject: Re: [Tsvwg] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org > Let me make sure I have this straight. In the NSIS discussion you > insist that we change the name to 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? yes > Hopefully you'll also respond to my comments 2 & 4: I'm not speaking for Francois, but I would ask that if you are pointingly asking for responses, then please display the same courtesy and respond to at the questions sent to you previously on this thread. if you choose not to, fine, but let's not make this one way street. > 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. implementations and deployments in the context you speak of are a rat hole. I'm under several non-disclosure agreements on this general topic, and I can imagine that Francois is under similar constraints with respect to his customers. You should be aware of this kind of bind. But, if you are not under the same constraints, I'd be happy to openly hear of specific vendor/operator deployments you are aware of. Otherwise, let's drop this specific sub-thread. > 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 > field is not directly comparable to the 2171 Admission Priority> field in the qspec draft so as to avoid > confusion. The above cited text clearly needs to be re-written depending on the outcome of this thread, so attempts at altering the it before any NEW consensus is agreed on premature at this point. -ken From tsvwg-bounces@ietf.org Fri Mar 7 10:41:33 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C7128C67E; Fri, 7 Mar 2008 10:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XPb2Vdt2zvlF; Fri, 7 Mar 2008 10:41:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD4528C6F1; Fri, 7 Mar 2008 10:41:33 -0800 (PST) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F42928C6F1; Fri, 7 Mar 2008 10:41:31 -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 diNjl79ANQXa; Fri, 7 Mar 2008 10:41:27 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C9C6828C387; Fri, 7 Mar 2008 10:41:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,463,1199682000"; d="scan'208";a="838554" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Mar 2008 13:41:13 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m27IfDPC019432; Fri, 7 Mar 2008 13:41:13 -0500 Received: from [161.44.173.20] (shaqzilla.cisco.com [161.44.173.20]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m27IfCaR017621; Fri, 7 Mar 2008 18:41:13 GMT Message-ID: <47D18C48.3080500@cisco.com> Date: Fri, 07 Mar 2008 13:41:12 -0500 From: Ashok Narayanan User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "Yegenoglu, Ferit" References: <79E4059BC98EAF48BBE42FCF392DAA520B10C24C@emss09m07.us.lmco.com> In-Reply-To: <79E4059BC98EAF48BBE42FCF392DAA520B10C24C@emss09m07.us.lmco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2746; t=1204915273; x=1205779273; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ashokn@cisco.com; z=From:=20Ashok=20Narayanan=20 |Subject:=20Re=3A=20[Tsvwg]=20Comments=20on=20draft-davie-t svwg-rsvp-l3vpn-02 |Sender:=20 |To:=20=22Yegenoglu,=20Ferit=22=20; bh=VwmV1KiW4tjUvyS1T6hmUB8j8q3fQdmM4Avh+wtgvP8=; b=GX3k3ZCv02u4nvcfgF54s2BCeGwwd7kGvvmTFpedoWVne2FQyzatI2OQjU QEO7nVZutoNNKGS7kwHzx/+b13yafScpFFHj40Ncvg3VbP9TFbm+r3hn8Dzf CPfra+iGzb; Authentication-Results: rtp-dkim-2; header.From=ashokn@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: l3vpn@ietf.org, tsvwg@ietf.org Subject: Re: [Tsvwg] Comments on draft-davie-tsvwg-rsvp-l3vpn-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Ferit, Please see inline for ASHOK> Yegenoglu, Ferit wrote: > Hi Bruce, Francois, and Ashok, > > > > I have a few comments on your draft: > > > > 1) Section 3.2, “The router……………determines the local VRF context by > finding a matching VPN-IPv4 prefix with the specified RD that has been > advertised by this router into BGP” > > - Can you clarify how the local VRF context is determined? Can the VRF > context be determined directly from the RD or does the router search > through advertised routes as described in the above sentence? ASHOK> That is an implementation-specific question. Most implementations will allocate a separate RD for each VRF for which routes are being advertised into BGP; so, any such implementation can just look up the VRF from the RD. However, since RFC2547 does not _impose_ this semantic on the RD, depending on the implementation it may have to look up the entire route. > > 2) Section 3.3, “The Resv message is sent to the IP address > contained within the RSVP_HOP object in the Path message.” > > - I believe you mean the RSVP_HOP object in the Path state (not > message). Note that you can actually delete this sentence (it is a repeat). ASHOK> Sure; but I didn't understand the difference between "the RSVP_HOP object in the Path message" and "the RSVP_HOP object in the Path state". > > 3) Section 5.2.2, paragraph starting with “When the upstream RSVP > hop sends a Path message…..” > > a. It is worth clarifying that just as there are upstream and > downstream RSVP hops, there are upstream and downstream ASBRs in the > description of how the Path messages are processed. ASHOK> Sure. > > b. The first Path message is processed by the ASBRs thus creating > Path state; Resv messages and all subsequent Path messages are only > processed by the upstream and downstream RSVP hops, causing eventually > the ASBR Path state to expire. It may help to clearly state this in the > paragraph. Also, are there any issues with this, i.e. the processing of > the first Path message of all end-to-end reservations at the ASBRs? ASHOK> So, in respect to Section 5.2.2, it is not expected that the ASBR will ever create any Path state. Its role is simply to receive and forward the Path message based on the VPN-IPv4 address in the SESSION object. Also, I should point out that the ASBR will have to do this for *every* Path message in the flow, not just the first one. Only if summary refresh (RFC2961) is used, will the ASBR not have to process subsequent refreshes for a flow. I'll add a clarification for this. -Ashok > > > Regards, > > Ferit > > > > > From tsvwg-bounces@ietf.org Fri Mar 7 11:06:24 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20FC28CAD2; Fri, 7 Mar 2008 11:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.738 X-Spam-Level: X-Spam-Status: No, score=0.738 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_BAD_ID=2.837] 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 v1+XvbolJ2ro; Fri, 7 Mar 2008 11:06:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C8428CA94; Fri, 7 Mar 2008 11:05:12 -0800 (PST) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3798828C71A; Fri, 7 Mar 2008 11:05:10 -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 CNc8StbSuq1m; Fri, 7 Mar 2008 11:04:36 -0800 (PST) Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.7]) by core3.amsl.com (Postfix) with ESMTP id F3A3C28CA3A; Fri, 7 Mar 2008 11:03:43 -0800 (PST) Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59])by mailgw3a.lmco.com (LM-6) with ESMTP id m27J3Vrs016715; Fri, 7 Mar 2008 14:03:31 -0500 (EST) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.3-x14 #31428) id <0JXD00A01JLVVH@lmco.com>; Fri, 07 Mar 2008 14:03:31 -0500 (EST) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.3-x14 #31428) with ESMTP id <0JXD00E34JLN9F@lmco.com>; Fri, 07 Mar 2008 14:03:26 -0500 (EST) Received: from emss09m07.us.lmco.com ([158.183.26.40]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 07 Mar 2008 14:03:26 -0500 Date: Fri, 07 Mar 2008 14:03:32 -0500 From: "Yegenoglu, Ferit" In-reply-to: <47D18C48.3080500@cisco.com> To: Ashok Narayanan Message-id: <79E4059BC98EAF48BBE42FCF392DAA520B10C4E6@emss09m07.us.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Tsvwg] Comments on draft-davie-tsvwg-rsvp-l3vpn-02 Thread-Index: AciAgtl0NQhlBX33Q4OUj7ZAlgbWcwAAYJdA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <79E4059BC98EAF48BBE42FCF392DAA520B10C24C@emss09m07.us.lmco.com> <47D18C48.3080500@cisco.com> X-OriginalArrivalTime: 07 Mar 2008 19:03:26.0414 (UTC) FILETIME=[EC563EE0:01C88085] Cc: l3vpn@ietf.org, tsvwg@ietf.org Subject: Re: [Tsvwg] Comments on draft-davie-tsvwg-rsvp-l3vpn-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Thanks Ashok - Please see inline for [FY] for a comment and a question. Ferit -----Original Message----- From: Ashok Narayanan [mailto:ashokn@cisco.com] Sent: Friday, March 07, 2008 1:41 PM To: Yegenoglu, Ferit Cc: l3vpn@ietf.org; tsvwg@ietf.org Subject: Re: [Tsvwg] Comments on draft-davie-tsvwg-rsvp-l3vpn-02 Ferit, Please see inline for ASHOK> Yegenoglu, Ferit wrote: > Hi Bruce, Francois, and Ashok, > > > > I have a few comments on your draft: > > > > 1) Section 3.2, "The router...............determines the local VRF context by > finding a matching VPN-IPv4 prefix with the specified RD that has been > advertised by this router into BGP" > > - Can you clarify how the local VRF context is determined? Can the VRF > context be determined directly from the RD or does the router search > through advertised routes as described in the above sentence? ASHOK> That is an implementation-specific question. Most implementations will allocate a separate RD for each VRF for which routes are being advertised into BGP; so, any such implementation can just look up the VRF from the RD. However, since RFC2547 does not _impose_ this semantic on the RD, depending on the implementation it may have to look up the entire route. [FY>] OK - If this is implementation dependent maybe the above sentence can be removed - it is referring to one way of determining the VRF context. > > 2) Section 3.3, "The Resv message is sent to the IP address > contained within the RSVP_HOP object in the Path message." > > - I believe you mean the RSVP_HOP object in the Path state (not > message). Note that you can actually delete this sentence (it is a repeat). ASHOK> Sure; but I didn't understand the difference between "the RSVP_HOP object in the Path message" and "the RSVP_HOP object in the Path state". > > 3) Section 5.2.2, paragraph starting with "When the upstream RSVP > hop sends a Path message....." > > a. It is worth clarifying that just as there are upstream and > downstream RSVP hops, there are upstream and downstream ASBRs in the > description of how the Path messages are processed. ASHOK> Sure. > > b. The first Path message is processed by the ASBRs thus creating > Path state; Resv messages and all subsequent Path messages are only > processed by the upstream and downstream RSVP hops, causing eventually > the ASBR Path state to expire. It may help to clearly state this in the > paragraph. Also, are there any issues with this, i.e. the processing of > the first Path message of all end-to-end reservations at the ASBRs? ASHOK> So, in respect to Section 5.2.2, it is not expected that the ASBR will ever create any Path state. Its role is simply to receive and forward the Path message based on the VPN-IPv4 address in the SESSION object. Also, I should point out that the ASBR will have to do this for *every* Path message in the flow, not just the first one. Only if summary refresh (RFC2961) is used, will the ASBR not have to process subsequent refreshes for a flow. I'll add a clarification for this. [FY>] After the upstream RSVP hop receives the Resv message, it will have a VPN-IPv4 address for the downstream RSVP hop. Why wouldn't any future Path messages be sent directly to the downstream RSVP hop with a label just like the Resv messages are sent directly to the upstream RSVP hop with a label. -Ashok > > > Regards, > > Ferit > > > > > From tsvwg-bounces@ietf.org Sat Mar 8 06:14:53 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F8328E044; Sat, 8 Mar 2008 06:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.143 X-Spam-Level: X-Spam-Status: No, score=-100.143 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 leylnE9nq6lI; Sat, 8 Mar 2008 06:14:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8907828D172; Sat, 8 Mar 2008 05:32:40 -0800 (PST) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D48928D9C1; Sat, 8 Mar 2008 05:32:38 -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 QZNoVYDI4AWn; Sat, 8 Mar 2008 05:32:32 -0800 (PST) Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.7]) by core3.amsl.com (Postfix) with ESMTP id 2EA743A6C60; Fri, 7 Mar 2008 14:10:15 -0800 (PST) Received: from emss04g01.ems.lmco.com (relay4.ems.lmco.com [166.17.13.122])by mailgw3a.lmco.com (LM-6) with ESMTP id m27M93NI001998; Fri, 7 Mar 2008 17:09:03 -0500 (EST) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.3-x14 #31428) id <0JXD00401S73G2@lmco.com>; Fri, 07 Mar 2008 17:09:03 -0500 (EST) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.3-x14 #31428) with ESMTP id <0JXD00BVYS6YWN@lmco.com>; Fri, 07 Mar 2008 17:08:58 -0500 (EST) Received: from emss09m07.us.lmco.com ([158.183.26.40]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 07 Mar 2008 17:08:58 -0500 Date: Fri, 07 Mar 2008 17:08:36 -0500 From: "Yegenoglu, Ferit" In-reply-to: <47D1B1AC.8040506@cisco.com> To: Ashok Narayanan Message-id: <79E4059BC98EAF48BBE42FCF392DAA520B1A82E9@emss09m07.us.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Tsvwg] Comments on draft-davie-tsvwg-rsvp-l3vpn-02 Thread-Index: AciAmVYsTeG5fKWoRMqolX3xHsHbWgAAQaeA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <79E4059BC98EAF48BBE42FCF392DAA520B10C24C@emss09m07.us.lmco.com> <47D18C48.3080500@cisco.com> <79E4059BC98EAF48BBE42FCF392DAA520B10C4E6@emss09m07.us.lmco.com> <47D1B1AC.8040506@cisco.com> X-OriginalArrivalTime: 07 Mar 2008 22:08:58.0546 (UTC) FILETIME=[D79AC920:01C8809F] Cc: l3vpn@ietf.org, tsvwg@ietf.org Subject: Re: [Tsvwg] Comments on draft-davie-tsvwg-rsvp-l3vpn-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Thanks - see inline. Ferit >> b. The first Path message is processed by the ASBRs thus > creating >> Path state; Resv messages and all subsequent Path messages are only >> processed by the upstream and downstream RSVP hops, causing eventually > >> the ASBR Path state to expire. It may help to clearly state this in > the >> paragraph. Also, are there any issues with this, i.e. the processing > of >> the first Path message of all end-to-end reservations at the ASBRs? > > ASHOK> So, in respect to Section 5.2.2, it is not expected that the ASBR > will > ever create any Path state. Its role is simply to receive and forward > the Path > message based on the VPN-IPv4 address in the SESSION object. Also, I > should > point out that the ASBR will have to do this for *every* Path message in > the > flow, not just the first one. Only if summary refresh (RFC2961) is used, > will > the ASBR not have to process subsequent refreshes for a flow. I'll add a > > clarification for this. > [FY>] After the upstream RSVP hop receives the Resv message, it will > have a VPN-IPv4 address for the downstream RSVP hop. Why wouldn't any > future Path messages be sent directly to the downstream RSVP hop with a > label just like the Resv messages are sent directly to the upstream RSVP > hop with a label. ASHOK2> So this is not how RSVP works in general. Path messages are responsible for route discovery, and can only handle routing changes if they are addressed towards the destination. Consider the case where the destination D is connected to two egress PEs B and C. If the Path is established through B, but then later then internal route changes to C for some reason, by continuously sending the Path _to_ B we would never discover this. Only by sending the Path to _D_ would we discover the routing change (because it would be received by C instead of B). [FY2>] OK - In the intra-AS case the ingress PE is sending the Path message directly to the egress PE, but this is OK since the VRF is checked every time to determine the correct egress PE. In the inter-AS option B case even though the ingress PE has a label to the egress PE (VPN IPv4 PHOP) it has no means to verify that it is still the correct PE, therefore the Path message must be forwarded ingress PE - ASBR - ASBR - egress PE. It may be useful to add this clarification. From tsvwg-bounces@ietf.org Sat Mar 8 06:19:34 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877FE28E3F0; Sat, 8 Mar 2008 06:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 REhE2JtYAbow; Sat, 8 Mar 2008 06:19:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6494E2930E2; Sat, 8 Mar 2008 05:48:53 -0800 (PST) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740FD28E94E for ; Sat, 8 Mar 2008 05:48:51 -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 IjMD6iE8EAGJ for ; Sat, 8 Mar 2008 05:48:49 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id ED2FD294032 for ; Fri, 7 Mar 2008 18:41:13 -0800 (PST) Received: (qmail invoked by alias); 08 Mar 2008 02:41:01 -0000 Received: from 12-198-48-130att-inc.com (EHLO [172.28.172.47]) [12.198.48.130] by mail.gmx.net (mp041) with SMTP; 08 Mar 2008 03:41:01 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19fgIJpgKVfjBHSThPA7yrl4qOeElQP0caz98fhtO b0TtQm68O+0Mr1 Message-ID: <47D1FCB7.1060906@gmx.net> Date: Sat, 08 Mar 2008 04:40:55 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tsvwg IETF list References: <477B8B57.6060006@gmx.net> In-Reply-To: <477B8B57.6060006@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [Tsvwg] Question regarding draft-polk-tsvwg-signaled-domain-id-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Resending Hannes Tschofenig wrote: > Hi James, > Hi Subha, > > I read through your draft > http://tools.ietf.org/wg/tsvwg/draft-polk-tsvwg-signaled-domain-id-00.txt > and wanted to know whether I understood it correctly. > > You propose to store context information (in this case > domain/sub-domain information) along with the reservation and to use > it for the decision making process about what flow to drop (in > addition to already available RFC 3181 information). > > Is this correct? > > Ciao > Hannes > > From tsvwg-bounces@ietf.org Sat Mar 8 06:23:18 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4314E28DF77; Sat, 8 Mar 2008 06:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 JlfbP5cCy8uP; Sat, 8 Mar 2008 06:23:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9EBB28EAD8; Sat, 8 Mar 2008 06:04:52 -0800 (PST) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF0F28DE10; Sat, 8 Mar 2008 06:04:49 -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 OuUzt0rco-Jc; Sat, 8 Mar 2008 06:04:46 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D5B4228DAA8; Fri, 7 Mar 2008 13:20:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,464,1199682000"; d="scan'208";a="868766" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Mar 2008 16:20:44 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m27LKiEE005686; Fri, 7 Mar 2008 16:20:44 -0500 Received: from [161.44.173.20] (shaqzilla.cisco.com [161.44.173.20]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m27LKijP003085; Fri, 7 Mar 2008 21:20:44 GMT Message-ID: <47D1B1AC.8040506@cisco.com> Date: Fri, 07 Mar 2008 16:20:44 -0500 From: Ashok Narayanan User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "Yegenoglu, Ferit" References: <79E4059BC98EAF48BBE42FCF392DAA520B10C24C@emss09m07.us.lmco.com> <47D18C48.3080500@cisco.com> <79E4059BC98EAF48BBE42FCF392DAA520B10C4E6@emss09m07.us.lmco.com> In-Reply-To: <79E4059BC98EAF48BBE42FCF392DAA520B10C4E6@emss09m07.us.lmco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3882; t=1204924844; x=1205788844; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ashokn@cisco.com; z=From:=20Ashok=20Narayanan=20 |Subject:=20Re=3A=20[Tsvwg]=20Comments=20on=20draft-davie-t svwg-rsvp-l3vpn-02 |Sender:=20 |To:=20=22Yegenoglu,=20Ferit=22=20; bh=90o7CR/BYz4DnquE5mxmoY+vlTlMYVaeMWwbKJ1oi2c=; b=S01OinUKBtlhyPa16X7DSvbne2chyD0e2qT4eiXiwXOtQlLIAn8URafWAf V9mNyDY2/x4Bqc16jU623HS70CiTpG5Uw/U8+QCfzRCzzljiU3NTLyb3edZd PZKINTtCnn; Authentication-Results: rtp-dkim-2; header.From=ashokn@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: l3vpn@ietf.org, tsvwg@ietf.org Subject: Re: [Tsvwg] Comments on draft-davie-tsvwg-rsvp-l3vpn-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Inline... Yegenoglu, Ferit wrote: > Thanks Ashok - Please see inline for [FY] for a comment and a question. > Ferit > > -----Original Message----- > From: Ashok Narayanan [mailto:ashokn@cisco.com] > Sent: Friday, March 07, 2008 1:41 PM > To: Yegenoglu, Ferit > Cc: l3vpn@ietf.org; tsvwg@ietf.org > Subject: Re: [Tsvwg] Comments on draft-davie-tsvwg-rsvp-l3vpn-02 > > Ferit, > > Please see inline for ASHOK> > > Yegenoglu, Ferit wrote: >> Hi Bruce, Francois, and Ashok, >> >> >> >> I have a few comments on your draft: >> >> >> >> 1) Section 3.2, "The router...............determines the local > VRF context by >> finding a matching VPN-IPv4 prefix with the specified RD that has been > >> advertised by this router into BGP" >> >> - Can you clarify how the local VRF context is determined? Can the VRF > >> context be determined directly from the RD or does the router search >> through advertised routes as described in the above sentence? > > ASHOK> That is an implementation-specific question. Most implementations > will > allocate a separate RD for each VRF for which routes are being > advertised into > BGP; so, any such implementation can just look up the VRF from the RD. > However, > since RFC2547 does not _impose_ this semantic on the RD, depending on > the > implementation it may have to look up the entire route. > [FY>] OK - If this is implementation dependent maybe the above sentence > can be removed - it is referring to one way of determining the VRF > context. ASHOK2> What I would like to say is that the local VRF is determined from the RD and prefix advertised in BGP; this is part of the protocol. The implementation-specific part is specifically _how_ it is determined; whether simply using the RD is sufficient or whether a route lookup is required. I'll try to tighten up the text a little. >> b. The first Path message is processed by the ASBRs thus > creating >> Path state; Resv messages and all subsequent Path messages are only >> processed by the upstream and downstream RSVP hops, causing eventually > >> the ASBR Path state to expire. It may help to clearly state this in > the >> paragraph. Also, are there any issues with this, i.e. the processing > of >> the first Path message of all end-to-end reservations at the ASBRs? > > ASHOK> So, in respect to Section 5.2.2, it is not expected that the ASBR > will > ever create any Path state. Its role is simply to receive and forward > the Path > message based on the VPN-IPv4 address in the SESSION object. Also, I > should > point out that the ASBR will have to do this for *every* Path message in > the > flow, not just the first one. Only if summary refresh (RFC2961) is used, > will > the ASBR not have to process subsequent refreshes for a flow. I'll add a > > clarification for this. > [FY>] After the upstream RSVP hop receives the Resv message, it will > have a VPN-IPv4 address for the downstream RSVP hop. Why wouldn't any > future Path messages be sent directly to the downstream RSVP hop with a > label just like the Resv messages are sent directly to the upstream RSVP > hop with a label. ASHOK2> So this is not how RSVP works in general. Path messages are responsible for route discovery, and can only handle routing changes if they are addressed towards the destination. Consider the case where the destination D is connected to two egress PEs B and C. If the Path is established through B, but then later then internal route changes to C for some reason, by continuously sending the Path _to_ B we would never discover this. Only by sending the Path to _D_ would we discover the routing change (because it would be received by C instead of B). -Ashok > -Ashok > >> >> >> Regards, >> >> Ferit >> >> >> >> >> > From tsvwg-bounces@ietf.org Sun Mar 9 08:05:57 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE1D3A68A8; Sun, 9 Mar 2008 08:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] 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 kMyfAGp11whq; Sun, 9 Mar 2008 08:05:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DCCF3A6926; Sun, 9 Mar 2008 08:05:57 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979433A6926 for ; Sun, 9 Mar 2008 08:05:55 -0700 (PDT) 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 rmcwNClFWhip for ; Sun, 9 Mar 2008 08:05:49 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 698CB3A68A8 for ; Sun, 9 Mar 2008 08:05:49 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Mar 2008 15:03:27 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Mar 2008 15:03:27 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 120507500629; Sun, 9 Mar 2008 15:03:26 +0000 Received: from mut.jungle.bt.co.uk ([10.73.64.103]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m29F38cM017574; Sun, 9 Mar 2008 15:03:22 GMT Message-Id: <200803091503.m29F38cM017574@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 09 Mar 2008 15:03:08 +0000 To: "James M. Polk" From: Bob Briscoe In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 09 Mar 2008 15:03:27.0164 (UTC) FILETIME=[BA8A8FC0:01C881F6] Cc: tsvwg Subject: [Tsvwg] Slides for tsvwg tomorrow X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org James & list, Here's my slides for tsvwg w-g mtg tomorrow afternoon: Or links to all the background stuff (.ppt, .pdf, draft, diffs etc) via: Cheers Bob At 16:09 27/02/2008, James M. Polk wrote: >Here is the link to our draft agenda >http://www.ietf.org/proceedings/08mar/agenda/tsvwg.txt /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >* Bob's - Byte and Packet Congestion Notification (10 min) > draft-briscoe-tsvwg-byte-pkt-mark-02.txt /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Mon Mar 10 07:51:51 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F3228E3AD; Mon, 10 Mar 2008 07:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.94 X-Spam-Level: X-Spam-Status: No, score=-99.94 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 KblUzfZHrUxm; Mon, 10 Mar 2008 07:51:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4129628D07D; Mon, 10 Mar 2008 07:24:48 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA75828CBF2 for ; Mon, 10 Mar 2008 07:24:46 -0700 (PDT) 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 8U9UV+9Jvbl6 for ; Mon, 10 Mar 2008 07:24:45 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (unknown [IPv6:2001:200:0:8803::53]) by core3.amsl.com (Postfix) with ESMTP id B91EC28DF94 for ; Mon, 10 Mar 2008 02:04:35 -0700 (PDT) Received: from Michio-Hondas-MacBook-Pro.local (unknown [63.133.180.130]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 5C2214C5D0 for ; Mon, 10 Mar 2008 18:02:07 +0900 (JST) Message-ID: <47D4F908.2050308@sfc.wide.ad.jp> Date: Mon, 10 Mar 2008 05:02:00 -0400 From: Michio HONDA User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Evaluation of draft-micchie-tsvwg-fastmsctp-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, I'll present draft-micchie-tsvwg-fastmsctp-01 today's TSVWG meeting, which is about a new retransmission trigger for SCTP mobility. Although the evaluation appears in a paper to be published in June, I place it at http://www.ht.sfc.keio.ac.jp/~micchie/pub/ICDCS08/icdcs08.pdf In order to see the efficiency of this draft, please read Section 4 of this paper. Best regards -- Michio Honda E-mail: micchie@sfc.wide.ad.jp, micchie@ht.sfc.keio.ac.jp Website: http://www.micchie.net/ From tsvwg-bounces@ietf.org Mon Mar 10 12:09:56 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D887A3A6DD4; Mon, 10 Mar 2008 12:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 N46cDf5fXgEM; Mon, 10 Mar 2008 12:09:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A473A6D4E; Mon, 10 Mar 2008 12:09:36 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7E23A6BDF for ; Mon, 10 Mar 2008 12:09:35 -0700 (PDT) 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 AOLgwaR0cjUL for ; Mon, 10 Mar 2008 12:09:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 48ED23A6C91 for ; Mon, 10 Mar 2008 12:07:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,475,1199682000"; d="scan'208";a="1213313" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Mar 2008 15:05:34 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2AJ5ZtX025910 for ; Mon, 10 Mar 2008 15:05:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2AJ5Yjb019074 for ; Mon, 10 Mar 2008 19:05:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 15:05:34 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.102]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 15:05:34 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 13:04:07 -0500 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 10 Mar 2008 19:05:34.0677 (UTC) FILETIME=[B806E050:01C882E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=532; t=1205175935; x=1206039935; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Confirming=20TSVWG=20Hum=20(IANA=20Allocation=2 0Guidelines=20ID) |Sender:=20 |To:=20tsvwg=20; bh=4k9/zlqp7pPVMUJhv3c59zIFqmI9KMK+Zwqa1NY8EZw=; b=CTI25yVgwiI2epvYMB2jPUAhKhJPUZMOr9kQ/PICG5CV7U6Y0QJfXy17R3 wNeFfikg6qdh56pT+ryevC9WjDF6b8RI/KAJ6C9PWMp8r5GBqCBYxFMekC57 JxMrfxj68l; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Tsvwg] Confirming TSVWG Hum (IANA Allocation Guidelines ID) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org TSVWG Today, TSVWG heard from Michelle Cotton on the Internet Draft "IANA Allocation Guidelines for TCP and UDP Port Numbers (draft-cotton-tsvwg-iana-ports-00). This document seems clearly tasked for TSVWG. The WG took a hum to adopt this ID as a TSVWG WG item. The room had 100% hum for, 0% hum against, making this ID a WG item. Comments in support of, and to the contrary to, this hum are encouraged on the WG list before the WG chairs decide to have the next revision be a WG item. James TSVWG co-chair From tsvwg-bounces@ietf.org Tue Mar 11 05:06:01 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1433A6DC7; Tue, 11 Mar 2008 05:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 m7ov-xXwuR+g; Tue, 11 Mar 2008 05:06:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025CD28C19F; Tue, 11 Mar 2008 05:06:00 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FD63A6D58 for ; Tue, 11 Mar 2008 05:05:59 -0700 (PDT) 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 NLwwAEEUQ6X7 for ; Tue, 11 Mar 2008 05:05:58 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 67B073A6DA0 for ; Tue, 11 Mar 2008 05:05:58 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 11 Mar 2008 05:03:39 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2BC3doZ005091 for ; Tue, 11 Mar 2008 05:03:39 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2BC3cLh007710 for ; Tue, 11 Mar 2008 12:03:38 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 05:03:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Mar 2008 05:03:14 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804D37758@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] Confirming TSVWG Hum (IANA Allocation Guidelines ID) Thread-Index: AciC4lY8APwdQ2qtRjeamFDWscvkKAAiFn9Q References: From: "Anantha Ramaiah (ananth)" To: "tsvwg" X-OriginalArrivalTime: 11 Mar 2008 12:03:38.0617 (UTC) FILETIME=[F0E46E90:01C8836F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1337; t=1205237019; x=1206101019; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[Tsvwg]=20Confirming=20TSVWG=20Hum=20(I ANA=20Allocation=20Guidelines=20ID) |Sender:=20; bh=wT+whgXLN9ZrHCAlqFrjYnGgCygRt8f/VJT4KRmkpm4=; b=KKkhjNRgV04PWB6uERYRjK4eq1dNpB+mZw5fZsIfLLxhhhH7FG3jbP9MaD MiutQOX0Pe6ZXuTQpdw3pjeQkko4Q+x46qa5NnF1usYPtfqLnlA89/oB8S05 I2urs+y42R; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Tsvwg] Confirming TSVWG Hum (IANA Allocation Guidelines ID) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org I gave this document a quick read and have the following comment.=20 - Should the title of the document be something like "IANA Allocation Guidelines for transport protocols" ?. After all the intention is to have consistent mechanism (and therefore a single document) for all transport port allocation requests which the introduction section of the document already mentions ? Just to be clear, I do support this document as a WG item. Thanks, -Anantha > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org]=20 > On Behalf Of James Polk (jmpolk) > Sent: Monday, March 10, 2008 11:04 AM > To: tsvwg > Subject: [Tsvwg] Confirming TSVWG Hum (IANA Allocation Guidelines ID) >=20 > TSVWG >=20 > Today, TSVWG heard from Michelle Cotton on the Internet Draft=20 > "IANA Allocation Guidelines for TCP and UDP Port Numbers=20 > (draft-cotton-tsvwg-iana-ports-00). This document seems=20 > clearly tasked for TSVWG. The WG took a hum to adopt this ID=20 > as a TSVWG WG item. >=20 > The room had 100% hum for, 0% hum against, making this ID a WG item. >=20 > Comments in support of, and to the contrary to, this hum are=20 > encouraged on the WG list before the WG chairs decide to have=20 > the next revision be a WG item. >=20 > James > TSVWG co-chair >=20 >=20 From tsvwg-bounces@ietf.org Tue Mar 11 07:08:04 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030D128C351; Tue, 11 Mar 2008 07:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 Vxk2gkY8i5kB; Tue, 11 Mar 2008 07:08:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29CB13A68E6; Tue, 11 Mar 2008 07:07:59 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E21328C3AB for ; Tue, 11 Mar 2008 07:07:53 -0700 (PDT) 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 P2QFsuBxiJqL for ; Tue, 11 Mar 2008 07:07:52 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by core3.amsl.com (Postfix) with ESMTP id 91A933A6DBF for ; Tue, 11 Mar 2008 07:07:08 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id c10so8228150nfd.39 for ; Tue, 11 Mar 2008 07:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=CD2AdgZRTrqaP49UQZmCxLrfNN3k7FFol1JNoEjYLDk=; b=MTsH7L6l4Hrujklab+BMQr9RHGbxkFzmqhkO/zuc82YxTqwitY6X0HfuTzP0/IIIS29x6eeGseu954HfavZtsh2nzNmVJw4V9wZxfDoIyrwTQ3gE9UaRTwfQeFp8+nCpHNeREu1y/dfAaJJ3ZaBO6rADs2kltYR0aibc9efAMls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=eXIvBx0k1Z3PaWGN1LPNnghOXOXquVkKz64NMryHM2RI4sjNIIB5TR4aqv3cbjUCIWU5hkZwpI4xCr5eWntJ8zKvAkT4oTcmilsitn+wsa4qWGIBHuogv1so/OvLIRhQOuzcyhQ9N2Al0/I+M5bdCgCKNAnG5kRUigCVNgtu7wk= Received: by 10.78.131.8 with SMTP id e8mr17910980hud.35.1205244287111; Tue, 11 Mar 2008 07:04:47 -0700 (PDT) Received: from dhcp-1413.ietf71.ietf.org ( [130.129.20.19]) by mx.google.com with ESMTPS id 37sm99176hub.4.2008.03.11.07.04.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Mar 2008 07:04:45 -0700 (PDT) Message-Id: <6D6F2702-DDDD-4CA1-A2DC-58EE691810ED@nokia.com> From: Lars Eggert To: tsvwg WG In-Reply-To: <2440B5C5-28BF-4A20-9357-0EC2FE88D2F8@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 11 Mar 2008 10:04:42 -0400 References: <20080225202613.E81B028C45B@core3.amsl.com> <2440B5C5-28BF-4A20-9357-0EC2FE88D2F8@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: draft-davie-tsvwg-rsvp-l3vpn@tools.ietf.org Subject: [Tsvwg] L3VPN feedback on draft-davie-tsvwg-rsvp-l3vpn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, FYI, after Bruce presented draft-davie-tsvwg-rsvp-l3vpn in L3VPN, I asked the L3VPN chairs to do a hum on whether the WG agreed that he presented solution was the one that they would like to see go forward in this space. The hum established that (at least in the room) there was strong consensus for that. Lars From tsvwg-bounces@ietf.org Tue Mar 11 08:12:55 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB8F3A6DFC; Tue, 11 Mar 2008 08:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=1.004, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 CqkxsOAVz4-A; Tue, 11 Mar 2008 08:12:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599863A6ACC; Tue, 11 Mar 2008 08:12:55 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175583A67B2 for ; Tue, 11 Mar 2008 08:12:52 -0700 (PDT) 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 gAOWs5e4pOxg for ; Tue, 11 Mar 2008 08:12:49 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AE7F13A6E1F for ; Tue, 11 Mar 2008 08:12:45 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F0B1420135; Tue, 11 Mar 2008 16:10:24 +0100 (CET) X-AuditID: c1b4fb3e-ab192bb000004ec0-f8-47d6a0e0b804 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E1099200DD; Tue, 11 Mar 2008 16:10:24 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 16:10:24 +0100 Received: from [127.0.0.1] ([153.88.21.66]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 16:10:23 +0100 Message-ID: <47D6A0D9.7080605@ericsson.com> Date: Tue, 11 Mar 2008 11:10:17 -0400 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC5804D37758@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5804D37758@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2008 15:10:23.0801 (UTC) FILETIME=[07B3D290:01C8838A] X-Brightmail-Tracker: AAAAAA== Cc: tsvwg Subject: Re: [Tsvwg] Confirming TSVWG Hum (IANA Allocation Guidelines ID) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Anantha Ramaiah (ananth) skrev: > I gave this document a quick read and have the following comment. > > - Should the title of the document be something like "IANA Allocation > Guidelines for transport protocols" ?. After all the intention is to > have consistent mechanism (and therefore a single document) for all > transport port allocation requests which the introduction section of the > document already mentions ? > Probably not, there is a good reason to have this focus on TCP and UDP. There currently are a document in DCCP that is working on updating the DCCP rules, including the complexities of service codes (draft-ietf-dccp-serv-codes). However, SCTP will also need some updates in the end. But it is TCP and UDP that are the critical. 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Thu Mar 13 00:00:46 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFFE28C749; Thu, 13 Mar 2008 00:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[AWL=1.391, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] 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 iA3GcaYGsTmu; Thu, 13 Mar 2008 00:00:45 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6346B28C631; Thu, 13 Mar 2008 00:00:45 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58FA128C5BA for ; Thu, 13 Mar 2008 00:00:44 -0700 (PDT) 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 2g6CRKi+9Jv3 for ; Thu, 13 Mar 2008 00:00:38 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 09A7828C631 for ; Thu, 13 Mar 2008 00:00:37 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 06:58:18 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 06:58:18 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205391497564; Thu, 13 Mar 2008 06:58:17 +0000 Received: from mut.jungle.bt.co.uk ([10.73.0.217]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2D6vwLk007462; Thu, 13 Mar 2008 06:58:16 GMT Message-Id: <200803130658.m2D6vwLk007462@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Mar 2008 06:56:53 +0000 To: Fred Baker From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 13 Mar 2008 06:58:18.0839 (UTC) FILETIME=[9E47A670:01C884D7] Cc: tsvwg IETF list Subject: [Tsvwg] Fwd: voice & video DSCPs? draft-ietf-tsvwg-admitted-realtime-dscp-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Fred, I've just re-read -03 of this, and will post review comments to list tomorrow. Below is re-send of commetns on -00 from a year ago, which still apply. Bob >Date: Wed, 21 Mar 2007 09:49:10 +0000 >To: Fred Baker >From: Bob Briscoe >Subject: voice & video DSCPs? draft-ietf-tsvwg-admitted-realtime-dscp-00.txt > >Fred, > >In the 'hands-up' just now in Prague on whether to assign another EF >DSCP for admitted video, separate from admitted voice, I put up my >hand for both yes and no. > >Here's why. > >Some operators might want to bundle the two together, others not. We >(in research not necessarily as a company) are trying to avoid >app-visibility if not absolutely necessary at the net layer. > >Some folks certainly have requirements to try to hide emergency >traffic in the data plane, which of course is do-able because the >precedence can be done in the control plane. They don't want to tag >packets with "Hey, I'm probably critical to the smooth running of >the Government, and I'm not hiding in a crowd of other stuff". > >Background is that from our simulations a couple of years ago, we >are perfectly happy with mixing audio and video (in terms of >queueing behaviour) where's there's high aggregation. In fact, the >more muxing the better when links are so fast that delay isn't a >concern. So we don't /need/ two DSCPs. Therefore, by the argument >above we may well not /want/ to identify the two as different, even >if it's only for SLAs or something. But we do /need/ a DSCP to >isolate or prioritise admitted traffic over non-admitted. > >So here's a proposal: >- two DSCPs from IANA for EF-admit-voice and EF-admit-video >- of which an operator can choose to use one (probably the voice >one) as just EF-admit-* if they want > >Is that feasible? Or have I missed the point? > > >Bob > > >____________________________________________________________________________ >Notice: This contribution is the personal view of the author and >does not necessarily reflect the technical nor commercial direction of BT plc. >____________________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Thu Mar 13 05:14:44 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F21328C7A5; Thu, 13 Mar 2008 05:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] 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 blmbMfwk3HbV; Thu, 13 Mar 2008 05:14:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4FE13A6A95; Thu, 13 Mar 2008 05:14:43 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBD528C766; Thu, 13 Mar 2008 05:14:42 -0700 (PDT) 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 8NLkBIa1F+tU; Thu, 13 Mar 2008 05:14:41 -0700 (PDT) Received: from mail200.messagelabs.com (mail200.messagelabs.com [216.82.254.195]) by core3.amsl.com (Postfix) with ESMTP id 9040028C6D8; Thu, 13 Mar 2008 05:14:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-200.messagelabs.com!1205410338!4428214!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 10564 invoked from network); 13 Mar 2008 12:12:19 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-10.tower-200.messagelabs.com with AES256-SHA encrypted SMTP; 13 Mar 2008 12:12:19 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id m2DCFeIJ008276; Thu, 13 Mar 2008 08:15:40 -0400 In-Reply-To: <200803130658.m2D6vwLk007462@bagheera.jungle.bt.co.uk> To: Bob Briscoe MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 13 Mar 2008 08:12:14 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 03/13/2008 08:15:32 AM, Serialize complete at 03/13/2008 08:15:32 AM Content-Type: multipart/alternative; boundary="=_alternative 0043073E8525740B_=" Cc: tsvwg-bounces@ietf.org, Fred Baker , tsvwg IETF list Subject: Re: [Tsvwg] Fwd: voice & video DSCPs? draft-ietf-tsvwg-admitted-realtime-dscp-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org This is a multipart message in MIME format. --=_alternative 0043073E8525740B_= Content-Type: text/plain; charset="US-ASCII" Bob, It probably doesn't change your comments, but the latest version is -04. The major changes (from -03 to -04) I am aware of are that the specific code point has changed, and the draft is now labeled as "standards track". Janet tsvwg-bounces@ietf.org wrote on 03/13/2008 02:56:53 AM: > Fred, > > I've just re-read -03 of this, and will post review comments to listtomorrow. > > Below is re-send of commetns on -00 from a year ago, which still apply. > > > Bob > > > >Date: Wed, 21 Mar 2007 09:49:10 +0000 > >To: Fred Baker > >From: Bob Briscoe > >Subject: voice & video DSCPs? draft-ietf-tsvwg-admitted-realtime-dscp-00.txt > > > >Fred, > > > >In the 'hands-up' just now in Prague on whether to assign another EF > >DSCP for admitted video, separate from admitted voice, I put up my > >hand for both yes and no. > > > >Here's why. > > > >Some operators might want to bundle the two together, others not. We > >(in research not necessarily as a company) are trying to avoid > >app-visibility if not absolutely necessary at the net layer. > > > >Some folks certainly have requirements to try to hide emergency > >traffic in the data plane, which of course is do-able because the > >precedence can be done in the control plane. They don't want to tag > >packets with "Hey, I'm probably critical to the smooth running of > >the Government, and I'm not hiding in a crowd of other stuff". > > > >Background is that from our simulations a couple of years ago, we > >are perfectly happy with mixing audio and video (in terms of > >queueing behaviour) where's there's high aggregation. In fact, the > >more muxing the better when links are so fast that delay isn't a > >concern. So we don't /need/ two DSCPs. Therefore, by the argument > >above we may well not /want/ to identify the two as different, even > >if it's only for SLAs or something. But we do /need/ a DSCP to > >isolate or prioritise admitted traffic over non-admitted. > > > >So here's a proposal: > >- two DSCPs from IANA for EF-admit-voice and EF-admit-video > >- of which an operator can choose to use one (probably the voice > >one) as just EF-admit-* if they want > > > >Is that feasible? Or have I missed the point? > > > > > >Bob > > > > > >____________________________________________________________________________ > >Notice: This contribution is the personal view of the author and > >does not necessarily reflect the technical nor commercial directionof BT plc. > >____________________________________________________________________________ > >Bob Briscoe, Networks Research Centre, BT Research > >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > > ____________________________________________________________________________ > Bob Briscoe, Networks Research Centre, BT Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > > --=_alternative 0043073E8525740B_= Content-Type: text/html; charset="US-ASCII"
Bob,

It probably doesn't change your comments, but the latest version is -04.

The major changes (from -03 to -04) I am aware of  are that the specific code point has changed, and the draft is now labeled as "standards track".

Janet

tsvwg-bounces@ietf.org wrote on 03/13/2008 02:56:53 AM:

> Fred,
>
> I've just re-read -03 of this, and will post review comments to listtomorrow.
>
> Below is re-send of commetns on -00 from a year ago, which still apply.
>
>
> Bob
>
>
> >Date: Wed, 21 Mar 2007 09:49:10 +0000
> >To: Fred Baker <fred@cisco.com>
> >From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
> >Subject: voice & video DSCPs? draft-ietf-tsvwg-admitted-realtime-dscp-00.txt
> >
> >Fred,
> >
> >In the 'hands-up' just now in Prague on whether to assign another EF
> >DSCP for admitted video, separate from admitted voice, I put up my
> >hand for both yes and no.
> >
> >Here's why.
> >
> >Some operators might want to bundle the two together, others not. We
> >(in research not necessarily as a company) are trying to avoid
> >app-visibility if not absolutely necessary at the net layer.
> >
> >Some folks certainly have requirements to try to hide emergency
> >traffic in the data plane, which of course is do-able because the
> >precedence can be done in the control plane. They don't want to tag
> >packets with "Hey, I'm probably critical to the smooth running of
> >the Government, and I'm not hiding in a crowd of other stuff".
> >
> >Background is that from our simulations a couple of years ago, we
> >are perfectly happy with mixing audio and video (in terms of
> >queueing behaviour) where's there's high aggregation. In fact, the
> >more muxing the better when links are so fast that delay isn't a
> >concern. So we don't /need/ two DSCPs. Therefore, by the argument
> >above we may well not /want/ to identify the two as different, even
> >if it's only for SLAs or something. But we do /need/ a DSCP to
> >isolate or prioritise admitted traffic over non-admitted.
> >
> >So here's a proposal:
> >- two DSCPs from IANA for EF-admit-voice and EF-admit-video
> >- of which an operator can choose to use one (probably the voice
> >one) as just EF-admit-* if they want
> >
> >Is that feasible? Or have I missed the point?
> >
> >
> >Bob
> >
> >
> >____________________________________________________________________________
> >Notice: This contribution is the personal view of the author and
> >does not necessarily reflect the technical nor commercial directionof BT plc.
> >____________________________________________________________________________
> >Bob Briscoe,                           Networks Research Centre, BT Research
> >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196
>
> ____________________________________________________________________________
> Bob Briscoe, <bob.briscoe@bt.com>      Networks Research Centre, BT Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196
>
>
--=_alternative 0043073E8525740B_=-- From tsvwg-bounces@ietf.org Thu Mar 13 05:28:20 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA28428C7F0; Thu, 13 Mar 2008 05:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.547 X-Spam-Level: X-Spam-Status: No, score=-4.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, GB_OPRAH=2, RCVD_IN_DNSWL_MED=-4] 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 5dOQbXSMfxFX; Thu, 13 Mar 2008 05:28:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD6B28C734; Thu, 13 Mar 2008 05:28:17 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8E228C6E9 for ; Thu, 13 Mar 2008 05:28:15 -0700 (PDT) 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 2gP32f62aVEW for ; Thu, 13 Mar 2008 05:28:14 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2CDF928C734 for ; Thu, 13 Mar 2008 05:28:10 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 13 Mar 2008 05:25:52 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2DCPqic031733; Thu, 13 Mar 2008 05:25:52 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m2DCPVdq028863; Thu, 13 Mar 2008 12:25:32 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 05:25:31 -0700 Received: from [10.150.132.106] ([10.21.87.132]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 05:25:30 -0700 In-Reply-To: <200803130658.m2D6vwLj007462@bagheera.jungle.bt.co.uk> References: <200803120435.m2C4ZSCk000330@bagheera.jungle.bt.co.uk> <98EAA9EF-5BCC-4737-82B0-EFE42D91A945@cisco.com> <200803130658.m2D6vwLj007462@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v753) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 13 Mar 2008 08:25:29 -0400 To: Bob Briscoe X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 13 Mar 2008 12:25:30.0953 (UTC) FILETIME=[53EE8390:01C88505] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9136; t=1205411152; x=1206275152; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20EF-ADMIT=20&=20PCN=20DSCP(s) |Sender:=20; bh=Oj0vQ1YA5dSB/BCbGqWWP89aWLKqspbWmIRUEbvO404=; b=Bo2JffRlMoHl2OZdz9T8b5RauqZH6SXjtlBculfb7/03JtpYXqpRUb//Do H1zwTyGxu5AMCzvCR9tbKHQT4t+irit9uQPa/A5KYkJN46EeZFvigq0+vCwq 40nkexzEZe; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: tsvwg@ietf.org, Phil EARDLEY , "CHAN, Kwok Ho" Subject: Re: [Tsvwg] EF-ADMIT & PCN DSCP(s) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org oops, resending - I include "tsvwg-chairs" on the CC line instead of "tsvwg". On Mar 13, 2008, at 2:53 AM, Bob Briscoe wrote: > Finally, I just read thru Capacity Admitted Traffic -04. I've got > quite a few comments, so I'll write them up tomorrow and post to > tsvwg. Next mail I'll also re-send the briefer review comments I > sent on it just under a year ago, which didn't seem to get noticed. Hmm. Yes, please send your comments. 2006-2008, I see 18 notes that comment on draft-ietf-tsvwg-admitted- realtime-dscp. Four of them announce the posting of a draft. One is the posting of minutes to a meeting in which a draft was discussed. Two are Magnus' comments of 13 February, addressed in draft -04, and four others are chitchat on 24 Feb pursuant to that. One is Martin Dolly agreeing to a set of changes. Brian Carpenter doesn't understand why we mention rate policing, as it is mentioned in RFC 3246. Janet Gunn would like draft-ietf-tsvwg-emergency-rsvp to refer to this draft (March 28 2007), which Ken Carlberg also commented on. One comment is from Dave McDysan, essentially asking that Video be added to the original Voice considerations. On March 21 March 2007, the email the quoted this morning, you suggested that we go for a second code point for video. > So here's a proposal: > - two DSCPs from IANA for EF-admit-voice and EF-admit-video > - of which an operator can choose to use one (probably the voice > one) as just EF-admit-* if they want > > Is that feasible? Or have I missed the point? This is something we looked at when you originally asked, and wound up deciding (in -03 and -04) to simply apply the considerations to existing video classes in 4594 rather than trying to allocate classes willy-nilly. As to your suggestion of dumping voice and video together in a common class and telling the operator to pick one of two DSCPs depending on admission or non-admission, the matter is discussed in RFCs 4594 and 5127. On gigabit links (the RFC 5127 case, the one PCN is applicable on), fine. On lower speed links (as a rule of thumb, below ten megabit), the interaction between voice and video traffic in the same class is disruptive to voice, and PCN is inapplicable because the process of adding a single data flow of speed at the same order of magnitude as the link rate is disruptive to the existing traffic. Lower speed access links being the primary consideration of RFC 4594 and of draft-ietf-tsvwg-admitted-realtime- dscp, I don't see the sense in befuddling the document with suggestions only applicable to gigabit links. That was the upshot of our discussion at the time and later in London at the IET as I recall. In my mind, this has been asked and answered. Bringing forward the private discussion you and I had overnight: On Mar 13, 2008, at 2:53 AM, Bob Briscoe wrote: > Fred, > > Tx for this. Some mark-up of your proposed text below (in HTML)... > > At 21:50 12/03/2008, Fred Baker wrote: >> Bob and Anna: >> >> Following up on our chat today. >> >> So I think we agreed to do something like the following. I need >> pointers to currently-relevant drafts and any other text changes that >> you would like to see. We spoke about adding a paragraph which I >> envision something like this. Please edit and correct. > > Are you meaning this to replace S.2.2.3 or add to it? Given Kwok & > Georgios supplied that text originally, I've cc'd them. I suggest > this new text goes beneath the text on Distributed approaches, > because PCN is also distributed and is another way to address > scalability of the big numbers region, other than RSVP aggregation. I was thinking of something in the *recommendation*, which is section 3. I'll have to think about exactly how to organize it in. What I sent you was the substance of a sub-paragraph that I proposed to add. > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > >> n.n.n Use of PCN signaling in a Diffserv domain >> >> [RFC2998] describes the integration of an Integrated Services domain >> such as described in this document with a Differentiated Services >> domain such as the relatively high speed links used in the Internet >> core. Figure N depicts such a mixture of domains. Host H1 is in an >> integrated services domain such as a SOHO connected via a relatively >> low uplink rate access link. It places a "call" to Host H2, which is >> in another Intserv domain. These pass through some number of routers >> that implement the Integrated Services model on the relevant >> interfaces, labeled IR1 through IR4. In the Differentiated Services >> domain, the routers are configured to use PCN to detect and report >> precongestion events. > > [draft-ietf-pcn-architecture] > > >> ,---. ,-------. ,---. >> ,' `. ,' `. ,' `. >> ,' Intserv `. ,' Diffserv/ `. ,' Intserv `. >> ; Domain : / PCN Domain \ ; Domain : >> ; : / +---+ \ ; : >> ;+--+ +---+ :---; +DR2+ :---; +---+ +--+: >> ||H1+---+IR1+---+IR2. .'+---+`. .'IR3+---+IR4+---+H2|| >> :+--+ +---+ ;---:`. +-+-+ +-+-+ / ;---: +---+ +--+; >> : ; \ `+DR1| |DR3+' / : ; >> : ; \ +---+ +---+ / : ; >> `. ,' `. ,' `. ,' >> `. ,' `. ,' `. ,' >> `---' `-------' `---' >> Figure N >> Integration of Integrated Services with Differentiated Services >> >> In such a scenario, one would expect that, as described in [RFC2998], >> the routers DR1 through DR3 do not implement Integrated Services. >> Rather, one expects that routers IR2 and IR3 serve as edge routers >> between the Diffserv and Intserv domains, and must translate the >> signaling. In essence, if IR3 receives an new request to place a >> reservation and is seeing precongestive signaling, > > more than a threshold level of pre-congestion notification (PCN), > >> it should refuse the request, unless there is a relevant policy >> permitting a specified requester to be exempt from that behavior. > >> The danger in such a scenario is that the combined behavior of >> variable rate codecs might permit a "call" to be placed at one time >> and for those "calls" to then create serious congestion at another >> time. The parameters for managing such scenarios, as well as the >> specific algorithms related to PCN for these services classes, is >> discussed in [XXX]. Your reply used an html format and crossed out the words "precongestive signaling" and the text following "refuse the request". I think Janet Gunn would likely want the rest of that sentence to remain, as it allows her to build her favorite service, but that is perhaps a nit. I return this to standard SMTP text formatting to make the picture readable :-) > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > I've scrubbed stuff about policy-based AC because you've said "in > essence", so there's no need to add detail describing policy > behaviours here, which could contradict stuff written in the PCN > docs now or later. I'm not trying to worry about the PCN docs. I'm noting that there might be interesting policy issues. > Incidentally, variable rate codecs that have made a signalled > reservation shouldn't increase their rate without modifying their > reservation, but they can reduce their rate to a lower bit-rate > codec without modifying their reservation. So I've scrubbed your > para about this, because it seems like too much detail for your > draft which isn't really about PCN, and it's a non-danger anyway. Yes, but the proposed text isn't talking about that. It is talking about the effect of variable rate codecs on measurement-based admission schemes in which correlated behavior occurs. Examples include last week's 242 GBPS phone call by Oprah (http:// www.disruptivetelephony.com/2008/03/the-oprah-tizat.html) or the behavior of TV advertisements (since TV channels know that users channel surf during ads, they correlate the times at which they advertise in order to catch eyeballs, which means that TV/DSL tends to have significant correlated traffic bursts around advertising). > Finally, I just read thru Capacity Admitted Traffic -04. I've got > quite a few comments, so I'll write them up tomorrow and post to > tsvwg. Next mail I'll also re-send the briefer review comments I > sent on it just under a year ago, which didn't seem to get noticed. As I say, I think I actually went through them, and found them to mostly be applying gigabit link considerations on sub-megabit upload- rate links. But I am very interested to catch your relevant comments. From tsvwg-bounces@ietf.org Thu Mar 13 06:12:59 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E10B28C820; Thu, 13 Mar 2008 06:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 EQCO-S5LXOaz; Thu, 13 Mar 2008 06:12:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C305228C5A3; Thu, 13 Mar 2008 06:12:56 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1134828C16E; Thu, 13 Mar 2008 06:12:54 -0700 (PDT) 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 hE3QY+39iYE1; Thu, 13 Mar 2008 06:12:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7B0E83A6E17; Thu, 13 Mar 2008 06:12:29 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3268B20544; Thu, 13 Mar 2008 14:10:10 +0100 (CET) X-AuditID: c1b4fb3e-ac194bb000004ec0-c4-47d927b2a84b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 142F3204FA; Thu, 13 Mar 2008 14:10:10 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 14:10:09 +0100 Received: from [127.0.0.1] ([153.88.21.99]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 14:10:09 +0100 Message-ID: <47D927AD.3020900@ericsson.com> Date: Thu, 13 Mar 2008 09:10:05 -0400 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Magnus Westerlund References: <47B560E3.2010506@ericsson.com> In-Reply-To: <47B560E3.2010506@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2008 13:10:09.0131 (UTC) FILETIME=[90400BB0:01C8850B] X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org, ccamp@ietf.org, tsvwg Subject: Re: [Tsvwg] WG last call for draft-ietf-tsvwg-rsvp-user-error-spec-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, This WG last call has now timed out. However, as there has not been a single comment it will continue until we actually get at least 3 reviewers stating that they have read it and find it ready to progress. Cheers Magnus Magnus Westerlund skrev: > This announces a WG last call for "User-Defined Errors for RSVP" to be > published as proposed standard. Please provide any comments by March 7. > (Yes, you get an extra week due to the just before the meeting time of > this last call). > > CCAMP and MPLS WG participants, please provide your comments to TSVWG. > > You can find the draft here: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-03.txt > > > Regards > > 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 > ---------------------------------------------------------------------- > > -- 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 ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Thu Mar 13 08:34:46 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDAA28C11B; Thu, 13 Mar 2008 08:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.07 X-Spam-Level: X-Spam-Status: No, score=-100.07 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 zWMBqDNDKWzg; Thu, 13 Mar 2008 08:34:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39AA428C944; Thu, 13 Mar 2008 08:34:17 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831863A6A65; Thu, 13 Mar 2008 08:14:13 -0700 (PDT) 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 tEgeItdO4Fc3; Thu, 13 Mar 2008 08:14:08 -0700 (PDT) Received: from smtp.ietf71.ietf.org (unknown [IPv6:2001:df8:0:5::6]) by core3.amsl.com (Postfix) with ESMTP id 34D253A6BF5; Thu, 13 Mar 2008 08:14:04 -0700 (PDT) Received: from AMALIS.gmail.com (unknown [130.129.102.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ietf71.ietf.org (Postfix) with ESMTP id 7A87FF08A33; Thu, 13 Mar 2008 11:11:41 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Mar 2008 11:11:36 -0400 To: Magnus Westerlund From: "Andrew G. Malis" In-Reply-To: <47D927AD.3020900@ericsson.com> References: <47B560E3.2010506@ericsson.com> <47D927AD.3020900@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20080313151141.7A87FF08A33@smtp.ietf71.ietf.org> X-Mailman-Approved-At: Thu, 13 Mar 2008 08:34:16 -0700 Cc: Magnus Westerlund , ccamp@ietf.org, tsvwg , mpls@ietf.org Subject: Re: [Tsvwg] [mpls] WG last call for draft-ietf-tsvwg-rsvp-user-error-spec-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org I just reviewed this draft and agree that it's ready to progress (I wrote an RFC creating an RVSP object with a new class number myself a few years back, so I've had a little bit of experience here). Cheers, Andy At 3/13/2008 09:10 AM -0400, Magnus Westerlund wrote: >Hi, > >This WG last call has now timed out. However, as there has not been a >single comment it will continue until we actually get at least 3 >reviewers stating that they have read it and find it ready to progress. > >Cheers > >Magnus > >Magnus Westerlund skrev: >> This announces a WG last call for "User-Defined Errors for RSVP" to be >> published as proposed standard. Please provide any comments by March 7. >> (Yes, you get an extra week due to the just before the meeting time of >> this last call). >> >> CCAMP and MPLS WG participants, please provide your comments to TSVWG. >> >> You can find the draft here: >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-03.txt >> >> >> Regards >> >> 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 >> ---------------------------------------------------------------------- >> >> > > >-- > >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 >---------------------------------------------------------------------- > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From tsvwg-bounces@ietf.org Thu Mar 13 08:45:34 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D463F3A6E4D; Thu, 13 Mar 2008 08:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_EQ_JP=1.265] 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 rhMXoLf3cQvC; Thu, 13 Mar 2008 08:45:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C8828C7E1; Thu, 13 Mar 2008 08:45:25 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8D528C7B6 for ; Thu, 13 Mar 2008 08:45:18 -0700 (PDT) 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 HxCxYpU9sXui for ; Thu, 13 Mar 2008 08:45:13 -0700 (PDT) Received: from smtp.ezqnews.com (yayoi-new.constitution.jp [219.94.145.168]) by core3.amsl.com (Postfix) with ESMTP id 07CCD28C818 for ; Thu, 13 Mar 2008 08:45:12 -0700 (PDT) Received: from [130.129.18.198] (dhcp-12c6.ietf71.ietf.org [130.129.18.198]) by yayoi-new.constitution.jp (Postfix) with ESMTP id 1DD58EBC2D; Fri, 14 Mar 2008 00:42:47 +0900 (JST) Message-ID: <47D94B38.4060003@kozuka.jp> Date: Thu, 13 Mar 2008 11:41:44 -0400 From: "M. Kozuka" User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: sctp-impl@external.cisco.com, Sctp-coders@lakerest.net Subject: [Tsvwg] "SCTP driver for Windows XP/Vista", Now available as beta release. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hello. Sorry for disturbing, but we hope this would be useful for some people. A beta release package of sctpDrv: an implementation of SCTP that works on 32bit Windows XP/Vista is available at: http://www.co-conv.jp/en/product/sctpDrv/20080313/ SctpDrv is a software that consists of a kernel driver which provides the facility of SCTP processing and a library which enables application programmers to use SCTP through Winsock. If your are interested, please check the above web site. Today I'm in IETF floor. If you have some questions about sctpDrv, please pick up me or contact me through e-mail. Happy SCTPing! -- KOZUKA Masahiro @ Graduate School of Law, Kyoto University, Japan From tsvwg-bounces@ietf.org Thu Mar 13 16:15:37 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64CD3A6F0D; Thu, 13 Mar 2008 16:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, GB_OPRAH=2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 kxY5WidFU-f7; Thu, 13 Mar 2008 16:15:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492F128C968; Thu, 13 Mar 2008 16:12:28 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE82828C9B3; Thu, 13 Mar 2008 16:12:26 -0700 (PDT) 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 w6feSyAmDXsw; Thu, 13 Mar 2008 16:12:24 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id 2576928C9FF; Thu, 13 Mar 2008 16:10:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-14.tower-171.messagelabs.com!1205449652!2171227!8 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 24761 invoked from network); 13 Mar 2008 23:08:32 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-14.tower-171.messagelabs.com with AES256-SHA encrypted SMTP; 13 Mar 2008 23:08:32 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id m2DNAm2v030826; Thu, 13 Mar 2008 19:11:48 -0400 In-Reply-To: To: Fred Baker MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 13 Mar 2008 19:02:21 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 03/13/2008 07:11:42 PM, Serialize complete at 03/13/2008 07:11:42 PM Content-Type: multipart/alternative; boundary="=_alternative 007E8ED48525740B_=" Cc: Phil EARDLEY , tsvwg-bounces@ietf.org, tsvwg@ietf.org, "CHAN, Kwok Ho" Subject: Re: [Tsvwg] EF-ADMIT & PCN DSCP(s) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org This is a multipart message in MIME format. --=_alternative 007E8ED48525740B_= Content-Type: text/plain; charset="US-ASCII" I am having some difficulty following this email, as there was apparently some html "markup" which has been lost. Please explain which sentence has been "crossed out" which would affect my "favorite service". Is it a sentence currently in -04, or in proposed additional text. Are you trying to say that pcn would constitute an alternative to RSVP as meeting the criteria "admitted". If so, what is the mechanism for considering RPH in admission criteria for pcn? (For RSVP, we have draft-ietf-tsvwg-emergency-rsvp-05) Are you proposing changes to this text in section 2.3? "If capacity admission as described in Section 2.2.3 is in use, then multiple thresholds must be applied in marking the traffic, multiple traffic marks must be applied, or there must be multiple ways to interpret the result. In any event, this is only applicable in domains in which the law of large numbers applies." Janet Computer Sciences Corporation Registered Office: 2100 East Grand Avenue, El Segundo California 90245, USA Registered in USA No: C-489-59 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- tsvwg-bounces@ietf.org wrote on 03/13/2008 08:25:29 AM: > oops, resending - I include "tsvwg-chairs" on the CC line instead of > "tsvwg". > > On Mar 13, 2008, at 2:53 AM, Bob Briscoe wrote: > > Finally, I just read thru Capacity Admitted Traffic -04. I've got > > quite a few comments, so I'll write them up tomorrow and post to > > tsvwg. Next mail I'll also re-send the briefer review comments I > > sent on it just under a year ago, which didn't seem to get noticed. > > Hmm. Yes, please send your comments. > > 2006-2008, I see 18 notes that comment on draft-ietf-tsvwg-admitted- > realtime-dscp. Four of them announce the posting of a draft. One is > the posting of minutes to a meeting in which a draft was discussed. > > Two are Magnus' comments of 13 February, addressed in draft -04, and > four others are chitchat on 24 Feb pursuant to that. One is Martin > Dolly agreeing to a set of changes. Brian Carpenter doesn't > understand why we mention rate policing, as it is mentioned in RFC > 3246. Janet Gunn would like draft-ietf-tsvwg-emergency-rsvp to refer > to this draft (March 28 2007), which Ken Carlberg also commented on. > One comment is from Dave McDysan, essentially asking that Video be > added to the original Voice considerations. > > On March 21 March 2007, the email the quoted this morning, you > suggested that we go for a second code point for video. > > > So here's a proposal: > > - two DSCPs from IANA for EF-admit-voice and EF-admit-video > > - of which an operator can choose to use one (probably the voice > > one) as just EF-admit-* if they want > > > > Is that feasible? Or have I missed the point? > > > This is something we looked at when you originally asked, and wound > up deciding (in -03 and -04) to simply apply the considerations to > existing video classes in 4594 rather than trying to allocate classes > willy-nilly. As to your suggestion of dumping voice and video > together in a common class and telling the operator to pick one of > two DSCPs depending on admission or non-admission, the matter is > discussed in RFCs 4594 and 5127. On gigabit links (the RFC 5127 case, > the one PCN is applicable on), fine. On lower speed links (as a rule > of thumb, below ten megabit), the interaction between voice and video > traffic in the same class is disruptive to voice, and PCN is > inapplicable because the process of adding a single data flow of > speed at the same order of magnitude as the link rate is disruptive > to the existing traffic. Lower speed access links being the primary > consideration of RFC 4594 and of draft-ietf-tsvwg-admitted-realtime- > dscp, I don't see the sense in befuddling the document with > suggestions only applicable to gigabit links. That was the upshot of > our discussion at the time and later in London at the IET as I > recall. In my mind, this has been asked and answered. > > > Bringing forward the private discussion you and I had overnight: > > On Mar 13, 2008, at 2:53 AM, Bob Briscoe wrote: > > Fred, > > > > Tx for this. Some mark-up of your proposed text below (in HTML)... > > > > At 21:50 12/03/2008, Fred Baker wrote: > >> Bob and Anna: > >> > >> Following up on our chat today. > >> > >> So I think we agreed to do something like the following. I need > >> pointers to currently-relevant drafts and any other text changes that > >> you would like to see. We spoke about adding a paragraph which I > >> envision something like this. Please edit and correct. > > > > Are you meaning this to replace S.2.2.3 or add to it? Given Kwok & > > Georgios supplied that text originally, I've cc'd them. I suggest > > this new text goes beneath the text on Distributed approaches, > > because PCN is also distributed and is another way to address > > scalability of the big numbers region, other than RSVP aggregation. > > I was thinking of something in the *recommendation*, which is section > 3. I'll have to think about exactly how to organize it in. What I > sent you was the substance of a sub-paragraph that I proposed to add. > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > >> n.n.n Use of PCN signaling in a Diffserv domain > >> > >> [RFC2998] describes the integration of an Integrated Services domain > >> such as described in this document with a Differentiated Services > >> domain such as the relatively high speed links used in the Internet > >> core. Figure N depicts such a mixture of domains. Host H1 is in an > >> integrated services domain such as a SOHO connected via a relatively > >> low uplink rate access link. It places a "call" to Host H2, which is > >> in another Intserv domain. These pass through some number of routers > >> that implement the Integrated Services model on the relevant > >> interfaces, labeled IR1 through IR4. In the Differentiated Services > >> domain, the routers are configured to use PCN to detect and report > >> precongestion events. > > > > [draft-ietf-pcn-architecture] > > > > > >> ,---. ,-------. ,---. > >> ,' `. ,' `. ,' `. > >> ,' Intserv `. ,' Diffserv/ `. ,' Intserv `. > >> ; Domain : / PCN Domain \ ; Domain : > >> ; : / +---+ \ ; : > >> ;+--+ +---+ :---; +DR2+ :---; +---+ +--+: > >> ||H1+---+IR1+---+IR2. .'+---+`. .'IR3+---+IR4+---+H2|| > >> :+--+ +---+ ;---:`. +-+-+ +-+-+ / ;---: +---+ +--+; > >> : ; \ `+DR1| |DR3+' / : ; > >> : ; \ +---+ +---+ / : ; > >> `. ,' `. ,' `. ,' > >> `. ,' `. ,' `. ,' > >> `---' `-------' `---' > >> Figure N > >> Integration of Integrated Services with Differentiated Services > >> > >> In such a scenario, one would expect that, as described in [RFC2998], > >> the routers DR1 through DR3 do not implement Integrated Services. > >> Rather, one expects that routers IR2 and IR3 serve as edge routers > >> between the Diffserv and Intserv domains, and must translate the > >> signaling. In essence, if IR3 receives an new request to place a > >> reservation and is seeing precongestive signaling, > > > > more than a threshold level of pre-congestion notification (PCN), > > > >> it should refuse the request, unless there is a relevant policy > >> permitting a specified requester to be exempt from that behavior. > > > >> The danger in such a scenario is that the combined behavior of > >> variable rate codecs might permit a "call" to be placed at one time > >> and for those "calls" to then create serious congestion at another > >> time. The parameters for managing such scenarios, as well as the > >> specific algorithms related to PCN for these services classes, is > >> discussed in [XXX]. > > Your reply used an html format and crossed out the words > "precongestive signaling" and the text following "refuse the > request". I think Janet Gunn would likely want the rest of that > sentence to remain, as it allows her to build her favorite service, > but that is perhaps a nit. I return this to standard SMTP text > formatting to make the picture readable :-) > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > > I've scrubbed stuff about policy-based AC because you've said "in > > essence", so there's no need to add detail describing policy > > behaviours here, which could contradict stuff written in the PCN > > docs now or later. > > I'm not trying to worry about the PCN docs. I'm noting that there > might be interesting policy issues. > > > Incidentally, variable rate codecs that have made a signalled > > reservation shouldn't increase their rate without modifying their > > reservation, but they can reduce their rate to a lower bit-rate > > codec without modifying their reservation. So I've scrubbed your > > para about this, because it seems like too much detail for your > > draft which isn't really about PCN, and it's a non-danger anyway. > > Yes, but the proposed text isn't talking about that. It is talking > about the effect of variable rate codecs on measurement-based > admission schemes in which correlated behavior occurs. Examples > include last week's 242 GBPS phone call by Oprah (http:// > www.disruptivetelephony.com/2008/03/the-oprah-tizat.html) or the > behavior of TV advertisements (since TV channels know that users > channel surf during ads, they correlate the times at which they > advertise in order to catch eyeballs, which means that TV/DSL tends > to have significant correlated traffic bursts around advertising). > > > Finally, I just read thru Capacity Admitted Traffic -04. I've got > > quite a few comments, so I'll write them up tomorrow and post to > > tsvwg. Next mail I'll also re-send the briefer review comments I > > sent on it just under a year ago, which didn't seem to get noticed. > > As I say, I think I actually went through them, and found them to > mostly be applying gigabit link considerations on sub-megabit upload- > rate links. But I am very interested to catch your relevant comments. > --=_alternative 007E8ED48525740B_= Content-Type: text/html; charset="US-ASCII"
I am having some difficulty following this email, as there was apparently some html "markup" which has been lost.

Please explain which sentence has been "crossed out"  which would affect  my "favorite service".  Is it a sentence currently in -04, or in proposed additional text.

Are you trying to say that pcn would constitute  an alternative to RSVP as meeting the criteria "admitted".  If so, what is the mechanism for considering RPH in admission criteria for pcn? (For RSVP, we have draft-ietf-tsvwg-emergency-rsvp-05)

Are you proposing changes to this text in section  2.3?
"If capacity admission as described in Section 2.2.3 is in use, then
   multiple thresholds must be applied in marking the traffic, multiple
   traffic marks must be applied, or there must be multiple ways to
   interpret the result.  In any event, this is only applicable in
   domains in which the law of large numbers applies."

Janet

Computer Sciences Corporation
Registered Office: 2100 East Grand Avenue, El Segundo California 90245, USA
Registered in USA No: C-489-59

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

tsvwg-bounces@ietf.org wrote on 03/13/2008 08:25:29 AM:

> oops, resending - I include "tsvwg-chairs" on the CC line instead of  
> "tsvwg".
>
> On Mar 13, 2008, at 2:53 AM, Bob Briscoe wrote:
> > Finally, I just read thru Capacity Admitted Traffic -04. I've got  
> > quite a few comments, so I'll write them up tomorrow and post to  
> > tsvwg. Next mail I'll also re-send the briefer review comments I  
> > sent on it just under a year ago, which didn't seem to get noticed.
>
> Hmm. Yes, please send your comments.
>
> 2006-2008, I see 18 notes that comment on draft-ietf-tsvwg-admitted-
> realtime-dscp. Four of them announce the posting of a draft. One is  
> the posting of minutes to a meeting in which a draft was discussed.
>
> Two are Magnus' comments of 13 February, addressed in draft -04, and  
> four others are chitchat on 24 Feb pursuant to that. One is Martin  
> Dolly agreeing to a set of changes. Brian Carpenter doesn't  
> understand why we mention rate policing, as it is mentioned in RFC  
> 3246. Janet Gunn would like draft-ietf-tsvwg-emergency-rsvp to refer  
> to this draft (March 28 2007), which Ken Carlberg also commented on.  
> One comment is from Dave McDysan, essentially asking that Video be  
> added to the original Voice considerations.
>
> On March 21 March 2007, the email the quoted this morning, you  
> suggested that we go for a second code point for video.
>
> > So here's a proposal:
> > - two DSCPs from IANA for EF-admit-voice and EF-admit-video
> > - of which an operator can choose to use one (probably the voice  
> > one) as just EF-admit-* if they want
> >
> > Is that feasible? Or have I missed the point?
>
>
> This is something we looked at when you originally asked, and wound  
> up deciding (in -03 and -04) to simply apply the considerations to  
> existing video classes in 4594 rather than trying to allocate classes  
> willy-nilly. As to your suggestion of dumping voice and video  
> together in a common class and telling the operator to pick one of  
> two DSCPs depending on admission or non-admission, the matter is  
> discussed in RFCs 4594 and 5127. On gigabit links (the RFC 5127 case,  
> the one PCN is applicable on), fine. On lower speed links (as a rule  
> of thumb, below ten megabit), the interaction between voice and video  
> traffic in the same class is disruptive to voice, and PCN is  
> inapplicable because the process of adding a single data flow of  
> speed at the same order of magnitude as the link rate is disruptive  
> to the existing traffic. Lower speed access links being the primary  
> consideration of RFC 4594 and of draft-ietf-tsvwg-admitted-realtime-
> dscp, I don't see the sense in befuddling the document with  
> suggestions only applicable to gigabit links. That was the upshot of  
> our discussion at the time and later in London at the IET as I  
> recall. In my mind, this has been asked and answered.
>
>
> Bringing forward the private discussion you and I had overnight:
>
> On Mar 13, 2008, at 2:53 AM, Bob Briscoe wrote:
> > Fred,
> >
> > Tx for this. Some mark-up of your proposed text below (in HTML)...
> >
> > At 21:50 12/03/2008, Fred Baker wrote:
> >> Bob and Anna:
> >>
> >> Following up on our chat today.
> >>
> >> So I think we agreed to do something like the following. I need
> >> pointers to currently-relevant drafts and any other text changes that
> >> you would like to see. We spoke about adding a paragraph which I
> >> envision something like this. Please edit and correct.
> >
> > Are you meaning this to replace S.2.2.3 or add to it? Given Kwok &  
> > Georgios supplied that text originally, I've cc'd them. I suggest  
> > this new text goes beneath the text on Distributed approaches,  
> > because PCN is also distributed and is another way to address  
> > scalability of the big numbers region, other than RSVP aggregation.
>
> I was thinking of something in the *recommendation*, which is section  
> 3. I'll have to think about exactly how to organize it in. What I  
> sent you was the substance of a sub-paragraph that I proposed to add.
>
> > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> >
> >> n.n.n Use of PCN signaling in a Diffserv domain
> >>
> >> [RFC2998] describes the integration of an Integrated Services domain
> >> such as described in this document with a Differentiated Services
> >> domain such as the relatively high speed links used in the Internet
> >> core. Figure N depicts such a mixture of domains. Host H1 is in an
> >> integrated services domain such as a SOHO connected via a relatively
> >> low uplink rate access link. It places a "call" to Host H2, which is
> >> in another Intserv domain. These pass through some number of routers
> >> that implement the Integrated Services model on the relevant
> >> interfaces, labeled IR1 through IR4. In the Differentiated Services
> >> domain, the routers are configured to use PCN to detect and report
> >> precongestion events.
> >
> > [draft-ietf-pcn-architecture]
> >
> >
> >>       ,---.                ,-------.                ,---.
> >>     ,'     `.            ,'         `.            ,'     `.
> >>   ,' Intserv `.        ,'  Diffserv/  `.        ,' Intserv `.
> >>  ;   Domain    :      /    PCN Domain   \      ;   Domain    :
> >>  ;             :     /       +---+       \     ;             :
> >> ;+--+   +---+   :---;        +DR2+        :---;   +---+   +--+:
> >> ||H1+---+IR1+---+IR2.      .'+---+`.     .'IR3+---+IR4+---+H2||
> >> :+--+   +---+   ;---:`. +-+-+     +-+-+ / ;---:   +---+   +--+;
> >>  :             ;     \ `+DR1|     |DR3+' /     :             ;
> >>  :             ;      \ +---+     +---+ /      :             ;
> >>   `.         ,'        `.             ,'        `.         ,'
> >>     `.     ,'            `.         ,'            `.     ,'
> >>       `---'                `-------'                `---'
> >> Figure N
> >> Integration of Integrated Services with Differentiated Services
> >>
> >> In such a scenario, one would expect that, as described in [RFC2998],
> >> the routers DR1 through DR3 do not implement Integrated Services.
> >> Rather, one expects that routers IR2 and IR3 serve as edge routers
> >> between the Diffserv and Intserv domains, and must translate the
> >> signaling. In essence, if IR3 receives an new request to place a
> >> reservation and is seeing precongestive signaling,
> >
> > more than a threshold level of pre-congestion notification (PCN),
> >
> >> it should refuse the request, unless there is a relevant policy  
> >> permitting a specified requester to be exempt from that behavior.
> >
> >> The danger in such a scenario is that the combined behavior of
> >> variable rate codecs might permit a "call" to be placed at one time
> >> and for those "calls" to then create serious congestion at another
> >> time. The parameters for managing such scenarios, as well as the
> >> specific algorithms related to PCN for these services classes, is
> >> discussed in [XXX].
>
> Your reply used an html format and crossed out the words  
> "precongestive signaling" and the text following "refuse the  
> request". I think Janet Gunn would likely want the rest of that  
> sentence to remain, as it allows her to build her favorite service,  
> but that is perhaps a nit. I return this to standard SMTP text  
> formatting to make the picture readable :-)
>
> > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> >
> > I've scrubbed stuff about policy-based AC because you've said "in  
> > essence", so there's no need to add detail describing policy  
> > behaviours here, which could contradict stuff written in the PCN  
> > docs now or later.
>
> I'm not trying to worry about the PCN docs. I'm noting that there  
> might be interesting policy issues.
>
> > Incidentally, variable rate codecs that have made a signalled  
> > reservation shouldn't increase their rate without modifying their  
> > reservation, but they can reduce their rate to a lower bit-rate  
> > codec without modifying their reservation. So I've scrubbed your  
> > para about this, because it seems like too much detail for your  
> > draft which isn't really about PCN, and it's a non-danger anyway.
>
> Yes, but the proposed text isn't talking about that. It is talking  
> about the effect of variable rate codecs on measurement-based  
> admission schemes in which correlated behavior occurs. Examples  
> include last week's 242 GBPS phone call by Oprah (http://
> www.disruptivetelephony.com/2008/03/the-oprah-tizat.html) or the  
> behavior of TV advertisements (since TV channels know that users  
> channel surf during ads, they correlate the times at which they  
> advertise in order to catch eyeballs, which means that TV/DSL tends  
> to have significant correlated traffic bursts around advertising).
>
> > Finally, I just read thru Capacity Admitted Traffic -04. I've got  
> > quite a few comments, so I'll write them up tomorrow and post to  
> > tsvwg. Next mail I'll also re-send the briefer review comments I  
> > sent on it just under a year ago, which didn't seem to get noticed.
>
> As I say, I think I actually went through them, and found them to  
> mostly be applying gigabit link considerations on sub-megabit upload-
> rate links. But I am very interested to catch your relevant comments.
>
--=_alternative 007E8ED48525740B_=-- From tsvwg-bounces@ietf.org Tue Mar 18 05:29:06 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9938A28C5CC; Tue, 18 Mar 2008 05:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.533 X-Spam-Level: X-Spam-Status: No, score=-4.533 tagged_above=-999 required=5 tests=[AWL=1.716, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 AvfbsAyOI36K; Tue, 18 Mar 2008 05:29:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548F528C59C; Tue, 18 Mar 2008 05:28:55 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FD03A6837; Tue, 18 Mar 2008 05:28:54 -0700 (PDT) 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 cc8dCueFSGD3; Tue, 18 Mar 2008 05:28:53 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9FA3128C59A; Tue, 18 Mar 2008 05:28:41 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ADE5720514; Tue, 18 Mar 2008 13:26:23 +0100 (CET) X-AuditID: c1b4fb3c-ae09bbb00000193b-b4-47dfb4efdb79 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9595420508; Tue, 18 Mar 2008 13:26:23 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 13:26:23 +0100 Received: from [127.0.0.1] ([147.214.30.103]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 13:26:23 +0100 Message-ID: <47DFB4ED.3000303@ericsson.com> Date: Tue, 18 Mar 2008 13:26:21 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Magnus Westerlund References: <47C58EB8.1000203@ericsson.com> In-Reply-To: <47C58EB8.1000203@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2008 12:26:23.0059 (UTC) FILETIME=[470E0230:01C888F3] X-Brightmail-Tracker: AAAAAA== Cc: dime@ietf.org, tsvwg , NSIS Subject: Re: [Tsvwg] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, There has now been a declaration of consensus in the NSIS WG regarding where to go with the admission priority field: 3) Keep Y.2171 admission priority and add admission priority as in tsvwg-rsvp-emergency to draft-ietf-nsis-qspec-19.txt. See thread starting at: http://www.ietf.org/mail-archive/web/nsis/current/msg08289.html To my understanding this means there is no need to make a major change to this document. However, some clarification may be warranted regarding the scope of the parameter that align with the NSIS QSpec updates. 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Wed Mar 19 09:23:50 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA7C28C5BB; Wed, 19 Mar 2008 09:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=1.055, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] 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 qikjaUWI1oMQ; Wed, 19 Mar 2008 09:23:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC02028C291; Wed, 19 Mar 2008 09:23:21 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB273A6A96 for ; Wed, 19 Mar 2008 09:23:20 -0700 (PDT) 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 JcmJeQVTEbAk for ; Wed, 19 Mar 2008 09:23:14 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id C23A83A68C3 for ; Wed, 19 Mar 2008 09:23:13 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 16:20:56 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 16:20:56 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205943646635; Wed, 19 Mar 2008 16:20:46 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2JGKmET015844; Wed, 19 Mar 2008 16:20:51 GMT Message-Id: <200803191620.m2JGKmET015844@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Mar 2008 15:53:17 +0000 To: Fred Baker , "POLK, James" , mdolly@att.com From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Mar 2008 16:20:56.0140 (UTC) FILETIME=[35AD80C0:01C889DD] Cc: tsvwg IETF list Subject: [Tsvwg] Nits in draft-ietf-tsvwg-admitted-realtime-dscp-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Fred, James, Martin, I've split my promised review of "DSCPs for capacity admitted traffic" into nits (this mail) and substantive comments (next mail). I generally support what you're trying to do here. These comments are designed to help get it through w-g and IETF last calls. ============================================================================== General terminology: The draft refers to the proposed service class(es?) with the following different names: - Capacity-Admitted Traffic - Admitted Telephony service class - Admitted Service Classes - VOICE-ADMIT - EF2 It would be useful to add these to the definitions section, if you mean different things by these. Otherwise, if they are all the same thing, pls make them consistent or explain why different words are useful for the same thing. General structure: I found Section 2.2 listing the five Capacity Admission Control techniques very confusing, because it came under the general section heading of "Implementations of the Admitted Service Classes", but only in Section 3 did you suddenly say (paraphrasing) "None of that stuff we just described is a good enough implementation of the Admitted Service Class except that in Section 2.2.5." 1. Intro Para 3: Video class doesn't have to be server-user. Can be user-user. Para 4: Clarify that these are all US-specific terms 1.2 Problem Para 1: Not clear what you mean by 'edge network'. 1.3 Proposed Solution "The IETF is asked to differentiate, in the Telephony Service, between sessions that are originated without capacity admission ..." The section heading and this text seems to be a hang-over from when you were making your case for a new codepoint. For standards track, we need a standard that can either be complied with or not, so you now need to simply define the semantics of the service class and assign the codepoint. "...without network-originated control..." what is this meant to imply? 2. Implementation of the Admitted Service Class Suggested new title: "Candidate Implementations of the Admitted Service Class" 2.1 Potential implementation of EF in this model "There are at least two possible ways to implement the Expedited Forwarding PHB in this model." -> "There are at least two possible ways to implement isolation between the Capacity Admitted PHB and the Expedited Forwarding PHB in this model." Ironically, the very long sentence starting "The reason this is necessary is that there is currently confusion in the industry..." is too long and too confusing. Fig 2 and the text describing it both need to say which PHB is which, out of EF and EF2 (for the avoidance of doubt). Para 6: "...datagrams containing video data are relatively large (generally the size of the path MTU)" -> "...datagrams conaining video data can be relatively large (often of variable sizes up to the path MTU)" 2.2 Capacity admission control "There are five major ways that capacity admission is done or has been proposed to be done in real-time applications." -> "There are five major ways that capacity admission is done or has been proposed to be done for real-time applications. Each will be described below, then Section 3 will judge which ones are likely to meet the requirements of the Admitted Telephony service class." (Otherwise it's very unclear what's going on.) "There is also a mechanism that has been proposed for enhancing the probability of call completion in a preferential manner. ..." I suggest this whole long para is given a new section 2.2.6 or something. It's a bit odd having a corner-case coming before the five main scenarios. 2.2.2 para 2: Garbled sentence. "SIP provides the option to go down another path, to admit its servers at layer 7, have no awareness of lower layer connectivity, resulting in a divorce from infrastructure knoweldge - save for [RFC3312] which binds the two, but only at the endpoints." -> "SIP seems to provide an alternative admission control mechanism, but its servers are at the application layer and have no awareness of lower layer connectivity - save for [RFC3312] which binds the two, but only at the endpoints. Therefore SIP alone cannot control capacity admission robustly." 2.2.2 para 3, 1st sentence: Garbled. 2.2.3 Suggested updated wording for whole PCN section: {I suggest this is placed after S.2.2.5 on Distributed Capacity AC, as it builds on the concepts described there.} 2.2.x Admission Control using Pre-Congestion Notification (PCN) If only the boundary nodes of a DS domain make admission control decisions [RFC2998], the interior links have to be overprovisioned to reduce the chance that an unusual pattern of traffic will focus on an interior link and degrade admitted flows. For every hop further away from the admission control at both edges, overprovisioning of the links has to increase linearly [Reid]. But, still, overprovisioning merely reduces the chance of overload rather than eliminating the possibility. The IETF is standardising pre-congestion notification (PCN [PCN-arch]) so that queues in the interior of a high speed DS domain can mark the IP headers of packets in bulk as traffic of a DS class approaches a configured threshold rate. Then, even without overprovisioning, admitted flows cannot be degraded whatever the pattern of demand, because capacity admission control at the edges of the DS domain can determine actual traffic conditions in the interior by monitoring for PCN markings. The PCN approach is not applicable for the small links around the edges of a network where a link showing no sign of congestion can be tipped into overload by a single extra flow. Nonetheless, on high speed links PCN provides equivalent capacity admission control to the Intserv Controlled Load service without any flow state or flow processing on interior nodes, thus addressing the scalability concerns of [RFC2208]. PCN is currently only defined for unicast forwarding. PCN standardises the essential aspects of numerous approaches proposed over the years, many referenced in [PCN-arch]. It was initially defined for use with RSVP signalling, but deployment scenarios are also being worked on using NSIS and the ETSI TIPSPAN resource admission control framework (RACF). 2.2.4 3rd sentence ambiguous "...can keep track of simple bookeeping functions apart from network elements such as routers." -> "...can keep track of simple bookeeping functions separately from network elements such as routers." 2.3 1st sentence "Emergency Telecommunications Service, the US Department of Defense's Assured Service, and e-911 each call for..." -> "Emergency Telecommunications Service, the US Department of Defense's Assured Service and e-911, the US emergency telephony service,..." (Only using US examples is fine as long as you say they are US-only) "...each call for..." -> "...each require..." (Using the phrase 'call for' here could be confused with the calls made by users of these services.) "In the PSTN, GETS operates..." -> "In the US PSTN, GETS operates..." 2.3 3rd para, last sentence: "In essence any capacity admission policy..." -> "Any typical capacity admission policy..." -> (This statement depends on the SLAs given to the other traffic.) 2.3 5th-8th paras, 1st sentences of each para: "If capacity admission as described in Section 2.2.x is in use..." -> "If capacity admission using {call counting|PCN|etc} (Section 2.2.x) is in use..." (Easier to read without having to refer back to which section number is which) 2.3 Delete 6th para last sentence: "In any event, this is only applicable in domains in which the law of large numbers applies." (I've now said this in the new S2.2.3, and it's not relevant in this section which is specifically about precedence.) 2.3 7th para last sentence: "...to the extent that is variable..." -> "...to the extent that it is variable..." 4. IANA Considerations. "It implements the Telephony Service Class described in [RFC4594] at lower speeds and is included in the Real Time Treatment Aggregate [RFC5127] at higher speeds." (These two RFCs are informational. I don't think you mean to make a standards action depend on informational stuff.) Additional References [Reid] Andy Reid, "Economics and Scalability of QoS Solutions," BT Technology Journal 23(2) (April, 2005) (access requires a fee) HTH Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Wed Mar 19 09:33:05 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64FD228C602; Wed, 19 Mar 2008 09:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=1.073, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 srkdp2oMiI6Q; Wed, 19 Mar 2008 09:33:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207803A6F22; Wed, 19 Mar 2008 09:33:05 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD6428C5DB for ; Wed, 19 Mar 2008 09:33:04 -0700 (PDT) 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 9UTf5cOP8lEk for ; Wed, 19 Mar 2008 09:32:58 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id E4F743A6F0D for ; Wed, 19 Mar 2008 09:32:57 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 16:30:40 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 16:30:39 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205944238134; Wed, 19 Mar 2008 16:30:38 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2JGUXRW016542; Wed, 19 Mar 2008 16:30:35 GMT Message-Id: <200803191630.m2JGUXRW016542@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Mar 2008 16:30:40 +0000 To: Fred Baker , "POLK, James" , mdolly@att.com From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Mar 2008 16:30:39.0632 (UTC) FILETIME=[91775100:01C889DE] Cc: tsvwg IETF list Subject: [Tsvwg] Review of draft-ietf-tsvwg-admitted-realtime-dscp-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Fred, James, Martin, I've split my promised review of "DSCPs for capacity admitted traffic" into substantive comments (this mail) and nits (previous mail). I generally support what you're trying to do here. These comments are designed to help get it through w-g and IETF last calls. ============================================================================== Basically, the draft is asking the IETF to make an unnecessarily large set of controversial statements all bundled together into a standards track I-D. My reading extracts the following things this draft is trying to do: 1/ Recommend best practice implementation for isolating Traffic Aggregates that have been admission controlled from those that haven't. 2/ Point out that we only need to isolate admitted traffic where there's a history of mixing a non-admitted TA with it, given certain commonly used service classes (video) have generally been admission controlled while others (voice) both have and haven't. 3/ Say that the PHBs of the admitted voice TA can re-use the existing EF PHB, but also define what is different about this admitted TA. The difference is solely that edge traffic conditioning MUST involve a robust admission control technique, so I believe you are defining a per-domain behaviour here. RFC3086 says what a good PDB should include so you should refer to it and follow it. 4/ Say that robust admission control should include call precedence handling. 5/ Assign a global DSCP to enable the admitted-voice TA to be isolated 6/ Retrospectively define the PDBs of the video classes to state the assumption that they use admission control, rather than a mix of AC and non-AC. 7/ Recommend best practice for which admission control mechanisms provide worthwhile admission control and precedence handling. It's up to you whether you try to submit this whole cocktail of fairly controversial proposals and recommendations in one go. I happen to agree with most of your views, but the chances of getting consensus on all of them at once are pretty slim. Especially given that a standards track assignment of a DSCP has to get through a full IETF last call. I suggest it would be easier to break out 4, 6 & 7 into an informational doc, or at least demote them to appendices. Admitted Voice service class (Items 1, 2, 3 & 5) ---------------------------- These items constitute a minimum coherent set to create a generic standards action that introduces an Admitted Voice service class. I believe you are defining a simple per-domain behaviour so you should try to use the relevant language and concepts in RFC3086. Retrospectively defining video as Admitted (Item 6) ------------------------------------------ The draft includes this sentence: "It also recommends that certain classes of video described in [RFC4594] be treated as requiring capacity admission as well." Admittedly, this is on-topic, but it's a very different type of standards action. Instead of defining a service class that vendors can choose to use, it's saying everyone should assume these video service classes have always been admission controlled. To make such a retrospective statement, you have to say what the admission control at the ingress to a domain should do with packets that carry one of the video DSCPs but have a filterspec that hasn't asked for admission control. As you are effectively defining a PDB for these classes, you should have sections answering all the other questions a PDB should answer [RFC3086]. Suggested alternative wording: "Given these video services are inelastic, their service definitions are likely to be meaningful only if traffic is also subject to admission control. Precedence handling (Item 4) ------------------- Multiple times the draft says AA is a non-optional aspect of the Admitted Voice service class (throughout the Abstract, Introduction, Definitions (CAC), Recommendations (S.3), IANA Considerations and Security Considerations). Authentication and authorization are only required if you need precedence, so they are completely orthogonal to a draft introducing an admitted voice service class. Suggested alternative wording: "If an operator wants to provide flow or call precedence handling, the admission control function must also provide authentication and authorization." Reasoning: Imagine a network provides free access to VoIP calls for all customers, but subject to admission control. It doesn't offer precedence. This might be an enterprise network or a public network in a jurisdiction where some operators are not subject to regulations requiring precedence. The admission control system works just fine without authentication and authorization. The network can stop one flow affecting the QoS of another even though it doesn't know (and doesn't care) who is making which call. So AA is truly orthogonal to your request for a capacity admitted service and for a DSCP. Recommending which AC mechanisms provide worthwhile assurances (Item 7) -------------------------------------------------------------- Slagging off everything except RSVP might be valid, but it's not relevant to the task at hand. The standards action is about defining Admitted Traffic service class(es) that can be isolated from non-admitted traffic (a chisel to be added to the toolkit of planers, band-saws etc that Diffserv provides - to use the analogy in RFCs 4594 & 5127). If an operator needs to make this isolation, it's up to the operator what it considers as a robust enough AC mechanism to warrant using isolation. Yes, the IETF can put together a 'project plan' on how to use this new chisel alongside the other 'tools' on offer. But I advise caution if you want to mix 'project plans' into a document defining a 'chisel'. I would suggest that, at least, you surround such text with strong warning signs explaining that the reader is no longer in 'standards action' land, but is now in 'useful guide' land. Also, you can't just write off all the other admission control techniques. The efficacy of each one depends on the topology it is applied to. Call counting is a perfectly deterministic admission control mechanism for the non-meshed links of a regional access network (which is where my company uses it). SIP-based admission control can also be sufficient over non-meshed parts of a network (using call-counting), assuming acceptance of a SIP call triggers the network to police each flow's bit-rate at ingress (or the codecs are under network control). Conversely, Intserv over Diffserv provides rubbish admission control if the DS domain has a very large hop diameter without increasingly heavily overprovisioned links towards the middle. Here's an example of an argument you can avoid by being less prescriptive: I would advise using the Admitted Voice DSCP to separate traffic subject to PCN-based admission control from traffic subject to only RFC2998 edge admission control without PCN. You might not want to advise this. Assuming you don't want this argument to hold up this draft (I don't either), then I suggest you don't include the argument in the draft --- given few people care what the IETF says about this right now anyway. On this basis, here's suggested wording for Section 3... 3. Section heading Old: "Recommendations on implementation of an Admitted Telephony Service Class" -> New: "Recommendations for Isolation of an Admitted Telephony Service Class" Old: "It is the belief of the authors that either data plane PHB described in Section 2.1, if coupled with adequate AAA and capacity admission procedures as described in Section 2.2.5, are sufficient to provide the services required for an Admitted Capacity service class and an Admitted Multimedia Conferencing Service Class." -> New: "Inelastic traffic that has not been subjected to robust admission control can overload links, which can make all sessions of the same inelastic class that pass through the link unusable. Therefore an Admitted Capacity service class is required to isolate traffic that has undergone robust admission control from traffic that has not. The Admitted Capacity service class uses the EF PHB, but is isolated from and prioritised over non-admission controlled EF traffic using either of the data plane queueing arrangements described in Section 2.1. The only further difference from EF is that Admitted Capacity traffic REQUIRES a per-domain behaviour [RFC3086] that conditions the Traffic Aggregate at the edge of the DS domain using a robust admission control technique. {Define the Admitted Multimedia Conferencing service class similarly.} It is up to the operator to decide which of the admission control techniques outlined in Section 2.2 are robust enough to warrant isolation from non-admission controlled traffic, but we offer the following guidelines... " HTH Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Fri Mar 21 14:34:38 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFFE828C46A; Fri, 21 Mar 2008 14:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 yk6TzQO-dFLu; Fri, 21 Mar 2008 14:34:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBB928C3E1; Fri, 21 Mar 2008 14:34:37 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EFF228C39D for ; Fri, 21 Mar 2008 14:34:36 -0700 (PDT) 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 5H7udrFki68s for ; Fri, 21 Mar 2008 14:34:35 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6FB1A3A683D for ; Fri, 21 Mar 2008 14:34:35 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2008 14:32:17 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2LLWCqq010207; Fri, 21 Mar 2008 14:32:12 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m2LLWCIC003060; Fri, 21 Mar 2008 21:32:12 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Mar 2008 14:32:12 -0700 Received: from [10.32.241.69] ([10.32.241.69]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Mar 2008 14:32:11 -0700 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19B39207-48AD-45DF-9AFD-85CF40A73A63@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Fri, 21 Mar 2008 17:31:52 -0400 To: tsvwg@ietf.org X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 21 Mar 2008 21:32:11.0967 (UTC) FILETIME=[062A0CF0:01C88B9B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2107; t=1206135132; x=1206999132; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bdavie@cisco.com; z=From:=20Bruce=20Davie=20 |Subject:=20Comments=20on=20draft-ietf-tsvwg-rsvp-user-erro r-spec-03.txt=20 |Sender:=20; bh=eyVVAREDu8XQkZrQA38zlPd9TdMKXtxC8CyK4OmWPRQ=; b=dM0yegQmi3Bago1j5ljvaL+AtmhG5tZqHXzFisvR27Q9BYurhv7Jd0WmG4 094uB7Qh9TClQlopqKfzpxX/tLKD6u+YQnEov1m+TLdyZI6Xafr8sMHxo0VQ XP5NwkY5wr; Authentication-Results: sj-dkim-3; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: George Swallow Subject: [Tsvwg] Comments on draft-ietf-tsvwg-rsvp-user-error-spec-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org I believe the chairs were looking for some reviews on this draft before letting it go past last call. Here is one. Summary: the draft looks basically fine to me. Minor comments to show that I read it. Bruce > > 2. User-Defined Error > > A new Error Code is defined for use in an ERROR_SPEC object. > > Error Code = : User Error Spec > > This error code is used to signal the presence of a > USER_ERROR_SPEC. No subcodes are defined. RFC2205 users the term "Error Value" rather than "subcode". I suggest using the same terminology here. > > 3. USER_ERROR_SPEC Class > > A new RSVP object class is defined called the the USER_ERROR_SPEC > Class. The class number is taken from the range 192 - 247. > This is > done for backward compatibility. Existing implementations will > ignore the object and pass it along according to the rules of > [RFC2205]. > I thought this could be written a little more clearly (especially when you consider that, when this is published, there will be an actual class number assigned). How about this: A new RSVP object class called USER_ERROR_SPEC is defined. To support backwards compatibility, its class number is in the range 192-247. As defined in [RFC2205], implementations that do not understand such an object will forward it unmodified. > User Error Value > > A 16-bit integer. The format and contents are specified by > the (sub-)organization indicated by the Enterprise Number > and Sub Org fields. I think what you mean to say its *meaning* is specified by the (sub-) organization indicated by the Enterprise Number and Sub Org fields. > 4.2 [...] > Implementations receiving a USER_ERROR_SPEC object on some message > other than a PathErr, ResvErr, or Notify message MUST treat the > error as a malformed message and process according to [RFC2205]. RFC2205 allows ERROR_SPEC objects in ResvConf messages. I suggest the USER_ERROR_SPEC should also be allowed to appear in those messages. From tsvwg-bounces@ietf.org Mon Mar 24 13:05:25 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80C028C365; Mon, 24 Mar 2008 13:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=3.415, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tIogG8VU1rwY; Mon, 24 Mar 2008 13:05:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4763A6BAF; Mon, 24 Mar 2008 13:05:25 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D773C3A6BAF for ; Mon, 24 Mar 2008 13:05:24 -0700 (PDT) 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 Tjtueeu7pEia for ; Mon, 24 Mar 2008 13:05:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CC65828C2C3 for ; Mon, 24 Mar 2008 13:05:16 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2008 13:02:58 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2OK2vDx005418 for ; Mon, 24 Mar 2008 13:02:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m2OK2wLY010952 for ; Mon, 24 Mar 2008 20:02:58 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 13:02:57 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.149.36]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 13:02:57 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Mar 2008 15:02:54 -0500 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 24 Mar 2008 20:02:57.0653 (UTC) FILETIME=[0DFBD250:01C88DEA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10892; t=1206388978; x=1207252978; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Review=20of=20RSVP=20Proxy=20Approaches=20 |Sender:=20; bh=7nV1urfTVo15nhyYUba3r+3/hjd552HRbCWWGRjC9vc=; b=Ybg/SotM7O5ciiI/DTQP1XjLVKU+NCxuWFleO+SNEt+rnwsiwSUD+Rl5bj TAZA3hgggSDd57wQFWd80NRl3coLQMSzTzish25rEeNh19whwen8NsRBztpU 5DDcXsZYCD; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Tsvwg] Review of RSVP Proxy Approaches X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org TSVWG This is my WG chair review of http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-proxy-approaches/ Overall, this is an well written document. I have some comments regarding some portions of the text in -03, as follows: In the Abstract, it says " With conventional RSVP..." Shouldn't this say "RSVPv1" or "RSVP version 1"? "This document presents RSVP Proxy behaviors allowing RSVP routers to perform RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable." Switch "perform" with "...initiate or terminate..." This allows resource reservations to be established on critical parts of the end-to-end path. Switch " the end-to-end path" with "... the end-to-edge, edge-to-edge or edge-to-end paths." In the Intro section I suggest adding the following to the end of the 1st paragraph of the Intro "...for example, flows such as end-to-edge, edge-to-edge and edge-to-end paths." In the second paragraph, there's this Since the data sender or receiver may be unaware of RSVP, there are two scenarios. s/or/"and/or" and s/two/three at the end of the second paragraph, this is where I would add a third example, which is Proxy-to-Proxy (which is what CUCM would does today). This third example is also what you highlight in Figure 7 on page 14, so this comment applies - and probably ought to be mentioned here. At the end of the 5th paragraph, which starts with " The IETF Next Steps in Signaling (NSIS)...", there ought to be a 2205 reference to bring this point home. Comment on transition between sections 2 and 2.1 I don't know if it's clear that existing [2205-based] RSVP signaling works with Proxies as described so far. This should be stated firmly somewhere in Section 2., and before Section 2.1 IMO. In other words, this document is not changing existing RSVP signaling, just what can start/initiate and end/terminate RSVP signaling. In section 2.1, in the paragraph that starts " In order for reservations..." there is a "should" that's lowercase. Is this 2119 SHOULD? If not, the word needs to be different. If it is 2119 language, it needs to capitalized. Section 2.2, second paragraph says "...somehow know..." this is question answered? Or is this out of scope for this doc? Can it be a case that the sender proxy is configured to initiate a path every time one isn't detected (under certain conditions)? In other words, so far, this doc does a good job explaining what the proxy is, but doesn't do anything for how the proxy knows when to do anything. Perhaps a few words on this is needed. If this is to be explained later, a hint that this is coming would be good (as the objective for this section perhaps). Nit in section 3, with the paragraph starting with "Note..." this should be indented 3 additional spaces to set it further apart, the way I read it. In the last paragraph of section 3, there are application examples (SIP and RTSP). Firstly, IMO, add SDP (because that is the only protocol that carries the RFC3312 specific signaling wrt wanting a reservation and what BW is desired). Next, each of these three need informational references (SIP-3261, SDP-4566, RTSP-2326) in this doc. I'm currently confused by the inconsistent signaling paths (no pun intended) in section 4.2 (with other sections in Approaches and ones in the RSVP Proxy doc). Currently there is this signaling |----| *** *** |----------| |----| | R |---------*r*----------*r*---------| RSVP |----------| S | |----| *** *** | Sender | |----| | Proxy | |----------| ---Path---> ----Path----> ---Path----> <--Path---> <---Path----- <--Path---- ---RESV---> ----RESV----> ---RESV----> <================RSVP================== since you have PATHs going in both directions, why aren't there RESVs going in both directions? If the first PATH is only to trigger the PATH in the reverse direction, won't the R (endpoint) believe it is done sending PATH messages and not send another one (to the right in this diagram) to get a two-way reservation? Further, if reservations are to only be in one direction, how does the RSVP-Capable Receiver know that the Non-RSVP-Capable sender's flow will go *to* this proxy in the first place? This is a challenge that should be mentioned, since the receiver (on the left of the page) has no control over the sender on the right of the page, no does the receiver have knowledge of the entire forwarding table getting to the proxy router, right? The paragraph after Figure 5., mentions " This is illustrated in Figure 6." I'd like to understand more about Figure 5's use-case, and why this needs to be different from Figure 6's; especially given the comments above. As I look at Figure 6, it appears to be a normal two-way reservation, yet this is mentioned to be a likely scenario based on Figure 5, which has an unusual signaling behavior (that I've mentioned). I'd like a clearer explanation of how the signaling in Figure 5 works and turns into the signaling of Figure 6. I.e., explain how the RSVP-Proxy unaware endpoint knows it has to send two PATHs, each at different times in the signaling, to get one two-way reservation? Section 4.3, the second paragraph below Figure 7 has this "...so that the application takes appropriate action (for example terminate the corresponding session..." At what point does the application know to terminate anything? SIP, for example, sure wouldn't - because it has zero feedback itself in this scenario. I think something like RTCP (RFC 3550) needs to be mentioned as the feedback mechanism for RTP based streams. Section 4.3, in the next sentence has "To mitigate this problem, the inspection-triggered RSVP Proxy may mark differently the DSCP of flows for which an RSVP reservation has been successfully proxied from the flows for which a reservation is not in place. How is this accomplished? If mentioned as a solution, you should explain an example of how this can be accomplished. Right now, my DSCP attribute in SDP (in MMUSIC) http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp-attribute-02.txt *can* (but doesn't have to) be a mentioned (informational) reference. This probably shouldn't be mentioned, since this effort isn't going well in MMUSIC, lacking a viable use-case to the WG's satisfaction. That said, without this SDP capability, how is Approaches text supported by an existing or future mechanism? RFC4542 also mentions this scenario (a reservation goes away, but the application (by configuration) wants to keep it up (perhaps using a scavenger class codepoint) instead of tearing the call or flow down. This might be worth mentioning here. Section 4.3, in the next sentence In some situations, the Inspection-Triggered Proxy might be able to modify the "packets of interest" (e.g. application signaling messages) to convey some hint to applications that the corresponding flows cannot be guaranteed by RSVP reservations. I would also mention it falls on the proxies to burden the load of attempting to reestablish a new reservation if the flow isn't to be torn down. In section 4.4, has this below Figure 8 For unicast flows, [I-D.ietf-mmusic-ice] is an already widely-adopted emerging standard for NAT traversal. An internet draft is a "widely adopted emerging standard"? Hmmmm..... I think it is a widely accepted direction many are moving in, but it isn't a standard yet, so this doc shouldn't say that it is. In section 4.4, in the same paragraph below Figure 8 "By including new STUN attributes in those connectivity check messages, an RSVP Proxy agent could perform its functions more effectively." More effectively than what, exactly? I'd say it is more efficient than packet snooping of Section 4.3 If this is what you mean here, that needs to be said here (to scope what you are saying) Also in section 4.4, in the same paragraph below Figure 8 "This provides very RSVP- like call admission control and signaling to the endpoints, without implementing RSVP on the endpoints..." This seems to be advocating never coding RSVP on endpoints. Is this what is meant here? I hope not. I would think you want to say this is an efficient trigger for RSVP Proxies, mitigating less efficient means of trigger RSVP Proxies - until RSVP is coded in an (or all) endpoint(s). Also in section 4.4, in the next paragraph (below Figure 8) "For multicast flows (or certain kinds of unicast flows that don't or can't use ICE), a STUN Indication message [I-D.ietf-behave-rfc3489bis] could indicate the flow's bandwidth..." I'd be careful with "could" when referring to IDs that don't have the text in them to support what the could in this ID are trying to mean. In section 4.5, in the paragraph below Figure 9 "As an example, the Application_Entity-Controlled Proxy may be used in the context of Session Border Controllers (SBCs) (see [I-D.ietf-sipping-sbc-funcs] for description of SBCs) to establish RSVP reservations for multimedia sessions." After the "of", add "SIP Servers" [RFC3261] first, then you can mention SBCs - but since SBCs are usually considered border elements, there are few of these facing an endpoint within a administrative domain (thus perhaps making readers wonder about the applicability) In section 4.5, in the next paragraph below Figure 9, there is the sentence starting with "This interface may..." Change to "might" Section 4.5.1 has the acronym "PHOP". What's this acronym? If the first time in the doc, please explode it. Section 4.8 has " In some cases, having a full RSVP implementation running on an end host can be seen to produce excessive overhead. The burden of RSVP is in the routers, not the endpoints - so the amount of code to be in endpoints is only about 20KB of code (per Fred Baker, who wrote it into IOS), so you really have to qualify this statement, given that most dumb wireless phones have this much space in memory. My concern is people not understanding what minimal code is needed to run RSVP, and read this - and use it to justify why RSVP can't be on endpoints like IP phones, when it can easily be on phones. Comments are welcome Cheers, James IETF TSVWG co-chair *********************************** "It should NEVER be inconvenient to do the right thing" From tsvwg-bounces@ietf.org Mon Mar 24 15:54:42 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25E428C35A; Mon, 24 Mar 2008 15:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.316 X-Spam-Level: X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=3.284, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ZVZU6itQfJeu; Mon, 24 Mar 2008 15:54:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A758528C2CC; Mon, 24 Mar 2008 15:54:42 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489DE3A6CA6 for ; Mon, 24 Mar 2008 15:54:42 -0700 (PDT) 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 1SNXTZsHQm1Z for ; Mon, 24 Mar 2008 15:54:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 690173A68E6 for ; Mon, 24 Mar 2008 15:54:31 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 24 Mar 2008 15:52:12 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2OMqCdL015195; Mon, 24 Mar 2008 15:52:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2OMqCeK011468; Mon, 24 Mar 2008 22:52:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 15:52:12 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.149.36]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 15:52:11 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Mar 2008 17:52:09 -0500 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 24 Mar 2008 22:52:12.0158 (UTC) FILETIME=[B28A51E0:01C88E01] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3459; t=1206399132; x=1207263132; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Review=20of=20RSVP=20Proto |Sender:=20; bh=/XLB8mq7WJ6JYBtP8pVjPD76hQEOc5olMYqNXJnWTH0=; b=mAcBJApZ2q47bq2DOTmteouWIFXv8jy8qF89M+qUCQDyQlRLwj7Ds2JPUN 3m5KPfMA1LJGAEIGtw+WGUeKKQkio2+cfjaQPpvLa3UjTNjIaU0F/z6LpRRj Vsjb9pTOBSbNyTw4PKncogq26pT3P2wXopiX3uSUdzi5SL6ML+AdM=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: allan.guillou@neufcegetel.fr, jmanner@cs.helsinki.fi, Hemant.Malik@airtel.in Subject: [Tsvwg] Review of RSVP Proto X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org TSVWG This is my chair review of http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-proxy-proto/ This is also an excellent document. I have a few comments About the Abstract The RFC-Editor will make a push for you to at least start the Abstract on the first page... Intro, 2nd paragraph, has "Since both the data sender and receiver may be unaware of RSVP, there are two distinct RSVP Proxy use-cases." ^^^^ add As stated in the Approaches review, I think there are 3 use-cases, the 3rd being proxy to proxy where both endpoints are RSVP-unaware. Section 2, there's this bullet, that shouldn't be a bullet o Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, Regular RSVP Router are all relative to one unidirectional flow. A given router may act as the RSVP Receiver Proxy for a flow, as the RSVP Sender Proxy for another flow and as a Regular RSVP router for yet another flow. This paragraph should *not* be bulleted, and should be indented differently, something like this Note: that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, Regular RSVP Router are all relative to one unidirectional flow. A given router may act as the RSVP Receiver Proxy for a flow, as the RSVP Sender Proxy for another flow and as a Regular RSVP router for yet another flow. Section 3, there's this message flow in Figure 1 (and in Figure 2 for that matter) |----| *** *** *** |----------| |----| | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | |----| *** *** *** | Receiver | |----| | Proxy | |----------| ************************************************************> ===================RSVP===================> --Path---> --Path---> --Path---> --Path---> <---Resv-- <---Resv-- <---Resv-- <---Resv-- It may be getting late here, and a reservation is in the direction of the PATH messages, yet this diagram has the reservation *before* the PATH message, which is inconsistent from how you have it in Approaches I believe, and what is normally possible from RSVPv1 (unless I missed that part ;-) In section 3.1.3, in the 4th paragraph, starting with " Optionally..." there is a 2119 "MAY", when this appears to be a configuration option, and not for future extensions for implementers. In other words, I'm not sure this is the correct usage of 2119 language. "MAY" means there could be a future RFC which specifies this as a SHOULD or MUST. Here I think you man 2119 "OPTIONAL", whereby support is the choice the implemtator to code or not. If this feature SHOULD be coded, but optionally configured for usage, then this needs to be either a SHOULD or a MUST, where configuration decides if this option is used or not. In the same paragraph as the above MAY, there is a comment about "old router". Does this really mean a non-RSVP capable router or a router that doesn't support this extension. I'd recommend saying which is true. Cheers, James IETF TSVWG co-chair *********************************** "It should NEVER be inconvenient to do the right thing" From tsvwg-bounces@ietf.org Wed Mar 26 09:08:12 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE54D3A6AE1; Wed, 26 Mar 2008 09:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.114 X-Spam-Level: X-Spam-Status: No, score=-4.114 tagged_above=-999 required=5 tests=[AWL=2.485, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 xxxiG0qDH8xu; Wed, 26 Mar 2008 09:08:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4163A6BF9; Wed, 26 Mar 2008 09:08:12 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B291D3A6BB7 for ; Wed, 26 Mar 2008 09:08:10 -0700 (PDT) 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 owWbOhzjXXFw for ; Wed, 26 Mar 2008 09:08:09 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 69ACE3A68CE for ; Wed, 26 Mar 2008 09:08:09 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2QG5TPf016275 for ; Wed, 26 Mar 2008 18:05:47 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Mar 2008 18:04:48 +0200 Received: from [172.21.30.105] ([172.21.30.105]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Mar 2008 18:04:48 +0200 Message-Id: From: Lars Eggert To: tsvwg WG In-Reply-To: <20080225220001.D9B5328C6C6@core3.amsl.com> Content-Type: multipart/signed; boundary=Apple-Mail-10-607020911; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 26 Mar 2008 18:04:47 +0200 References: <20080225220001.D9B5328C6C6@core3.amsl.com> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 26 Mar 2008 16:04:48.0071 (UTC) FILETIME=[1D8E2570:01C88F5B] X-Nokia-AV: Clean Subject: [Tsvwg] reviewers needed: draft-ietf-tsvwg-port-randomization-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-10-607020911 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, Mark, Joe and some other have commented on the previous version. This update attempts top reflect these comments. I'd like to encourage folks to give this a read; your chairs are interested in hearing about how close to done you think this is. Thanks, Lars On 2008-2-26, at 0:00, ext i-d-announce-bounces@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Area Working Group > Working Group of the IETF. > > > Title : Port Randomization > Author(s) : M. Larsen, F. Gont > Filename : draft-ietf-tsvwg-port-randomization-01.txt > Pages : 25 > Date : 2008-02-25 > > Recently, awareness has been raised about a number of "blind" attacks > that can be performed against the Transmission Control Protocol (TCP) > and similar protocols. The consequences of these attacks range from > throughput-reduction to broken connections or data corruption. These > attacks rely on the attacker's ability to guess or know the five- > tuple (Protocol, Source Address, Destination Address, Source Port, > Destination Port) that identifies the transport protocol instance to > be attacked. This document describes a simple and efficient method > for random selection of the client port number, such that the > possibility of an attacker guessing the exact value is reduced. > While this is not a replacement for cryptographic methods, the > described port number randomization algorithms provide improved > security/obfuscation with very little effort and without any key > management overhead. The mechanisms described in this document are a > local modification that may be incrementally deployed, and that does > not violate the specifications of any of the transport protocols that > may benefit from it, such as TCP, UDP, SCTP, DCCP, and RTP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-tsvwg-port-randomization-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2008-02-25135814.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > http://www.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-10-607020911 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDMyNjE2MDQ0N1owIwYJKoZI hvcNAQkEMRYEFC7FJm9Hi9x+kqVsI8Bf2OMmoA2wMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQCNLsT69uiyP0xwja0puDb4IQ6R 6w9mfhkj9u6G/RANCtiQQJwK5Jfmha2mJiTWrAeRUfOSN/ts/Oj2V50Rm0bHKtz6cMWCgSdkAHHg 2m5fctMcvw+3rsR1LBwvt+RQN4eVJY7caSu7wltijDHhhJk9ncbsnHzXpQmcYfDNFvwAvQw7KJMO etXwDvHpdcQ8qdudyDAjj6vXCeQM/sEPDye6vlYTwhbt1sFny7qrUWkCFp1HymXxgAftC63Z94vC v5T53S+KN07IEkj5LCI4hGjhlmQpDOtBGSLxFzDRAYqW02Kmnx8r+mvy/pHuxTCeM7OfPJ6+fcx7 kb6HV3EIIEMUAAAAAAAA --Apple-Mail-10-607020911-- From tsvwg-bounces@ietf.org Wed Mar 26 09:42:21 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1111528C6A3; Wed, 26 Mar 2008 09:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.404 X-Spam-Level: X-Spam-Status: No, score=-4.404 tagged_above=-999 required=5 tests=[AWL=1.845, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 d7YVnbQmJNOM; Wed, 26 Mar 2008 09:42:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40533A6F54; Wed, 26 Mar 2008 09:42:20 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CD128C68A for ; Wed, 26 Mar 2008 09:42:19 -0700 (PDT) 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 JTHmGtrBdjC0 for ; Wed, 26 Mar 2008 09:42:13 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A8ECE28C694 for ; Wed, 26 Mar 2008 09:42:13 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 63E1720782 for ; Wed, 26 Mar 2008 17:30:55 +0100 (CET) X-AuditID: c1b4fb3c-ac898bb00000193b-1a-47ea7a3f325d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 55F972075A for ; Wed, 26 Mar 2008 17:30:55 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 17:30:54 +0100 Received: from [127.0.0.1] ([147.214.30.213]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 17:30:49 +0100 Message-ID: <47EA7A3A.7070900@ericsson.com> Date: Wed, 26 Mar 2008 17:30:50 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Magnus Westerlund References: <47C40EE1.7090700@ericsson.com> In-Reply-To: <47C40EE1.7090700@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2008 16:30:49.0943 (UTC) FILETIME=[C080E670:01C88F5E] X-Brightmail-Tracker: AAAAAA== Cc: tsvwg Subject: Re: [Tsvwg] WG last call: draft-ietf-tsvwg-admitted-realtime-dscp-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Magnus Westerlund skrev: > This announces the WG last call on "DSCPs for Capacity-Admitted Traffic" > with the intended status of Proposed Standard. Due to IETF meeting the > WG last call will run for 3 weeks. The WG last call ends the 20th of March. > > http://tools.ietf.org/id/draft-ietf-tsvwg-admitted-realtime-dscp-04.txt This WG last call has ended. There are some comments that needs to be resolved before progressing this. 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Wed Mar 26 10:06:56 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC7D3A6DD2; Wed, 26 Mar 2008 10:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.457 X-Spam-Level: X-Spam-Status: No, score=-4.457 tagged_above=-999 required=5 tests=[AWL=1.792, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 pRUSWDto7wyl; Wed, 26 Mar 2008 10:06:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD5028C57C; Wed, 26 Mar 2008 10:06:53 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94BF63A6F5A; Wed, 26 Mar 2008 10:06:46 -0700 (PDT) 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 ta6uIQ-dlNPV; Wed, 26 Mar 2008 10:06:44 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 034F828C24D; Wed, 26 Mar 2008 10:06:34 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 40D8622A77; Wed, 26 Mar 2008 17:32:07 +0100 (CET) X-AuditID: c1b4fb3e-ae198bb000004ec0-ae-47ea7a875eea Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 33F172110A; Wed, 26 Mar 2008 17:32:07 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 17:32:06 +0100 Received: from [127.0.0.1] ([147.214.30.213]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 17:32:06 +0100 Message-ID: <47EA7A86.8000209@ericsson.com> Date: Wed, 26 Mar 2008 17:32:06 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Magnus Westerlund References: <47C58EB8.1000203@ericsson.com> In-Reply-To: <47C58EB8.1000203@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2008 16:32:06.0767 (UTC) FILETIME=[EE4B4FF0:01C88F5E] X-Brightmail-Tracker: AAAAAA== Cc: dime@ietf.org, tsvwg , NSIS Subject: Re: [Tsvwg] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Magnus Westerlund skrev: > 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). > This is a reminder about the WG last call. Without some comments we can't judge consensus on publishing this document. So please provide any comments, even if just to say that it is ready to be published. 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Wed Mar 26 10:07:58 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF7928C660; Wed, 26 Mar 2008 10:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.271 X-Spam-Level: X-Spam-Status: No, score=-4.271 tagged_above=-999 required=5 tests=[AWL=1.978, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 d4VstPhFlQv7; Wed, 26 Mar 2008 10:07:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215D23A6F2B; Wed, 26 Mar 2008 10:07:58 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8023A692C for ; Wed, 26 Mar 2008 10:07:57 -0700 (PDT) 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 zW9CGsnvRBIu for ; Wed, 26 Mar 2008 10:07:51 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C82073A6CA1 for ; Wed, 26 Mar 2008 10:07:51 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7C9AE22D7C for ; Wed, 26 Mar 2008 17:34:46 +0100 (CET) X-AuditID: c1b4fb3e-b019cbb000004ec0-85-47ea7b26070e Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6B5D122D46 for ; Wed, 26 Mar 2008 17:34:46 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 17:34:46 +0100 Received: from [127.0.0.1] ([147.214.30.213]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 17:34:45 +0100 Message-ID: <47EA7B25.6080502@ericsson.com> Date: Wed, 26 Mar 2008 17:34:45 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tsvwg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2008 16:34:45.0654 (UTC) FILETIME=[4CFF8B60:01C88F5F] X-Brightmail-Tracker: AAAAAA== Subject: [Tsvwg] Adopt draft-brisco-tsvwg-byte-pkt-mark as WG item? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, At the IETF meeting we had an good discussion around Bob's "Byte and Packet Congestion Notification" draft: http://tools.ietf.org/wg/tsvwg/draft-briscoe-tsvwg-byte-pkt-mark-02.txt There seems to be interest in this and a meaningful document for TSVWG to take on. So please provide your view if this should become a WG document now or not. Deadline for comments are 10th of April. Best Regards 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 ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Wed Mar 26 11:44:24 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350DA28C4A9; Wed, 26 Mar 2008 11:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 RwzwoEX13jXh; Wed, 26 Mar 2008 11:44:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43773A6CCE; Wed, 26 Mar 2008 11:44:23 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9B13A6CCE for ; Wed, 26 Mar 2008 11:44:22 -0700 (PDT) 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 yhV0UDlptXer for ; Wed, 26 Mar 2008 11:44:16 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 640613A6BCD for ; Wed, 26 Mar 2008 11:44:16 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 26 Mar 2008 11:41:57 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2QIfvVd024580; Wed, 26 Mar 2008 11:41:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2QIfvcl012859; Wed, 26 Mar 2008 18:41:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 11:41:56 -0700 Received: from [10.32.241.73] ([10.32.241.73]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 11:41:56 -0700 In-Reply-To: <47EA7B25.6080502@ericsson.com> References: <47EA7B25.6080502@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Wed, 26 Mar 2008 14:41:54 -0400 To: Magnus Westerlund X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 26 Mar 2008 18:41:56.0535 (UTC) FILETIME=[115B9470:01C88F71] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1094; t=1206556917; x=1207420917; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bdavie@cisco.com; z=From:=20Bruce=20Davie=20 |Subject:=20Re=3A=20[Tsvwg]=20Adopt=20draft-brisco-tsvwg-by te-pkt-mark=20as=20WG=20item? |Sender:=20; bh=A8snWnX7pJ+SUg8HponPZeEokTXJzCl20hd2ZCzuWYk=; b=iRfsfwIai1MLK1Mcsvhkl3G17WH/j/6Lrdt3SebBEDGomcE5Qe2MPZ1hjH T/slyxeunL08otvnzOjcUfdK2cDHaC1dp7h2+EmR2Go6YKElLzoIBBDOCH3b xICYWTS/ZskLYZFmcGmwl+y1zDF99yKNqH2GR8JDVTLoalPiOofbk=; Authentication-Results: sj-dkim-1; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tsvwg Subject: Re: [Tsvwg] Adopt draft-brisco-tsvwg-byte-pkt-mark as WG item? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org I would like to see the Wg take this on as a work item. Bruce On Mar 26, 2008, at 12:34 PM, Magnus Westerlund wrote: > Hi, > > At the IETF meeting we had an good discussion around Bob's "Byte > and Packet Congestion Notification" draft: > http://tools.ietf.org/wg/tsvwg/draft-briscoe-tsvwg-byte-pkt- > mark-02.txt > > There seems to be interest in this and a meaningful document for > TSVWG to take on. So please provide your view if this should become > a WG document now or not. Deadline for comments are 10th of April. > > Best Regards > > 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 > ---------------------------------------------------------------------- > From tsvwg-bounces@ietf.org Thu Mar 27 07:31:01 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797003A69EA; Thu, 27 Mar 2008 07:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=2.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 q4ATYQRewxu9; Thu, 27 Mar 2008 07:31:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340593A6C26; Thu, 27 Mar 2008 07:31:01 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E543A6D71 for ; Thu, 27 Mar 2008 07:30:59 -0700 (PDT) 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 TGjgKcC5PemT for ; Thu, 27 Mar 2008 07:30:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6222A3A6C26 for ; Thu, 27 Mar 2008 07:30:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,563,1199660400"; d="scan'208";a="4618329" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2008 15:28:21 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2RESL3n031584; Thu, 27 Mar 2008 15:28:21 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2RESL2p025071; Thu, 27 Mar 2008 14:28:21 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 15:28:21 +0100 Received: from [10.0.0.14] ([10.61.65.83]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 15:28:20 +0100 In-Reply-To: <47EA7A86.8000209@ericsson.com> References: <47C58EB8.1000203@ericsson.com> <47EA7A86.8000209@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Date: Thu, 27 Mar 2008 15:28:15 +0100 To: Magnus Westerlund X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 27 Mar 2008 14:28:20.0999 (UTC) FILETIME=[CE9AC970:01C89016] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2231; t=1206628101; x=1207492101; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[Dime]=20[NSIS]=20WG=20last=20call=20on =20draft-ietf-tsvwg-emergency-rsvp-05 |Sender:=20; bh=S892AaVnFtMRFK2nrTglk0qWr3K3s4egc1nl8mrxO/g=; b=kxc03MDPXB66E/ZWfcUa9MJrgy+IlHrO/wBliIz+ADqRQ93nAmkPHUG3so BCNLjpWo/256PCi10q4zACPo68rBk77nUeDOkw8OljJBP9Oko1Qqq3Sp8wDp Q/S8PpOlRD; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: tsvwg list IETF Subject: Re: [Tsvwg] [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi Magnus, There are a couple small items that needs to be fixed: - adding a reference to MAR in response to Jerry's Last Call comments (as agreed in http://www.ietf.org/mail-archive/web/tsvwg/ current/msg08209.html) - updating reference text to NSIS Admission Priority in line with NSIS WG consensus (as per your message in http://www.ietf.org/mail- archive/web/tsvwg/current/msg08231.html) Other than that, from my perspective, the document is ready for publication. We'll wait a few more days in case there are more belated comments from WG Last Call and issue an new version addressing the above two minor items. Thanks Francois On 26 Mar 2008, at 17:32, Magnus Westerlund wrote: > Magnus Westerlund skrev: >> 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). >> > > This is a reminder about the WG last call. Without some comments we > can't judge consensus on publishing this document. So please > provide any > comments, even if just to say that it is ready to be published. > > 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: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From tsvwg-bounces@ietf.org Thu Mar 27 08:01:45 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B7828C8C5; Thu, 27 Mar 2008 08:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=1.756, BAYES_00=-2.599] 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 iovHYqHx8P6U; Thu, 27 Mar 2008 08:01:45 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC053A6FD8; Thu, 27 Mar 2008 08:01:37 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72AEC28CA2F for ; Thu, 27 Mar 2008 08:01:33 -0700 (PDT) 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 MyaBjM84CbmP for ; Thu, 27 Mar 2008 08:01:32 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id E6A1C3A7149 for ; Thu, 27 Mar 2008 08:00:54 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id 6AXJ1Z0020S2fkCA90P000; Thu, 27 Mar 2008 14:57:29 +0000 Received: from [192.168.1.120] ([69.255.76.43]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id 6EyX1Z00B0w3GCt8V00000; Thu, 27 Mar 2008 14:58:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=4USeCAh87kQA:10 a=JoVHi_vjK0X4OA9ylPQA:9 a=23Dm_h8njy9HCPK9kgaYRpkCWh8A:4 a=vNGxQsTWjH8A:10 Message-Id: From: ken carlberg To: Francois Le Faucheur IMAP In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 27 Mar 2008 10:58:31 -0400 References: <47C58EB8.1000203@ericsson.com> <47EA7A86.8000209@ericsson.com> X-Mailer: Apple Mail (2.919.2) Cc: Magnus Westerlund , tsvwg list IETF Subject: Re: [Tsvwg] [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Magnus, On Mar 27, 2008, at 10:28 AM, Francois Le Faucheur IMAP wrote: > Other than that, from my perspective, the document is ready for > publication. I concur. The current version and the subsequent from Francois wrap up the loose end from last November of making sure our draft, the QSPEC in NSIS, and the QoS Parameters draft from DIME are in synch with several common fields. So any last comments of this last Last Call should be aimed at this agreement -- and hopefully, there are none :-) As a side note, I hope there isn't a need to revisit the issue of interest in the document. If needed, I can dig up the comments from the past year along with meetings minutes. cheers, -ken From tsvwg-bounces@ietf.org Thu Mar 27 18:08:53 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C977C28C19C; Thu, 27 Mar 2008 18:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 1zVnR9zWL8GW; Thu, 27 Mar 2008 18:08:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6EA3A6951; Thu, 27 Mar 2008 18:08:52 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27743A6823; Thu, 27 Mar 2008 18:08:51 -0700 (PDT) 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 sgybk5SGfjj2; Thu, 27 Mar 2008 18:08:50 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id 9CE4B3A683F; Thu, 27 Mar 2008 18:08:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-14.tower-171.messagelabs.com!1206666458!1871599!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 14531 invoked from network); 28 Mar 2008 01:08:45 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-14.tower-171.messagelabs.com with AES256-SHA encrypted SMTP; 28 Mar 2008 01:08:45 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id m2S1BIZJ013164; Thu, 27 Mar 2008 21:11:18 -0400 In-Reply-To: <47EA7A86.8000209@ericsson.com> To: Magnus Westerlund MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 27 Mar 2008 21:07:28 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 03/27/2008 09:10:45 PM, Serialize complete at 03/27/2008 09:10:45 PM Content-Type: multipart/alternative; boundary="=_alternative 0005680D8525741A_=" Cc: Magnus Westerlund , dime@ietf.org, nsis-bounces@ietf.org, NSIS , tsvwg Subject: Re: [Tsvwg] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org This is a multipart message in MIME format. --=_alternative 0005680D8525741A_= Content-Type: text/plain; charset="US-ASCII" Just saying that, from my perspective, "it is ready to be published". And, yes I have read it and followed the discussions on the related DIME and NSIS documents. Janet Gunn Computer Sciences Corporation Registered Office: 2100 East Grand Avenue, El Segundo California 90245, USA Registered in USA No: C-489-59 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- nsis-bounces@ietf.org wrote on 03/26/2008 12:32:06 PM: > Magnus Westerlund skrev: > > 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). > > > > This is a reminder about the WG last call. Without some comments we > can't judge consensus on publishing this document. So please provide any > comments, even if just to say that it is ready to be published. > > 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: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis --=_alternative 0005680D8525741A_= Content-Type: text/html; charset="US-ASCII"
Just saying that, from my perspective, "it is ready to be published".  And, yes I have read it and followed the discussions on the related DIME and NSIS documents.

Janet Gunn

Computer Sciences Corporation
Registered Office: 2100 East Grand Avenue, El Segundo California 90245, USA
Registered in USA No: C-489-59

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

nsis-bounces@ietf.org wrote on 03/26/2008 12:32:06 PM:

> Magnus Westerlund skrev:
> > 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).
> >
>
> This is a reminder about the WG last call. Without some comments we
> can't judge consensus on publishing this document. So please provide any
> comments, even if just to say that it is ready to be published.
>
> 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www.ietf.org/mailman/listinfo/nsis
 --=_alternative 0005680D8525741A_=-- From tsvwg-bounces@ietf.org Fri Mar 28 08:03:36 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6095B3A6E5D; Fri, 28 Mar 2008 08:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599] 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 IUNHMOvPLf3N; Fri, 28 Mar 2008 08:03:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDC328CA22; Fri, 28 Mar 2008 08:00:20 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D48CA28C9D6 for ; Fri, 28 Mar 2008 08:00:18 -0700 (PDT) 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 c3h8JBsMxNwH for ; Fri, 28 Mar 2008 08:00:13 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 7B0D728C976 for ; Fri, 28 Mar 2008 08:00:08 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m2SExtgc019490; Fri, 28 Mar 2008 14:59:55 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m2SExkFa019273; Fri, 28 Mar 2008 14:59:53 GMT Message-ID: <04fd01c890e4$595cb410$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Bruce Davie" , References: <19B39207-48AD-45DF-9AFD-85CF40A73A63@cisco.com> Date: Fri, 28 Mar 2008 14:58:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: George Swallow Subject: Re: [Tsvwg] Comments on draft-ietf-tsvwg-rsvp-user-error-spec-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Bruce, Thanks for reading. Please see in line. Adrian >I believe the chairs were looking for some reviews on this draft > before letting it go past last call. Here is one. > > Summary: the draft looks basically fine to me. > > Minor comments to show that I read it. > > Bruce > >> >> 2. User-Defined Error >> >> A new Error Code is defined for use in an ERROR_SPEC object. >> >> Error Code = : User Error Spec >> >> This error code is used to signal the presence of a >> USER_ERROR_SPEC. No subcodes are defined. > > RFC2205 users the term "Error Value" rather than "subcode". I suggest > using the same terminology here. Good. >> 3. USER_ERROR_SPEC Class >> >> A new RSVP object class is defined called the the USER_ERROR_SPEC >> Class. The class number is taken from the range 192 - 247. This is >> done for backward compatibility. Existing implementations will >> ignore the object and pass it along according to the rules of >> [RFC2205]. >> > > I thought this could be written a little more clearly (especially > when you consider that, when this is published, there will be an > actual class number assigned). How about this: > > A new RSVP object class called USER_ERROR_SPEC is defined. To support > backwards compatibility, its class number is in the range 192-247. As > defined in [RFC2205], implementations that do not understand such an > object will forward it unmodified. OK >> User Error Value >> >> A 16-bit integer. The format and contents are specified by >> the (sub-)organization indicated by the Enterprise Number >> and Sub Org fields. > > I think what you mean to say its *meaning* is specified by the (sub-) > organization indicated by the Enterprise Number and Sub Org fields. Yup. >> 4.2 > [...] >> Implementations receiving a USER_ERROR_SPEC object on some message >> other than a PathErr, ResvErr, or Notify message MUST treat the >> error as a malformed message and process according to [RFC2205]. > > RFC2205 allows ERROR_SPEC objects in ResvConf messages. I suggest the > USER_ERROR_SPEC should also be allowed to appear in those messages. In fact, the ERROR_SPEC is mandatory on the ResvConf, but RFC 2205 says: The ERROR_SPEC is used only to carry the IP address of the originating node, in the Error Node Address; the Error Code and Value are zero to indicate a confirmation. So there would never be cause to include USER_ERROR_SPEC. Or would there? From tsvwg-bounces@ietf.org Fri Mar 28 08:04:48 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7343A6E16; Fri, 28 Mar 2008 08:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=1.546, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] 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 cEvYlrNSIUNS; Fri, 28 Mar 2008 08:04:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2357E28C924; Fri, 28 Mar 2008 08:04:42 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B5528C9FD for ; Fri, 28 Mar 2008 08:04:33 -0700 (PDT) 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 8bcBcjn9TQez for ; Fri, 28 Mar 2008 08:04:06 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 6412D28CAD0 for ; Fri, 28 Mar 2008 08:00:37 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 15:00:35 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 15:00:34 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1206716440163; Fri, 28 Mar 2008 15:00:40 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2SF0Xls031774; Fri, 28 Mar 2008 15:00:33 GMT Message-Id: <200803281500.m2SF0Xls031774@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 28 Mar 2008 15:00:45 +0000 To: Fred Baker From: Bob Briscoe In-Reply-To: References: <47EA7B25.6080502@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 28 Mar 2008 15:00:34.0935 (UTC) FILETIME=[79BBC070:01C890E4] Cc: Magnus Westerlund , tsvwg Subject: Re: [Tsvwg] Adopt draft-brisco-tsvwg-byte-pkt-mark as WG item? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Fred, I'm interested to know whether you still have objections to this one? I tried to accommodate you in the latest text. Bob At 18:41 26/03/2008, Bruce Davie wrote: >I would like to see the Wg take this on as a work item. > >Bruce > >On Mar 26, 2008, at 12:34 PM, Magnus Westerlund wrote: > >>Hi, >> >>At the IETF meeting we had an good discussion around Bob's "Byte >>and Packet Congestion Notification" draft: >>http://tools.ietf.org/wg/tsvwg/draft-briscoe-tsvwg-byte-pkt- mark-02.txt >> >>There seems to be interest in this and a meaningful document for >>TSVWG to take on. So please provide your view if this should become >>a WG document now or not. Deadline for comments are 10th of April. >> >>Best Regards >> >>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 >>---------------------------------------------------------------------- ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Fri Mar 28 08:06:37 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6F228C29E; Fri, 28 Mar 2008 08:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.625 X-Spam-Level: X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[AWL=1.374, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] 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 JE5ueGuRgnME; Fri, 28 Mar 2008 08:06:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5883A6AB5; Fri, 28 Mar 2008 08:06:37 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B67C3A6A0F for ; Fri, 28 Mar 2008 08:06:35 -0700 (PDT) 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 rCQyGrrB+p4G for ; Fri, 28 Mar 2008 08:06:27 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id ED16928C1CF for ; Fri, 28 Mar 2008 08:06:26 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 15:06:25 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 15:05:52 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1206716752426; Fri, 28 Mar 2008 15:05:52 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2SF5nfJ031990; Fri, 28 Mar 2008 15:05:49 GMT Message-Id: <200803281505.m2SF5nfJ031990@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 28 Mar 2008 15:06:01 +0000 To: Magnus Westerlund From: Bob Briscoe In-Reply-To: <47EA7B25.6080502@ericsson.com> References: <47EA7B25.6080502@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 28 Mar 2008 15:05:52.0697 (UTC) FILETIME=[37226290:01C890E5] Cc: tsvwg Subject: Re: [Tsvwg] Adopt draft-briscoe-tsvwg-byte-pkt-mark as WG item? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Magnus, I've corrected a typo in the filename in the subject line, so people can find it more easily. Bob At 16:34 26/03/2008, Magnus Westerlund wrote: >Hi, > >At the IETF meeting we had an good discussion around Bob's "Byte and >Packet Congestion Notification" draft: >http://tools.ietf.org/wg/tsvwg/draft-briscoe-tsvwg-byte-pkt-mark-02.txt > >There seems to be interest in this and a meaningful document for >TSVWG to take on. So please provide your view if this should become >a WG document now or not. Deadline for comments are 10th of April. > >Best Regards > >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 >---------------------------------------------------------------------- ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Fri Mar 28 09:52:16 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF0628C2CF; Fri, 28 Mar 2008 09:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 2iSjvbE0clHA; Fri, 28 Mar 2008 09:52:16 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4CB3A696F; Fri, 28 Mar 2008 09:52:16 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A543A69E2 for ; Fri, 28 Mar 2008 09:52:15 -0700 (PDT) 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 K+DeJHY2P-PL for ; Fri, 28 Mar 2008 09:52:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 085453A696F for ; Fri, 28 Mar 2008 09:52:11 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Mar 2008 09:52:10 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2SGqAAF008299; Fri, 28 Mar 2008 09:52:10 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2SGqAqD013064; Fri, 28 Mar 2008 16:52:10 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 09:52:10 -0700 Received: from [10.32.241.73] ([10.32.241.73]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 09:52:09 -0700 In-Reply-To: <04fd01c890e4$595cb410$0300a8c0@your029b8cecfe> References: <19B39207-48AD-45DF-9AFD-85CF40A73A63@cisco.com> <04fd01c890e4$595cb410$0300a8c0@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Content-Type: multipart/alternative; boundary=Apple-Mail-13-782659721 Message-Id: <6F8C232D-5A39-47A8-9975-14F8DE5C6EEC@cisco.com> From: Bruce Davie Date: Fri, 28 Mar 2008 12:52:06 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 28 Mar 2008 16:52:09.0815 (UTC) FILETIME=[10315E70:01C890F4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5444; t=1206723130; x=1207587130; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bdavie@cisco.com; z=From:=20Bruce=20Davie=20 |Subject:=20Re=3A=20Comments=20on=20draft-ietf-tsvwg-rsvp-u ser-error-spec-03.txt=20 |Sender:=20; bh=zUS1cF+QW0cFCuEFQBjfBOKmnOIxCsOz4coi46TIGN4=; b=NhnUzfOfUJJ+tj0MLnWNZ+gIFtO5jB0jp2G/Qqs8v7ZFcYICZZRBr0y7+c 4VprHkUVyPhkK8syJMbtgKWbEW5rsG0Z0tX8CZj1wR7SBKvEr6nk7s+m4X++ B2neA2buqg; Authentication-Results: sj-dkim-3; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: George Swallow , tsvwg@ietf.org Subject: Re: [Tsvwg] Comments on draft-ietf-tsvwg-rsvp-user-error-spec-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-13-782659721 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Adrian, [points of agreement clipped] On Mar 28, 2008, at 10:58 AM, Adrian Farrel wrote: > >>> 4.2 >> [...] >>> Implementations receiving a USER_ERROR_SPEC object on some >>> message >>> other than a PathErr, ResvErr, or Notify message MUST treat the >>> error as a malformed message and process according to [RFC2205]. >> RFC2205 allows ERROR_SPEC objects in ResvConf messages. I suggest >> the USER_ERROR_SPEC should also be allowed to appear in those >> messages. > > In fact, the ERROR_SPEC is mandatory on the ResvConf, but RFC 2205 > says: > > The ERROR_SPEC is > used only to carry the IP address of the originating node, in > the Error Node Address; the Error Code and Value are zero to > indicate a confirmation. > > So there would never be cause to include USER_ERROR_SPEC. Or would > there? Your reasoning seems sound to me. Perhaps you want to put in a sentence along these lines to avoid future readers scratching their heads as I did. So, with the few changes that I sent previously and that you agreed to, I think this document would be ready for publication. Bruce --Apple-Mail-13-782659721 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Adrian,
[points of agreement = clipped]

On Mar 28, 2008, at 10:58 AM, Adrian Farrel = wrote:


4.2

[...]

=A0= =A0 Implementations receiving a USER_ERROR_SPEC object on some = message

=A0=A0 other than a PathErr, = ResvErr, or Notify message MUST treat the

=A0= =A0 error as a malformed message and process according to = [RFC2205].

RFC2205 allows ERROR_SPEC objects in ResvConf messages. I = suggest the=A0 = USER_ERROR_SPEC should also be allowed to appear in those = messages.


In fact, the ERROR_SPEC is = mandatory on the ResvConf, but RFC 2205 says:


=A0 =A0 =A0 =A0 = The ERROR_SPEC is

=A0 =A0 =A0 =A0 = used only to carry the IP address of the originating node, = in

=A0 =A0 =A0 =A0 the Error Node = Address; the Error Code and Value are zero to

=A0 =A0 =A0 =A0 indicate a = confirmation.


So there would never be cause to = include USER_ERROR_SPEC. Or would there?

=

Your reasoning seems sound to me. Perhaps = you want to put in a sentence along these lines to avoid future readers = scratching their heads as I did.

So, with the = few changes that I sent previously and that you agreed to, I think this = document would be ready for = publication.

Bruce

= --Apple-Mail-13-782659721-- From tsvwg-bounces@ietf.org Fri Mar 28 10:08:56 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A53828C6F1; Fri, 28 Mar 2008 10:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 k7W2aT3j+z4f; Fri, 28 Mar 2008 10:08:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35163A6CED; Fri, 28 Mar 2008 10:08:55 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8688B3A6CED for ; Fri, 28 Mar 2008 10:08:55 -0700 (PDT) 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 CpqXiS04J++U for ; Fri, 28 Mar 2008 10:08:54 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 67ECD3A6BE5 for ; Fri, 28 Mar 2008 10:08:54 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m2SH8DxA017326; Fri, 28 Mar 2008 17:08:13 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m2SH8CJt017307; Fri, 28 Mar 2008 17:08:13 GMT Message-ID: <054e01c890f6$495745f0$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Bruce Davie" References: <19B39207-48AD-45DF-9AFD-85CF40A73A63@cisco.com> <04fd01c890e4$595cb410$0300a8c0@your029b8cecfe> <6F8C232D-5A39-47A8-9975-14F8DE5C6EEC@cisco.com> Date: Fri, 28 Mar 2008 17:08:01 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: George Swallow , tsvwg@ietf.org Subject: Re: [Tsvwg] Comments on draft-ietf-tsvwg-rsvp-user-error-spec-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Thanks Bruce! I made the changes you suggested and added a note about ResvConf. New version submitted. Cheers, Adrian ----- Original Message ----- From: "Bruce Davie" To: "Adrian Farrel" Cc: ; "George Swallow" Sent: Friday, March 28, 2008 4:52 PM Subject: Re: Comments on draft-ietf-tsvwg-rsvp-user-error-spec-03.txt > > Adrian, > [points of agreement clipped] > > On Mar 28, 2008, at 10:58 AM, Adrian Farrel wrote: > >> >>>> 4.2 >>> [...] >>>> Implementations receiving a USER_ERROR_SPEC object on some >>>> message >>>> other than a PathErr, ResvErr, or Notify message MUST treat the >>>> error as a malformed message and process according to [RFC2205]. >>> RFC2205 allows ERROR_SPEC objects in ResvConf messages. I suggest >>> the USER_ERROR_SPEC should also be allowed to appear in those >>> messages. >> >> In fact, the ERROR_SPEC is mandatory on the ResvConf, but RFC 2205 >> says: >> >> The ERROR_SPEC is >> used only to carry the IP address of the originating node, in >> the Error Node Address; the Error Code and Value are zero to >> indicate a confirmation. >> >> So there would never be cause to include USER_ERROR_SPEC. Or would >> there? > > Your reasoning seems sound to me. Perhaps you want to put in a > sentence along these lines to avoid future readers scratching their > heads as I did. > > So, with the few changes that I sent previously and that you agreed > to, I think this document would be ready for publication. > > Bruce > > From tsvwg-bounces@ietf.org Fri Mar 28 10:15:05 2008 Return-Path: X-Original-To: ietfarch-tsvwg-archive@core3.amsl.com Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847A428C9B6; Fri, 28 Mar 2008 10:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, 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 CrZ6jM0-Q8hp; Fri, 28 Mar 2008 10:15:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC5328C967; Fri, 28 Mar 2008 10:15:04 -0700 (PDT) X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B51F628C96B; Fri, 28 Mar 2008 10:15:02 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080328171502.B51F628C96B@core3.amsl.com> Date: Fri, 28 Mar 2008 10:15:02 -0700 (PDT) Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-rsvp-user-error-spec-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : User-Defined Errors for RSVP Author(s) : G. Swallow, A. Farrel Filename : draft-ietf-tsvwg-rsvp-user-error-spec-04.txt Pages : 8 Date : 2008-03-28 The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP. This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-rsvp-user-error-spec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-28100720.I-D@ietf.org> --NextPart-- From tsvwg-bounces@ietf.org Sun Mar 30 23:21:12 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0EA828C39D; Sun, 30 Mar 2008 23:21:12 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A5A28C39D for ; Sun, 30 Mar 2008 23:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-4] 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 fk4WykeF+mKv for ; Sun, 30 Mar 2008 23:21:10 -0700 (PDT) Received: from smtp.uibk.ac.at (lmr1.uibk.ac.at [138.232.1.142]) by core3.amsl.com (Postfix) with ESMTP id E5C5328C38C for ; Sun, 30 Mar 2008 23:21:09 -0700 (PDT) Received: from [138.232.65.105] (pc105-c703.uibk.ac.at [138.232.65.105] michael.welzl@uibk.ac.at) (authenticated bits=0) by smtp.uibk.ac.at (8.13.8/8.13.8/F1) with ESMTP id m2V6L0MJ001592 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 31 Mar 2008 08:21:00 +0200 From: Michael Welzl To: Magnus Westerlund In-Reply-To: <47EA7B25.6080502@ericsson.com> References: <47EA7B25.6080502@ericsson.com> Content-Type: text/plain Organization: University of Innsbruck Date: Mon, 31 Mar 2008 08:21:00 +0200 Message-Id: <1206944460.3731.21.camel@pc105-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 at uibk.ac.at on 138.232.1.140 Cc: tsvwg Subject: Re: [Tsvwg] Adopt draft-brisco-tsvwg-byte-pkt-mark as WG item? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org On Wed, 2008-03-26 at 17:34 +0100, Magnus Westerlund wrote: > Hi, > > At the IETF meeting we had an good discussion around Bob's "Byte and > Packet Congestion Notification" draft: > http://tools.ietf.org/wg/tsvwg/draft-briscoe-tsvwg-byte-pkt-mark-02.txt > > There seems to be interest in this and a meaningful document for TSVWG > to take on. So please provide your view if this should become a WG > document now or not. Deadline for comments are 10th of April. Being silent on this list as I am, I feel as if I don't even have the right to speak up - but still, yes, I think it should be a WG item! Cheers, Michael From tsvwg-bounces@ietf.org Mon Mar 31 07:05:23 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91F028C47C; Mon, 31 Mar 2008 07:05:22 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED8828C488; Mon, 31 Mar 2008 07:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 J5iNt0rQ+2KJ; Mon, 31 Mar 2008 07:05:18 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E214428C494; Mon, 31 Mar 2008 07:05:17 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4203D2367B; Mon, 31 Mar 2008 15:44:18 +0200 (CEST) X-AuditID: c1b4fb3e-ab192bb000004ec0-30-47f0eab29011 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2EA3523677; Mon, 31 Mar 2008 15:44:18 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 15:44:17 +0200 Received: from [127.0.0.1] ([147.214.30.213]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 15:44:17 +0200 Message-ID: <47F0EAB0.8090504@ericsson.com> Date: Mon, 31 Mar 2008 15:44:16 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Magnus Westerlund References: <47B560E3.2010506@ericsson.com> <47D927AD.3020900@ericsson.com> In-Reply-To: <47D927AD.3020900@ericsson.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2008 13:44:17.0453 (UTC) FILETIME=[5094ADD0:01C89335] X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org, ccamp@ietf.org, tsvwg Subject: Re: [Tsvwg] WG last call for draft-ietf-tsvwg-rsvp-user-error-spec-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, Version 04 is now available. I am still waiting for at least one more review before requesting publication. http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-04.txt Cheers Magnus Magnus Westerlund skrev: > Hi, > > This WG last call has now timed out. However, as there has not been a > single comment it will continue until we actually get at least 3 > reviewers stating that they have read it and find it ready to progress. > > Cheers > > Magnus > > Magnus Westerlund skrev: >> This announces a WG last call for "User-Defined Errors for RSVP" to be >> published as proposed standard. Please provide any comments by March >> 7. (Yes, you get an extra week due to the just before the meeting time >> of this last call). >> >> CCAMP and MPLS WG participants, please provide your comments to TSVWG. >> >> You can find the draft here: >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-03.txt >> >> >> Regards >> >> 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 >> ---------------------------------------------------------------------- >> >> > > -- 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 ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Mon Mar 31 07:08:37 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C01028C4B2; Mon, 31 Mar 2008 07:08:37 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8673A6930 for ; Mon, 31 Mar 2008 07:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 odoHquLlhi8B for ; Mon, 31 Mar 2008 07:08:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9678728C4DE for ; Mon, 31 Mar 2008 07:07:17 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DD1BA23934; Mon, 31 Mar 2008 15:47:58 +0200 (CEST) X-AuditID: c1b4fb3e-ae198bb000004ec0-d3-47f0eb8e0305 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CED2123932; Mon, 31 Mar 2008 15:47:58 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 15:47:58 +0200 Received: from [127.0.0.1] ([147.214.30.213]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 15:47:58 +0200 Message-ID: <47F0EB8C.3020809@ericsson.com> Date: Mon, 31 Mar 2008 15:47:56 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francois Le Faucheur IMAP References: <47C58EB8.1000203@ericsson.com> <47EA7A86.8000209@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2008 13:47:58.0109 (UTC) FILETIME=[D41A1CD0:01C89335] X-Brightmail-Tracker: AAAAAA== Cc: tsvwg list IETF Subject: Re: [Tsvwg] [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Francois Le Faucheur IMAP skrev: > Hi Magnus, > > There are a couple small items that needs to be fixed: > - adding a reference to MAR in response to Jerry's Last Call > comments (as agreed in > http://www.ietf.org/mail-archive/web/tsvwg/current/msg08209.html) > - updating reference text to NSIS Admission Priority in line with > NSIS WG consensus (as per your message in > http://www.ietf.org/mail-archive/web/tsvwg/current/msg08231.html) > > Other than that, from my perspective, the document is ready for > publication. > > We'll wait a few more days in case there are more belated comments from > WG Last Call and issue an new version addressing the above two minor items. > The WG last call has now ended. There are a few issues that needs to be updated. As there has been some contention around this document I will do a short 1-week confirmation call on the updates as soon the new version is available. 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Mon Mar 31 07:42:24 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933763A6C1A; Mon, 31 Mar 2008 07:42:24 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB303A6814; Mon, 31 Mar 2008 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] 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 zsyqOu1XQxIK; Mon, 31 Mar 2008 07:37:43 -0700 (PDT) Received: from mxoutps1.us.army.mil (mxoutps1.us.army.mil [143.69.250.38]) by core3.amsl.com (Postfix) with ESMTP id 8ED503A6E84; Mon, 31 Mar 2008 07:37:41 -0700 (PDT) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=At8qcinbpUzj8nrcxM9rTbcgkjg9AEhl9L1b/lJ2lIau/zVERQ2pqyvJ bsNoxF37j8HB0NSnjzzd/RKXUw43Yg==; From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 116504073:10.224.36.65:31 Mar 2008 14:37:38 +0000:$Webmail:None X-IronPort-AV: E=Sophos;i="4.25,583,1199664000"; d="scan'208";a="116504073" Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 31 Mar 2008 14:37:38 +0000 Received: from [10.240.32.176] (Forwarded-For: 134.80.13.193, [10.240.32.176]) by mail5.int.ps1.us.army.mil (mshttpd); Mon, 31 Mar 2008 10:37:38 -0400 To: Magnus Westerlund ,Janet P Gunn Message-ID: Date: Mon, 31 Mar 2008 10:37:38 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: References: <47EA7A86.8000209@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 31 Mar 2008 07:42:23 -0700 Cc: dime@ietf.org, NSIS , nsis-bounces@ietf.org, tsvwg Subject: Re: [Tsvwg] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, Magnus: There is an important typo in reference to NSIS-QSPEC priority. NSIS-QSPEC is version 19 and resource-priority is in Section 5.2.9 (not Section 6.2.9). More importantly, this draft needs to reference ONLY to this of part of the resource-priority that is successfully resolved by the NSIS WG in relation to the consensus of the QSPEC draft (e.g. not to specifically mention Y.xxxx resource-priority ONLY, etc. because it will create confusions and distractions about the main technical aspects). Ken and other members need to look into this as they have taken the lead in resolving the issues related to the QSSPEC draft. Otherwise, the draft seems to be well-written, and I also agree with Janet other than the above. Sorry that I missed the last Friday's deadline. Best regards, Radhika PS: For SIP and SIPPING WG members: RFC 3312 and RFCs related to SIP call flows need to use the latest RFCs of NSIS and TSVWG for taking care of QOS. ----- Original Message ----- From: Janet P Gunn Date: Thursday, March 27, 2008 21:09 Subject: Re: [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 To: Magnus Westerlund Cc: dime@ietf.org, nsis-bounces@ietf.org, NSIS , tsvwg > Just saying that, from my perspective, "it is ready to be > published". And, > yes I have read it and followed the discussions on the related > DIME and > NSIS documents. > > Janet Gunn > > Computer Sciences Corporation > Registered Office: 2100 East Grand Avenue, El Segundo California > 90245, > USA > Registered in USA No: C-489-59 > > ------------------------------------------------------------------- > ------------------------------------------------------------------- > ------------------------------------------------------------------- > ------- > This is a PRIVATE message. If you are not the intended recipient, > please > delete without copying and kindly advise us by e-mail of the > mistake in > delivery. > NOTE: Regardless of content, this e-mail shall not operate to bind > CSC to > any order or other contract unless pursuant to explicit written > agreement > or government initiative expressly permitting the use of e-mail > for such > purpose. > ------------------------------------------------------------------- > ------------------------------------------------------------------- > ------------------------------------------------------------------- > ------- > > > nsis-bounces@ietf.org wrote on 03/26/2008 12:32:06 PM: > > > Magnus Westerlund skrev: > > > 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). > > > > > > > This is a reminder about the WG last call. Without some comments > we > > can't judge consensus on publishing this document. So please > provide any > > > comments, even if just to say that it is ready to be published. > > > > 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: magnus.westerlund@ericsson.com > > ----------------------------------------------------------------- > ----- > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www.ietf.org/mailman/listinfo/nsis > From tsvwg-bounces@ietf.org Mon Mar 31 11:24:44 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63DDC3A6B49; Mon, 31 Mar 2008 11:24:44 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24DC28C1C5; Mon, 31 Mar 2008 11:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 PvVSrjwX95hv; Mon, 31 Mar 2008 11:24:42 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id C7A7128C13B; Mon, 31 Mar 2008 11:24:41 -0700 (PDT) Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 31 Mar 2008 21:24:37 +0300 id 00067D06.47F12C65.00007099 Date: Mon, 31 Mar 2008 21:24:36 +0300 (EEST) From: Jukka MJ Manner To: Magnus Westerlund In-Reply-To: <47F0EAB0.8090504@ericsson.com> Message-ID: References: <47B560E3.2010506@ericsson.com> <47D927AD.3020900@ericsson.com> <47F0EAB0.8090504@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, ccamp@ietf.org, tsvwg Subject: Re: [Tsvwg] WG last call for draft-ietf-tsvwg-rsvp-user-error-spec-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, I have read the draft, and think it is a reasonable proposal, and presented well. I have just a few minor comments/clarification requests: - What is exactly meant by "it is RECOMMENDED that organizations use a published scheme for this string to promote consistent decoding."? Could you add an example, perhaps? - Is it possible to not include the Error Description? If so, this could be said explicitly. - Is it possible to not include User-defined subobjects? If so, this could be said explicitly. These latter two comments are about making the user error propagation a bit simpler, e.g., one could primarily use the extended number space to define new error values, but leave in some cases the description and subobjects out to save bytes. Regards, Jukka On Mon, 31 Mar 2008, Magnus Westerlund wrote: > Hi, > > Version 04 is now available. I am still waiting for at least one more review > before requesting publication. > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-04.txt > > Cheers > > Magnus > > Magnus Westerlund skrev: > > Hi, > > > > This WG last call has now timed out. However, as there has not been a single > > comment it will continue until we actually get at least 3 reviewers stating > > that they have read it and find it ready to progress. > > > > Cheers > > > > Magnus > > > > Magnus Westerlund skrev: > > > This announces a WG last call for "User-Defined Errors for RSVP" to be > > > published as proposed standard. Please provide any comments by March 7. > > > (Yes, you get an extra week due to the just before the meeting time of > > > this last call). > > > > > > CCAMP and MPLS WG participants, please provide your comments to TSVWG. > > > > > > You can find the draft here: > > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-03.txt > > > > > > > > > Regards > > > > > > 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 > > > ---------------------------------------------------------------------- > > > > > > > > > > > > > From tsvwg-bounces@ietf.org Mon Mar 31 12:45:10 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C0328C455; Mon, 31 Mar 2008 12:45:10 -0700 (PDT) X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4519028C3B8; Mon, 31 Mar 2008 12:45:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080331194501.4519028C3B8@core3.amsl.com> Date: Mon, 31 Mar 2008 12:45:01 -0700 (PDT) Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-emergency-rsvp-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Author(s) : F. Le Faucheur, et al. Filename : draft-ietf-tsvwg-emergency-rsvp-06.txt Pages : 32 Date : 2008-03-31 An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-emergency-rsvp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-31124009.I-D@ietf.org> --NextPart-- From tsvwg-bounces@ietf.org Mon Mar 31 14:48:48 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B152528C39A; Mon, 31 Mar 2008 14:48:48 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9FD228C328; Mon, 31 Mar 2008 14:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 WXo2g5x4aq4z; Mon, 31 Mar 2008 14:48:47 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id BC6FE28C2BB; Mon, 31 Mar 2008 14:48:46 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m2VLmbed016694; Mon, 31 Mar 2008 22:48:37 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m2VLmY7a016679; Mon, 31 Mar 2008 22:48:36 +0100 Message-ID: <025201c89378$f29f1690$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Jukka MJ Manner" References: <47B560E3.2010506@ericsson.com> <47D927AD.3020900@ericsson.com><47F0EAB0.8090504@ericsson.com> Date: Mon, 31 Mar 2008 22:47:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: mpls@ietf.org, ccamp@ietf.org, tsvwg , Magnus Westerlund Subject: Re: [Tsvwg] WG last callfor draft-ietf-tsvwg-rsvp-user-error-spec-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi Jukka, > I have read the draft, and think it is a reasonable proposal, and > presented well. I have just a few minor comments/clarification requests: > > - What is exactly meant by "it is RECOMMENDED that organizations use a > published scheme for this string to promote consistent decoding."? Could > you add an example, perhaps? Ah. Probably over-enthusiastic text created when we added the Error Description string before this became a WG I-D. What we meant was that it might be helpful to a device that is going to a user that is going to read this string if they knew that a string coming from a device made by vendor X should be interpreted in a particular way. For example, date stamp, IP address, error string. However, looking at this again, I would be happy to strike this text. > - Is it possible to not include the Error Description? If so, this could > be said explicitly. Yes, the length can be set to zero, in which case there are no bytes of description string. I can clarify this. > - Is it possible to not include User-defined subobjects? If so, this could > be said explicitly. We already have: User-defined subobjects MAY be included. I think that is sufficiently explicit that it is possible to not include them. > These latter two comments are about making the user error propagation a > bit simpler, e.g., one could primarily use the extended number space to > define new error values, but leave in some cases the description and > subobjects out to save bytes. Agreed, and that is our intention. Does that work for you? Adrian From tsvwg-bounces@ietf.org Mon Mar 31 23:18:40 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086AA28C13D; Mon, 31 Mar 2008 23:18:40 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9B828C0F5; Mon, 31 Mar 2008 23:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Y4yWkoC8GBUV; Mon, 31 Mar 2008 23:18:38 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 04F7A28C10C; Mon, 31 Mar 2008 23:18:37 -0700 (PDT) Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 01 Apr 2008 09:18:34 +0300 id 00067DEA.47F1D3BA.000010B0 Date: Tue, 1 Apr 2008 09:18:34 +0300 (EEST) From: Jukka MJ Manner To: Adrian Farrel In-Reply-To: <025201c89378$f29f1690$0300a8c0@your029b8cecfe> Message-ID: References: <47B560E3.2010506@ericsson.com> <47D927AD.3020900@ericsson.com><47F0EAB0.8090504@ericsson.com> <025201c89378$f29f1690$0300a8c0@your029b8cecfe> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, ccamp@ietf.org, tsvwg , Magnus Westerlund Subject: Re: [Tsvwg] WG last callfor draft-ietf-tsvwg-rsvp-user-error-spec-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, Sounds very good to me. Sorry that I missed that "MAY" for the suboptions. :) Cheers, Jukka On Mon, 31 Mar 2008, Adrian Farrel wrote: > Hi Jukka, > > > I have read the draft, and think it is a reasonable proposal, and > > presented well. I have just a few minor comments/clarification requests: > > > > - What is exactly meant by "it is RECOMMENDED that organizations use a > > published scheme for this string to promote consistent decoding."? Could > > you add an example, perhaps? > > Ah. Probably over-enthusiastic text created when we added the Error > Description string before this became a WG I-D. > > What we meant was that it might be helpful to a device that is going to a user > that is going to read this string if they knew that a string coming from a > device made by vendor X should be interpreted in a particular way. For > example, date stamp, IP address, error string. > > However, looking at this again, I would be happy to strike this text. > > > - Is it possible to not include the Error Description? If so, this could > > be said explicitly. > > Yes, the length can be set to zero, in which case there are no bytes of > description string. > > I can clarify this. > > > - Is it possible to not include User-defined subobjects? If so, this could > > be said explicitly. > > We already have: > User-defined subobjects MAY be included. > > I think that is sufficiently explicit that it is possible to not include them. > > > These latter two comments are about making the user error propagation a > > bit simpler, e.g., one could primarily use the extended number space to > > define new error values, but leave in some cases the description and > > subobjects out to save bytes. > > Agreed, and that is our intention. > > Does that work for you? > > Adrian > > > From tsvwg-bounces@ietf.org Tue Apr 1 02:45:07 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA24528C2BB; Tue, 1 Apr 2008 02:45:07 -0700 (PDT) X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A3E7D3A6D2D; Tue, 1 Apr 2008 02:45:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080401094501.A3E7D3A6D2D@core3.amsl.com> Date: Tue, 1 Apr 2008 02:45:01 -0700 (PDT) Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-rsvp-user-error-spec-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : User-Defined Errors for RSVP Author(s) : G. Swallow, A. Farrel Filename : draft-ietf-tsvwg-rsvp-user-error-spec-05.txt Pages : 8 Date : 2008-04-01 The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP. This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-rsvp-user-error-spec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-01023346.I-D@ietf.org> --NextPart-- From tsvwg-bounces@ietf.org Tue Apr 1 02:49:28 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C862628C46E; Tue, 1 Apr 2008 02:49:28 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E63F3A6AC3 for ; Tue, 1 Apr 2008 02:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 OK3mN3PyqMGo for ; Tue, 1 Apr 2008 02:49:20 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 9BE7E28C4D1 for ; Tue, 1 Apr 2008 02:47:15 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m319lB4r019344 for ; Tue, 1 Apr 2008 10:47:12 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m319l98p019287 for ; Tue, 1 Apr 2008 10:47:11 +0100 Message-ID: <029e01c893dd$55af81c0$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "tsvwg" References: <20080401094501.A3E7D3A6D2D@core3.amsl.com> Date: Tue, 1 Apr 2008 10:46:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Tsvwg] I-D Action:draft-ietf-tsvwg-rsvp-user-error-spec-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Updated after discussion with Jukka. Adrian >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : User-Defined Errors for RSVP > Author(s) : G. Swallow, A. Farrel > Filename : draft-ietf-tsvwg-rsvp-user-error-spec-05.txt > Pages : 8 > Date : 2008-04-01 > > The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object > for communicating errors. That object has a defined format that > permits the definition of 256 error codes. As RSVP has been > developed and extended, the convention has been to be conservative in > defining new error codes. Further, no provision for user-defined > errors exists in RSVP. > > This document defines a USER_ERROR_SPEC to be used in addition to the > ERROR_SPEC to carry additional user information related to errors. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-05.txt From tsvwg-bounces@ietf.org Tue Apr 1 04:46:27 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD9D3A6D78; Tue, 1 Apr 2008 04:46:27 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948C13A6C05 for ; Tue, 1 Apr 2008 04:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Tn2IWxw-v9V1 for ; Tue, 1 Apr 2008 04:46:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 21E7D3A6E5D for ; Tue, 1 Apr 2008 04:45:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,587,1199660400"; d="scan'208";a="5031598" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2008 13:45:27 +0200 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 m31BjRg4028417; Tue, 1 Apr 2008 13:45:27 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m31BjRRb021269; Tue, 1 Apr 2008 11:45:27 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); Tue, 1 Apr 2008 13:45:27 +0200 Received: from [144.254.53.198] ([144.254.53.198]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 13:45:26 +0200 In-Reply-To: <47F0EB8C.3020809@ericsson.com> References: <47C58EB8.1000203@ericsson.com> <47EA7A86.8000209@ericsson.com> <47F0EB8C.3020809@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Date: Tue, 1 Apr 2008 13:45:20 +0200 To: Magnus Westerlund X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 01 Apr 2008 11:45:26.0726 (UTC) FILETIME=[E0BFD660:01C893ED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1767; t=1207050327; x=1207914327; 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 |Subject:=20Re=3A=20[Dime]=20[NSIS]=20WG=20last=20call=20on =20draft-ietf-tsvwg-emergency-rsvp-05 |Sender:=20; bh=KDKre7RcIASJyoh+AdVWQQ93p7t/MHQgKWnIlIXd9Yw=; b=cFtBZ2PWTMyDxTDQ7Xp2uN4DlqqoUh7wce87sK9fdbkE+fX62lddnAWcHz RikPXSguH9iDsKcYFH7qRsc1KFQnuJwVxRbMaU5NKicsC3mUHDNFtKHpcKdo wqawCVf9HW; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: tsvwg list IETF Subject: Re: [Tsvwg] [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi Magnus, On 31 Mar 2008, at 15:47, Magnus Westerlund wrote: > Francois Le Faucheur IMAP skrev: >> Hi Magnus, >> There are a couple small items that needs to be fixed: >> - adding a reference to MAR in response to Jerry's Last Call >> comments (as agreed in http://www.ietf.org/mail-archive/web/tsvwg/ >> current/msg08209.html) >> - updating reference text to NSIS Admission Priority in line >> with NSIS WG consensus (as per your message in http://www.ietf.org/ >> mail-archive/web/tsvwg/current/msg08231.html) >> Other than that, from my perspective, the document is ready for >> publication. >> We'll wait a few more days in case there are more belated comments >> from WG Last Call and issue an new version addressing the above >> two minor items. > > The WG last call has now ended. There are a few issues that needs > to be updated. As there has been some contention around this > document I will do a short 1-week confirmation call on the updates > as soon the new version is available. The new version (draft-ietf-tsvwg-emergency-rsvp-06) is now available. It addresses the items listed above as well as the comments brought up Yesterday by Roy. Francois > > 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: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From tsvwg-bounces@ietf.org Tue Apr 1 04:48:31 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9955628C23C; Tue, 1 Apr 2008 04:48:31 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A073B28C1E0; Tue, 1 Apr 2008 04:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] 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 Dwl7ygfblc07; Tue, 1 Apr 2008 04:48:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9357D3A6B26; Tue, 1 Apr 2008 04:48:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,587,1199660400"; d="scan'208";a="5031981" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2008 13:48:24 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m31BmODB002818; Tue, 1 Apr 2008 13:48:24 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m31BmOPq022635; Tue, 1 Apr 2008 11:48:24 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 13:48:24 +0200 Received: from [144.254.53.198] ([144.254.53.198]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 13:48:24 +0200 In-Reply-To: References: <47EA7A86.8000209@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E405955-620F-43D9-8EB4-F070F8948A1C@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Date: Tue, 1 Apr 2008 13:48:17 +0200 To: "Roy, Radhika R Dr CTR USA USAMC" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 01 Apr 2008 11:48:24.0161 (UTC) FILETIME=[4A824510:01C893EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4784; t=1207050504; x=1207914504; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[Dime]=20[NSIS]=20WG=20last=20call=20on =20draft-ietf-tsvwg-emergency-rsvp-05 |Sender:=20; bh=I2XvpoGo/+ZSJYwy+ji6eBE05Fkb/UJYYivwsxry1Yc=; b=Frub0AHp8NPGDn6NuLwQUCt1T4cDlWIdReoOfthEND6/fadQbj6fbnR2FW NaTXUqcUGKhF5krBl2NEbzAfw44CsIDlBntcPVT3sN2FBF9uqfB/9jq+fQqf zhv6CcPTYb; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Magnus Westerlund , tsvwg , NSIS , nsis-bounces@ietf.org, dime@ietf.org Subject: Re: [Tsvwg] [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi Roy, On 31 Mar 2008, at 16:37, Roy, Radhika R Dr CTR USA USAMC wrote: > Hi, Magnus: > > There is an important typo in reference to NSIS-QSPEC priority. > NSIS-QSPEC is version 19 and resource-priority is in Section 5.2.9 > (not Section 6.2.9). Because I feared a change of section numbering in the next version of nsis-qspec I removed the section number (just referred to the section title). So this is solve in -06. > > More importantly, this draft needs to reference ONLY to this of > part of the resource-priority that is successfully resolved by the > NSIS WG in relation to the consensus of the QSPEC draft (e.g. not > to specifically mention Y.xxxx resource-priority ONLY, etc. because > it will create confusions and distractions about the main technical > aspects). Right. -06 only refers to the nsis-qspec "Admission Priority" and not to the nsis-qspec "Y.xxx Admission Priority". Thanks for your review. Francois > > Ken and other members need to look into this as they have taken the > lead in resolving the issues related to the QSSPEC draft. > > Otherwise, the draft seems to be well-written, and I also agree > with Janet other than the above. > > Sorry that I missed the last Friday's deadline. > > Best regards, > Radhika > > PS: For SIP and SIPPING WG members: > > RFC 3312 and RFCs related to SIP call flows need to use the latest > RFCs of NSIS and TSVWG for taking care of QOS. > > > ----- Original Message ----- > From: Janet P Gunn > Date: Thursday, March 27, 2008 21:09 > Subject: Re: [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 > To: Magnus Westerlund > Cc: dime@ietf.org, nsis-bounces@ietf.org, NSIS , tsvwg > >> Just saying that, from my perspective, "it is ready to be >> published". And, >> yes I have read it and followed the discussions on the related >> DIME and >> NSIS documents. >> >> Janet Gunn >> >> Computer Sciences Corporation >> Registered Office: 2100 East Grand Avenue, El Segundo California >> 90245, >> USA >> Registered in USA No: C-489-59 >> >> ------------------------------------------------------------------- >> ------------------------------------------------------------------- >> ------------------------------------------------------------------- >> ------- >> This is a PRIVATE message. If you are not the intended recipient, >> please >> delete without copying and kindly advise us by e-mail of the >> mistake in >> delivery. >> NOTE: Regardless of content, this e-mail shall not operate to bind >> CSC to >> any order or other contract unless pursuant to explicit written >> agreement >> or government initiative expressly permitting the use of e-mail >> for such >> purpose. >> ------------------------------------------------------------------- >> ------------------------------------------------------------------- >> ------------------------------------------------------------------- >> ------- >> >> >> nsis-bounces@ietf.org wrote on 03/26/2008 12:32:06 PM: >> >>> Magnus Westerlund skrev: >>>> 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). >>>> >>> >>> This is a reminder about the WG last call. Without some comments >> we >>> can't judge consensus on publishing this document. So please >> provide any >> >>> comments, even if just to say that it is ready to be published. >>> >>> 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: magnus.westerlund@ericsson.com >>> ----------------------------------------------------------------- >> ----- >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsis >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From tsvwg-bounces@ietf.org Tue Apr 1 05:31:24 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF1B2951FF; Tue, 1 Apr 2008 05:30:59 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A34D294D00; Tue, 1 Apr 2008 05:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HELO_EQ_SE=0.35, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] 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 lGoU6PysBqq7; Tue, 1 Apr 2008 05:28:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AE9CC28D36D; Tue, 1 Apr 2008 05:17:21 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 20FA6217E5; Tue, 1 Apr 2008 14:14:50 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-29-47f2273afaea Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1073A2178E; Tue, 1 Apr 2008 14:14:50 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 14:14:49 +0200 Received: from [127.0.0.1] ([147.214.30.213]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 14:14:49 +0200 Message-ID: <47F22739.90701@ericsson.com> Date: Tue, 01 Apr 2008 14:14:49 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 References: <20080331194501.4519028C3B8@core3.amsl.com> In-Reply-To: <20080331194501.4519028C3B8@core3.amsl.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2008 12:14:49.0514 (UTC) FILETIME=[FB73F0A0:01C893F1] X-Brightmail-Tracker: AAAAAA== Cc: dime@ietf.org, tsvwg@ietf.org, NSIS Subject: [Tsvwg] Confirmation on draft-ietf-tsvwg-emergency-rsvp-06.txt ready for publication X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, This is a call for confirmation that the changes since the previous version is okay and that we can forward and request publication of this document. So any final comment should be be sent to the TSVWG list no later than the 7th of April. The diff: http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-emergency-rsvp/draft-ietf-tsvwg-emergency-rsvp-06-from-05.diff.html Cheers Magnus Internet-Drafts@ietf.org skrev: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group Working Group of the IETF. > > > Title : Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services > Author(s) : F. Le Faucheur, et al. > Filename : draft-ietf-tsvwg-emergency-rsvp-06.txt > Pages : 32 > Date : 2008-03-31 > > An Emergency Telecommunications Service (ETS) requires the ability to > provide an elevated probability of session establishment to an > authorized user in times of network congestion (typically, during a > crisis). When supported over the Internet Protocol suite, this may > be facilitated through a network layer admission control solution, > which supports prioritized access to resources (e.g., bandwidth). > These resources may be explicitly set aside for emergency services, > or they may be shared with other sessions. > > This document specifies RSVP extensions that can be used to support > such an admission priority capability at the network layer. Note > that these extensions represent one possible solution component in > satisfying ETS requirements. Other solution components, or other > solutions, are outside the scope of this document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > -- 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 ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Tue Apr 1 06:53:23 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5983A679C; Tue, 1 Apr 2008 06:53:23 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BF7D28C215 for ; Tue, 1 Apr 2008 06:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 uIgvMmw6k9HC for ; Tue, 1 Apr 2008 06:53:11 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7BD9E28C4F2 for ; Tue, 1 Apr 2008 06:51:54 -0700 (PDT) Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m31Dobas009274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Apr 2008 06:50:38 -0700 (PDT) Message-ID: <47F23DAC.2020905@isi.edu> Date: Tue, 01 Apr 2008 06:50:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Magnus Westerlund References: <47EA7B25.6080502@ericsson.com> In-Reply-To: <47EA7B25.6080502@ericsson.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09CD661BEE566A76E881D8A0" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg Subject: Re: [Tsvwg] Adopt draft-brisco-tsvwg-byte-pkt-mark as WG item? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09CD661BEE566A76E881D8A0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Magnus Westerlund wrote: > Hi, >=20 > At the IETF meeting we had an good discussion around Bob's "Byte and=20 > Packet Congestion Notification" draft: > http://tools.ietf.org/wg/tsvwg/draft-briscoe-tsvwg-byte-pkt-mark-02.txt= >=20 > There seems to be interest in this and a meaningful document for TSVWG = > to take on. So please provide your view if this should become a WG=20 > document now or not. Deadline for comments are 10th of April. I'd like our chairs to take note of those who would like this -- or any=20 other doc -- as a WG item. Those parties ought, IMO, are implicitly=20 signing up for key reviews of documents they suggest. That would certainly avoid the pleading at last call time for interested = parties. ;-) In the spirit of such, I'll suggest this ought to be a WG doc as well,=20 and sign up for last call review too. Joe --------------enig09CD661BEE566A76E881D8A0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH8j2tE5f5cImnZrsRAnHcAJ9Fa+YS554a7z4HCmTocglJhsd3/gCfaLo4 s+CpV4B+cB8RH48x4hIVemE= =aNSW -----END PGP SIGNATURE----- --------------enig09CD661BEE566A76E881D8A0-- From tsvwg-bounces@ietf.org Tue Apr 1 06:58:27 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BFC83A6ADF; Tue, 1 Apr 2008 06:58:27 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3CB3A6A1A for ; Tue, 1 Apr 2008 06:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 QsH35IBMnMw4 for ; Tue, 1 Apr 2008 06:58:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1A0763A6B64 for ; Tue, 1 Apr 2008 06:58:25 -0700 (PDT) Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m31Dvp06012109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Apr 2008 06:57:52 -0700 (PDT) Message-ID: <47F23F5F.1010606@isi.edu> Date: Tue, 01 Apr 2008 06:57:51 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Joe Touch References: <47EA7B25.6080502@ericsson.com> <47F23DAC.2020905@isi.edu> In-Reply-To: <47F23DAC.2020905@isi.edu> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26EDA58730F844A5276453BF" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Magnus Westerlund , tsvwg Subject: Re: [Tsvwg] Adopt draft-brisco-tsvwg-byte-pkt-mark as WG item? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26EDA58730F844A5276453BF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Joe Touch wrote: =2E.. > I'd like our chairs to take note of those who would like this -- or any= =20 > other doc -- as a WG item. Those parties, IMO, are implicitly=20 > signing up for key reviews of documents they suggest. Corrected text above...(sorry for the spurious "ought" )... >=20 > That would certainly avoid the pleading at last call time for intereste= d=20 > parties. ;-) >=20 > In the spirit of such, I'll suggest this ought to be a WG doc as well, = > and sign up for last call review too. >=20 > Joe >=20 --------------enig26EDA58730F844A5276453BF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH8j9fE5f5cImnZrsRAoVTAKDH6aiWp0lXU/GM5DM7oNpBnk1qtACaAxDr 8EQajMsQntuHVYdlChDWjvE= =Gntv -----END PGP SIGNATURE----- --------------enig26EDA58730F844A5276453BF-- From tsvwg-bounces@ietf.org Tue Apr 1 07:17:28 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F6628C44A; Tue, 1 Apr 2008 07:17:28 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169B03A6ADF for ; Tue, 1 Apr 2008 07:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.741 X-Spam-Level: X-Spam-Status: No, score=-3.741 tagged_above=-999 required=5 tests=[AWL=2.858, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 X9clyCmiImTh for ; Tue, 1 Apr 2008 07:03:20 -0700 (PDT) Received: from ndjsbar02.ndc.nasa.gov (ndjsbar02.ndc.nasa.gov [198.120.25.39]) by core3.amsl.com (Postfix) with ESMTP id 4BC7E28C313 for ; Tue, 1 Apr 2008 07:03:20 -0700 (PDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id 37772714390; Tue, 1 Apr 2008 09:03:18 -0500 (CDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov with ESMTP id IUr9CSWlcarj3wc6; Tue, 01 Apr 2008 09:03:18 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 09:03:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Apr 2008 09:03:17 -0500 Message-ID: In-Reply-To: <47F23DAC.2020905@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] Adopt draft-brisco-tsvwg-byte-pkt-mark as WG item? Thread-Index: AciUACnPIw04uB3jRhWj+6Xs1ht3VAAAMLag References: <47EA7B25.6080502@ericsson.com> <47F23DAC.2020905@isi.edu> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Joe Touch" , "Magnus Westerlund" X-OriginalArrivalTime: 01 Apr 2008 14:03:18.0148 (UTC) FILETIME=[22E6AC40:01C89401] X-Mailman-Approved-At: Tue, 01 Apr 2008 07:17:22 -0700 Cc: tsvwg Subject: Re: [Tsvwg] Adopt draft-brisco-tsvwg-byte-pkt-mark as WG item? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org >-----Original Message----- >From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org]=20 >On Behalf Of Joe Touch >Sent: Tuesday, April 01, 2008 9:51 AM > >Magnus Westerlund wrote: >> Hi, >>=20 >> At the IETF meeting we had an good discussion around Bob's "Byte and=20 >> Packet Congestion Notification" draft: >>=20 >http://tools.ietf.org/wg/tsvwg/draft-briscoe-tsvwg-byte-pkt-mark-02.txt >>=20 >> There seems to be interest in this and a meaningful document=20 >for TSVWG=20 >> to take on. So please provide your view if this should become a WG=20 >> document now or not. Deadline for comments are 10th of April. > >I'd like our chairs to take note of those who would like this=20 >-- or any=20 >other doc -- as a WG item. Those parties ought, IMO, are implicitly=20 >signing up for key reviews of documents they suggest. > >That would certainly avoid the pleading at last call time for=20 >interested=20 >parties. ;-) > >In the spirit of such, I'll suggest this ought to be a WG doc as well,=20 >and sign up for last call review too. I like Joe's idea, and I'll say "me too" for making this a WG doc and volunteering to make last-call comments. From tsvwg-bounces@ietf.org Tue Apr 1 07:44:02 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD36428C3CD; Tue, 1 Apr 2008 07:44:02 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84CE28C3CD for ; Tue, 1 Apr 2008 07:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 wPa1mhcUvoQs for ; Tue, 1 Apr 2008 07:44:00 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id DB46E28C3A8 for ; Tue, 1 Apr 2008 07:43:59 -0700 (PDT) Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 01 Apr 2008 17:43:55 +0300 id 00067DE9.47F24A2B.00004547 Date: Tue, 1 Apr 2008 17:43:55 +0300 (EEST) From: Jukka MJ Manner To: Magnus Westerlund In-Reply-To: <47EA7B25.6080502@ericsson.com> Message-ID: References: <47EA7B25.6080502@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tsvwg Subject: Re: [Tsvwg] Adopt draft-brisco-tsvwg-byte-pkt-mark as WG item? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, I'm also very much in favor of adopting this work. And, as the people before me, I'll sign up for a WGLC review, too. Jukka On Wed, 26 Mar 2008, Magnus Westerlund wrote: > Hi, > > At the IETF meeting we had an good discussion around Bob's "Byte and Packet > Congestion Notification" draft: > http://tools.ietf.org/wg/tsvwg/draft-briscoe-tsvwg-byte-pkt-mark-02.txt > > There seems to be interest in this and a meaningful document for TSVWG to take > on. So please provide your view if this should become a WG document now or > not. Deadline for comments are 10th of April. > > Best Regards > > 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 > ---------------------------------------------------------------------- > > From tsvwg-bounces@ietf.org Tue Apr 1 09:14:42 2008 Return-Path: X-Original-To: tsvwg-archive@optimus.ietf.org Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7B9D3A6EB2; Tue, 1 Apr 2008 09:14:42 -0700 (PDT) X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4B128C4AA for ; Tue, 1 Apr 2008 09:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 14yWOk337+GQ for ; Tue, 1 Apr 2008 09:14:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 05EA028C4C4 for ; Tue, 1 Apr 2008 09:14:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,588,1199660400"; d="scan'208";a="5070026" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2008 18:14:21 +0200 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 m31GELep026480 for ; Tue, 1 Apr 2008 18:14:21 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m31GELWD022043 for ; Tue, 1 Apr 2008 16:14:21 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 18:14:21 +0200 Received: from [144.254.53.198] ([144.254.53.198]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 18:14:21 +0200 Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: tsvwg IETF list From: Francois Le Faucheur IMAP Date: Tue, 1 Apr 2008 18:14:13 +0200 X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 01 Apr 2008 16:14:21.0082 (UTC) FILETIME=[71932FA0:01C89413] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1446; t=1207066461; x=1207930461; 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 |Subject:=20Re=3A=20[Tsvwg]=20I-D=20Action=3Adraft-ietf-tsv wg-rsvp-user-error-spec-05.txt |Sender:=20; bh=EjnmSjPMxOIih6F/+beuH01Y87VFqxT3/ijW/mPGqh0=; b=IoX+K4+Ok6nrPhh/dBaHZ4efYtSXjiSKASYQrjFSLkixWIY3jOJsmdd3DU P4UehrK7cj4I+j+1wN1zmMPWm3Tv9hGixy4GPm6ybMxaAHulU2oQJh99HiAO vdRZPg8DfM; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Tsvwg] I-D Action:draft-ietf-tsvwg-rsvp-user-error-spec-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org Hi, I think this document is ready to move forward. One small suggestion perhaps. It probably wouldn't hurt to be explicit about the "Error Value" field of the ERROR_SPEC (when Error Code = "User Error Spec"). I understand this field is basically not to serve any purpose ("No Error Values are defined), suggesting a "MUST be set to zero on transmit and MUST be ignored on receipt" . Francois =============================================================== Updated after discussion with Jukka. Adrian A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : User-Defined Errors for RSVP Author(s) : G. Swallow, A. Farrel Filename : draft-ietf-tsvwg-rsvp-user-error-spec-05.txt Pages : 8 Date : 2008-04-01 The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP. This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error- spec-05.txt