From exim@www1.ietf.org Wed Jul 2 09:36:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17593 for ; Wed, 2 Jul 2003 09:36:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhmQ-0001BP-Vs for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 09:36:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62DaExC004546 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 09:36:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhmQ-0001BF-Se for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09:36:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17545 for ; Wed, 2 Jul 2003 09:36:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhmP-0006Qb-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 09:36:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XhmO-0006QW-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 09:36:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhmE-0001AP-4v; Wed, 02 Jul 2003 09:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhWo-0000RY-WC for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 09:20:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15859 for ; Wed, 2 Jul 2003 09:20:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhWl-0005kh-00 for ieprep@ietf.org; Wed, 02 Jul 2003 09:20:03 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 19XhWl-0005ke-00 for ieprep@ietf.org; Wed, 02 Jul 2003 09:20:03 -0400 Received: from scooter.psp.pas.earthlink.net ([207.217.78.185]) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19XhWj-0001V0-00 for ieprep@ietf.org; Wed, 02 Jul 2003 06:20:01 -0700 Received: from [207.217.78.201] by EarthlinkWAM via HTTP; Wed Jul 02 06:20:01 PDT 2003 Message-ID: <322223.1057152001721.JavaMail.nobody@scooter.psp.pas.earthlink.net> Date: Wed, 2 Jul 2003 06:21:16 -0400 (EDT) From: Janet Gunn To: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Web Access Mail version 3.0 Content-Transfer-Encoding: 7bit Subject: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telephony Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This message somhow got "lost in the ether" the first time, so I am resubmitting it form a different email account. Which probably guarantees that the original verison will show up. Janet Several of us have coauthored a Best Common Practices ID on configuring a single domain, IP bridging, topology to support Emergency Telecommunications Service. This ID has been published as an Internet draft http://www.ietf.org/internet-drafts/draft-mcgregor-ieprep-bridging-bcp-00.txt We are looking forward to feedback. The following is the abstract from the ID: RECOMMENDED best current practices in applying existing protocols for operational implementation of an Emergency Telecommunications Service (ETS) in a single-domain IP Bridging topology are to use a) Session Initiation Protocol (SIP) Priority header value of "emergency", b) Session Description Protocol (SDP) attribute experimental parameters to designate the call (session) as either a National Emergency call, International Emergency call, or both, c) MEGACO context descriptors of priorities 0-4 and emergency indication, and d) Multi-Protocol Label Switching (MPLS) with Exp-Inferred Label Switched Paths (E-LSPs) having a dedicated codepoint specifying application of ETS Per-Hop Behavior (PHB), where ETS PHB is technically specified the same as EF PHB, but with different parameter values and associated with an ETS-specific MPLS Differentiated Service. RECOMMENDED best current practices include IP Differentiated Services marking using specified codepoints allocated from the Experimental and Local Use pool (pool 2) to designate the traffic as either National Emergency or International Emergency for corresponding ETS PHB use, and signaling between the Signaling Gateway (SG) and Media Gateway Controller (MGC) using the MTP3 SS7 protocol over the M2UA adaptation protocol with the Stream Control Transmission Protocol (SCTP). Support is suggested for work in progress on defining a SIP Resource-Priority header and defining a SIP telephone URI extension for calling party category designation. Since the deadline for submission of Internet Drafts, we have made several enhancements and clarifications. We have posted a new version at https://gets-ic-pmo.is.dyncorp.com/IETF/Documents.htm _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 09:37:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17665 for ; Wed, 2 Jul 2003 09:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhnE-0001Hz-8L for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 09:37:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Db4sj004949 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 09:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhnE-0001Hk-3B for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09:37:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17630 for ; Wed, 2 Jul 2003 09:37:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhnC-0006Sd-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 09:37:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XhnB-0006Sa-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 09:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhnB-0001Ez-R2; Wed, 02 Jul 2003 09:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xhml-0001DZ-8c for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 09:36:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17577 for ; Wed, 2 Jul 2003 09:36:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xhmj-0006RW-00 for ieprep@ietf.org; Wed, 02 Jul 2003 09:36:33 -0400 Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 19Xhmi-0006RS-00 for ieprep@ietf.org; Wed, 02 Jul 2003 09:36:32 -0400 Received: from thecount.psp.pas.earthlink.net ([207.217.78.22]) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19Xhmh-00043R-00 for ieprep@ietf.org; Wed, 02 Jul 2003 06:36:31 -0700 Received: from [207.217.78.16] by EarthlinkWAM via HTTP; Wed Jul 02 06:36:31 PDT 2003 Message-ID: <4628663.1057152991640.JavaMail.nobody@thecount.psp.pas.earthlink.net> Date: Wed, 2 Jul 2003 06:37:46 -0400 (EDT) From: Janet Gunn To: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Web Access Mail version 3.0 Content-Transfer-Encoding: 7bit Subject: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telephony Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Third attempt to send this to the list). Several of us have coauthored a Best Common Practices ID on configuring a single domain, IP bridging, topology to support Emergency Telecommunications Service. This ID has been published as an Internet draft http://www.ietf.org/internet-drafts/draft-mcgregor-ieprep-bridging-bcp-00.txt We are looking forward to feedback. The following is the abstract from the ID: RECOMMENDED best current practices in applying existing protocols for operational implementation of an Emergency Telecommunications Service (ETS) in a single-domain IP Bridging topology are to use a) Session Initiation Protocol (SIP) Priority header value of "emergency", b) Session Description Protocol (SDP) attribute experimental parameters to designate the call (session) as either a National Emergency call, International Emergency call, or both, c) MEGACO context descriptors of priorities 0-4 and emergency indication, and d) Multi-Protocol Label Switching (MPLS) with Exp-Inferred Label Switched Paths (E-LSPs) having a dedicated codepoint specifying application of ETS Per-Hop Behavior (PHB), where ETS PHB is technically specified the same as EF PHB, but with different parameter values and associated with an ETS-specific MPLS Differentiated Service. RECOMMENDED best current practices include IP Differentiated Services marking using specified codepoints allocated from the Experimental and Local Use pool (pool 2) to designate the traffic as either National Emergency or International Emergency for corresponding ETS PHB use, and signaling between the Signaling Gateway (SG) and Media Gateway Controller (MGC) using the MTP3 SS7 protocol over the M2UA adaptation protocol with the Stream Control Transmission Protocol (SCTP). Support is suggested for work in progress on defining a SIP Resource-Priority header and defining a SIP telephone URI extension for calling party category designation. Since the deadline for submission of Internet Drafts, we have made several enhancements and clarifications. We have posted a new version at https://gets-ic-pmo.is.dyncorp.com/IETF/Documents.htm _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 10:26:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23248 for ; Wed, 2 Jul 2003 10:26:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiYf-0004Sh-45 for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 10:26:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62EQ5d9017145 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 10:26:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiYe-0004SS-UG for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 10:26:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23222 for ; Wed, 2 Jul 2003 10:25:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XiYa-0000Qo-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 10:26:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XiYZ-0000Ql-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 10:25:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiYa-0004Qx-3e; Wed, 02 Jul 2003 10:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiYG-0004Qe-PJ for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 10:25:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23208 for ; Wed, 2 Jul 2003 10:25:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XiYD-0000QN-00 for ieprep@ietf.org; Wed, 02 Jul 2003 10:25:37 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 19XiYC-0000QI-00 for ieprep@ietf.org; Wed, 02 Jul 2003 10:25:37 -0400 Received: from extremenetworks.com (unknown [10.18.3.105]) by gnat.inet.org (Postfix) with ESMTP id F3BBA67117; Wed, 2 Jul 2003 10:51:41 -0400 (EDT) Date: Wed, 2 Jul 2003 10:25:17 -0400 Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telephony Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ieprep@ietf.org To: Janet Gunn From: RJ Atkinson In-Reply-To: <322223.1057152001721.JavaMail.nobody@scooter.psp.pas.earthlink.net> Message-Id: <00FD8D18-AC99-11D7-A803-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, Jul 2, 2003, at 06:21 America/Montreal, Janet Gunn wrote: > Several of us have coauthored a Best Common Practices ID on > configuring a single domain, IP bridging, topology to support > Emergency Telecommunications Service. Thanks for the heads-up. :-) A BCP document ought to represent actual currently deployed practice and what the community believes to be the best practice at the time the document is published. Readers probably should consider whether those two properties hold for the contents of the above document when reviewing the document. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 11:46:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27768 for ; Wed, 2 Jul 2003 11:46:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XjoG-00007c-3J for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 11:46:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62FkGBQ000469 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 11:46:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XjoF-00007P-Go for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 11:46:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27608 for ; Wed, 2 Jul 2003 11:46:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XjoE-0002aH-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 11:46:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XjoC-0002aD-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 11:46:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjo1-0008En-JW; Wed, 02 Jul 2003 11:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XQYH-00029T-Kz for ieprep@optimus.ietf.org; Tue, 01 Jul 2003 15:12:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07699 for ; Tue, 1 Jul 2003 13:34:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XP1d-0006VB-00 for ieprep@ietf.org; Tue, 01 Jul 2003 13:34:41 -0400 Received: from host-133-208.is.dyncorp.com ([131.131.133.208] helo=chntex04.is.dyncorp.com) by ietf-mx with esmtp (Exim 4.12) id 19XP1c-0006V2-00 for ieprep@ietf.org; Tue, 01 Jul 2003 13:34:40 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Jul 2003 13:11:51 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AA1F@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: ieprep@ietf.org Date: Tue, 1 Jul 2003 13:11:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33FF3.D775CBD0" Subject: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telephony Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33FF3.D775CBD0 Content-Type: text/plain; charset="iso-8859-1" Several of us have coauthored a Best Common Practices ID on configuring a single domain, IP bridging, topology to support Emergency Telecommunications Service. This ID has been published as an Internet draft http://www.ietf.org/internet-drafts/draft-mcgregor-ieprep-bridging-bcp-00.tx t Since the deadline for submission of Internet Drafts, we have made several enhancements and clarifications. We have posted a new version at https://gets-ic-pmo.is.dyncorp.com/IETF/Documents.htm The following is the abstract from the ID: RECOMMENDED best current practices in applying existing protocols for operational implementation of an Emergency Telecommunications Service (ETS) in a single-domain IP Bridging topology are to use a) Session Initiation Protocol (SIP) Priority header value of "emergency", b) Session Description Protocol (SDP) attribute experimental parameters to designate the call (session) as either a National Emergency call, International Emergency call, or both, c) MEGACO context descriptors of priorities 0-4 and emergency indication, and d) Multi-Protocol Label Switching (MPLS) with Exp-Inferred Label Switched Paths (E-LSPs) having a dedicated codepoint specifying application of ETS Per-Hop Behavior (PHB), where ETS PHB is technically specified the same as EF PHB, but with different parameter values and associated with an ETS-specific MPLS Differentiated Service. RECOMMENDED best current practices include IP Differentiated Services marking using specified codepoints allocated from the Experimental and Local Use pool (pool 2) to designate the traffic as either National Emergency or International Emergency for corresponding ETS PHB use, and signaling between the Signaling Gateway (SG) and Media Gateway Controller (MGC) using the MTP3 SS7 protocol over the M2UA adaptation protocol with the Stream Control Transmission Protocol (SCTP). Support is suggested for work in progress on defining a SIP Resource-Priority header and defining a SIP telephone URI extension for calling party category designation. ---------------------------------------------------------------------------- ------------ 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. ---------------------------------------------------------------------------- ------------ ------_=_NextPart_001_01C33FF3.D775CBD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IP Bridging Configuration Guidance for IEPREP Telephony

Several of us have coauthored a Best Common Practices = ID on configuring a single domain, IP bridging, topology to support = Emergency Telecommunications Service.

This ID has been published as an Internet = draft
http://www.ietf.org/internet-drafts/draft-mcgregor-iep= rep-bridging-bcp-00.txt

Since the deadline for submission  of Internet = Drafts, we have made several enhancements and clarifications.  We = have posted a new version at

https://gets-ic-pmo.is.dyncorp.com/IETF/Documents.htm<= /A>


The following is the abstract from the ID:

RECOMMENDED best current practices in applying = existing
protocols for operational implementation of an = Emergency
Telecommunications Service (ETS) in a single-domain = IP Bridging
topology are to use a) Session Initiation Protocol = (SIP)
Priority header value of "emergency", b) = Session Description
Protocol (SDP) attribute experimental parameters to = designate
the call (session) as either a National Emergency = call,
International Emergency call, or both, c) MEGACO = context
descriptors of priorities 0-4 and emergency = indication, and
d) Multi-Protocol Label Switching (MPLS) with = Exp-Inferred Label
Switched Paths (E-LSPs) having a dedicated codepoint = specifying
application of ETS Per-Hop Behavior (PHB), where ETS = PHB is
technically specified the same as EF PHB, but with = different
parameter values and associated with an ETS-specific = MPLS
Differentiated Service.  RECOMMENDED best = current practices include IP
Differentiated Services marking using specified = codepoints allocated
from the Experimental and Local Use pool (pool 2) to = designate the
traffic as either National Emergency or = International Emergency for
corresponding ETS PHB use, and signaling between the = Signaling Gateway
(SG) and Media Gateway Controller (MGC) using the = MTP3 SS7 protocol
over the M2UA adaptation protocol with the Stream = Control Transmission
Protocol (SCTP).  Support is suggested for work = in progress on
defining a SIP Resource-Priority header and defining = a SIP telephone
URI extension for calling party category = designation.


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

---------------------------------------------------------------= -------------------------
 

------_=_NextPart_001_01C33FF3.D775CBD0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 12:12:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29155 for ; Wed, 2 Jul 2003 12:12:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkDD-0003Du-BT for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 12:12:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62GC3rs012384 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 12:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkDD-0003Df-7y for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 12:12:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29112 for ; Wed, 2 Jul 2003 12:11:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkDC-00039o-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 12:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XkDB-00039l-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 12:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkDB-0003C6-HU; Wed, 02 Jul 2003 12:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkCF-00039f-5n for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 12:11:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29086 for ; Wed, 2 Jul 2003 12:10:59 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkCD-00038r-00 for IEPREP@ietf.org; Wed, 02 Jul 2003 12:11:01 -0400 Received: from imo-m01.mx.aol.com ([64.12.136.4]) by ietf-mx with esmtp (Exim 4.12) id 19XkCD-00038R-00 for IEPREP@ietf.org; Wed, 02 Jul 2003 12:11:01 -0400 Received: from Mpierce1@aol.com by imo-m01.mx.aol.com (mail_out_v36_r1.1.) id r.1e9.c4d59f2 (3988); Wed, 2 Jul 2003 12:10:16 -0400 (EDT) Message-ID: <1e9.c4d59f2.2c345de6@aol.com> Date: Wed, 2 Jul 2003 12:10:14 EDT To: Janet.Gunn@DynCorp.com, IEPREP@ietf.org CC: steves@shentel.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1e9.c4d59f2.2c345de6_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Subject: [Ieprep] Re: IEPREP IP Bridging Configuration Guidance for IEPREP Telephony Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --part1_1e9.c4d59f2.2c345de6_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Comments on draft-mcgregor-ieprep-ip-bridging-bcp-00a The draft talks of assigning 2 DiffServ Codepoints (for national and international) and that both are "functionally specified as the EF PHB, but have ETS parameter settings". Is there any additional idea of what these parameter settings could be? This sounds sort of like what has been described in draft-silverman-diffserv-mlefphb-01 which defines a scheme for multiple code points pointing to one EF queue but with different thresholds for dropping in case of queue overflow. I believe that Silverman's draft would cover what you need. This is an MLEF PHB, but one of its applications could be for ETS. ETS sounds like a good example to put in the Annex of Silverman's draft. Mike Pierce --part1_1e9.c4d59f2.2c345de6_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Comments on draft-mcgrego= r-ieprep-ip-bridging-bcp-00a

The draft talks of assigning 2 DiffServ Codepoints (for national and int= ernational) and that both are "functionally specified as the EF PHB, but hav= e ETS parameter settings". Is there any additional idea of what these parame= ter settings could be?

This sounds sort of like what has been described in draft-silverman-diff= serv-mlefphb-01 which defines a scheme for multiple code points pointing to=20= one EF queue but with different thresholds for dropping in case of queue ove= rflow. I believe that Silverman's draft would cover what you need. This is a= n MLEF PHB, but one of its applications could be for ETS. ETS sounds like a=20= good example to put in the Annex of Silverman's draft.

Mike Pierce
--part1_1e9.c4d59f2.2c345de6_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 12:26:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00008 for ; Wed, 2 Jul 2003 12:26:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkQm-0004WT-3K for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 12:26:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62GQ4lP017380 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 12:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkQm-0004WF-0L for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 12:26:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29993 for ; Wed, 2 Jul 2003 12:26:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkQk-0003Wm-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 12:26:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XkQk-0003Wj-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 12:26:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkQj-0004Uk-KK; Wed, 02 Jul 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkPx-0004UD-0w for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 12:25:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29982 for ; Wed, 2 Jul 2003 12:25:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkPv-0003W2-00 for ieprep@ietf.org; Wed, 02 Jul 2003 12:25:11 -0400 Received: from host-133-208.is.dyncorp.com ([131.131.133.208] helo=chntex04.is.dyncorp.com) by ietf-mx with esmtp (Exim 4.12) id 19XkPv-0003Vy-00 for ieprep@ietf.org; Wed, 02 Jul 2003 12:25:11 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jul 2003 12:23:07 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE899E0E3B@chntex04.is.dyncorp.com> From: "Berg, Dennis" To: "'RJ Atkinson'" Cc: "'ieprep@ietf.org'" , "'Janet Gunn'" Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Teleph ony Date: Wed, 2 Jul 2003 12:23:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C340B6.383D68C0" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C340B6.383D68C0 Content-Type: text/plain Ran, Understand you comment, and we recognize that there is one case in the ID where we are not using existing protocols, viz., the Resource Priority Header. But, we looked at the ieprep charter statements and thought they supported that approach, at least partially: The working group will develop a BCP RFC or set of RFCs, regarding operational implementation of services for Emergency Preparedness using existing Internet protocols. The RFC may include identification of gaps in existing protocols and requirements for use in new protocol or protocol feature design. It is out of scope for this working group to do protocol or protocol feature development. Deliverables Best Current Practice: IETF Recommendations for the Emergency Telecommunications Service using existing protocols - what can be done with existing protocols and what can not be done. I.e., the reference to the RPH is covered, at least in part, by the gap analysis "what can not be done" component of the charter. To the extent that it is not, it seems that the right approach is to assume that the RPH ID will be acted upon and become an RFC before the ieprep BCP is finalized. If this doesn't happen, of course we would have to revise the BCP draft. Dennis Berg CSC dennis.berg@dyncorp.com -----Original Message----- From: RJ Atkinson [mailto:rja@extremenetworks.com] Sent: Wednesday, July 02, 2003 10:25 AM To: Janet Gunn Cc: ieprep@ietf.org Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telephony On Wednesday, Jul 2, 2003, at 06:21 America/Montreal, Janet Gunn wrote: > Several of us have coauthored a Best Common Practices ID on > configuring a single domain, IP bridging, topology to support > Emergency Telecommunications Service. Thanks for the heads-up. :-) A BCP document ought to represent actual currently deployed practice and what the community believes to be the best practice at the time the document is published. Readers probably should consider whether those two properties hold for the contents of the above document when reviewing the document. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep ------_=_NextPart_001_01C340B6.383D68C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP = Telephony

Ran,

Understand you comment, and we recognize that there = is one case in the ID where we are not using existing protocols, viz., = the Resource Priority Header.  But, we looked at the ieprep = charter statements and thought they supported that approach, at least = partially:

        The = working group will develop a BCP RFC or set of RFCs, regarding
        operational implementation of services for Emergency = Preparedness using
        existing = Internet protocols. The RFC may include identification of gaps
        in = existing protocols and requirements for use in new protocol or
        protocol = feature design. It is out of scope for this working group to
        do = protocol or protocol feature development.

        Deliverables

        Best = Current Practice:
         = IETF Recommendations for the Emergency Telecommunications = Service
         = using existing protocols - what can be done with existing = protocols
         and = what can not be done.

I.e., the reference to the RPH is covered, at least = in part, by the gap analysis "what can not be done" component = of the charter.  To the extent that it is not, it seems that the = right approach is to assume that the RPH ID will be acted upon and = become an RFC before the ieprep BCP is finalized.  If this doesn't = happen, of course we would have to revise the BCP draft.

Dennis Berg
CSC
dennis.berg@dyncorp.com


On Wednesday, Jul 2, 2003, at 06:21 America/Montreal, = Janet Gunn wrote:
> Several of us have coauthored a Best Common = Practices ID on
> configuring a single domain, IP bridging, = topology to support
> Emergency Telecommunications Service.

Thanks for the heads-up. :-)

A BCP document ought to represent actual currently = deployed practice and
what the community believes to be the best practice = at the time the
document
is published.

Readers probably should consider whether those two = properties hold
for the contents of the above document when = reviewing the document.

Ran


_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep

------_=_NextPart_001_01C340B6.383D68C0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 12:40:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00626 for ; Wed, 2 Jul 2003 12:40:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkeM-0005yz-01 for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 12:40:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Ge5OP022991 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 12:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkeL-0005yk-Os for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 12:40:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00619 for ; Wed, 2 Jul 2003 12:40:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkeK-0003lw-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 12:40:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XkeJ-0003ls-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 12:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkeI-0005x7-5a; Wed, 02 Jul 2003 12:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkdZ-0005oC-9S for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 12:39:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00555 for ; Wed, 2 Jul 2003 12:39:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkdX-0003lG-00 for ieprep@ietf.org; Wed, 02 Jul 2003 12:39:15 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19XkdX-0003kd-00 for ieprep@ietf.org; Wed, 02 Jul 2003 12:39:15 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 Jul 2003 09:35:19 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h62Gcgrm001293 for ; Wed, 2 Jul 2003 09:38:43 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA25345 for ; Wed, 2 Jul 2003 09:38:42 -0700 (PDT) Message-Id: <4.3.2.7.2.20030702105506.02185588@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 11:38:43 -0500 To: ieprep@ietf.org From: "James M. Polk" Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telephony In-Reply-To: <00FD8D18-AC99-11D7-A803-00039357A82A@extremenetworks.com> References: <322223.1057152001721.JavaMail.nobody@scooter.psp.pas.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , At 10:25 AM 7/2/2003 -0400, RJ Atkinson wrote: >On Wednesday, Jul 2, 2003, at 06:21 America/Montreal, Janet Gunn wrote: >>Several of us have coauthored a Best Common Practices ID on configuring a >>single domain, IP bridging, topology to support Emergency >>Telecommunications Service. > >Thanks for the heads-up. :-) > >A BCP document ought to represent actual currently deployed practice and >what the community believes to be the best practice at the time the document >is published. > >Readers probably should consider whether those two properties hold >for the contents of the above document when reviewing the document. Fairly clearly, with brand new normative text within this document directed at several different WGs and Protocols.... I don't believe the document satisfies the guidance of creating a BCP. If each of these sections of normative text were discussed and reviewed by the appropriate WGs (in a Standards Track document or documents per), then, perhaps, this document might be more appropriate as an architecture type doc.... Bottom line, I don't believe IEPREP can dictate extensions to existing protocols. Our AD was clear on this in the recent past. IEPREP can create requirements documents directed at other WGs for those WGs to then decide on whether to do work on that 'called-for' extension. As a side comment, there are several new normative topics brought up here without any requirements being generated or discussion within this WG (SDP to name one). >Ran cheers, James ******************* The answer is "42", what's the question? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 12:47:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00898 for ; Wed, 2 Jul 2003 12:47:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xkl9-0006Lb-Oz for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 12:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Gl7xD024393 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 12:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xkl9-0006LM-Kv for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 12:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00881 for ; Wed, 2 Jul 2003 12:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xkl8-0003qz-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 12:47:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xkl7-0003qw-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 12:47:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xkl3-0006JL-Gh; Wed, 02 Jul 2003 12:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkkB-0006IW-PB for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 12:46:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00844 for ; Wed, 2 Jul 2003 12:46:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkkA-0003qN-00 for ieprep@ietf.org; Wed, 02 Jul 2003 12:46:06 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 19Xkk9-0003qK-00 for ieprep@ietf.org; Wed, 02 Jul 2003 12:46:05 -0400 Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h62Gj1Dw023608; Wed, 2 Jul 2003 12:45:01 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h62Gj1LU023607; Wed, 2 Jul 2003 12:45:01 -0400 (EDT) Date: Wed, 2 Jul 2003 12:45:01 -0400 (EDT) From: Scott Bradner Message-Id: <200307021645.h62Gj1LU023607@newdev.harvard.edu> To: ieprep@ietf.org, jmpolk@cisco.com Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telephony In-Reply-To: <4.3.2.7.2.20030702105506.02185588@localhost> Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > Bottom line, I don't believe IEPREP can dictate extensions to existing > protocols. Our AD was clear on this in the recent past. IEPREP can create > requirements documents directed at other WGs for those WGs to then decide > on whether to do work on that 'called-for' extension. that is correct Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 15:31:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08828 for ; Wed, 2 Jul 2003 15:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XnJq-0006OX-Np for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 15:31:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62JV6ZQ024577 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 15:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XnJq-0006OK-K5 for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 15:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08819 for ; Wed, 2 Jul 2003 15:31:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XnJn-0006EP-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 15:31:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XnJm-0006EM-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 15:31:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XnJl-0006NR-Cq; Wed, 02 Jul 2003 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XnIm-0006Ge-TC for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 15:30:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08728 for ; Wed, 2 Jul 2003 15:29:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XnIj-0006DA-00 for ieprep@ietf.org; Wed, 02 Jul 2003 15:29:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19XnIi-0006Cm-00 for ieprep@ietf.org; Wed, 02 Jul 2003 15:29:57 -0400 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h62JTNf0003086; Wed, 2 Jul 2003 12:29:24 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA07751; Wed, 2 Jul 2003 12:29:23 -0700 (PDT) Message-Id: <4.3.2.7.2.20030702140014.022744c0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 14:29:23 -0500 To: "Berg, Dennis" , "'RJ Atkinson'" From: "James M. Polk" Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Teleph ony Cc: "'ieprep@ietf.org'" , "'Janet Gunn'" In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE899E0E3B@chntex04.is.dyncorp .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , At 12:23 PM 7/2/2003 -0400, Berg, Dennis wrote: >Ran, > >Understand you comment, and we recognize that there is one case in the ID >where we are not using existing protocols, viz., the Resource Priority Header. Dennis - I believe you might have this backwards (maybe). The R-P header has had a requirements ID generated (and RFCd) by IEPREP (3487), and it is now properly being worked on by its existing Protocol WG (SIP). I don't see the same efforts (requirements IDs) for the other protocols mentioned within your ID (SDP, Diffserv, MPLS, MEGACO, etc) that (I believe) must go through the same process as the R-P header did (as painful as that was/is - hopefully R-P blazed a trail that others will find easier....). > But, we looked at the ieprep charter statements and thought they > supported that approach, at least partially: > > The working group will develop a BCP RFC or set of RFCs, regarding > operational implementation of services for Emergency Preparedness > using > existing Internet protocols. The RFC may include identification > of gaps > in existing protocols and requirements for use in new protocol or > protocol feature design. It is out of scope for this working > group to > do protocol or protocol feature development. > > Deliverables > > Best Current Practice: > IETF Recommendations for the Emergency Telecommunications Service > using existing protocols I believe this includes all existing extensions to existing protocols - which might be part of a discrepancy with your ID, because yours calls for many new extensions that each protocol's WGs haven't properly discussed (nor have many of these been discussed in IEPREP - SDP being the best example of one that hasn't been mentioned before). I'd say that the R-P header is 'the one' mentioned within your ID that *has* been discussed within its appropriate WG, and SIP is close to working out the final details of it now. None of the other extensions called for in this new ID have been discussed on any other mailing list or in the WG meetings that I know of in the last 4 years. > - what can be done with existing protocols > and what can not be done. What this ID calls for should be the results of much discussion and one or more requirements IDs calling for these extensions to occur with proper justification of usage and perhaps why existing mechanisms in each protocol can't solve what you want. >I.e., the reference to the RPH is covered, at least in part, by the gap >analysis "what can not be done" component of the charter. To the extent >that it is not, it seems that the right approach is to assume that the RPH >ID will be acted upon and become an RFC before the ieprep BCP is >finalized. If this doesn't happen, of course we would have to revise the >BCP draft. As an example of what I mentioned above, where exists a similar requirements ID and Standards Track mechanism ID for what you want in/for SDP? Or Diffserv (? Or MEGACO? I believe each doc is required per protocol, per mechanism (meaning there could be multiple docs written within one or each WG to solve what you/we need). >Dennis Berg >CSC >dennis.berg@dyncorp.com > >-----Original Message----- >From: RJ Atkinson >[mailto:rja@extremenetworks.com] >Sent: Wednesday, July 02, 2003 10:25 AM >To: Janet Gunn >Cc: ieprep@ietf.org >Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telephony > >On Wednesday, Jul 2, 2003, at 06:21 America/Montreal, Janet Gunn wrote: > > Several of us have coauthored a Best Common Practices ID on > > configuring a single domain, IP bridging, topology to support > > Emergency Telecommunications Service. > >Thanks for the heads-up. :-) > >A BCP document ought to represent actual currently deployed practice and >what the community believes to be the best practice at the time the >document >is published. > >Readers probably should consider whether those two properties hold >for the contents of the above document when reviewing the document. > >Ran > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep > cheers, James ******************* The answer is "42", what's the question? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 16:32:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12777 for ; Wed, 2 Jul 2003 16:32:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoGx-0002a4-EH for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 16:32:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KWBvF009916 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 16:32:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoGx-0002Zr-BQ for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 16:32:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12618 for ; Wed, 2 Jul 2003 16:32:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XoGt-0007GG-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 16:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XoGt-0007GD-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 16:32:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoGn-0002VO-JG; Wed, 02 Jul 2003 16:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoGb-0002Tu-By for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 16:31:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12528; Wed, 2 Jul 2003 16:31:44 -0400 (EDT) Message-Id: <200307022031.QAA12528@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 16:31:43 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-reflexive-dscp-02.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Reflexive DSCP Policy Author(s) : R. Atarashi, F. Baker Filename : draft-ietf-ieprep-reflexive-dscp-02.txt Pages : 10 Date : 2003-7-2 In reviewing the specific use of the Differentiated Services Architecture for supporting the Internet Emergency Preparedness System, we found what we believe is a general issue. This is that even though a client or peer can connect to a server or peer with a predictable DSCP value, the response does not have a predictable DSCP value. We consider the issues, and recommend an approach to application policy regarding the DSCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-reflexive-dscp-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ieprep-reflexive-dscp-02.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-ieprep-reflexive-dscp-02.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-reflexive-dscp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-reflexive-dscp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161426.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 20:20:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04854 for ; Wed, 2 Jul 2003 20:20:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XrpZ-0005Xs-Kz for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 20:20:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h630K9sl021312 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 20:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XrpZ-0005Xf-Gp for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 20:20:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04813 for ; Wed, 2 Jul 2003 20:20:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XrpX-0006oj-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 20:20:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XrpW-0006og-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 20:20:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XrpR-0005W5-KI; Wed, 02 Jul 2003 20:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XroZ-0005V0-Cp for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 20:19:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04658 for ; Wed, 2 Jul 2003 20:19:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XroX-0006ku-00 for ieprep@ietf.org; Wed, 02 Jul 2003 20:19:05 -0400 Received: from chntex04.is.dyncorp.com ([131.131.133.208]) by ietf-mx with esmtp (Exim 4.12) id 19XroW-0006kY-00 for ieprep@ietf.org; Wed, 02 Jul 2003 20:19:04 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jul 2003 20:16:53 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE899E0E9B@chntex04.is.dyncorp.com> From: "Berg, Dennis" To: "'James M. Polk'" , "'RJ Atkinson'" Cc: "'ieprep@ietf.org'" , "Gunn, Janet" , "'Pat_Mcgregor'" , "Kaczmarek, Richard NE" Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Date: Wed, 2 Jul 2003 20:16:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C340F8.6651CD90" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C340F8.6651CD90 Content-Type: text/plain Ran, James, In our ID, we have tried to separate "RECOMMENDED" practices from "suggested" work items for the IEPREP WG. As noted below, all the "RECOMMENDED" practices (we believe) have been checked for feasibility with existing protocols without protocol extensions, and can be applied via local administration. The "RECOMMENDED" practices do include specifics for such local administration, but we understand this is consistent both with BCP intent and with the needs of our ETS service providers. We recognize that use of local and experimental values limits the implementation to a single domain; however, the scope of the ID is just a single domain, which is the scope of our discussions with the service providers. Where we have seen protocol gaps, we have "suggested" (the flag word versus "RECOMMENDED" for actual BCP recommendations) IEPREP initiatives to address, and probably should be more explicit in characterizing such initiatives as efforts to develop Requirements that can then be used as input to the appropriate protocol WG. On a more detailed level, our "RECOMMENDED" practices and why we consider them within scope are noted below: 1. ETS call signaling should use the basic signaling protocol stack assumed for the reference topology (Conventional SS7 [SS7] from AT to STP to SG and SS7 over IP using M2UA [M2UA] over SCTP [SCTP] between the SG and MGC.) * This recommends the use of specific existing protocols for carrying SS7 over IP, and so clearly meets the BCP scope of specifying what can be done with existing protocols. 2. There should be direct mapping of the CSN (international and / or national) ETS call marking(s) and associated SS7 congestion priorities. * Recommends that two specific parameters of interest to ETS should be mapped ("preserved" probably would have been a better choice of words) at a signaling gateway. I.e., the SG should function just like an STP and send out only what it receives without modifying the input. 3. For an ETS call the same mapping and translation should be applied to the call setup IAM being sent from the IP network to the CSN upon egress as was applied to the IAM sent from the CSN to the IP network upon ingress, e.g., in the U.S.A. the NSEP codepoint in the Calling Party Category (CPC) and, if present, the optional Precedence parameter. * Recommends that the mapping and translation function - as specified for the ETS parameters of interest in (2) - at ingress and egress to the signaling gateway be symmetrical, i.e., that the network should be transparent. 4. The MPT3 congestion priority of the received IAM be propagated unchanged in the outgoing IAM, (e.g., in the U.S., IAMs with NSEP set have a congestion priority of one whereas all other IAMs have a lower congestion priority of zero). * Specifically, recommends that the congestion priority of the IAM at ingress not be changed at egress. 5. Assign two values from the experimental and local use pool of Diffserv codepoints to designate and differentiate International ETS and National ETS. * Our understanding is that the use of experimental and locally administrable items within a single domain is a practice, not a protocol extension. 6. Correlate the two Diffserv codepoints with a PHB constructed by "copying" the EF PHB, but perhaps changing some parameter values. * Our understanding is that defining a PHB for a Diffserv local and experimental codepoint is matter of practice. 7. Use the following specific experimental and local pool Diffserv codepoints: assignments: National Emergency = 011111, International Emergency = 011011 * This recommendation just calls out specific values for convenience in order to coordinate usage of the Diffserv values from this pool. 8. Separate ETS traffic treatment, both signaling and data, from other traffic treatment by the use of a dedicated MPLS Diff-serv codepoint in E-LSPs * We understand that MPLS codepoints and E-LSPs are matters of local administration. We intend to clarify this recommendation to specify that one of the two unused MPLS Diffserv codepoints should be used (specifically 6, since we understand that common practice is to use 7 for network management). Based upon the current practice of using 7 for network management, we conclude that we are able to recommend the practice of using 6 for ETS within a single administrative domain. 9. Associate the Diffserv PHB with the MPLS Diffserv codepoint as is used for Diffserv in general. * Again, if we can define the MPLS Diffserv codepoint at a matter of practice, it would seem that we can also define its PBH as a matter of practice. 10. ETS calls should be specified by use of the SIP Priority header with a designation of "emergency". * We are not recommending changing the use of this field for notifying the user. We're just saying, for ETS calls, use it for its intended purpose. 11. Use SDP attribute parameters to specify ETS sessions as either National Emergency sessions using the attribute parameter value "x-NatETS" (where the leading "x" is understood to be customary to designate non-standard values) or International Emergency sessions using the attribute parameter value "x-IntETS". * Since we are recommending locally administrable values, we understand this to be a matter of practice for a single administrable domain, rather than protocol extension. 12. Use the MEGACO ContextRequest parameter for "emergency" (Boolean) to indicate "emergency" and the MEGACO ContextRequest parameter for "priority" with priorities 0-4. * Our understanding here is that these parameters are already defined and their use is a matter of local practice. Note that we do not include the SIP RPH in any of our recommendations. We recognize that the SIP section is there for information and that the ETS namespace position needs to be officially pursued as a separate effort. We are at the stage of discussions with vendors and carriers that requires real (and preferably official) guidance on how we would like them to address our ETS needs in their new IP deployments. We understand a BCP carries with it the endorsement of the IETF, and although it is not a standard, it has a lot more weight than other non-standard RFCs. We recognize that some could raise the question of whether or not the IETF should advocate a practice without a firm experiential base for knowing if it is the best (or even a good) practice. Our view, at least at the moment, is that an expert view of what seems to be a "best practice in the absence of experience" is still a lot better in meeting our needs than no view at all. Would appreciate your specific feedback, specifically on our views of how the ID's recommendations are in scope for a BCP. Dennis, Janet, Pat, Kacz -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Wednesday, July 02, 2003 3:29 PM To: Berg, Dennis; 'RJ Atkinson' Cc: 'ieprep@ietf.org'; 'Janet Gunn' Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Teleph ony At 12:23 PM 7/2/2003 -0400, Berg, Dennis wrote: >Ran, > >Understand you comment, and we recognize that there is one case in the ID >where we are not using existing protocols, viz., the Resource Priority Header. Dennis - I believe you might have this backwards (maybe). The R-P header has had a requirements ID generated (and RFCd) by IEPREP (3487), and it is now properly being worked on by its existing Protocol WG (SIP). I don't see the same efforts (requirements IDs) for the other protocols mentioned within your ID (SDP, Diffserv, MPLS, MEGACO, etc) that (I believe) must go through the same process as the R-P header did (as painful as that was/is - hopefully R-P blazed a trail that others will find easier....). > But, we looked at the ieprep charter statements and thought they > supported that approach, at least partially: > > The working group will develop a BCP RFC or set of RFCs, regarding > operational implementation of services for Emergency Preparedness > using > existing Internet protocols. The RFC may include identification > of gaps > in existing protocols and requirements for use in new protocol or > protocol feature design. It is out of scope for this working > group to > do protocol or protocol feature development. > > Deliverables > > Best Current Practice: > IETF Recommendations for the Emergency Telecommunications Service > using existing protocols I believe this includes all existing extensions to existing protocols - which might be part of a discrepancy with your ID, because yours calls for many new extensions that each protocol's WGs haven't properly discussed (nor have many of these been discussed in IEPREP - SDP being the best example of one that hasn't been mentioned before). I'd say that the R-P header is 'the one' mentioned within your ID that *has* been discussed within its appropriate WG, and SIP is close to working out the final details of it now. None of the other extensions called for in this new ID have been discussed on any other mailing list or in the WG meetings that I know of in the last 4 years. > - what can be done with existing protocols > and what can not be done. What this ID calls for should be the results of much discussion and one or more requirements IDs calling for these extensions to occur with proper justification of usage and perhaps why existing mechanisms in each protocol can't solve what you want. >I.e., the reference to the RPH is covered, at least in part, by the gap >analysis "what can not be done" component of the charter. To the extent >that it is not, it seems that the right approach is to assume that the RPH >ID will be acted upon and become an RFC before the ieprep BCP is >finalized. If this doesn't happen, of course we would have to revise the >BCP draft. As an example of what I mentioned above, where exists a similar requirements ID and Standards Track mechanism ID for what you want in/for SDP? Or Diffserv (? Or MEGACO? I believe each doc is required per protocol, per mechanism (meaning there could be multiple docs written within one or each WG to solve what you/we need). >Dennis Berg >CSC >dennis.berg@dyncorp.com > >-----Original Message----- >From: RJ Atkinson >[mailto:rja@extremenetworks.com] >Sent: Wednesday, July 02, 2003 10:25 AM >To: Janet Gunn >Cc: ieprep@ietf.org >Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telephony > >On Wednesday, Jul 2, 2003, at 06:21 America/Montreal, Janet Gunn wrote: > > Several of us have coauthored a Best Common Practices ID on > > configuring a single domain, IP bridging, topology to support > > Emergency Telecommunications Service. > >Thanks for the heads-up. :-) > >A BCP document ought to represent actual currently deployed practice and >what the community believes to be the best practice at the time the >document >is published. > >Readers probably should consider whether those two properties hold >for the contents of the above document when reviewing the document. > >Ran > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailma n/listinfo/ieprep > cheers, James ******************* The answer is "42", what's the question? ------_=_NextPart_001_01C340F8.6651CD90 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP = Telephony

Ran, James,

In our ID, we have tried to separate "RECOMMENDED" = practices from "suggested" work items for the IEPREP WG.   As = noted below, all the "RECOMMENDED" practices (we believe) have been = checked for feasibility with existing protocols without protocol = extensions, and can be applied via local administration.  The = "RECOMMENDED" practices do include specifics for such local = administration, but we understand this is consistent both with BCP = intent and with the needs of our ETS service providers.  We = recognize that use of local and experimental values limits the = implementation to a single domain; however, the scope of the ID is just = a single domain, which is the scope of our discussions with the service = providers.

Where we have seen protocol gaps, we have "suggested" = (the flag word versus "RECOMMENDED" for actual BCP recommendations) = IEPREP initiatives to address, and probably should be more explicit in = characterizing such initiatives as efforts to develop Requirements that = can then be used as input to the appropriate protocol WG.  =

On a more detailed level, our "RECOMMENDED" practices = and why we consider them within scope are noted below:

1.  ETS call signaling should use the basic = signaling protocol stack assumed for the reference topology = (Conventional SS7 [SS7] from AT to STP to SG and SS7 over IP using M2UA = [M2UA] over SCTP [SCTP] between the SG and MGC.)

*  This recommends the use of specific existing = protocols for carrying SS7 over IP, and so clearly meets the BCP scope = of specifying what can be done with existing protocols.

2.  There should be direct mapping of the CSN = (international and / or national) ETS call marking(s) and associated = SS7 congestion priorities.

*  Recommends that two specific parameters of = interest to ETS should be mapped ("preserved" probably would have been = a better choice of words) at a signaling gateway. I.e., the SG should = function just like an STP and send out only what it receives without = modifying the input.

3.  For an ETS call the same mapping and = translation should be applied to the call setup IAM being sent from the = IP network to the CSN upon egress as was applied to the IAM sent from = the CSN to the IP network upon ingress, e.g., in the U.S.A. the NSEP = codepoint in the Calling Party Category (CPC) and, if present, the = optional Precedence parameter.

*  Recommends that the mapping and translation = function - as specified for the ETS parameters of interest in (2) - at = ingress and egress to the signaling gateway be symmetrical, i.e., that = the network should be transparent.

4.  The MPT3 congestion priority of the received = IAM be propagated unchanged in the outgoing IAM, (e.g., in the U.S., = IAMs with NSEP set have a congestion priority of one whereas all other = IAMs have a lower congestion priority of zero).

*  Specifically, recommends that the congestion = priority of the IAM at ingress not be changed at egress.

5.  Assign two values from the experimental and = local use pool of Diffserv codepoints to designate and differentiate = International ETS and National ETS.

*  Our understanding is that the use of = experimental and locally administrable items within a single domain is = a practice, not a protocol extension.

6.  Correlate the two Diffserv codepoints with a = PHB constructed by "copying" the EF PHB, but perhaps changing some = parameter values.

*  Our understanding is that defining a PHB for = a Diffserv local and experimental codepoint is matter of = practice.

7.  Use the following specific experimental and = local pool Diffserv codepoints: assignments: National Emergency =3D = 011111, International Emergency =3D 011011

*  This recommendation just calls out specific = values for convenience in order to coordinate usage of the Diffserv = values from this pool.

8.  Separate ETS traffic treatment, both = signaling and data, from other traffic treatment by the use of a = dedicated MPLS Diff-serv codepoint in E-LSPs

*  We understand that MPLS codepoints and E-LSPs = are matters of local administration.  We intend to clarify this = recommendation to specify that one of the two unused MPLS Diffserv = codepoints should be used (specifically 6, since we understand that = common practice is to use 7 for network management).  Based upon = the current practice of using 7 for network management, we conclude = that we are able to recommend the practice of using 6 for ETS within a = single administrative domain.

9.  Associate the Diffserv PHB with the MPLS = Diffserv codepoint as is used for Diffserv in general.
*  Again, if we can define the MPLS Diffserv = codepoint at a matter of practice, it would seem that we can also = define its PBH as a matter of practice.

10.  ETS calls should be specified by use of the = SIP Priority header with a designation of "emergency".  =
*  We are not recommending changing the use of = this field for notifying the user.  We're just saying, for ETS = calls, use it for its intended purpose.

11.  Use SDP attribute parameters to specify ETS = sessions as either National Emergency sessions using the attribute = parameter value "x-NatETS" (where the leading "x" = is understood to be customary to designate non-standard values) or = International Emergency sessions using the attribute parameter value = "x-IntETS".

*  Since we are recommending locally = administrable values, we understand this to be a matter of practice for = a single administrable domain, rather than protocol extension. =

12.  Use the MEGACO ContextRequest parameter for = "emergency" (Boolean) to indicate "emergency" and the MEGACO = ContextRequest parameter for "priority" with priorities 0-4.  =

*  Our understanding here is that these = parameters are already defined and their use is a matter of local = practice. 

Note that we do not include the SIP RPH in any of our = recommendations.  We recognize that the SIP section is there for = information and that the ETS namespace position needs to be officially = pursued as a separate effort.

We are at the stage of discussions with vendors and = carriers that requires real (and preferably official) guidance on how = we would like them to address our ETS needs in their new IP = deployments.  We understand a BCP carries with it the endorsement = of the IETF, and although it is not a standard, it has a lot more = weight than other non-standard RFCs.  We recognize that some could = raise the question of whether or not the IETF should advocate a = practice without a firm experiential base for knowing if it is the best = (or even a good) practice.  Our view, at least at the moment, is = that an expert view of what seems to be a "best practice in the absence = of experience" is still a lot better in meeting our needs than no view = at all.

Would appreciate your specific feedback, specifically = on our views of how the ID's recommendations are in scope for a = BCP.

Dennis, Janet, Pat, Kacz

-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Wednesday, July 02, 2003 3:29 PM
To: Berg, Dennis; 'RJ Atkinson'
Cc: 'ieprep@ietf.org'; 'Janet Gunn'
Subject: RE: [Ieprep] IP Bridging Configuration = Guidance for IEPREP Teleph ony

At 12:23 PM 7/2/2003 -0400, Berg, Dennis = wrote:

>Ran,
>
>Understand you comment, and we recognize that = there is one case in the ID
>where we are not using existing protocols, viz., = the Resource Priority Header.

Dennis - I believe you might have this backwards = (maybe). The R-P header
has had a requirements ID generated (and RFCd) by = IEPREP (3487), and it is
now properly being worked on by its existing = Protocol WG (SIP). I don't see
the same efforts (requirements IDs) for the other = protocols mentioned
within your ID (SDP, Diffserv, MPLS, MEGACO, etc) = that (I believe) must go
through the same process as the R-P header did (as = painful as that was/is -
hopefully R-P blazed a trail that others will find = easier....).

>  But, we looked at the ieprep charter = statements and thought they
> supported that approach, at least = partially:
>
>         = The working group will develop a BCP RFC or set of RFCs, = regarding
>         = operational implementation of services for Emergency Preparedness =
> using
>         = existing Internet protocols. The RFC may include identification
> of gaps
>         = in existing protocols and requirements for use in new protocol = or
>         = protocol feature design. It is out of scope for this working
> group to
>         = do protocol or protocol feature development.
>
>         = Deliverables
>
>         = Best Current Practice:
>          = IETF Recommendations for the Emergency Telecommunications = Service
>          = using existing protocols

I believe this includes all existing extensions to = existing protocols -
which might be part of a discrepancy with your ID, = because yours calls for
many new extensions that each protocol's WGs haven't = properly discussed
(nor have many of these been discussed in IEPREP - = SDP being the best
example of one that hasn't been mentioned = before).

I'd say that the R-P header is 'the one' mentioned = within your ID that
*has* been discussed within its appropriate WG, and = SIP is close to working
out the final details of it now. None of the other = extensions called for in
this new ID have been discussed on any other mailing = list or in the WG
meetings that I know of in the last 4 years.

>  - what can be done with existing = protocols
>          and = what can not be done.

What this ID calls for should be the results of much = discussion and one or
more requirements IDs calling for these extensions = to occur with proper
justification of usage and perhaps why existing = mechanisms in each protocol
can't solve what you want.


>I.e., the reference to the RPH is covered, at = least in part, by the gap
>analysis "what can not be done" = component of the charter.  To the extent
>that it is not, it seems that the right approach = is to assume that the RPH
>ID will be acted upon and become an RFC before = the ieprep BCP is
>finalized.  If this doesn't happen, of = course we would have to revise the
>BCP draft.

As an example of what I mentioned above, where exists = a similar
requirements ID and Standards Track mechanism ID for = what you want in/for
SDP? Or Diffserv (? Or MEGACO?

I believe each doc is required per protocol, per = mechanism (meaning there
could be multiple docs written within one or each WG = to solve what you/we
need).


>Dennis Berg
>CSC
>dennis.berg@dyncorp.com
>
>-----Original Message-----
>From: RJ Atkinson
>[<mailto:rja@extremenetworks.com>mailto:rja@extremenetworks.com]
>Sent: Wednesday, July 02, 2003 10:25 AM
>To: Janet Gunn
>Cc: ieprep@ietf.org
>Subject: Re: [Ieprep] IP Bridging Configuration = Guidance for IEPREP Telephony
>
>On Wednesday, Jul 2, 2003, at 06:21 = America/Montreal, Janet Gunn wrote:
> > Several of us have coauthored a Best = Common Practices ID on
> > configuring a single domain, IP bridging, = topology to support
> > Emergency Telecommunications = Service.
>
>Thanks for the heads-up. :-)
>
>A BCP document ought to represent actual = currently deployed practice and
>what the community believes to be the best = practice at the time the
>document
>is published.
>
>Readers probably should consider whether those = two properties hold
>for the contents of the above document when = reviewing the document.
>
>Ran
>
>_______________________________________________
>Ieprep mailing list
>Ieprep@ietf.org
><https://www1.ietf.org/mailman/listinfo/ieprep><= A HREF=3D"https://www1.ietf.org/mailman/listinfo/ieprep" = TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/ieprep =
>


cheers,
James

          &nb= sp;           &nb= sp;         = *******************
          &nb= sp;         The answer is = "42", what's the question?

------_=_NextPart_001_01C340F8.6651CD90-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 21:26:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09431 for ; Wed, 2 Jul 2003 21:26:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XsrO-00009H-Sa for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 21:26:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h631Q64O000565 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 21:26:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XsrO-000092-PD for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 21:26:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09374 for ; Wed, 2 Jul 2003 21:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XsrM-0000mv-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 21:26:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XsrL-0000mp-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 21:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XsrJ-00008G-Rq; Wed, 02 Jul 2003 21:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XsqQ-0008Sh-CG for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 21:25:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09272 for ; Wed, 2 Jul 2003 21:25:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XsqN-0000kk-00 for ieprep@ietf.org; Wed, 02 Jul 2003 21:25:03 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 19XsqM-0000kU-00 for ieprep@ietf.org; Wed, 02 Jul 2003 21:25:02 -0400 Received: from extremenetworks.com (unknown [10.0.8.94]) by gnat.inet.org (Postfix) with ESMTP id 974DC67104 for ; Wed, 2 Jul 2003 21:51:19 -0400 (EDT) Date: Wed, 2 Jul 2003 21:24:55 -0400 Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: quoted-printable In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE899E0E9B@chntex04.is.dyncorp.com> Message-Id: <2768623D-ACF5-11D7-A0E4-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: quoted-printable Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Wednesday, Jul 2, 2003, at 20:16 America/Montreal, Berg, Dennis=20 wrote: > We are at the stage of discussions with vendors and carriers that=20 > requires > real (and preferably official) guidance on how we would like them to=20= > address > our ETS needs in their new IP deployments.=A0 We understand a BCP = carries > with it the endorsement of the IETF, and although it is not a = standard, > it has a lot more weight than other non-standard RFCs.=A0 There is substantial experimental data (e.g. Navy TAC-4 workstation contract) that the US Government is not restricted to citing=20 standards-track documents in its procurements, contracts, or agreements. Instead, the evidence indicates that any open specification is something that could be used in a procurement, contract, or agreement. So the state of DISA or NCS (or any other party's) negotiations with vendors,=20 operators, or others is quite irrelevant to any IETF Working Group. An alternative approach would be for a set of concerned individuals or an organisation (e.g. DISA or NCS) to publish an Informational RFC as a position document, then work with operators to obtain appropriate practical deployment experience, then AFTERWARDS work towards moving a (possibly modified based on experience) document forward for=20 consideration as BCP. This would be a more productive approach in my own view. I continue to be concerned that contractors of the US Government are not acting as individuals here, but rather acting based primarily on who is paying which salaries. And I also continue to be concerned that those persons are not giving due and fair consideration of the=20 International (i.e. non-US) nature of both the IETF and the global Internet. > We recognize that some could raise the question of whether or not the=20= > IETF > should advocate a practice without a firm experiential base for = knowing > if it is the best (or even a good) practice.=A0 Not "some could" ask those questions, but rather that each active=20 participant in this WG NEEDS to consider those questions *as a normal part of being an active participant in an IETF WG*. Of course different individuals=20= might reach different conclusions -- on any question before any IETF WG -- but the responsibility of the IETF participant is to carefully consider=20 exactly those sorts of questions. As near as I can tell, it would not be consistent with past IETF=20 decisions and policies for IETF to publish a BCP about a practice that has=20 negligible deployment experience -- particularly in the situation at hand where=20 there are significant unresolved technical concerns with the specific=20 proposal. > Our view, at least at the moment, is that an expert view of what seems > to be a "best practice in the absence of experience" is still a lot=20 > better > in meeting our needs than no view at all. The working definition of "expert" is very much in the eye of the=20 beholder in this WG. There is significant evidence of non-consensus on the=20 problem definition as well as on the "expert's view" of how to proceed. While that is sad, it is also reality. We ought to keep grounded in reality. Yours, Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 2 21:32:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09592 for ; Wed, 2 Jul 2003 21:32:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xsx9-0000Pl-Vc for ieprep-archive@odin.ietf.org; Wed, 02 Jul 2003 21:32:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h631W3dJ001588 for ieprep-archive@odin.ietf.org; Wed, 2 Jul 2003 21:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xsx9-0000PX-Pi for ieprep-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 21:32:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09589 for ; Wed, 2 Jul 2003 21:32:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xsx7-0000tT-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 21:32:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xsx6-0000tQ-00 for ieprep-web-archive@ietf.org; Wed, 02 Jul 2003 21:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xsx7-0000O8-R7; Wed, 02 Jul 2003 21:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XswW-0000NN-Vp for ieprep@optimus.ietf.org; Wed, 02 Jul 2003 21:31:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09574 for ; Wed, 2 Jul 2003 21:31:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XswU-0000sz-00 for ieprep@ietf.org; Wed, 02 Jul 2003 21:31:22 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 19XswT-0000sw-00 for ieprep@ietf.org; Wed, 02 Jul 2003 21:31:21 -0400 Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h631V3Dw026471; Wed, 2 Jul 2003 21:31:03 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h631V3ru026470; Wed, 2 Jul 2003 21:31:03 -0400 (EDT) Date: Wed, 2 Jul 2003 21:31:03 -0400 (EDT) From: Scott Bradner Message-Id: <200307030131.h631V3ru026470@newdev.harvard.edu> To: Dennis.Berg@DynCorp.com, jmpolk@cisco.com, rja@extremenetworks.com Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Cc: ieprep@ietf.org, Janet.Gunn@DynCorp.com, pat_mcgregor@msn.com, Richard.Kaczmarek@DynCorp.com In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE899E0E9B@chntex04.is.dyncorp.com> Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > Would appreciate your specific feedback, specifically on our views of how > the ID's recommendations are in scope for a BCP. if the doc is designed to ask other IETF working groups to explore how to meet requirements that teh IEPREP WG feels need to be met to support emergency traffic then it can not be a BCP by definition and I agree with James that the odc should be split unto individual documents that provide ieprep requirements on a per technology nasis if the doc is intended to tell ISPs and enterprises what the IEPREP thinks is the best way to meet the needs of emergency traffic it must be based on technology that the ISPs or enterprises have or can get thus, if the doc suggests changes or additions to other IETF technologies (including having a SIP recource header) then it can not be published as a BCP until those changes have been accepted, and woudl have to be revised based on what the other IETF WGs actually do to your specific points > In our ID, we have tried to separate "RECOMMENDED" practices from > "suggested" work items for the IEPREP WG. As noted below, all the > "RECOMMENDED" practices (we believe) have been checked for feasibility with > existing protocols without protocol extensions, and can be applied via local > administration. The "RECOMMENDED" practices do include specifics for such > local administration, but we understand this is consistent both with BCP > intent and with the needs of our ETS service providers. We recognize that > use of local and experimental values limits the implementation to a single > domain; however, the scope of the ID is just a single domain, which is the > scope of our discussions with the service providers. > Where we have seen protocol gaps, we have "suggested" (the flag word versus > "RECOMMENDED" for actual BCP recommendations) IEPREP initiatives to address, > and probably should be more explicit in characterizing such initiatives as > efforts to develop Requirements that can then be used as input to the > appropriate protocol WG. I think a BCP should just say what is recommended to meet the needs and think teh difference between RECOMMENDED and "suggested" is too fine a difference to be clear to the reader > On a more detailed level, our "RECOMMENDED" practices and why we consider > them within scope are noted below: > > 1. ETS call signaling should use the basic signaling protocol stack assumed > for the reference topology (Conventional SS7 [SS7] from AT to STP to SG and > SS7 over IP using M2UA [M2UA] over SCTP [SCTP] between the SG and MGC.) > * This recommends the use of specific existing protocols for carrying SS7 > over IP, and so clearly meets the BCP scope of specifying what can be done > with existing protocols. if indeed it points to existing RFCs saying how to transport the particular SS7 functions over SCTP then this is in scope > 2. There should be direct mapping of the CSN (international and / or > national) ETS call marking(s) and associated SS7 congestion priorities. > * Recommends that two specific parameters of interest to ETS should be > mapped ("preserved" probably would have been a better choice of words) at a > signaling gateway. I.e., the SG should function just like an STP and send > out only what it receives without modifying the input. I may be confused but if its just SS7 stuff I'm not sure the IETF is right place to make recommendations > 3. For an ETS call the same mapping and translation should be applied to > the call setup IAM being sent from the IP network to the CSN upon egress as > was applied to the IAM sent from the CSN to the IP network upon ingress, > e.g., in the U.S.A. the NSEP codepoint in the Calling Party Category (CPC) > and, if present, the optional Precedence parameter. > * Recommends that the mapping and translation function - as specified for > the ETS parameters of interest in (2) - at ingress and egress to the > signaling gateway be symmetrical, i.e., that the network should be > transparent. if this is a recommendation on how a SIP field should be used then it should be done by the SIP WG - ieprep could tell sipping that there is a need to transport the NSEP codepoint to the gateway and the SIP wg can think about the best way to do that > 4. The MPT3 congestion priority of the received IAM be propagated unchanged > in the outgoing IAM, (e.g., in the U.S., IAMs with NSEP set have a > congestion priority of one whereas all other IAMs have a lower congestion > priority of zero). > * Specifically, recommends that the congestion priority of the IAM at > ingress not be changed at egress. I do not know how this actually applies to transporting things over IP networks - if it saying that data needs to be carried from the gateway to the IP end node then the comment for #3 applies - > 5. Assign two values from the experimental and local use pool of Diffserv > codepoints to designate and differentiate International ETS and National > ETS. > * Our understanding is that the use of experimental and locally > administrable items within a single domain is a practice, not a protocol > extension. I do not think that we can reasonabally avoid the normal review process for this type of thing by saying its just a local matter - this is defining a specific use of a value and any such definition should go thorugh the normal process for that variable - anything else distorts the review process that has been properly established for the variables > 6. Correlate the two Diffserv codepoints with a PHB constructed by > "copying" the EF PHB, but perhaps changing some parameter values. > * Our understanding is that defining a PHB for a Diffserv local and > experimental codepoint is matter of practice. see # 5 > 7. Use the following specific experimental and local pool Diffserv > codepoints: assignments: National Emergency = 011111, International > Emergency = 011011 > * This recommendation just calls out specific values for convenience in > order to coordinate usage of the Diffserv values from this pool. see # 5 > 8. Separate ETS traffic treatment, both signaling and data, from other > traffic treatment by the use of a dedicated MPLS Diff-serv codepoint in > E-LSPs > * We understand that MPLS codepoints and E-LSPs are matters of local > administration. We intend to clarify this recommendation to specify that > one of the two unused MPLS Diffserv codepoints should be used (specifically > 6, since we understand that common practice is to use 7 for network > management). Based upon the current practice of using 7 for network > management, we conclude that we are able to recommend the practice of using > 6 for ETS within a single administrative domain. see #5 > 9. Associate the Diffserv PHB with the MPLS Diffserv codepoint as is used > for Diffserv in general. > * Again, if we can define the MPLS Diffserv codepoint at a matter of > practice, it would seem that we can also define its PBH as a matter of > practice. see #5 > 10. ETS calls should be specified by use of the SIP Priority header with a > designation of "emergency". > * We are not recommending changing the use of this field for notifying the > user. We're just saying, for ETS calls, use it for its intended purpose. I do not think there is a "SIP Priority header" yet approved > 11. Use SDP attribute parameters to specify ETS sessions as either National > Emergency sessions using the attribute parameter value "x-NatETS" (where the > leading "x" is understood to be customary to designate non-standard values) > or International Emergency sessions using the attribute parameter value > "x-IntETS". > * Since we are recommending locally administrable values, we understand > this to be a matter of practice for a single administrable domain, rather > than protocol extension. see #5 > 12. Use the MEGACO ContextRequest parameter for "emergency" (Boolean) to > indicate "emergency" and the MEGACO ContextRequest parameter for "priority" > with priorities 0-4. > * Our understanding here is that these parameters are already defined and > their use is a matter of local practice. see #5 > Note that we do not include the SIP RPH in any of our recommendations. We > recognize that the SIP section is there for information and that the ETS > namespace position needs to be officially pursued as a separate effort. > > We are at the stage of discussions with vendors and carriers that requires > real (and preferably official) guidance on how we would like them to address > our ETS needs in their new IP deployments. We understand a BCP carries with > it the endorsement of the IETF, and although it is not a standard, it has a > lot more weight than other non-standard RFCs. We recognize that some could > raise the question of whether or not the IETF should advocate a practice > without a firm experiential base for knowing if it is the best (or even a > good) practice. Our view, at least at the moment, is that an expert view of > what seems to be a "best practice in the absence of experience" is still a > lot better in meeting our needs than no view at all. but that does not qualify a RFC to be designated a BCP - it could be designated experimental but without any indication that things would actually do what is needed it clearly can not be a BCP and again, I agree with James that the right way forward for these recommendations is to agree on documents that have the requirements for the other WGs and send them off to those WGs the idea behind the BCP deliverable in the charter came from the 1st BOF where it was pointed out that there were some things that were actually being done in today's networks and it was pointed out that it woudl be useful to write them down - Fred Baker did a pass on this and I've suggested to him that he revive that ID for further consideration now that the other work is mostly done Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 10:12:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12357 for ; Thu, 3 Jul 2003 10:12:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4oo-0005JH-D3 for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 10:12:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63ECEKi020407 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 10:12:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4oo-0005J4-6f for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 10:12:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12311 for ; Thu, 3 Jul 2003 10:12:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y4ol-0006sa-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 10:12:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y4ol-0006sW-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 10:12:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4ob-0005IF-Qj; Thu, 03 Jul 2003 10:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4o3-0005Hj-Nx for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 10:11:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12203 for ; Thu, 3 Jul 2003 10:11:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y4o1-0006rg-00 for ieprep@ietf.org; Thu, 03 Jul 2003 10:11:25 -0400 Received: from host-133-208.is.dyncorp.com ([131.131.133.208] helo=chntex04.is.dyncorp.com) by ietf-mx with esmtp (Exim 4.12) id 19Y4o0-0006rc-00 for ieprep@ietf.org; Thu, 03 Jul 2003 10:11:24 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 10:09:19 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AA41@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Scott Bradner'" , jmpolk@cisco.com, rja@extremenetworks.com, ieprep@ietf.org Cc: "Berg, Dennis" , pat_mcgregor@msn.com, "Kaczmarek, Richard NE" Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Date: Thu, 3 Jul 2003 10:09:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3416C.B1C00250" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3416C.B1C00250 Content-Type: text/plain; charset="iso-8859-1" Scott, Ran, Thanks for your comments. I think we understand your specifics and can aggregate them into the following views: 1) It would be better to develop the guidance as an informational RFC versus an official BCP, and then maybe later, if its application and experience warrants, advance it as a BCP. I think we agree with this approach. We certainly agree that our objective to provide guidance to our providers does not have to be met with "standards", but can be met with less "official" documents. We just want to gain as much as possible community review and consensus on how best to implement an ETS. The BCP description in the Charter sounded like the right thing, but if an informational RFC is more appropriate, then that is ok. 2) If we are trying to develop a BCP, then the "suggested" work initiatives should be removed and developed separately as IEPREP requirements products for input to the protocol WGs. We agree, and if the document is continued as a BCP initiative, we will edit accordingly. I also presume that if the document is an informational RFC, then it may be more appropriate to discuss the work in progress and its potential application, but that we should nonetheless initiate requirements docs for the work in progress we want to support and / or refine. 3) We should not try to bypass the normal review process for assignment of values to variables. We agree and that was not our intent. Rather, we were trying to align with the notion that a BCP should deal only with what can be done with existing protocol standards, and not with protocol extensions. Thus, we were advocating use of consistent local practices in variable value assignments as permitted in the standards until such assignments could be properly reviewed and advanced as standard. If we make the document an informational RFC versus a BCP, are we on better ground to suggest such local practice consistency in variable value assignment? We do not remember any document as you describe from Fred and if you could give us a pointer to it, that would be much appreciated. If he has not yet released a draft, then we would endorse your encouragement of him to do so. Finally, as a point of info, page 174 of the SIP RFC 3261 describes the Priority header (which is separate from the Resource-Priority header that is only in draft status and may have been what you were thinking of). Thanks again for the comments. I think the above summarizes the view, but if we missed some point or got a point wrong, please let us know. -----Original Message----- From: Scott Bradner [mailto:sob@harvard.edu] Sent: Wednesday, July 02, 2003 9:31 PM To: Berg, Dennis; jmpolk@cisco.com; rja@extremenetworks.com Cc: ieprep@ietf.org; Gunn, Janet; pat_mcgregor@msn.com; Kaczmarek, Richard NE Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony > Would appreciate your specific feedback, specifically on our views of how > the ID's recommendations are in scope for a BCP. if the doc is designed to ask other IETF working groups to explore how to meet requirements that teh IEPREP WG feels need to be met to support emergency traffic then it can not be a BCP by definition and I agree with James that the odc should be split unto individual documents that provide ieprep requirements on a per technology nasis if the doc is intended to tell ISPs and enterprises what the IEPREP thinks is the best way to meet the needs of emergency traffic it must be based on technology that the ISPs or enterprises have or can get thus, if the doc suggests changes or additions to other IETF technologies (including having a SIP recource header) then it can not be published as a BCP until those changes have been accepted, and woudl have to be revised based on what the other IETF WGs actually do to your specific points > In our ID, we have tried to separate "RECOMMENDED" practices from > "suggested" work items for the IEPREP WG. As noted below, all the > "RECOMMENDED" practices (we believe) have been checked for feasibility with > existing protocols without protocol extensions, and can be applied via local > administration. The "RECOMMENDED" practices do include specifics for such > local administration, but we understand this is consistent both with BCP > intent and with the needs of our ETS service providers. We recognize that > use of local and experimental values limits the implementation to a single > domain; however, the scope of the ID is just a single domain, which is the > scope of our discussions with the service providers. > Where we have seen protocol gaps, we have "suggested" (the flag word versus > "RECOMMENDED" for actual BCP recommendations) IEPREP initiatives to address, > and probably should be more explicit in characterizing such initiatives as > efforts to develop Requirements that can then be used as input to the > appropriate protocol WG. I think a BCP should just say what is recommended to meet the needs and think teh difference between RECOMMENDED and "suggested" is too fine a difference to be clear to the reader > On a more detailed level, our "RECOMMENDED" practices and why we consider > them within scope are noted below: > > 1. ETS call signaling should use the basic signaling protocol stack assumed > for the reference topology (Conventional SS7 [SS7] from AT to STP to SG and > SS7 over IP using M2UA [M2UA] over SCTP [SCTP] between the SG and MGC.) > * This recommends the use of specific existing protocols for carrying SS7 > over IP, and so clearly meets the BCP scope of specifying what can be done > with existing protocols. if indeed it points to existing RFCs saying how to transport the particular SS7 functions over SCTP then this is in scope > 2. There should be direct mapping of the CSN (international and / or > national) ETS call marking(s) and associated SS7 congestion priorities. > * Recommends that two specific parameters of interest to ETS should be > mapped ("preserved" probably would have been a better choice of words) at a > signaling gateway. I.e., the SG should function just like an STP and send > out only what it receives without modifying the input. I may be confused but if its just SS7 stuff I'm not sure the IETF is right place to make recommendations > 3. For an ETS call the same mapping and translation should be applied to > the call setup IAM being sent from the IP network to the CSN upon egress as > was applied to the IAM sent from the CSN to the IP network upon ingress, > e.g., in the U.S.A. the NSEP codepoint in the Calling Party Category (CPC) > and, if present, the optional Precedence parameter. > * Recommends that the mapping and translation function - as specified for > the ETS parameters of interest in (2) - at ingress and egress to the > signaling gateway be symmetrical, i.e., that the network should be > transparent. if this is a recommendation on how a SIP field should be used then it should be done by the SIP WG - ieprep could tell sipping that there is a need to transport the NSEP codepoint to the gateway and the SIP wg can think about the best way to do that > 4. The MPT3 congestion priority of the received IAM be propagated unchanged > in the outgoing IAM, (e.g., in the U.S., IAMs with NSEP set have a > congestion priority of one whereas all other IAMs have a lower congestion > priority of zero). > * Specifically, recommends that the congestion priority of the IAM at > ingress not be changed at egress. I do not know how this actually applies to transporting things over IP networks - if it saying that data needs to be carried from the gateway to the IP end node then the comment for #3 applies - > 5. Assign two values from the experimental and local use pool of Diffserv > codepoints to designate and differentiate International ETS and National > ETS. > * Our understanding is that the use of experimental and locally > administrable items within a single domain is a practice, not a protocol > extension. I do not think that we can reasonabally avoid the normal review process for this type of thing by saying its just a local matter - this is defining a specific use of a value and any such definition should go thorugh the normal process for that variable - anything else distorts the review process that has been properly established for the variables > 6. Correlate the two Diffserv codepoints with a PHB constructed by > "copying" the EF PHB, but perhaps changing some parameter values. > * Our understanding is that defining a PHB for a Diffserv local and > experimental codepoint is matter of practice. see # 5 > 7. Use the following specific experimental and local pool Diffserv > codepoints: assignments: National Emergency = 011111, International > Emergency = 011011 > * This recommendation just calls out specific values for convenience in > order to coordinate usage of the Diffserv values from this pool. see # 5 > 8. Separate ETS traffic treatment, both signaling and data, from other > traffic treatment by the use of a dedicated MPLS Diff-serv codepoint in > E-LSPs > * We understand that MPLS codepoints and E-LSPs are matters of local > administration. We intend to clarify this recommendation to specify that > one of the two unused MPLS Diffserv codepoints should be used (specifically > 6, since we understand that common practice is to use 7 for network > management). Based upon the current practice of using 7 for network > management, we conclude that we are able to recommend the practice of using > 6 for ETS within a single administrative domain. see #5 > 9. Associate the Diffserv PHB with the MPLS Diffserv codepoint as is used > for Diffserv in general. > * Again, if we can define the MPLS Diffserv codepoint at a matter of > practice, it would seem that we can also define its PBH as a matter of > practice. see #5 > 10. ETS calls should be specified by use of the SIP Priority header with a > designation of "emergency". > * We are not recommending changing the use of this field for notifying the > user. We're just saying, for ETS calls, use it for its intended purpose. I do not think there is a "SIP Priority header" yet approved > 11. Use SDP attribute parameters to specify ETS sessions as either National > Emergency sessions using the attribute parameter value "x-NatETS" (where the > leading "x" is understood to be customary to designate non-standard values) > or International Emergency sessions using the attribute parameter value > "x-IntETS". > * Since we are recommending locally administrable values, we understand > this to be a matter of practice for a single administrable domain, rather > than protocol extension. see #5 > 12. Use the MEGACO ContextRequest parameter for "emergency" (Boolean) to > indicate "emergency" and the MEGACO ContextRequest parameter for "priority" > with priorities 0-4. > * Our understanding here is that these parameters are already defined and > their use is a matter of local practice. see #5 > Note that we do not include the SIP RPH in any of our recommendations. We > recognize that the SIP section is there for information and that the ETS > namespace position needs to be officially pursued as a separate effort. > > We are at the stage of discussions with vendors and carriers that requires > real (and preferably official) guidance on how we would like them to address > our ETS needs in their new IP deployments. We understand a BCP carries with > it the endorsement of the IETF, and although it is not a standard, it has a > lot more weight than other non-standard RFCs. We recognize that some could > raise the question of whether or not the IETF should advocate a practice > without a firm experiential base for knowing if it is the best (or even a > good) practice. Our view, at least at the moment, is that an expert view of > what seems to be a "best practice in the absence of experience" is still a > lot better in meeting our needs than no view at all. but that does not qualify a RFC to be designated a BCP - it could be designated experimental but without any indication that things would actually do what is needed it clearly can not be a BCP and again, I agree with James that the right way forward for these recommendations is to agree on documents that have the requirements for the other WGs and send them off to those WGs the idea behind the BCP deliverable in the charter came from the 1st BOF where it was pointed out that there were some things that were actually being done in today's networks and it was pointed out that it woudl be useful to write them down - Fred Baker did a pass on this and I've suggested to him that he revive that ID for further consideration now that the other work is mostly done Scott ------_=_NextPart_001_01C3416C.B1C00250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP = Telephony

Scott, Ran,

Thanks for your comments.  I think we understand = your specifics and can aggregate them into the following views:

1)      It would be better = to develop the guidance as an informational RFC versus an official BCP, = and then maybe later, if its application and experience warrants, = advance it as a BCP.

I think we agree with this approach.  We = certainly agree that our objective to provide guidance to our providers = does not have to be met with "standards", but can be met with less = "official" documents.  We just want to gain as much as possible = community review and consensus on how best to implement an ETS.  = The BCP description in the Charter sounded like the right thing, but if = an informational RFC is more appropriate, then that is ok.  =

2)      If we are trying to = develop a BCP, then the "suggested" work initiatives should be removed = and developed separately as IEPREP requirements products for input to = the protocol WGs.

We agree, and if the document is continued as a BCP = initiative, we will edit accordingly.  I also presume that if the = document is an informational RFC, then it may be more appropriate to = discuss the work in progress and its potential application, but that we = should nonetheless initiate requirements docs for the work in progress = we want to support and / or refine.

3)      We should not try to = bypass the normal review process for assignment of values to = variables.

We agree and that was not our intent.  Rather, = we were trying to align with the notion that a BCP should deal only = with what can be done with existing protocol standards, and not with = protocol extensions.  Thus, we were advocating use of consistent = local practices in variable value assignments as permitted in the = standards until such assignments could be properly reviewed and = advanced as standard.  If we make the document an informational = RFC versus a BCP, are we on better ground to suggest such local = practice consistency in variable value assignment? 

We do not remember any document as you describe from = Fred and if you could give us a pointer to it, that would be much = appreciated.  If he has not yet released a draft, then we would = endorse your encouragement of him to do so. 

Finally, as a point of info, page 174 of the SIP RFC = 3261 describes the Priority header (which is separate from the = Resource-Priority header that is only in draft status and may have been = what you were thinking of).

Thanks again for the comments.  I think the = above summarizes the view, but if we missed some point or got a point = wrong, please let us know. 

-----Original Message-----
From: Scott Bradner [mailto:sob@harvard.edu]
Sent: Wednesday, July 02, 2003 9:31 PM
To: Berg, Dennis; jmpolk@cisco.com; = rja@extremenetworks.com
Cc: ieprep@ietf.org; Gunn, Janet; = pat_mcgregor@msn.com; Kaczmarek,
Richard NE
Subject: RE: [Ieprep] IP Bridging Configuration = Guidance for IEPREP
Telep hony


> Would appreciate your specific feedback, = specifically on our views of how
> the ID's recommendations are in scope for a = BCP.

if the doc is designed to ask other IETF working = groups to explore
how to meet requirements that teh IEPREP WG feels = need to be
met to support emergency traffic then it can not be = a BCP by definition
and I agree with James that the odc should be split = unto individual
documents that provide ieprep requirements on a per = technology nasis

if the doc is intended to tell ISPs and enterprises = what the IEPREP
thinks is the best way to meet the needs of = emergency traffic it must
be based on technology that the ISPs or enterprises = have or can get
thus, if the doc suggests changes or additions to = other IETF
technologies (including having a SIP recource = header) then it
can not be published as a BCP until those changes = have been accepted,
and woudl have to be revised based on what the other = IETF WGs actually do

to your specific points

> In our ID, we have tried to separate = "RECOMMENDED" practices from
> "suggested" work items for the IEPREP = WG.   As noted below, all the
> "RECOMMENDED" practices (we believe) = have been checked for feasibility with
> existing protocols without protocol extensions, = and can be applied via local
> administration.  The = "RECOMMENDED" practices do include specifics for such
> local administration, but we understand this is = consistent both with BCP
> intent and with the needs of our ETS service = providers.  We recognize that
> use of local and experimental values limits the = implementation to a single
> domain; however, the scope of the ID is just a = single domain, which is the
> scope of our discussions with the service = providers.
> Where we have seen protocol gaps, we have = "suggested" (the flag word versus
> "RECOMMENDED" for actual BCP = recommendations) IEPREP initiatives to address,
> and probably should be more explicit in = characterizing such initiatives as
> efforts to develop Requirements that can then = be used as input to the
> appropriate protocol WG. 

I think a BCP should just say what is recommended to = meet the needs
and think teh difference between RECOMMENDED and = "suggested" is too
fine a difference to be clear to the reader

> On a more detailed level, our = "RECOMMENDED" practices and why we consider
> them within scope are noted below:
>
> 1.  ETS call signaling should use the = basic signaling protocol stack assumed
> for the reference topology (Conventional SS7 = [SS7] from AT to STP to SG and
> SS7 over IP using M2UA [M2UA] over SCTP [SCTP] = between the SG and MGC.)
> *  This recommends the use of specific = existing protocols for carrying SS7
> over IP, and so clearly meets the BCP scope of = specifying what can be done
> with existing protocols.

if indeed it points to existing RFCs saying how to = transport the
particular SS7 functions over SCTP then this is in = scope

> 2.  There should be direct mapping of the = CSN (international and / or
> national) ETS call marking(s) and associated = SS7 congestion priorities.
> *  Recommends that two specific parameters = of interest to ETS should be
> mapped ("preserved" probably would = have been a better choice of words) at a
> signaling gateway. I.e., the SG should function = just like an STP and send
> out only what it receives without modifying the = input.

I may be confused but if its just SS7 stuff I'm not = sure the IETF is
right place to make recommendations

> 3.  For an ETS call the same mapping and = translation should be applied to
> the call setup IAM being sent from the IP = network to the CSN upon egress as
> was applied to the IAM sent from the CSN to the = IP network upon ingress,
> e.g., in the U.S.A. the NSEP codepoint in the = Calling Party Category (CPC)
> and, if present, the optional Precedence = parameter.
> *  Recommends that the mapping and = translation function - as specified for
> the ETS parameters of interest in (2) - at = ingress and egress to the
> signaling gateway be symmetrical, i.e., that = the network should be
> transparent.

if this is a recommendation on how a SIP field should = be used then
it should be done by the SIP WG - ieprep could tell = sipping that
there is a need to transport the  NSEP = codepoint to the gateway
and the SIP wg can think about the best way to do = that

> 4.  The MPT3 congestion priority of the = received IAM be propagated unchanged
> in the outgoing IAM, (e.g., in the U.S., IAMs = with NSEP set have a
> congestion priority of one whereas all other = IAMs have a lower congestion
> priority of zero).
> *  Specifically, recommends that the = congestion priority of the IAM at
> ingress not be changed at egress.

I do not know how this actually applies to = transporting things
over IP networks - if it saying that data needs to = be carried from the
gateway to the IP end node then the comment for #3 = applies -

> 5.  Assign two values from the experimental = and local use pool of Diffserv
> codepoints to designate and differentiate = International ETS and National
> ETS.
> *  Our understanding is that the use of = experimental and locally
> administrable items within a single domain is a = practice, not a protocol
> extension.

I do not think that we can reasonabally avoid the = normal review process
for this type of thing by saying its just a local = matter - this is defining
a specific use of a value and any such definition = should go thorugh
the normal process for that variable - anything else = distorts the
review process that has been properly established = for the variables

> 6.  Correlate the two Diffserv codepoints = with a PHB constructed by
> "copying" the EF PHB, but perhaps = changing some parameter values.
> *  Our understanding is that defining a = PHB for a Diffserv local and
> experimental codepoint is matter of = practice.

see # 5

> 7.  Use the following specific experimental = and local pool Diffserv
> codepoints: assignments: National Emergency =3D = 011111, International
> Emergency =3D 011011
> *  This recommendation just calls out = specific values for convenience in
> order to coordinate usage of the Diffserv = values from this pool.

see # 5

> 8.  Separate ETS traffic treatment, both = signaling and data, from other
> traffic treatment by the use of a dedicated = MPLS Diff-serv codepoint in
> E-LSPs
> *  We understand that MPLS codepoints and = E-LSPs are matters of local
> administration.  We intend to clarify this = recommendation to specify that
> one of the two unused MPLS Diffserv codepoints = should be used (specifically
> 6, since we understand that common practice is = to use 7 for network
> management).  Based upon the current = practice of using 7 for network
> management, we conclude that we are able to = recommend the practice of using
> 6 for ETS within a single administrative = domain.

see #5

> 9.  Associate the Diffserv PHB with the = MPLS Diffserv codepoint as is used
> for Diffserv in general.
> *  Again, if we can define the MPLS = Diffserv codepoint at a matter of
> practice, it would seem that we can also define = its PBH as a matter of
> practice.

see #5

> 10.  ETS calls should be specified by use = of the SIP Priority header with a
> designation of "emergency".  =
> *  We are not recommending changing the = use of this field for notifying the
> user.  We're just saying, for ETS calls, = use it for its intended purpose.

I do not think there is a "SIP Priority = header" yet approved

> 11.  Use SDP attribute parameters to = specify ETS sessions as either National
> Emergency sessions using the attribute = parameter value "x-NatETS" (where the
> leading "x" is understood to be = customary to designate non-standard values)
> or International Emergency sessions using the = attribute parameter value
> "x-IntETS".
> *  Since we are recommending locally = administrable values, we understand
> this to be a matter of practice for a single = administrable domain, rather
> than protocol extension.

see #5

> 12.  Use the MEGACO ContextRequest = parameter for "emergency" (Boolean) to
> indicate "emergency" and the MEGACO = ContextRequest parameter for "priority"
> with priorities 0-4. 
> *  Our understanding here is that these = parameters are already defined and
> their use is a matter of local practice.  =

see #5

> Note that we do not include the SIP RPH in any = of our recommendations.  We
> recognize that the SIP section is there for = information and that the ETS
> namespace position needs to be officially = pursued as a separate effort.
>
> We are at the stage of discussions with vendors = and carriers that requires
> real (and preferably official) guidance on how = we would like them to address
> our ETS needs in their new IP = deployments.  We understand a BCP carries with
> it the endorsement of the IETF, and although it = is not a standard, it has a
> lot more weight than other non-standard = RFCs.  We recognize that some could
> raise the question of whether or not the IETF = should advocate a practice
> without a firm experiential base for knowing if = it is the best (or even a
> good) practice.  Our view, at least at the = moment, is that an expert view of
> what seems to be a "best practice in the = absence of experience" is still a
> lot better in meeting our needs than no view at = all.

but that does not qualify a RFC to be designated a = BCP - it could
be designated experimental but without any = indication that
things would actually do what is needed it clearly = can not be a BCP

and again, I agree with James that the right way = forward for these
recommendations is to agree on documents that have = the requirements
for the other WGs and send them off to those = WGs

the idea behind the BCP deliverable in the charter = came from the
1st BOF where it was pointed out that there were = some things
that were actually being done in today's networks = and it was
pointed out that it woudl be useful to write them = down - Fred Baker
did a pass on this and I've suggested to him that he = revive that
ID for further consideration now that the other work = is mostly
done

Scott

------_=_NextPart_001_01C3416C.B1C00250-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 10:17:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12931 for ; Thu, 3 Jul 2003 10:17:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4tX-0005WH-PI for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 10:17:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63EH7V0021211 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 10:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4tX-0005W2-Ka for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 10:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12888 for ; Thu, 3 Jul 2003 10:17:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y4tV-0006x6-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 10:17:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y4tU-0006x3-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 10:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4tR-0005TB-DQ; Thu, 03 Jul 2003 10:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4t8-0005Qo-Tp for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 10:16:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12851 for ; Thu, 3 Jul 2003 10:16:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y4t6-0006wU-00 for ieprep@ietf.org; Thu, 03 Jul 2003 10:16:40 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 19Y4t4-0006wF-00 for ieprep@ietf.org; Thu, 03 Jul 2003 10:16:39 -0400 Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h63EGNDw004673; Thu, 3 Jul 2003 10:16:23 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h63EGNl9004672; Thu, 3 Jul 2003 10:16:23 -0400 (EDT) Date: Thu, 3 Jul 2003 10:16:23 -0400 (EDT) From: Scott Bradner Message-Id: <200307031416.h63EGNl9004672@newdev.harvard.edu> To: ieprep@ietf.org, Janet.Gunn@DynCorp.com, jmpolk@cisco.com, rja@extremenetworks.com, sob@harvard.edu Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Cc: Dennis.Berg@DynCorp.com, pat_mcgregor@msn.com, Richard.Kaczmarek@DynCorp.com In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE8915AA41@chntex04.is.dyncorp.com> Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > We do not remember any document as you describe from Fred and if you could > give us a pointer to it, that would be much appreciated. draft-ietf-ieprep-packet-marking-policy-01.txt but the ID has expired - you can find it through google Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 10:32:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13494 for ; Thu, 3 Jul 2003 10:32:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y57z-0006EF-Qk for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 10:32:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63EW3Dw023937 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 10:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y57z-0006E0-LS for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 10:32:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13480 for ; Thu, 3 Jul 2003 10:32:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y57x-0007C4-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 10:32:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y57w-0007C1-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 10:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y57x-0006CO-8S; Thu, 03 Jul 2003 10:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y57v-0006BW-Em for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 10:31:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13472 for ; Thu, 3 Jul 2003 10:31:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y57s-0007Bm-00 for ieprep@ietf.org; Thu, 03 Jul 2003 10:31:56 -0400 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx with smtp (Exim 4.12) id 19Y57s-0007Bi-00 for ieprep@ietf.org; Thu, 03 Jul 2003 10:31:56 -0400 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Jul 2003 15:31:50 +0100 To: Scott Bradner cc: ieprep@ietf.org, Janet.Gunn@DynCorp.com, jmpolk@cisco.com, rja@extremenetworks.com, Dennis.Berg@DynCorp.com, pat_mcgregor@msn.com, Richard.Kaczmarek@DynCorp.com, K.Carlberg@cs.ucl.ac.uk Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony In-reply-to: Your message of "Thu, 03 Jul 2003 10:16:23 EDT." <200307031416.h63EGNl9004672@newdev.harvard.edu> Date: Thu, 03 Jul 2003 15:31:49 +0100 Message-ID: <4189.1057242709@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > draft-ietf-ieprep-packet-marking-policy-01.txt > > but the ID has expired - you can find it through google the draft can also be found in the proceedings of the Tokyo IETF, where Fred gave a presentation on the draft (see Transport area, IEPREP). http://www.ietf.org/proceedings/02jul/index.html -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 10:37:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13714 for ; Thu, 3 Jul 2003 10:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Cr-0006bt-5r for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 10:37:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Eb55O025403 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 10:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Cr-0006be-1b for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 10:37:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13688 for ; Thu, 3 Jul 2003 10:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5Co-0007Hz-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 10:37:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y5Co-0007Hw-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 10:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Cn-0006Y4-Vi; Thu, 03 Jul 2003 10:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5CO-0006Uc-TQ for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 10:36:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13664 for ; Thu, 3 Jul 2003 10:36:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5CM-0007HF-00 for ieprep@ietf.org; Thu, 03 Jul 2003 10:36:34 -0400 Received: from host-133-208.is.dyncorp.com ([131.131.133.208] helo=chntex04.is.dyncorp.com) by ietf-mx with esmtp (Exim 4.12) id 19Y5CL-0007Gv-00 for ieprep@ietf.org; Thu, 03 Jul 2003 10:36:33 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 10:34:17 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AA43@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Scott Bradner'" , ieprep@ietf.org, jmpolk@cisco.com, rja@extremenetworks.com Cc: "Berg, Dennis" , pat_mcgregor@msn.com, "Kaczmarek, Richard NE" Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Date: Thu, 3 Jul 2003 10:34:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34170.2EB62F20" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C34170.2EB62F20 Content-Type: text/plain; charset="iso-8859-1" OK, I have that one. I will send it to Dennis, Pat and Kaz. I didn't realize it was considered a BCP. -----Original Message----- From: Scott Bradner [mailto:sob@harvard.edu] Sent: Thursday, July 03, 2003 10:16 AM To: ieprep@ietf.org; Gunn, Janet; jmpolk@cisco.com; rja@extremenetworks.com; sob@harvard.edu Cc: Berg, Dennis; pat_mcgregor@msn.com; Kaczmarek, Richard NE Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony > We do not remember any document as you describe from Fred and if you could > give us a pointer to it, that would be much appreciated. draft-ietf-ieprep-packet-marking-policy-01.txt but the ID has expired - you can find it through google Scott ------_=_NextPart_001_01C34170.2EB62F20 Content-Type: text/html; charset="iso-8859-1" RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony

OK, I have that one.  I will send it to Dennis, Pat and Kaz.  I didn't realize it was considered a BCP.

-----Original Message-----
From: Scott Bradner [mailto:sob@harvard.edu]
Sent: Thursday, July 03, 2003 10:16 AM
To: ieprep@ietf.org; Gunn, Janet; jmpolk@cisco.com;
rja@extremenetworks.com; sob@harvard.edu
Cc: Berg, Dennis; pat_mcgregor@msn.com; Kaczmarek, Richard NE
Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP
Telep hony


> We do not remember any document as you describe from Fred and if you could
> give us a pointer to it, that would be much appreciated.

draft-ietf-ieprep-packet-marking-policy-01.txt

but the ID has expired - you can find it through google

Scott

------_=_NextPart_001_01C34170.2EB62F20-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 10:40:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13787 for ; Thu, 3 Jul 2003 10:40:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Fl-0006xt-Me for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 10:40:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Ee5MF026767 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 10:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Fl-0006xW-Fv for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 10:40:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13784 for ; Thu, 3 Jul 2003 10:40:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5Fj-0007Ka-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 10:40:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y5Fi-0007KX-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 10:40:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Fj-0006w7-1w; Thu, 03 Jul 2003 10:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5FJ-0006vF-I8 for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 10:39:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13776 for ; Thu, 3 Jul 2003 10:39:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5FH-0007KD-00 for ieprep@ietf.org; Thu, 03 Jul 2003 10:39:35 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 19Y5FG-0007KA-00 for ieprep@ietf.org; Thu, 03 Jul 2003 10:39:34 -0400 Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h63EdQDw004858; Thu, 3 Jul 2003 10:39:26 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h63EdQCm004857; Thu, 3 Jul 2003 10:39:26 -0400 (EDT) Date: Thu, 3 Jul 2003 10:39:26 -0400 (EDT) From: Scott Bradner Message-Id: <200307031439.h63EdQCm004857@newdev.harvard.edu> To: ieprep@ietf.org, Janet.Gunn@DynCorp.com, jmpolk@cisco.com, rja@extremenetworks.com, sob@harvard.edu Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Cc: Dennis.Berg@DynCorp.com, pat_mcgregor@msn.com, Richard.Kaczmarek@DynCorp.com In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE8915AA43@chntex04.is.dyncorp.com> Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , > OK, I have that one. I will send it to Dennis, Pat and Kaz. I didn't > realize it was considered a BCP. it is not yet considered a BCP - that would not happen unless the WG consensus is that it represents the best way we know of to meet the requirements with existing technology (I've not read the ID in a year and do not specifically recommend or not recommend it to the WG but Fred was writing from experience and that is a good start for a document to be considered for publication as a BCP RFC) Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 12:55:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24495 for ; Thu, 3 Jul 2003 12:55:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7MQ-0007pg-2n for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 12:55:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Gt6cw030108 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 12:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7MP-0007pX-Us for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 12:55:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24479 for ; Thu, 3 Jul 2003 12:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7MO-0003AZ-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 12:55:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y7MN-0003AW-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 12:55:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7ML-0007o1-5S; Thu, 03 Jul 2003 12:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7Le-0007nA-2I for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 12:54:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24419 for ; Thu, 3 Jul 2003 12:54:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7Lc-00039X-00 for ieprep@ietf.org; Thu, 03 Jul 2003 12:54:16 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19Y7La-00038V-00 for ieprep@ietf.org; Thu, 03 Jul 2003 12:54:14 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 03 Jul 2003 09:50:31 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h63GrfQr011774; Thu, 3 Jul 2003 09:53:42 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA21008; Thu, 3 Jul 2003 09:53:39 -0700 (PDT) Message-Id: <4.3.2.7.2.20030703110135.05147f00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Jul 2003 11:53:23 -0500 To: "Gunn, Janet" , "'Scott Bradner'" , rja@extremenetworks.com, ieprep@ietf.org From: "James M. Polk" Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Cc: "Berg, Dennis" , pat_mcgregor@msn.com, "Kaczmarek, Richard NE" In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE8915AA41@chntex04.is.dyncorp .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , I think there has been some misunderstandings about the charter and the IETF process(es). An ID that is to become a BCP does so after WG consensus, this ID clearly hasn't achieved that consensus - therefore I question its movement towards an Informational publication at this point. This ID calls for specific changes to existing protocols which have been stated as only a matter of local policy, therefore the existing protocols aren't really changed - this is *not* correct. An existing protocol is one that requires nothing new to be done to it; a form of implement "as is in RFC XXXX". Take SDP for example, if someone were to implement RFC 2327 "as is", would they get what you are calling for? The answer would be "no". You have called for an extension to that protocol within your ID - and that is not appropriate without the WG that is responsible for SDP to reach consensus on that extension. This is where a requirement(s) ID should be generated by the IEPREP WG into the MMUSIC WG to extend the SDP protocol. This would allow (perhaps almost force) MMUSIC to look at this requirements ID and decide if further work was necessary (through WG discussions). If further work was deemed necessary to satisfy this/these requirements, then a extension mechanism ID would be generated by someone as a Standards Track ID (in MMUSIC) to (hopefully) become a Standards Track RFC. Only at that point can a BCP (anywhere) reference it this capability. I read at least 5 different extensions that are needed to different protocols from your ID. I almost feel as if this ID was the conclusions of a gap analysis. That isn't a bad thing. My belief is that the conclusions of a gap analysis should generate one or more requirements IDs to be RFCd and put forth into the appropriate WGs for their discussions (just as in the SDP example mentioned above). One idea from this ID is to turn it backwards into a requirements ID with what you conclude as the probable answers to the requirements. For example with SDP, you state that there should be two new attributes (x-NatETS and x-IntETS). In this new requirements ID, you (someone) can clearly state why the existing SDP (upon a careful review of specific referenced RFCs) cannot satisfy what you envision these new attributes accomplishing, and thus require "something" be done to satisfy these new capabilities that SDP MUST provide (that it currently doesn't). This will lead to pointed discussions about SDP, and will allow community review of the requirements before deciding on the appropriate mechanism so satisfy the requirements. Having this requirements ID be a separate ID for SDP would allow specific energy to be directed at the ID by those that know SDP. This would be in contrast to an all-encompassing requirements ID that covers (at least) 5 different protocols requiring people to sift through what they are not interested in to get to what they are interested in. This also saves the sanity of the authors *not* having to keep one document together that makes sense ;-) Similar approaches should be taken with all protocols mentioned within this ID (Diffserv, MPLS, SIP, MEGACO). Now to a point of correction, there is indeed a SIP Priority Header, but it is not used in a fashion you appear to think it does. The SIP Priority Header does NOT cause anything to be processed any differently, it is merely an indication to the receiving user (and not the user agent) of the importance of the session. This was why Henning and I needed to propose an extension to the SIP protocol for resource priority of SIP entities between the requesting and responding UAs. This effort had to be in a separate ID, after a requirements ID was agreed upon (RFC 3487). Once a Resource Priority header is created via a Standards Track RFC, vendors should interpret any priority in that header to also mean a priority indication to the called user (via the UI). In your ID's reference to the SIP Priority header, it gives the syntax of the Resource Priority Header (without referencing that ID, BTW). This, too, is incorrect. At 10:09 AM 7/3/2003 -0400, Gunn, Janet wrote: >Scott, Ran, > >Thanks for your comments. I think we understand your specifics and can >aggregate them into the following views: > >1) It would be better to develop the guidance as an informational RFC >versus an official BCP, and then maybe later, if its application and >experience warrants, advance it as a BCP. > >I think we agree with this approach. We certainly agree that our >objective to provide guidance to our providers does not have to be met >with "standards", but can be met with less "official" documents. We just >want to gain as much as possible community review and consensus on how >best to implement an ETS. The BCP description in the Charter sounded like >the right thing, but if an informational RFC is more appropriate, then >that is ok. > >2) If we are trying to develop a BCP, then the "suggested" work >initiatives should be removed and developed separately as IEPREP >requirements products for input to the protocol WGs. > >We agree, and if the document is continued as a BCP initiative, we will >edit accordingly. I also presume that if the document is an informational >RFC, then it may be more appropriate to discuss the work in progress and >its potential application, but that we should nonetheless initiate >requirements docs for the work in progress we want to support and / or refine. > >3) We should not try to bypass the normal review process for >assignment of values to variables. > >We agree and that was not our intent. Rather, we were trying to align >with the notion that a BCP should deal only with what can be done with >existing protocol standards, and not with protocol extensions. Thus, we >were advocating use of consistent local practices in variable value >assignments as permitted in the standards until such assignments could be >properly reviewed and advanced as standard. If we make the document an >informational RFC versus a BCP, are we on better ground to suggest such >local practice consistency in variable value assignment? > >We do not remember any document as you describe from Fred and if you could >give us a pointer to it, that would be much appreciated. If he has not >yet released a draft, then we would endorse your encouragement of him to >do so. > >Finally, as a point of info, page 174 of the SIP RFC 3261 describes the >Priority header (which is separate from the Resource-Priority header that >is only in draft status and may have been what you were thinking of). > >Thanks again for the comments. I think the above summarizes the view, but >if we missed some point or got a point wrong, please let us know. > >-----Original Message----- >From: Scott Bradner [mailto:sob@harvard.edu] >Sent: Wednesday, July 02, 2003 9:31 PM >To: Berg, Dennis; jmpolk@cisco.com; rja@extremenetworks.com >Cc: ieprep@ietf.org; Gunn, Janet; pat_mcgregor@msn.com; Kaczmarek, >Richard NE >Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP >Telep hony > > > Would appreciate your specific feedback, specifically on our views of how > > the ID's recommendations are in scope for a BCP. > >if the doc is designed to ask other IETF working groups to explore >how to meet requirements that teh IEPREP WG feels need to be >met to support emergency traffic then it can not be a BCP by definition >and I agree with James that the odc should be split unto individual >documents that provide ieprep requirements on a per technology nasis > >if the doc is intended to tell ISPs and enterprises what the IEPREP >thinks is the best way to meet the needs of emergency traffic it must >be based on technology that the ISPs or enterprises have or can get >thus, if the doc suggests changes or additions to other IETF >technologies (including having a SIP recource header) then it >can not be published as a BCP until those changes have been accepted, >and woudl have to be revised based on what the other IETF WGs actually do > >to your specific points > > > In our ID, we have tried to separate "RECOMMENDED" practices from > > "suggested" work items for the IEPREP WG. As noted below, all the > > "RECOMMENDED" practices (we believe) have been checked for feasibility > with > > existing protocols without protocol extensions, and can be applied via > local > > administration. The "RECOMMENDED" practices do include specifics for such > > local administration, but we understand this is consistent both with BCP > > intent and with the needs of our ETS service providers. We recognize that > > use of local and experimental values limits the implementation to a single > > domain; however, the scope of the ID is just a single domain, which is the > > scope of our discussions with the service providers. > > Where we have seen protocol gaps, we have "suggested" (the flag word > versus > > "RECOMMENDED" for actual BCP recommendations) IEPREP initiatives to > address, > > and probably should be more explicit in characterizing such initiatives as > > efforts to develop Requirements that can then be used as input to the > > appropriate protocol WG. > >I think a BCP should just say what is recommended to meet the needs >and think teh difference between RECOMMENDED and "suggested" is too >fine a difference to be clear to the reader > > > On a more detailed level, our "RECOMMENDED" practices and why we consider > > them within scope are noted below: > > > > 1. ETS call signaling should use the basic signaling protocol stack > assumed > > for the reference topology (Conventional SS7 [SS7] from AT to STP to SG > and > > SS7 over IP using M2UA [M2UA] over SCTP [SCTP] between the SG and MGC.) > > * This recommends the use of specific existing protocols for carrying SS7 > > over IP, and so clearly meets the BCP scope of specifying what can be done > > with existing protocols. > >if indeed it points to existing RFCs saying how to transport the >particular SS7 functions over SCTP then this is in scope > > > 2. There should be direct mapping of the CSN (international and / or > > national) ETS call marking(s) and associated SS7 congestion priorities. > > * Recommends that two specific parameters of interest to ETS should be > > mapped ("preserved" probably would have been a better choice of words) > at a > > signaling gateway. I.e., the SG should function just like an STP and send > > out only what it receives without modifying the input. > >I may be confused but if its just SS7 stuff I'm not sure the IETF is >right place to make recommendations > > > 3. For an ETS call the same mapping and translation should be applied to > > the call setup IAM being sent from the IP network to the CSN upon > egress as > > was applied to the IAM sent from the CSN to the IP network upon ingress, > > e.g., in the U.S.A. the NSEP codepoint in the Calling Party Category (CPC) > > and, if present, the optional Precedence parameter. > > * Recommends that the mapping and translation function - as specified for > > the ETS parameters of interest in (2) - at ingress and egress to the > > signaling gateway be symmetrical, i.e., that the network should be > > transparent. > >if this is a recommendation on how a SIP field should be used then >it should be done by the SIP WG - ieprep could tell sipping that >there is a need to transport the NSEP codepoint to the gateway >and the SIP wg can think about the best way to do that > > > 4. The MPT3 congestion priority of the received IAM be propagated > unchanged > > in the outgoing IAM, (e.g., in the U.S., IAMs with NSEP set have a > > congestion priority of one whereas all other IAMs have a lower congestion > > priority of zero). > > * Specifically, recommends that the congestion priority of the IAM at > > ingress not be changed at egress. > >I do not know how this actually applies to transporting things >over IP networks - if it saying that data needs to be carried from the >gateway to the IP end node then the comment for #3 applies - > > > 5. Assign two values from the experimental and local use pool of Diffserv > > codepoints to designate and differentiate International ETS and National > > ETS. > > * Our understanding is that the use of experimental and locally > > administrable items within a single domain is a practice, not a protocol > > extension. > >I do not think that we can reasonabally avoid the normal review process >for this type of thing by saying its just a local matter - this is defining >a specific use of a value and any such definition should go thorugh >the normal process for that variable - anything else distorts the >review process that has been properly established for the variables > > > 6. Correlate the two Diffserv codepoints with a PHB constructed by > > "copying" the EF PHB, but perhaps changing some parameter values. > > * Our understanding is that defining a PHB for a Diffserv local and > > experimental codepoint is matter of practice. > >see # 5 > > > 7. Use the following specific experimental and local pool Diffserv > > codepoints: assignments: National Emergency = 011111, International > > Emergency = 011011 > > * This recommendation just calls out specific values for convenience in > > order to coordinate usage of the Diffserv values from this pool. > >see # 5 > > > 8. Separate ETS traffic treatment, both signaling and data, from other > > traffic treatment by the use of a dedicated MPLS Diff-serv codepoint in > > E-LSPs > > * We understand that MPLS codepoints and E-LSPs are matters of local > > administration. We intend to clarify this recommendation to specify that > > one of the two unused MPLS Diffserv codepoints should be used > (specifically > > 6, since we understand that common practice is to use 7 for network > > management). Based upon the current practice of using 7 for network > > management, we conclude that we are able to recommend the practice of > using > > 6 for ETS within a single administrative domain. > >see #5 > > > 9. Associate the Diffserv PHB with the MPLS Diffserv codepoint as is used > > for Diffserv in general. > > * Again, if we can define the MPLS Diffserv codepoint at a matter of > > practice, it would seem that we can also define its PBH as a matter of > > practice. > >see #5 > > > 10. ETS calls should be specified by use of the SIP Priority header > with a > > designation of "emergency". > > * We are not recommending changing the use of this field for notifying > the > > user. We're just saying, for ETS calls, use it for its intended purpose. > >I do not think there is a "SIP Priority header" yet approved > > > 11. Use SDP attribute parameters to specify ETS sessions as either > National > > Emergency sessions using the attribute parameter value "x-NatETS" > (where the > > leading "x" is understood to be customary to designate non-standard > values) > > or International Emergency sessions using the attribute parameter value > > "x-IntETS". > > * Since we are recommending locally administrable values, we understand > > this to be a matter of practice for a single administrable domain, rather > > than protocol extension. > >see #5 > > > 12. Use the MEGACO ContextRequest parameter for "emergency" (Boolean) to > > indicate "emergency" and the MEGACO ContextRequest parameter for > "priority" > > with priorities 0-4. > > * Our understanding here is that these parameters are already defined and > > their use is a matter of local practice. > >see #5 > > > Note that we do not include the SIP RPH in any of our recommendations. We > > recognize that the SIP section is there for information and that the ETS > > namespace position needs to be officially pursued as a separate effort. > > > > We are at the stage of discussions with vendors and carriers that requires > > real (and preferably official) guidance on how we would like them to > address > > our ETS needs in their new IP deployments. We understand a BCP carries > with > > it the endorsement of the IETF, and although it is not a standard, it > has a > > lot more weight than other non-standard RFCs. We recognize that some > could > > raise the question of whether or not the IETF should advocate a practice > > without a firm experiential base for knowing if it is the best (or even a > > good) practice. Our view, at least at the moment, is that an expert > view of > > what seems to be a "best practice in the absence of experience" is still a > > lot better in meeting our needs than no view at all. > >but that does not qualify a RFC to be designated a BCP - it could >be designated experimental but without any indication that >things would actually do what is needed it clearly can not be a BCP > >and again, I agree with James that the right way forward for these >recommendations is to agree on documents that have the requirements >for the other WGs and send them off to those WGs > >the idea behind the BCP deliverable in the charter came from the >1st BOF where it was pointed out that there were some things >that were actually being done in today's networks and it was >pointed out that it woudl be useful to write them down - Fred Baker >did a pass on this and I've suggested to him that he revive that >ID for further consideration now that the other work is mostly >done > >Scott cheers, James ******************* The answer is "42", what's the question? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 13:36:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27250 for ; Thu, 3 Jul 2003 13:36:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y805-0000r3-Pz for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 13:36:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Ha5PE003279 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 13:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y805-0000qo-ME for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 13:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27219 for ; Thu, 3 Jul 2003 13:36:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y803-0004RW-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 13:36:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y802-0004RT-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 13:36:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y801-0000pP-3X; Thu, 03 Jul 2003 13:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7zq-0000oX-FE for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 13:35:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27183 for ; Thu, 3 Jul 2003 13:35:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7zo-0004Qx-00 for ieprep@ietf.org; Thu, 03 Jul 2003 13:35:48 -0400 Received: from host-133-208.is.dyncorp.com ([131.131.133.208] helo=chntex04.is.dyncorp.com) by ietf-mx with esmtp (Exim 4.12) id 19Y7zn-0004Qs-00 for ieprep@ietf.org; Thu, 03 Jul 2003 13:35:47 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 13:33:43 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AA4C@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'James M. Polk'" , "'Scott Bradner'" , rja@extremenetworks.com, ieprep@ietf.org Cc: "Berg, Dennis" , pat_mcgregor@msn.com, "Kaczmarek, Richard NE" Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Tele p hony Date: Thu, 3 Jul 2003 13:33:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34189.3F4F6A40" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C34189.3F4F6A40 Content-Type: text/plain; charset="iso-8859-1" James, We DO understand that the "SIP Priority Header" simply "flags" the call as "emergency" to the end user. Quite independent of anything else that happens with SIP or DIffServe or MPLS or SDC, it seems sensible to use the existing "notify the user that this is an emergency related call" feature. The paragraph that talks about the SIP Priority Header references RFC 3261. A next paragraph talks about the (not yet formally adopted) Resource Priority Header, and the associated syntax. Maybe we need to insert some text in between to make it clearer that we are talking about two different things. I agree we are missing the reference to "Communications Resource Priority Header for the Session Initiation Protocol" (formerly draft-polk-sip-resource-02.txt and now draft-ietf-sip-resource-priority-00.txt). At one round of editing, I did insert it, but somehow it didn't make it into the final version, and I didn't proof well enough. Apologies. Janet -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Thursday, July 03, 2003 12:53 PM Now to a point of correction, there is indeed a SIP Priority Header, but it is not used in a fashion you appear to think it does. The SIP Priority Header does NOT cause anything to be processed any differently, it is merely an indication to the receiving user (and not the user agent) of the importance of the session. This was why Henning and I needed to propose an extension to the SIP protocol for resource priority of SIP entities between the requesting and responding UAs. This effort had to be in a separate ID, after a requirements ID was agreed upon (RFC 3487). Once a Resource Priority header is created via a Standards Track RFC, vendors should interpret any priority in that header to also mean a priority indication to the called user (via the UI). In your ID's reference to the SIP Priority header, it gives the syntax of the Resource Priority Header (without referencing that ID, BTW). This, too, is incorrect. ------_=_NextPart_001_01C34189.3F4F6A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP = Telep hony

James,

We DO understand that the "SIP Priority = Header" simply "flags" the call as "emergency" = to the end user.  Quite independent of anything else that happens = with SIP or DIffServe or MPLS or SDC, it seems sensible to use the = existing "notify the user that this is an emergency related = call" feature.

The  paragraph that talks about the SIP Priority = Header references  RFC 3261.

A next paragraph talks about the (not yet formally = adopted) Resource Priority Header, and the associated syntax. Maybe we = need to insert some text in between to make it clearer that we are = talking about two different things.

I agree we are missing the reference to  = "Communications Resource Priority Header for the Session = Initiation Protocol" (formerly draft-polk-sip-resource-02.txt and = now draft-ietf-sip-resource-priority-00.txt).  At one round of = editing, I did insert it, but somehow it didn't make it into the final = version, and I didn't proof well enough.   Apologies.  =

Janet         &nbs= p;   

-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Thursday, July 03, 2003 12:53 PM



Now to a point of correction, there is indeed a SIP = Priority Header, but it
is not used in a fashion you appear to think it = does. The SIP Priority
Header does NOT cause anything to be processed any = differently, it is
merely an indication to the receiving user (and not = the user agent) of the
importance of the session. This was why Henning and = I needed to propose an
extension to the SIP protocol for resource priority = of SIP entities between
the requesting and responding UAs. This effort had = to be in a separate ID,
after a requirements ID was agreed upon (RFC 3487). = Once a Resource
Priority header is created via a Standards Track = RFC, vendors should
interpret any priority in that header to also mean a = priority indication to
the called user (via the UI).

In your ID's reference to the SIP Priority header, it = gives the syntax of
the Resource Priority Header (without referencing = that ID, BTW). This, too,
is incorrect.

------_=_NextPart_001_01C34189.3F4F6A40-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 14:14:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29512 for ; Thu, 3 Jul 2003 14:14:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8au-0002qp-If for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 14:14:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63IE8IY010953 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 14:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8au-0002qZ-By for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 14:14:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29378 for ; Thu, 3 Jul 2003 14:14:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y8ap-0005qx-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 14:14:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y8ao-0005qu-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 14:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8an-0002p2-92; Thu, 03 Jul 2003 14:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8am-0002oi-HH for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 14:14:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29292 for ; Thu, 3 Jul 2003 14:13:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y8TQ-0005Y9-00 for ieprep@ietf.org; Thu, 03 Jul 2003 14:06:24 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx with esmtp (Exim 4.12) id 19Y8TP-0005Y5-00 for ieprep@ietf.org; Thu, 03 Jul 2003 14:06:23 -0400 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Thu, 3 Jul 2003 14:05:56 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.21) with SMTP id M2003070314055606471 for ; Thu, 03 Jul 2003 14:05:56 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <3C1H3ZXM>; Thu, 3 Jul 2003 14:08:41 -0400 Message-Id: From: "King, Kimberly S." To: "Ieprep (E-mail)" Date: Thu, 3 Jul 2003 14:05:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] IEPREP agenda Vienna meeting Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , The ieprep WG is scheduled to meet Wednesday, July 17, 2003 from 1300-1500. Proposed ieprep Agenda agenda bashing 5 minutes Chairs Clarification on any outstanding issues 20 minutes draft-ietf-ieprep-framework-05.txt draft-ietf-ieprep-ets-general-03.txt draft-ietf-ieprep-ets-telephony-05.txt Ken Carlberg Changes for the next versions 30 minutes draft-carlberg-ets-stub-frame-00.txt draft-carlberg-ets-req-stub-00.txt Ken Carlberg Changes for the next version 10 minutes draft-mcgregor-ieprep-bridging-bcp-00.txt Janet Gunn/Dennis Berg High Availability Networks 15 minutes Discussion on high availability networks followed by question/answer period. Total 80 minutes It is assumed that the WG has read the documents in preparation for the meeting. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 14:24:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29818 for ; Thu, 3 Jul 2003 14:24:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8kU-0003AI-Tt for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 14:24:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63IO2iL012160 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 14:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8kU-0003A3-O2 for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 14:24:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29803 for ; Thu, 3 Jul 2003 14:24:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y8kS-00068j-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 14:24:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y8kR-00068g-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 14:23:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8kS-00038U-Hx; Thu, 03 Jul 2003 14:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8kK-000388-2J for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 14:23:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29777 for ; Thu, 3 Jul 2003 14:23:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y8kH-00068O-00 for ieprep@ietf.org; Thu, 03 Jul 2003 14:23:49 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19Y8kG-00060N-00 for ieprep@ietf.org; Thu, 03 Jul 2003 14:23:48 -0400 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h63INHQr028579; Thu, 3 Jul 2003 11:23:17 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA06597; Thu, 3 Jul 2003 11:23:16 -0700 (PDT) Message-Id: <4.3.2.7.2.20030703132156.02262528@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Jul 2003 13:23:18 -0500 To: "Gunn, Janet" , "'Scott Bradner'" , rja@extremenetworks.com, ieprep@ietf.org From: "James M. Polk" Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Tele p hony Cc: "Berg, Dennis" , pat_mcgregor@msn.com, "Kaczmarek, Richard NE" In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE8915AA4C@chntex04.is.dyncorp .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , At 01:33 PM 7/3/2003 -0400, Gunn, Janet wrote: >James, >At one round of editing, I did insert it, but somehow it didn't make it >into the final version, and I didn't proof well enough. Apologies. no problem - additional text isn't a bad thing in this case. A lot of topics are covered in a short amount of space >Janet cheers, James ******************* The answer is "42", what's the question? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 19:45:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26705 for ; Thu, 3 Jul 2003 19:45:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDki-0002Jl-KC for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 19:44:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Nia2w008905 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 19:44:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDki-0002JT-Dh for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 19:44:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26645 for ; Thu, 3 Jul 2003 19:44:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YDVh-0004ju-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 19:29:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YDVg-0004jr-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 19:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDVd-0000e9-0n; Thu, 03 Jul 2003 19:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDV4-0000bY-4B for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 19:28:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25761 for ; Thu, 3 Jul 2003 19:28:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YCxo-0007kh-00 for ieprep@ietf.org; Thu, 03 Jul 2003 18:54:04 -0400 Received: from kc-msxproto2.kc.umkc.edu ([134.193.143.159]) by ietf-mx with esmtp (Exim 4.12) id 19YCxo-0007kc-00 for ieprep@ietf.org; Thu, 03 Jul 2003 18:54:04 -0400 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Jul 2003 17:54:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ieprep] IEPREP agenda Vienna meeting Date: Thu, 3 Jul 2003 17:54:03 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108021@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] IEPREP agenda Vienna meeting Thread-Index: AcNBjuFpboa0QwJZSVy51a67scgLGQAJpBpw From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "King, Kimberly S." , "Ieprep (E-mail)" X-OriginalArrivalTime: 03 Jul 2003 22:54:03.0804 (UTC) FILETIME=[0019A5C0:01C341B6] Content-Transfer-Encoding: quoted-printable Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >High Availability Networks 15 minutes >Discussion on high availability networks=20 You mean high speed networks like Internet2 where BW*delay product=20 is high? or a backbone network? If we have high availability, why=20 should we worry about giving special priority to ieprep traffic? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 19:46:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26961 for ; Thu, 3 Jul 2003 19:46:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDmT-0002c0-0C for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 19:46:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63NkOCn010029 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 19:46:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDkM-0002Bz-HS for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 19:44:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24276 for ; Thu, 3 Jul 2003 19:26:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YDSk-0004Gq-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 19:26:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YDSj-0004Gn-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 19:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDSi-0000Kn-Qq; Thu, 03 Jul 2003 19:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDSS-0000KP-Vk for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 19:25:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23952 for ; Thu, 3 Jul 2003 19:25:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YDE8-0002Qm-00 for ieprep@ietf.org; Thu, 03 Jul 2003 19:10:56 -0400 Received: from kc-msxproto2.kc.umkc.edu ([134.193.143.159]) by ietf-mx with esmtp (Exim 4.12) id 19YDE7-0002Qb-00 for ieprep@ietf.org; Thu, 03 Jul 2003 19:10:55 -0400 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Jul 2003 18:10:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Date: Thu, 3 Jul 2003 18:10:55 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108022@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Thread-Index: AcNBbcYD6hReExNQRNKThXB7sCUWKwASb4Tw From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: Cc: X-OriginalArrivalTime: 03 Jul 2003 23:10:55.0877 (UTC) FILETIME=[5B57BB50:01C341B8] Content-Transfer-Encoding: quoted-printable Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >> We do not remember any document as you describe from Fred=20 >> and if you could give us a pointer to it, that would be=20 >> much appreciated.=20 > >draft-ietf-ieprep-packet-marking-policy-01.txt > >but the ID has expired=20 http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-00= .txt=20 This does have more technical content (particularly, traffic categories) = than expired ieprep-packet-marking-policy. I don't know whether it updates = the marking policy draft or it is something all together different.=20 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 20:31:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28381 for ; Thu, 3 Jul 2003 20:31:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YETi-0005ob-FK for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 20:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h640V61i022352 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 20:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YETi-0005oR-CY for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 20:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28356 for ; Thu, 3 Jul 2003 20:31:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YETg-0006Du-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 20:31:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YETf-0006Dr-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 20:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YETd-0005n2-Dr; Thu, 03 Jul 2003 20:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YETK-0005mO-51 for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 20:30:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28344 for ; Thu, 3 Jul 2003 20:30:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YETH-0006DN-00 for ieprep@ietf.org; Thu, 03 Jul 2003 20:30:39 -0400 Received: from hammerhead.shentel.net ([204.111.11.43]) by ietf-mx with esmtp (Exim 4.12) id 19YETH-0006Ck-00 for ieprep@ietf.org; Thu, 03 Jul 2003 20:30:39 -0400 Received: from Steve (ha30s493.d.shentel.net [204.111.30.237]) by hammerhead.shentel.net (8.12.9/8.12.9) with SMTP id h640U7Tv009400; Thu, 3 Jul 2003 20:30:08 -0400 From: "Steve Silverman" To: "Ayyasamy, Senthilkumar \(UMKC-Student\)" , "King, Kimberly S." , "Ieprep \(E-mail\)" Subject: RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting Date: Thu, 3 Jul 2003 20:31:02 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B01108021@KC-MAIL4.kc.umkc.edu> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As has been said many times before, not all networks have the advantage of optical bandwidth. Some ships must make do with limited radio links. There are places in the world without fiber. Some users require high probability of connection even when the emergency happens in a place with limited bandwidth. Steve Silverman > -----Original Message----- > From: > [mailto:ieprep-admin@ietf.org]On Behalf Of > Ayyasamy, Senthilkumar (UMKC-Student) > Sent: Thursday, July 03, 2003 6:54 PM > To: King, Kimberly S.; Ieprep (E-mail) > Subject: RE: [Ieprep] IEPREP agenda Vienna meeting > > > > >High Availability Networks 15 minutes > >Discussion on high availability networks > > You mean high speed networks like Internet2 where BW*delay product > is high? or a backbone network? If we have high availability, why > should we worry about giving special priority to ieprep traffic? > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 3 20:52:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28766 for ; Thu, 3 Jul 2003 20:52:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YEo1-0007dI-4X for ieprep-archive@odin.ietf.org; Thu, 03 Jul 2003 20:52:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h640q5xZ029334 for ieprep-archive@odin.ietf.org; Thu, 3 Jul 2003 20:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YEo1-0007d3-1a for ieprep-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 20:52:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28758 for ; Thu, 3 Jul 2003 20:52:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YEny-0006fd-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 20:52:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YEny-0006fa-00 for ieprep-web-archive@ietf.org; Thu, 03 Jul 2003 20:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YEnw-0007be-Kc; Thu, 03 Jul 2003 20:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YEnT-0007XM-Rz for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 20:51:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28747 for ; Thu, 3 Jul 2003 20:51:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YEnR-0006ek-00 for ieprep@ietf.org; Thu, 03 Jul 2003 20:51:29 -0400 Received: from kc-msxproto2.kc.umkc.edu ([134.193.143.159]) by ietf-mx with esmtp (Exim 4.12) id 19YEnQ-0006eg-00 for ieprep@ietf.org; Thu, 03 Jul 2003 20:51:28 -0400 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Jul 2003 19:51:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting Date: Thu, 3 Jul 2003 19:51:25 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390BAA7753@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting Thread-Index: AcNBw4BlDC3P52fqRzmnrhjRuHTMvgAAr3og From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Steve Silverman" , "King, Kimberly S." , "Ieprep (E-mail)" X-OriginalArrivalTime: 04 Jul 2003 00:51:25.0852 (UTC) FILETIME=[657CE5C0:01C341C6] Content-Transfer-Encoding: quoted-printable Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >As has been said many times before, not all networks have the >advantage of optical bandwidth. Some ships must make do with=20 >limited radio links. There are places in the world without=20 >fiber. Some users require high probability of connection even=20 >when the emergency happens in a place with limited bandwidth. I understand your point. This is not just common to limited cases you depict. There are many places around deep space where you have=20 constrained bandwidth and so, capacity management is a major issue.=20 For example, a military sensor deployment or an ad-hoc network=20 formation in a emergency spot depends on constrained BW in a=20 multi-hop network. I don't think ieprep WG can help you with this issue. I possibly consider tranport level solutions in such scenarios as a non-starter. Probably, a lot can be done at MAC layer for efficient capacity management in such a power/BW-constrained environment. But, there=20 are situations in which an intermediate wireless node may need to=20 communicate with the source about its limited bandwidth. So, it can=20 sent some kind of triggered notifications to the source. Their are=20 other issues like corruption Vs loss in such environments. some of these issues are addressed by Trigtran and many research groups. On a parallel side, a whole research group by name "delay tolerant=20 networks" is suggesting architecture for such environments. what do you expect from ieprep for such deep space networks?=20 >Steve Silverman > >> -----Original Message----- >> From: >> [mailto:ieprep-admin@ietf.org]On Behalf Of >> Ayyasamy, Senthilkumar (UMKC-Student) >> Sent: Thursday, July 03, 2003 6:54 PM >> To: King, Kimberly S.; Ieprep (E-mail) >> Subject: RE: [Ieprep] IEPREP agenda Vienna meeting >> >> >> >> >High Availability Networks 15 minutes >> >Discussion on high availability networks >> >> You mean high speed networks like Internet2 where BW*delay product >> is high? or a backbone network? If we have high availability, why >> should we worry about giving special priority to ieprep traffic? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Fri Jul 4 10:21:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27803 for ; Fri, 4 Jul 2003 10:21:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRR4-000792-Vz for ieprep-archive@odin.ietf.org; Fri, 04 Jul 2003 10:21:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64ELEkX027462 for ieprep-archive@odin.ietf.org; Fri, 4 Jul 2003 10:21:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRR4-00078r-RQ for ieprep-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 10:21:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27799 for ; Fri, 4 Jul 2003 10:21:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YRR2-00061H-00 for ieprep-web-archive@ietf.org; Fri, 04 Jul 2003 10:21:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YRR2-00061D-00 for ieprep-web-archive@ietf.org; Fri, 04 Jul 2003 10:21:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRQs-00078C-0e; Fri, 04 Jul 2003 10:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRQe-00077V-SH for ieprep@optimus.ietf.org; Fri, 04 Jul 2003 10:20:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27793 for ; Fri, 4 Jul 2003 10:20:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YRQc-000612-00 for ieprep@ietf.org; Fri, 04 Jul 2003 10:20:46 -0400 Received: from hammerhead.shentel.net ([204.111.11.43]) by ietf-mx with esmtp (Exim 4.12) id 19YRQb-00060k-00 for ieprep@ietf.org; Fri, 04 Jul 2003 10:20:46 -0400 Received: from Steve (ha30s462.d.shentel.net [204.111.30.206]) by hammerhead.shentel.net (8.12.9/8.12.9) with SMTP id h64EKCTv028984; Fri, 4 Jul 2003 10:20:14 -0400 From: "Steve Silverman" To: "Ayyasamy, Senthilkumar \(UMKC-Student\)" , "Ieprep \(E-mail\)" Subject: RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting Date: Fri, 4 Jul 2003 10:21:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390BAA7753@KC-MAIL4.kc.umkc.edu> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ayyasamy, Senthilkumar (UMKC-Student) [mailto:saq66@umkc.edu] > Sent: Thursday, July 03, 2003 8:51 PM > To: Steve Silverman; King, Kimberly S.; Ieprep (E-mail) > Subject: RE: [Ieprep] IEPREP agenda High Availability > Networks Vienna > meeting > > > >As has been said many times before, not all networks have the > >advantage of optical bandwidth. Some ships must make do with > >limited radio links. There are places in the world without > >fiber. Some users require high probability of connection even > >when the emergency happens in a place with limited bandwidth. > > > I understand your point. This is not just common to limited cases > you depict. There are many places around deep space where you have > constrained bandwidth and so, capacity management is a major issue. Deep space has not been a case I have considered. My primary focus has been voice which stops being very useful as the delay gets too great (I would guess a 15 second delay would make voice sufficiently annoying that people would turn to email. But I don't know of any experimental research on what this limit is. ) > For example, a military sensor deployment or an ad-hoc network > formation in a emergency spot depends on constrained BW in a > multi-hop network. > > I don't think ieprep WG can help you with this issue. I possibly > consider tranport level solutions in such scenarios as a > non-starter. I didn't think IEPREP was constrained to Transport level solutions. While the WG is in the Transport Area, it is chartered to investigate the requirements in emergency comm. As I understand it, the WG specifies requirements that are to be passed to other WGs to actually write protocols. But these WGs don't have to be in the Transport area. If anyone disagrees with this (especially an AD) please correct me. The solution I have been proposing for congested voice in a limited bandwidth environment is described in < draft-silverman-diffserv-mlefphb-01.txt >. (-02 will be submitted after the blackout.) Unfortunately, the diffserv WG was closed just before -00 was submitted so it is hard to know where this should be worked. Note, the draft is a proposed experimental RFC not a standards track. This requirement is for ceertain networks with special requirements and probably for only some of the routers within that network ( routers on the bottlenecks). Steve Silverman _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Fri Jul 4 11:00:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28756 for ; Fri, 4 Jul 2003 11:00:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YS2d-0001jg-6i for ieprep-archive@odin.ietf.org; Fri, 04 Jul 2003 11:00:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64F03vC006671 for ieprep-archive@odin.ietf.org; Fri, 4 Jul 2003 11:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YS2d-0001jW-3X for ieprep-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 11:00:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28737 for ; Fri, 4 Jul 2003 10:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YS2a-0006Sy-00 for ieprep-web-archive@ietf.org; Fri, 04 Jul 2003 11:00:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YS2Z-0006Sv-00 for ieprep-web-archive@ietf.org; Fri, 04 Jul 2003 10:59:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YS2a-0001iP-UE; Fri, 04 Jul 2003 11:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YS1p-0001gW-Js for ieprep@optimus.ietf.org; Fri, 04 Jul 2003 10:59:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28725 for ; Fri, 4 Jul 2003 10:59:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YS1n-0006SJ-00 for ieprep@ietf.org; Fri, 04 Jul 2003 10:59:11 -0400 Received: from kc-msxproto2.kc.umkc.edu ([134.193.143.159]) by ietf-mx with esmtp (Exim 4.12) id 19YS1m-0006SF-00 for ieprep@ietf.org; Fri, 04 Jul 2003 10:59:10 -0400 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Fri, 4 Jul 2003 09:59:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting Date: Fri, 4 Jul 2003 09:59:09 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B0110802C@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting Thread-Index: AcNCN3ZlpnpX/I7yRQ+oewej+CXZsgAAfL8Q From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Steve Silverman" , "Ieprep (E-mail)" X-OriginalArrivalTime: 04 Jul 2003 14:59:09.0990 (UTC) FILETIME=[D2E06C60:01C3423C] Content-Transfer-Encoding: quoted-printable Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >My primary focus has been voice which stops being very useful as=20 >the delay gets too great (I would guess a 15 second delay would=20 >make voice sufficiently annoying that people would turn to email. >But I don't know of any experimental research on what this limit >is. ) I think, we have to think reverse...i.e.VoIP traffic blocking the=20 transfer of legitimate TCP based traffic;the related fairness=20 issue and tcp-friendliness. Please read the recent IAB draft, which=20 clearly illustrates with back of the envelope calculations based on=20 a VoIP transfer between Atlanta and Nairobi demoed at a previous=20 ieprep session.=20 >> For example, a military sensor deployment or an ad-hoc network >> formation in a emergency spot depends on constrained BW in a >> multi-hop network. >> >> I don't think ieprep WG can help you with this issue. I possibly >> consider transport level solutions in such scenarios as a >> non-starter. > >I didn't think IEPREP was constrained to Transport level solutions. that was not my point. >The solution I have been proposing for congested voice in a limited >bandwidth environment is described in < draft-silverman-diffserv- >mlefphb-01.txt >.=20 new PHB? If you actually propose a new PHB for a limited local=20 setting (like MLPP exercised in a private domain which has no=20 connection with Internet), i don't think it requires IETF=20 ratification.=20 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Fri Jul 4 14:25:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03922 for ; Fri, 4 Jul 2003 14:25:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVF2-00046D-G3 for ieprep-archive@odin.ietf.org; Fri, 04 Jul 2003 14:25:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64IP4Uj015751 for ieprep-archive@odin.ietf.org; Fri, 4 Jul 2003 14:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVF2-00045y-C9 for ieprep-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 14:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03919 for ; Fri, 4 Jul 2003 14:25:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YVEz-0000no-00 for ieprep-web-archive@ietf.org; Fri, 04 Jul 2003 14:25:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YVEz-0000nl-00 for ieprep-web-archive@ietf.org; Fri, 04 Jul 2003 14:25:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVEz-00045A-55; Fri, 04 Jul 2003 14:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVEw-00044t-B6 for ieprep@optimus.ietf.org; Fri, 04 Jul 2003 14:24:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03916 for ; Fri, 4 Jul 2003 14:24:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YVEt-0000nh-00 for ieprep@ietf.org; Fri, 04 Jul 2003 14:24:55 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19YVEt-0000nO-00 for ieprep@ietf.org; Fri, 04 Jul 2003 14:24:55 -0400 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h64ION7F002763; Fri, 4 Jul 2003 11:24:23 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA29321; Fri, 4 Jul 2003 11:24:22 -0700 (PDT) Message-Id: <4.3.2.7.2.20030704132043.02276e20@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Jul 2003 13:24:24 -0500 To: "Steve Silverman" , "Ieprep \(E-mail\)" From: "James M. Polk" Subject: RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting In-Reply-To: References: <5EF7D95E17BDAD4A968C812E5ABC390B01108021@KC-MAIL4.kc.umkc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , At 08:31 PM 7/3/2003 -0400, Steve Silverman wrote: > Some users require "high probability of connection" Steve - can you define this phrase (above) to me/us as it relates to an IP network? >even when the emergency happens in a place with limited bandwidth. > >Steve Silverman cheers, James ******************* The answer is "42", what's the question? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Fri Jul 4 14:51:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04487 for ; Fri, 4 Jul 2003 14:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVeD-00067r-CX for ieprep-archive@odin.ietf.org; Fri, 04 Jul 2003 14:51:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64Ip5qD023541 for ieprep-archive@odin.ietf.org; Fri, 4 Jul 2003 14:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVeD-00067c-8b for ieprep-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 14:51:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04479 for ; Fri, 4 Jul 2003 14:51:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YVeA-00019n-00 for ieprep-web-archive@ietf.org; Fri, 04 Jul 2003 14:51:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YVe9-00019k-00 for ieprep-web-archive@ietf.org; Fri, 04 Jul 2003 14:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVe9-00066D-Cm; Fri, 04 Jul 2003 14:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVe0-00065O-P2 for ieprep@optimus.ietf.org; Fri, 04 Jul 2003 14:50:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04475 for ; Fri, 4 Jul 2003 14:50:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YVdx-00019W-00 for ieprep@ietf.org; Fri, 04 Jul 2003 14:50:50 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19YVdx-00018m-00 for ieprep@ietf.org; Fri, 04 Jul 2003 14:50:49 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Jul 2003 11:52:02 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h64IoGrm013494; Fri, 4 Jul 2003 11:50:17 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA12876; Fri, 4 Jul 2003 11:50:15 -0700 (PDT) Message-Id: <4.3.2.7.2.20030704132729.055b5790@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Jul 2003 13:50:17 -0500 To: "Steve Silverman" , "Ieprep \(E-mail\)" From: "James M. Polk" Subject: RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting In-Reply-To: References: <5EF7D95E17BDAD4A968C812E5ABC390BAA7753@KC-MAIL4.kc.umkc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , At 10:21 AM 7/4/2003 -0400, Steve Silverman wrote: >I didn't think IEPREP was constrained to Transport level solutions. While >the WG is in the Transport Area, it is chartered to investigate the >requirements in emergency comm. As I understand it, the WG specifies >requirements that are to be passed to other WGs to actually write >protocols. But these WGs don't have to be in the Transport area. If >anyone disagrees with this (especially an AD) please correct me. OK, I do not agree, but that might only be in the way I read the above. You might have meant the clarification I have below that includes an important piece that was omitted from the above: IEPREP is the type of WG that writes requirements for other WGs to *consider* doing protocol/mechanism work on. IEPREP cannot demand, nor does it direct WGs like SIP or MPLS to *do* work. It merely presents requirements that are not currently met by existing protocols "as is" and provides the justification (and not the solution) for how one or more protocols/mechanisms should be extended to satisfy those requirements. Case in point is RFC 3487, which was produced by IEPREP for SIP(PING). That WG produced an ID very quickly (from our AD himself in fact) questioning some of the requirements the IEPREP WG reached consensus on. This action was following proper procedure within the IETF. >The solution I have been proposing for congested voice in a limited >bandwidth environment is described in < >draft-silverman-diffserv-mlefphb-01.txt >. (-02 will be submitted after >the blackout.) Unfortunately, the diffserv WG was closed just before -00 >was submitted so it is hard to know where this should be worked. Note, >the draft is a proposed experimental RFC not a standards track. This >requirement is for ceertain networks with special requirements and >probably for only some of the routers within that network (routers on the >bottlenecks). In times of great disaster, whether natural or man-made, I find it somewhat curious that anyone can predict with certainty which routers will experience bottlenecks and which will not.... If there is any doubt in that prediction, any proactive mechanism proposal (such as this Diffserv ID) would need to be configured on all routers in a network, wouldn't it? I think the answer is yes. >Steve Silverman cheers, James ******************* The answer is "42", what's the question? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Sat Jul 5 07:45:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05829 for ; Sat, 5 Jul 2003 07:45:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YlTX-0003dU-Nc for ieprep-archive@odin.ietf.org; Sat, 05 Jul 2003 07:45:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h65Bj7Ta013961 for ieprep-archive@odin.ietf.org; Sat, 5 Jul 2003 07:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YlTX-0003cv-KM for ieprep-web-archive@optimus.ietf.org; Sat, 05 Jul 2003 07:45:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05818 for ; Sat, 5 Jul 2003 07:45:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YlTW-0000bQ-00 for ieprep-web-archive@ietf.org; Sat, 05 Jul 2003 07:45:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YlTV-0000bN-00 for ieprep-web-archive@ietf.org; Sat, 05 Jul 2003 07:45:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YlTR-0003al-In; Sat, 05 Jul 2003 07:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDpR-0002jl-3V for ieprep@optimus.ietf.org; Thu, 03 Jul 2003 19:49:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27087 for ; Thu, 3 Jul 2003 19:49:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YDpP-0005Gi-00 for ieprep@ietf.org; Thu, 03 Jul 2003 19:49:27 -0400 Received: from kc-msxproto2.kc.umkc.edu ([134.193.143.159]) by ietf-mx with esmtp (Exim 4.12) id 19YDpO-0005Gf-00 for ieprep@ietf.org; Thu, 03 Jul 2003 19:49:26 -0400 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Jul 2003 18:49:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Date: Thu, 3 Jul 2003 18:49:26 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108023@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony Thread-Index: AcNBg9j1BCET16j1SsuDiZSqnTfOIwANoMgg From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "James M. Polk" , "Gunn, Janet" , "Scott Bradner" , , Cc: "Berg, Dennis" , , "Kaczmarek, Richard NE" X-OriginalArrivalTime: 03 Jul 2003 23:49:26.0514 (UTC) FILETIME=[BC96F520:01C341BD] Content-Transfer-Encoding: quoted-printable Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable At 10:09 AM 7/3/2003 -0400, Gunn, Janet wrote: >> It would be better to develop the guidance as an informational = RFC=20 >> versus an official BCP, and then maybe later, if its = application and=20 >> experience warrants, advance it as a BCP. Probably, you should read RFC 2026 (particularly Section 4.2 ) also, quoting scott(?), //How can we get BCP without current practices? BCP is best way we know how to do something rather than the best way we ARE doing something. = // so, clearly your work can be considered as BCP, if you have _not_ = proposed changes to existing protocols; also, accepted by this WG (operators = support will be a huge plus) as a best way of *how to do something*. I don't = think,=20 there is a clear current operational practice for giving priority to = ieprep traffic in Internet;except ensuring high availability. Hence, experience = based drafts like ieprep packet marking policy can be classified as = BCP.=20 another way to do is, to put your proposal in practice with the help of=20 some ISPs and then, standardise(as ran suggests at many places.) It has=20 been followed for some transport area standardizations. But, sometimes, it will also lead to vendor inter-operability problems.=20 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Sun Jul 6 17:47:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23134 for ; Sun, 6 Jul 2003 17:47:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHLh-0003Y5-La for ieprep-archive@odin.ietf.org; Sun, 06 Jul 2003 17:47:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66Ll9e9013640 for ieprep-archive@odin.ietf.org; Sun, 6 Jul 2003 17:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHLh-0003Xv-HZ for ieprep-web-archive@optimus.ietf.org; Sun, 06 Jul 2003 17:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23123 for ; Sun, 6 Jul 2003 17:47:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZHLf-0004tL-00 for ieprep-web-archive@ietf.org; Sun, 06 Jul 2003 17:47:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZHLe-0004tH-00 for ieprep-web-archive@ietf.org; Sun, 06 Jul 2003 17:47:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHLY-0003X8-RO; Sun, 06 Jul 2003 17:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHKd-0003Wr-Em for ieprep@optimus.ietf.org; Sun, 06 Jul 2003 17:46:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23110 for ; Sun, 6 Jul 2003 17:45:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZHKa-0004t4-00 for ieprep@ietf.org; Sun, 06 Jul 2003 17:46:00 -0400 Received: from seahorse.shentel.net ([204.111.11.44]) by ietf-mx with esmtp (Exim 4.12) id 19ZHKZ-0004sb-00 for ieprep@ietf.org; Sun, 06 Jul 2003 17:45:59 -0400 Received: from Steve (ha24s027.d.shentel.net [204.111.24.27]) by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id h66LjE412151; Sun, 6 Jul 2003 17:45:14 -0400 From: "Steve Silverman" To: "James M. Polk" , "Ieprep \(E-mail\)" Subject: RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting Date: Sun, 6 Jul 2003 17:46:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20030704132043.02276e20@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Obviously at the IP level, only packets are flowing and intermediate nodes (routers) don't know about the connection. But, "the President doesn't get a busy signal (or "No resources available") " When he makes a VoIP call, his (or her) packets get thru and the called and calling parties can understand each other (enough packets get thru for usable voice). Even if there are many people making voice calls or attempting voice calls and the existing bandwidth is insufficient, certain previously marked users get some sort of priority so that they can have useful voice calls. This means that those marked users and their called party's packets don't get dropped or delayed enough that those packets are unusable. Note that this is a functional description as perceived by the end users. While I have certain ideas about how this might be accomplished, I am only proposing a functional requirement here since that is all IEPREP is allowed to do. It should also be noted that this function has been available for 40 years and is a prerequisite for the DOD to convert to VoIP. They simply CAN'T migrate without it. Some people may disagree as to the "true" requirements but certain major decision makers (JCS - Joint Chiefs of Staff) are quite convinced about the need for this function. I don't this level or management tends to spend much time on this list. Since I have no problem envisioning scenarios in which this functionality is truly required, I have no problem attempting to accomplish it. (e.g., Dec. 7, 1941: Pearl Harbor - "The Japanese have declared war".... ) I think everything above is old info on this list but I thought I should respond to a direct question. Steve Silverman > > > Some users require "high probability of connection" > > Steve - can you define this phrase (above) to me/us as it > relates to an IP > network? > > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Jul 7 08:18:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22555 for ; Mon, 7 Jul 2003 08:18:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUwW-0006M5-Me for ieprep-archive@odin.ietf.org; Mon, 07 Jul 2003 08:18:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67CI4e6024428 for ieprep-archive@odin.ietf.org; Mon, 7 Jul 2003 08:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUwW-0006Lv-Ee for ieprep-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 08:18:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22521 for ; Mon, 7 Jul 2003 08:18:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZUwV-0003h2-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 08:18:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZUwU-0003gz-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 08:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUwT-0006LD-PX; Mon, 07 Jul 2003 08:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZUwN-0006KY-5I for ieprep@optimus.ietf.org; Mon, 07 Jul 2003 08:17:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22510 for ; Mon, 7 Jul 2003 08:17:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZUwM-0003gk-00 for ieprep@ietf.org; Mon, 07 Jul 2003 08:17:54 -0400 Received: from portal.east.saic.com ([198.151.13.15]) by ietf-mx with smtp (Exim 4.12) id 19ZUwL-0003gf-00 for ieprep@ietf.org; Mon, 07 Jul 2003 08:17:53 -0400 Received: from mcl-its-dq.saic.com by portal.east.saic.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 7 Jul 2003 08:17:53 -0400 Received: from mcl-its-ieg01.mail.saic.com by mcl-its-dq.saic.com for ieprep@ietf.org; Mon, 7 Jul 2003 08:17:52 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.21) with SMTP id M2003070708175030191 ; Mon, 07 Jul 2003 08:17:50 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <3C1HPM3N>; Mon, 7 Jul 2003 08:20:36 -0400 Message-Id: From: "King, Kimberly S." To: "'Steve Silverman'" , "Ayyasamy, Senthilkumar (UMKC-Student)" , "King, Kimberly S." , "Ieprep (E-mail)" Subject: RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meet ing Date: Mon, 7 Jul 2003 08:17:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , All, It is completely unproductive to cycle through the same arguments based upon vague unstated assumptions. Defining the context is key. For example, consider the statement "ships need to communicate over radio links". I surmise these radio links connect to an enterprise network. Yes, preferential treatment to some users is possible. There are drafts on this. Do they meet the needs? In another context, suppose we would like a high availability network. Maybe we are an emergency relief organization and want to know what to look for in a service provider's network that would ensure quality service. Maybe we are an enterprise designing a network to support emergency services. What is the hallmark of a high availability network? Perhaps this merits a discussion at the meeting. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Jul 7 09:58:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25098 for ; Mon, 7 Jul 2003 09:58:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWUm-0001ll-QW for ieprep-archive@odin.ietf.org; Mon, 07 Jul 2003 09:57:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67DvWc0006800 for ieprep-archive@odin.ietf.org; Mon, 7 Jul 2003 09:57:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWUm-0001lb-NA for ieprep-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 09:57:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25068 for ; Mon, 7 Jul 2003 09:57:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWUk-0004Qm-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 09:57:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZWUj-0004Qj-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 09:57:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWUH-0001kQ-O1; Mon, 07 Jul 2003 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWU9-0001jz-65 for ieprep@optimus.ietf.org; Mon, 07 Jul 2003 09:56:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25049 for ; Mon, 7 Jul 2003 09:56:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWU7-0004QK-00 for ieprep@ietf.org; Mon, 07 Jul 2003 09:56:51 -0400 Received: from chntex04.is.dyncorp.com ([131.131.133.208]) by ietf-mx with esmtp (Exim 4.12) id 19ZWU6-0004QG-00 for ieprep@ietf.org; Mon, 07 Jul 2003 09:56:50 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jul 2003 09:54:32 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE899E0F8A@chntex04.is.dyncorp.com> From: "Berg, Dennis" To: "'Ayyasamy, Senthilkumar (UMKC-Student)'" , "'Steve Silverman'" , "'Ieprep (E-mail)'" Subject: RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meet ing Date: Mon, 7 Jul 2003 09:54:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3448F.4A838050" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3448F.4A838050 Content-Type: text/plain I think, we have to think reverse...i.e.VoIP traffic blocking the transfer of legitimate TCP based traffic;the related fairness issue and tcp-friendliness. Please read the recent IAB draft, which clearly illustrates with back of the envelope calculations based on a VoIP transfer between Atlanta and Nairobi demoed at a previous ieprep session. COULD YOU IDENTIFY THE IAB DRAFT THAT YOU ARE REFERRING TO? DENNIS ------_=_NextPart_001_01C3448F.4A838050 Content-Type: text/html RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting

I think, we have to think reverse...i.e.VoIP traffic blocking the
transfer of legitimate TCP based traffic;the related fairness
issue and tcp-friendliness. Please read the recent IAB draft, which
clearly illustrates with back of the envelope calculations based on
a VoIP transfer between Atlanta and Nairobi demoed at a previous
ieprep session.

COULD YOU IDENTIFY THE IAB DRAFT THAT YOU ARE REFERRING TO?
DENNIS

------_=_NextPart_001_01C3448F.4A838050-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Jul 7 16:29:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13656 for ; Mon, 7 Jul 2003 16:29:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zcbm-0002yZ-Bv for ieprep-archive@odin.ietf.org; Mon, 07 Jul 2003 16:29:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67KTAix011433 for ieprep-archive@odin.ietf.org; Mon, 7 Jul 2003 16:29:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zcbm-0002yK-7t for ieprep-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 16:29:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13633 for ; Mon, 7 Jul 2003 16:29:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zcbk-0002JE-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 16:29:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zcbj-0002JB-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 16:29:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zcbd-0002vr-4A; Mon, 07 Jul 2003 16:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zcb0-0002u8-P0 for ieprep@optimus.ietf.org; Mon, 07 Jul 2003 16:28:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13561 for ; Mon, 7 Jul 2003 16:28:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zcay-0002HQ-00 for ieprep@ietf.org; Mon, 07 Jul 2003 16:28:20 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 19Zcaw-0002HN-00 for ieprep@ietf.org; Mon, 07 Jul 2003 16:28:19 -0400 Received: from extremenetworks.com (unknown [10.18.3.105]) by gnat.inet.org (Postfix) with ESMTP id 09E4E67106; Mon, 7 Jul 2003 16:54:32 -0400 (EDT) Date: Mon, 7 Jul 2003 16:28:04 -0400 Subject: Re: [Ieprep] IEPREP agenda Vienna meeting Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Kimberly S.King" From: RJ Atkinson In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B01108021@KC-MAIL4.kc.umkc.edu> Message-Id: <82D16D20-B0B9-11D7-9E7F-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Jul 3, 2003, at 18:54 America/Montreal, Ayyasamy, Senthilkumar (UMKC-Student) wrote: >> High Availability Networks 15 minutes >> Discussion on high availability networks > > You mean high speed networks like Internet2 where BW*delay product > is high? or a backbone network? If we have high availability, why > should we worry about giving special priority to ieprep traffic? And who is presenting what material in that slot ? With all other non-administrative agenda items there is an I-D as the basis for discussion AND the schedule presenter/discusser is listed openly right now. Could you please provide more detail on the above item ? and its objectives ? Thanks. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Jul 7 16:39:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14182 for ; Mon, 7 Jul 2003 16:39:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZclM-0003kS-HW for ieprep-archive@odin.ietf.org; Mon, 07 Jul 2003 16:39:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Kd4Rg014402 for ieprep-archive@odin.ietf.org; Mon, 7 Jul 2003 16:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZclM-0003kD-EY for ieprep-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 16:39:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14165 for ; Mon, 7 Jul 2003 16:39:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZclK-0002RP-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 16:39:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZclK-0002RM-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 16:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZclJ-0003ig-DB; Mon, 07 Jul 2003 16:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZclD-0003iP-M0 for ieprep@optimus.ietf.org; Mon, 07 Jul 2003 16:38:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14157 for ; Mon, 7 Jul 2003 16:38:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZclB-0002RD-00 for ieprep@ietf.org; Mon, 07 Jul 2003 16:38:53 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 19ZclA-0002RA-00 for ieprep@ietf.org; Mon, 07 Jul 2003 16:38:52 -0400 Received: from extremenetworks.com (unknown [10.18.3.105]) by gnat.inet.org (Postfix) with ESMTP id C314167106; Mon, 7 Jul 2003 17:05:18 -0400 (EDT) Date: Mon, 7 Jul 2003 16:38:50 -0400 Subject: Re: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Ieprep (E-mail)" To: "Steve Silverman" From: RJ Atkinson In-Reply-To: Message-Id: <04338F72-B0BB-11D7-9E7F-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sunday, Jul 6, 2003, at 17:46 America/Montreal, Steve Silverman wrote: > Obviously at the IP level, only packets are flowing and intermediate > nodes (routers) don't know about the connection. Thanks. > But, "the President doesn't get a busy signal (or "No resources > available") " > When he makes a VoIP call, his (or her) packets get thru and the > called and calling parties can understand > each other (enough packets get thru for usable voice). > Even if there are many people making voice calls or attempting voice > calls and the existing bandwidth > is insufficient, certain previously marked users get some sort of > priority so that they can > have useful voice calls. This means that those marked users and their > called party's packets don't get dropped or delayed enough that those > packets are unusable. > > Note that this is a functional description as perceived by the end > users. While I have certain ideas > about how this might be accomplished, I am only proposing a functional > requirement here since that is all > IEPREP is allowed to do. > > It should also be noted that this function has been available for 40 > years and is a prerequisite for the DOD to > convert to VoIP. They simply CAN'T migrate without it. Some people > may disagree as to the "true" requirements > but certain major decision makers (JCS - Joint Chiefs of Staff) are > quite convinced about the need for this function. > I don't this level or management tends to spend much time on this > list. > Since I have no problem > envisioning scenarios in which this functionality is truly required, I > have no problem attempting to accomplish it. > (e.g., Dec. 7, 1941: Pearl Harbor - "The Japanese have declared > war".... ) > > I think everything above is old info on this list but I thought I > should respond to a direct question. The "old" DDN of the late 1980s reportedly implemented the IP ToS Priority bits as per RFC-791. One might imagine that the same solution would work now that worked back then. There are any number of commercial products that could support such a deployment today iff DoD decided to enable that configuration in the equipment. A fair chunk of the deployed NIPRnet/SIPRnet equipment could support MLPP tomorrow with a simple edit to the config file, if the applicable DoD folks decided that they wanted to deploy such a policy. Whether those DoD folks decide to do that or not is their internal policy issue, not an IETF matter. What I continue to have trouble locating in your notes is the IETF standards problem, as different from a DoD-internal matter of what existing technologies they choose to use or not use. If this note is in some way confusing, I'm happy to drive in to DISA/Skyline some day and walk through how it can be done with existing technology with any set of interested folks. The constraints on the existing technology mainly involves inter-domain QoS -- but the DoD is a single policy domain so existing technology can address the DoD VoIP deployment space pretty well. GETS-like capabilities, which are generally inter-domain, are somewhat more challenging to deploy with existing technology for reasons discussed at great length on-list and in-meetings in the past. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Jul 7 19:07:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20995 for ; Mon, 7 Jul 2003 19:07:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zf4h-0004LT-Ep for ieprep-archive@odin.ietf.org; Mon, 07 Jul 2003 19:07:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67N7BQp016699 for ieprep-archive@odin.ietf.org; Mon, 7 Jul 2003 19:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zf4h-0004LF-A0 for ieprep-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 19:07:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20987 for ; Mon, 7 Jul 2003 19:07:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zf4e-000413-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 19:07:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zf4d-00040z-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 19:07:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zf4X-0004Jf-7w; Mon, 07 Jul 2003 19:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zf40-0004J4-KB for ieprep@optimus.ietf.org; Mon, 07 Jul 2003 19:06:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20962 for ; Mon, 7 Jul 2003 19:06:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zf3x-00040a-00 for ieprep@ietf.org; Mon, 07 Jul 2003 19:06:25 -0400 Received: from kc-msxproto2.kc.umkc.edu ([134.193.143.159]) by ietf-mx with esmtp (Exim 4.12) id 19Zf3w-00040X-00 for ieprep@ietf.org; Mon, 07 Jul 2003 19:06:24 -0400 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Mon, 7 Jul 2003 18:06:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting Date: Mon, 7 Jul 2003 18:06:22 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108030@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] IEPREP agenda High Availability Networks Vienna meeting Thread-Index: AcNEj5VFIkyImRFKT9uTqESYcG+xTQAS1Qwg From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Berg, Dennis" , "Steve Silverman" , "Ieprep (E-mail)" Cc: X-OriginalArrivalTime: 07 Jul 2003 23:06:22.0811 (UTC) FILETIME=[623C2AB0:01C344DC] Content-Transfer-Encoding: quoted-printable Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >> I think, we have to think reverse...i.e.VoIP traffic blocking the=20 >> transfer of legitimate TCP based traffic;the related fairness=20 >> issue and tcp-friendliness. Please read the recent IAB draft, which=20 >> clearly illustrates with back of the envelope calculations based on=20 >> a VoIP transfer between Atlanta and Nairobi demoed at a previous=20 >> ieprep session.=20 > COULD YOU IDENTIFY THE IAB DRAFT THAT YOU ARE REFERRING TO?=20 actually, Ran forwarded the ID to this list.=20 http://www.ietf.org/internet-drafts/draft-iab-congestion-00.txt It has some rough calculations on how TCP is affected based on the packet drop rates exhibited by the VoIP transfer between=20 Atlanta and Nairobi.=20 but, comments about the draft should belong to e2e list. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Jul 7 20:07:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22213 for ; Mon, 7 Jul 2003 20:07:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zg0h-0007dq-AN for ieprep-archive@odin.ietf.org; Mon, 07 Jul 2003 20:07:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68077ie029368 for ieprep-archive@odin.ietf.org; Mon, 7 Jul 2003 20:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zg0h-0007db-4c for ieprep-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 20:07:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22208 for ; Mon, 7 Jul 2003 20:07:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zg0f-0004MN-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 20:07:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zg0e-0004MK-00 for ieprep-web-archive@ietf.org; Mon, 07 Jul 2003 20:07:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zg0b-0007cA-9C; Mon, 07 Jul 2003 20:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zg0G-0007bf-F8 for ieprep@optimus.ietf.org; Mon, 07 Jul 2003 20:06:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22205 for ; Mon, 7 Jul 2003 20:06:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zg0E-0004MB-00 for ieprep@ietf.org; Mon, 07 Jul 2003 20:06:38 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 19Zg0C-0004M6-00 for ieprep@ietf.org; Mon, 07 Jul 2003 20:06:37 -0400 Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h6806RDw010217; Mon, 7 Jul 2003 20:06:27 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h6806RS0010216; Mon, 7 Jul 2003 20:06:27 -0400 (EDT) Date: Mon, 7 Jul 2003 20:06:27 -0400 (EDT) From: Scott Bradner Message-Id: <200307080006.h6806RS0010216@newdev.harvard.edu> To: KIMBERLY.S.KING@saic.com, rja@extremenetworks.com Subject: Re: [Ieprep] IEPREP agenda Vienna meeting Cc: ieprep@ietf.org In-Reply-To: <82D16D20-B0B9-11D7-9E7F-00039357A82A@extremenetworks.com> Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , >> High Availability Networks 15 minutes >> Discussion on high availability networks > And who is presenting what material in that slot ? I will kick off a discussion on the topic mostly to see if there is any different definition of a "high availability network" than what ISPs are already doing (in the ISP space) or what an enterprise could do with today's technology (if it had the network budget) Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Jul 8 08:06:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18666 for ; Tue, 8 Jul 2003 08:06:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrES-0005vj-Ut for ieprep-archive@odin.ietf.org; Tue, 08 Jul 2003 08:06:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68C64sS022791 for ieprep-archive@odin.ietf.org; Tue, 8 Jul 2003 08:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrES-0005vW-Rk for ieprep-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 08:06:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18649 for ; Tue, 8 Jul 2003 08:06:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZrER-000102-00 for ieprep-web-archive@ietf.org; Tue, 08 Jul 2003 08:06:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZrEQ-0000zz-00 for ieprep-web-archive@ietf.org; Tue, 08 Jul 2003 08:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrEP-0005uq-Tc; Tue, 08 Jul 2003 08:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZAzJ-0007aG-3U for ieprep@optimus.ietf.org; Sun, 06 Jul 2003 10:59:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15361 for ; Sun, 6 Jul 2003 10:59:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZAzG-0002tJ-00 for ieprep@ietf.org; Sun, 06 Jul 2003 10:59:34 -0400 Received: from smtp6.mindspring.com ([207.69.200.110]) by ietf-mx with esmtp (Exim 4.12) id 19ZAzF-0002tD-00 for ieprep@ietf.org; Sun, 06 Jul 2003 10:59:34 -0400 Received: from dialup-171.75.56.207.dial1.washington1.level3.net ([171.75.56.207] helo=ix.netcom.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 19ZAz4-0003Lg-00; Sun, 06 Jul 2003 10:59:22 -0400 Message-ID: <3F083987.391FACD@ix.netcom.com> Date: Sun, 06 Jul 2003 11:00:23 -0400 From: Janet Gunn Organization: None X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: "Ayyasamy, Senthilkumar (UMKC-Student)" , "James M. Polk" , "Gunn, Janet" , Scott Bradner , rja@extremenetworks.com, ieprep@ietf.org, "Berg, Dennis" , pat_mcgregor@msn.com, "Kaczmarek, Richard NE" Subject: Re: [Ieprep] IP Bridging Configuration Guidance for IEPREP Telep hony References: <5EF7D95E17BDAD4A968C812E5ABC390B01108023@KC-MAIL4.kc.umkc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just to clarify, this approach is aimed at "a single domain IP-Bridging" topology. "Ayyasamy, Senthilkumar (UMKC-Student)" wrote: > > At 10:09 AM 7/3/2003 -0400, Gunn, Janet wrote: > >> It would be better to develop the guidance as an informational RFC > >> versus an official BCP, and then maybe later, if its application and > >> experience warrants, advance it as a BCP. > > Probably, you should read RFC 2026 (particularly Section 4.2 ) > > also, quoting scott(?), > //How can we get BCP without current practices? BCP is best way we know > how to do something rather than the best way we ARE doing something. // > > so, clearly your work can be considered as BCP, if you have _not_ proposed > changes to existing protocols; also, accepted by this WG (operators support > will be a huge plus) as a best way of *how to do something*. I don't think, > there is a clear current operational practice for giving priority to ieprep > traffic in Internet;except ensuring high availability. Hence, experience > based drafts like ieprep packet marking policy can be classified as BCP. > > another way to do is, to put your proposal in practice with the help of > some ISPs and then, standardise(as ran suggests at many places.) It has > been followed for some transport area standardizations. But, sometimes, > it will also lead to vendor inter-operability problems. > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 10 09:15:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00604 for ; Thu, 10 Jul 2003 09:15:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abGR-0006av-CJ for ieprep-archive@odin.ietf.org; Thu, 10 Jul 2003 09:15:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ADFBGo025345 for ieprep-archive@odin.ietf.org; Thu, 10 Jul 2003 09:15:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abGR-0006ai-94 for ieprep-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 09:15:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00593 for ; Thu, 10 Jul 2003 09:15:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19abGP-0002eW-00 for ieprep-web-archive@ietf.org; Thu, 10 Jul 2003 09:15:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19abGP-0002eS-00 for ieprep-web-archive@ietf.org; Thu, 10 Jul 2003 09:15:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abGH-0006Zw-HO; Thu, 10 Jul 2003 09:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abGC-0006ZS-Cj for ieprep@optimus.ietf.org; Thu, 10 Jul 2003 09:14:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00588 for ; Thu, 10 Jul 2003 09:14:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19abGA-0002eN-00 for ieprep@ietf.org; Thu, 10 Jul 2003 09:14:54 -0400 Received: from mtahqs3.ncr.disa.mil ([164.117.144.157] helo=pfwhqs1.ncr.disa.mil) by ietf-mx with smtp (Exim 4.12) id 19abG9-0002eK-00 for ieprep@ietf.org; Thu, 10 Jul 2003 09:14:53 -0400 Received: from mtahqs3.ncr.disa.mil by pfwhqs1.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 10 Jul 2003 13:16:04 UT Received: by mtahqs3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id <3NWQNDT4>; Thu, 10 Jul 2003 09:14:48 -0400 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02EF4EDB@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: ieprep@ietf.org Date: Thu, 10 Jul 2003 09:14:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] FW: Hui-Lan Lu: Access Link Intermediaries Assisting Services (al ias) BOF announcement Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This ALIAS BOF may be of interest to IEPREP. An -----Original Message----- From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] Sent: Sunday, July 06, 2003 7:15 PM To: IPsec WG Subject: Hui-Lan Lu: Access Link Intermediaries Assisting Services (alias) BOF announcement Content-Transfer-Encoding: 7bit Date: Thu, 26 Jun 2003 22:03:47 -0400 From: Hui-Lan Lu To: trigtran@ietf.org, intersec@psg.com CC: mankin@psg.com, kfall@eecs.berkeley.edu, jon.peterson@neustar.biz Subject: Access Link Intermediaries Assisting Services (alias) BOF announcement X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-intersec@psg.com Precedence: bulk Access Link Intermediaries Assisting Services (alias) BOF Tuesday, July 15 at 1545-1645 ============================== CHAIRS: Kevin Fall (kfall@eecs.berkeley.edu), Hui-Lan Lu (huilanlu@lucent.com) AGENDA: + Agenda bashing + A brief history, Area Directors, 5 min. + INTERSEC perspective, T. Woo, 15 min. http://www.ietf.org/internet-drafts/draft-blumenthal-intermediary-transport- 00.txt + TRIGTRAN perspective, S. Dawkins, 15 min. http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-framework-00.txt http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-probstmt-01.txt + Tentative charter + Wrapping up MAILING LIST: alias@mailman.berkeley.intel-research.net TO JOIN: http://mailman.berkeley.intel-research.net/mailman/listinfo/alias PROPOSED CHARTER: Several types of access links in widespread use for Internet connectivity today have characteristics that affect the operation Internet protocols and services. Low-bandwidth, high latency links patched over telephone lines via modems are one common example. Radio links in wireless networks (such as GSM, IS-95, GPRS and 802.11) are another example. These links often have undesirable characteristics such as high loss, high delay and low reliability. Transport intermediaries have been used to enhance the performance of problematic links in the past (see RFC 3135). This BoF investigates further work in support of transport intermediaries that provide assistance to access links, including (but not exclusively) wireless links, primarily in the areas of security protocol interaction with transport intermediaries and response to changing link conditions. In particular, existing intermediaries used for these purposes interfere with IPSec and may weaken overall end-to-end security - work is therefore necessary to determine how to request, authenticate and authorize the services of intermediaries, and when possible to mitigate the interference of intermediaries in security. This work focuses on support for TCP initially but does not preclude consideration of other transport-layer protocols. The relationship of transport intermediaries to devices constrained by OPES and UNSAF is also critical to the architectural framework. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 16 09:51:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00204 for ; Wed, 16 Jul 2003 09:51:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmgg-0003xs-RH for ieprep-archive@odin.ietf.org; Wed, 16 Jul 2003 09:51:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GDpIik015236 for ieprep-archive@odin.ietf.org; Wed, 16 Jul 2003 09:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmgg-0003xf-MH for ieprep-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 09:51:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00170 for ; Wed, 16 Jul 2003 09:51:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cmge-0007II-00 for ieprep-web-archive@ietf.org; Wed, 16 Jul 2003 09:51:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cmgZ-0007ID-00 for ieprep-web-archive@ietf.org; Wed, 16 Jul 2003 09:51:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmgO-0003sn-8S; Wed, 16 Jul 2003 09:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmg6-0003sQ-Fo for ieprep@optimus.ietf.org; Wed, 16 Jul 2003 09:50:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00144 for ; Wed, 16 Jul 2003 09:50:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cmg4-0007I7-00 for ieprep@ietf.org; Wed, 16 Jul 2003 09:50:40 -0400 Received: from chntex04.is.dyncorp.com ([131.131.133.208]) by ietf-mx with esmtp (Exim 4.12) id 19cmft-0007Hv-00 for ieprep@ietf.org; Wed, 16 Jul 2003 09:50:30 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id <3S5QLWKV>; Wed, 16 Jul 2003 09:48:04 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AA84@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'ieprep@ietf.org'" Date: Wed, 16 Jul 2003 09:48:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] Multiple instances of EF Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Since this came up twice in today's IEPREP meeting, here is the text from 3246 (last paragraph of actual text before the author addresses). "It should be noted that it is quite acceptable for a Diffserv domain to provide multiple instances of EF. Each instance should be characterizable by the equations in Section 2.2 of this specification. The effect of having multiple instances of EF on the E_a and E_p values of each instance will depend considerably on how the multiple instances are implemented. For example, in a multi- level priority scheduler, an instance of EF that is not at the highest priority may experience relatively long periods when it receives no service while higher priority instances of EF are served. This would result in relatively large values of E_a and E_p. By contrast, in a WFQ-like scheduler, each instance of EF would be represented by a queue served at some configured rate and the values of E_a and E_p could be similar to those for a single EF instance." It clearly refers to multiple instances with different priority ("an instance of EF that is not at the highest priority", and to multiple queues ("each instance of EF would be represented by a queue"). What it doesn't address is the use of additional code points to distinguish the additional instances. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 16 11:46:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06541 for ; Wed, 16 Jul 2003 11:46:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coTq-00037X-5G for ieprep-archive@odin.ietf.org; Wed, 16 Jul 2003 11:46:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GFkAgn011989 for ieprep-archive@odin.ietf.org; Wed, 16 Jul 2003 11:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coTo-00037I-La for ieprep-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 11:46:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06531 for ; Wed, 16 Jul 2003 11:46:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coTn-0000fH-00 for ieprep-web-archive@ietf.org; Wed, 16 Jul 2003 11:46:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19coTi-0000fE-00 for ieprep-web-archive@ietf.org; Wed, 16 Jul 2003 11:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coTh-00034c-K7; Wed, 16 Jul 2003 11:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coTQ-00034J-GF for ieprep@optimus.ietf.org; Wed, 16 Jul 2003 11:45:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06516 for ; Wed, 16 Jul 2003 11:45:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coTP-0000f8-00 for ieprep@ietf.org; Wed, 16 Jul 2003 11:45:43 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 19coTE-0000eq-00 for ieprep@ietf.org; Wed, 16 Jul 2003 11:45:32 -0400 Received: from extremenetworks.com (unknown [10.255.102.102]) by gnat.inet.org (Postfix) with ESMTP id 4FEE367119 for ; Wed, 16 Jul 2003 12:12:58 -0400 (EDT) Date: Wed, 16 Jul 2003 11:44:55 -0400 Subject: Re: [Ieprep] Multiple instances of EF Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE8915AA84@chntex04.is.dyncorp.com> Message-Id: <727C2413-B7A4-11D7-A707-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, Jul 16, 2003, at 09:48 America/Montreal, Gunn, Janet wrote: > It clearly refers to multiple instances with different priority ("an > instance of EF that is not at the highest priority", and to multiple > queues > ("each instance of EF would be represented by a queue"). What it > doesn't > address is the use of additional code points to distinguish the > additional > instances. I believe that most shipping DiffServ implementations already can support multiple EF or multiple AF (or any mixture) concurrently. The number of queues supported does often vary, with DoD precedence needing 8 queues and much currently shipping equipment only supporting 2 or 4 queues. So operators should test before they decide what to deploy (as always). Note Well: The question of which codepoints have which meanings is quite literally a deployment detail. Each deployment will very probably be different. This is not a problem since inter-domain DiffServ is virtually non-existent today (and will remain non-existent for the foreseeable future for reasons discussed at length here in the past). Ran Atkinson rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Jul 22 15:58:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25062 for ; Tue, 22 Jul 2003 15:58:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3H7-0006b2-Uw for ieprep-archive@odin.ietf.org; Tue, 22 Jul 2003 15:58:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MJwHZl025355 for ieprep-archive@odin.ietf.org; Tue, 22 Jul 2003 15:58:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3H7-0006as-RN for ieprep-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 15:58:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25055 for ; Tue, 22 Jul 2003 15:58:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f3H6-00072R-00 for ieprep-web-archive@ietf.org; Tue, 22 Jul 2003 15:58:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f3H0-00072N-00 for ieprep-web-archive@ietf.org; Tue, 22 Jul 2003 15:58:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3Gq-0006Zo-SX; Tue, 22 Jul 2003 15:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3GV-0006Zd-9P for ieprep@optimus.ietf.org; Tue, 22 Jul 2003 15:57:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25036 for ; Tue, 22 Jul 2003 15:57:35 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f3GT-00072I-00 for ieprep@ietf.org; Tue, 22 Jul 2003 15:57:37 -0400 Received: from imo-m03.mx.aol.com ([64.12.136.6]) by ietf-mx with esmtp (Exim 4.12) id 19f3GD-000723-00 for ieprep@ietf.org; Tue, 22 Jul 2003 15:57:22 -0400 Received: from Mpierce1@aol.com by imo-m03.mx.aol.com (mail_out_v36_r1.1.) id r.154.21dee7ef (3940); Tue, 22 Jul 2003 15:55:48 -0400 (EDT) Message-ID: <154.21dee7ef.2c4ef0c3@aol.com> Date: Tue, 22 Jul 2003 15:55:47 EDT Subject: Re: [Ieprep] Multiple instances of EF To: Janet.Gunn@DynCorp.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_154.21dee7ef.2c4ef0c3_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --part1_154.21dee7ef.2c4ef0c3_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 7/16/2003 9:51:47 AM Eastern Daylight Time, Janet.Gunn@DynCorp.com writes: > Since this came up twice in today's IEPREP meeting, here is the text from > 3246 (last paragraph of actual text before the author addresses). > > "It should be noted that it is quite acceptable for a Diffserv domain > to provide multiple instances of EF. Each instance should be > characterizable by the equations in Section 2.2 of this > specification. The effect of having multiple instances of EF on the > E_a and E_p values of each instance will depend considerably on how > the multiple instances are implemented. For example, in a multi- > level priority scheduler, an instance of EF that is not at the > highest priority may experience relatively long periods when it > receives no service while higher priority instances of EF are served. > This would result in relatively large values of E_a and E_p. By > contrast, in a WFQ-like scheduler, each instance of EF would be > represented by a queue served at some configured rate and the values > of E_a and E_p could be similar to those for a single EF instance." > I think this notion of multiple instances of EF has caused some confusion, since RFC 3246 says so little about it. As noted above, with a multilevel priority scheduler, an instance of EF (queue) not at the highest priority would not comply with the criteria for being called "EF". Therefore, it is not EF. With a WFQ-like scheduler, each EF queue is guaranteed to be served often enough, that is, a certain amount of the output bandwidth is reserved for it and its queue size limit must be set based on the amount of bandwidth it gets. It seems that this makes all such EF queues equal, but depends on careful scheduling of serving the queues so no one gets ignored too long. It also seems to me that the next logical step is to use a single queue, but to apply different queue thresholds for each of the multiple DSCPs which point to that one queue. Mike Pierce Artel --part1_154.21dee7ef.2c4ef0c3_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 7/16/2= 003 9:51:47 AM Eastern Daylight Time, Janet.Gunn@DynCorp.com writes:


Since this came up twice in= today's IEPREP meeting, here is the text from
3246 (last paragraph of actual text before the author addresses).

  "It should be noted that it is quite acceptable for a Diffs= erv domain
  to provide multiple instances of EF.  Each instance sh= ould be
  characterizable by the equations in Section 2.2 of this
  specification.  The effect of having multiple instance= s of EF on the
  E_a and E_p values of each instance will depend considerabl= y on how
  the multiple instances are implemented.  For example,=20= in a multi-
  level priority scheduler, an instance of EF that is not at=20= the
  highest priority may experience relatively long periods whe= n it
  receives no service while higher priority instances of EF a= re served.
  This would result in relatively large values of E_a and E_p= .  By
  contrast, in a WFQ-like scheduler, each instance of EF woul= d be
  represented by a queue served at some configured rate and t= he values
  of E_a and E_p could be similar to those for a single EF in= stance."


I think this notion of multiple instances of EF has caused some confusio= n, since RFC 3246 says so little about it. As noted above, with a multilevel= priority scheduler, an instance of EF (queue) not at the highest priority w= ould not comply with the criteria for being called "EF". Therefore, it is no= t EF.

With a WFQ-like scheduler, each EF queue is guaranteed to be served ofte= n enough, that is, a certain amount of the output bandwidth is reserved for=20= it and its queue size limit must be set based on the amount of bandwidth it=20= gets. It seems that this makes all such EF queues equal, but depends on care= ful scheduling of serving the queues so no one gets ignored too long. It als= o seems to me that the next logical step is to use a single queue, but to ap= ply different queue thresholds for each of the multiple DSCPs which point to= that one queue.

Mike Pierce
Artel

--part1_154.21dee7ef.2c4ef0c3_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Jul 22 16:18:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25747 for ; Tue, 22 Jul 2003 16:18:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3aK-0007mR-EK for ieprep-archive@odin.ietf.org; Tue, 22 Jul 2003 16:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MKI8kH029903 for ieprep-archive@odin.ietf.org; Tue, 22 Jul 2003 16:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3aK-0007mE-BZ for ieprep-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 16:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25732 for ; Tue, 22 Jul 2003 16:18:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f3aI-0007Be-00 for ieprep-web-archive@ietf.org; Tue, 22 Jul 2003 16:18:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f3aD-0007Bb-00 for ieprep-web-archive@ietf.org; Tue, 22 Jul 2003 16:18:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3aD-0007ju-57; Tue, 22 Jul 2003 16:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f3a6-0007jW-Cg for ieprep@optimus.ietf.org; Tue, 22 Jul 2003 16:17:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25728 for ; Tue, 22 Jul 2003 16:17:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f3a4-0007BX-00 for ieprep@ietf.org; Tue, 22 Jul 2003 16:17:52 -0400 Received: from chntex04.is.dyncorp.com ([131.131.133.208]) by ietf-mx with esmtp (Exim 4.12) id 19f3Zu-0007BK-00 for ieprep@ietf.org; Tue, 22 Jul 2003 16:17:42 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id <3S5QMG20>; Tue, 22 Jul 2003 16:15:06 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AA8F@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Mpierce1@aol.com'" , ieprep@ietf.org Subject: RE: [Ieprep] Multiple instances of EF Date: Tue, 22 Jul 2003 16:15:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Responding in particular to: " As noted above, with a multilevel priority scheduler, an instance of EF (queue) not at the highest priority would not comply with the criteria for being called "EF". Therefore, it is not EF." Yes it is. It is just EF with a relatively large E_a and E_p. The definition of EF doesn't say they have to be small, just they have to be bounds. -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Tuesday, July 22, 2003 3:56 PM To: Gunn, Janet; ieprep@ietf.org Subject: Re: [Ieprep] Multiple instances of EF In a message dated 7/16/2003 9:51:47 AM Eastern Daylight Time, Janet.Gunn@DynCorp.com writes: Since this came up twice in today's IEPREP meeting, here is the text from 3246 (last paragraph of actual text before the author addresses). "It should be noted that it is quite acceptable for a Diffserv domain to provide multiple instances of EF. Each instance should be characterizable by the equations in Section 2.2 of this specification. The effect of having multiple instances of EF on the E_a and E_p values of each instance will depend considerably on how the multiple instances are implemented. For example, in a multi- level priority scheduler, an instance of EF that is not at the highest priority may experience relatively long periods when it receives no service while higher priority instances of EF are served. This would result in relatively large values of E_a and E_p. By contrast, in a WFQ-like scheduler, each instance of EF would be represented by a queue served at some configured rate and the values of E_a and E_p could be similar to those for a single EF instance." I think this notion of multiple instances of EF has caused some confusion, since RFC 3246 says so little about it. As noted above, with a multilevel priority scheduler, an instance of EF (queue) not at the highest priority would not comply with the criteria for being called "EF". Therefore, it is not EF. With a WFQ-like scheduler, each EF queue is guaranteed to be served often enough, that is, a certain amount of the output bandwidth is reserved for it and its queue size limit must be set based on the amount of bandwidth it gets. It seems that this makes all such EF queues equal, but depends on careful scheduling of serving the queues so no one gets ignored too long. It also seems to me that the next logical step is to use a single queue, but to apply different queue thresholds for each of the multiple DSCPs which point to that one queue. Mike Pierce Artel _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 23 09:37:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12365 for ; Wed, 23 Jul 2003 09:37:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJnF-0001ae-VY for ieprep-archive@odin.ietf.org; Wed, 23 Jul 2003 09:36:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NDaXtI006108 for ieprep-archive@odin.ietf.org; Wed, 23 Jul 2003 09:36:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJnF-0001aR-SW for ieprep-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 09:36:33 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12331 for ; Wed, 23 Jul 2003 09:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJmi-0001SF-Uu; Wed, 23 Jul 2003 09:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJlm-0001O6-IQ for ieprep@optimus.ietf.org; Wed, 23 Jul 2003 09:35:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12238 for ; Wed, 23 Jul 2003 09:34:59 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJlk-0004hZ-00 for ieprep@ietf.org; Wed, 23 Jul 2003 09:35:00 -0400 Received: from imo-r07.mx.aol.com ([152.163.225.103]) by ietf-mx with esmtp (Exim 4.12) id 19fJlV-0004gs-00 for ieprep@ietf.org; Wed, 23 Jul 2003 09:34:45 -0400 Received: from Mpierce1@aol.com by imo-r07.mx.aol.com (mail_out_v36_r1.1.) id r.105.3343fa3b (4328); Wed, 23 Jul 2003 09:31:28 -0400 (EDT) Message-ID: <105.3343fa3b.2c4fe830@aol.com> Date: Wed, 23 Jul 2003 09:31:28 EDT Subject: Re: [Ieprep] Multiple instances of EF To: Janet.Gunn@DynCorp.com, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_105.3343fa3b.2c4fe830_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --part1_105.3343fa3b.2c4fe830_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 7/22/2003 4:17:40 PM Eastern Standard Time, Janet.Gunn@DynCorp.com writes: > Responding in particular to: > " As noted above, with a multilevel priority scheduler, an instance of EF > (queue) not at the highest priority would not comply with the criteria for > being called "EF". Therefore, it is not EF." > > Yes it is. It is just EF with a relatively large E_a and E_p. The > definition of EF doesn't say they have to be small, just they have to be > bounds. > Guess I'm thinking of the use of the multiple queues for voice, since that was the subject here (emergeny calls). While it is true that the lower "priority" queue could meet the criteria for EF for some other constant bit rate service with much less stringent delay requirements, I don't believe it could meet the requirements for voice. Mike --part1_105.3343fa3b.2c4fe830_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 7/22/2= 003 4:17:40 PM Eastern Standard Time, Janet.Gunn@DynCorp.com writes:


Responding in particular to= :
" As noted above, with a multilevel priority scheduler, an instance of E= F
(queue) not at the highest priority would not comply with the criteria f= or
being called "EF". Therefore, it is not EF."

Yes it is.  It is just EF with a relatively large  E_a and E_p= .  The
definition of EF doesn't say they have to be small, just they have to be
bounds.


Guess I'm thinking of the use of the multiple queues for voice, since th= at was the subject here (emergeny calls). While it is true that the lower "p= riority" queue could meet the criteria for EF for some other constant bit ra= te service with much less stringent delay requirements, I don't believe it c= ould meet the requirements for voice.

Mike
--part1_105.3343fa3b.2c4fe830_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 23 10:36:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15275 for ; Wed, 23 Jul 2003 10:36:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKix-0004dF-TQ for ieprep-archive@odin.ietf.org; Wed, 23 Jul 2003 10:36:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NEaBvh017800 for ieprep-archive@odin.ietf.org; Wed, 23 Jul 2003 10:36:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKix-0004d1-3A for ieprep-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 10:36:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15222 for ; Wed, 23 Jul 2003 10:36:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKiu-00055v-00 for ieprep-web-archive@ietf.org; Wed, 23 Jul 2003 10:36:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fKip-00055s-00 for ieprep-web-archive@ietf.org; Wed, 23 Jul 2003 10:36:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKip-0004aA-0y; Wed, 23 Jul 2003 10:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKi1-0004Yl-US for ieprep@optimus.ietf.org; Wed, 23 Jul 2003 10:35:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15156 for ; Wed, 23 Jul 2003 10:35:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKhz-00055P-00 for ieprep@ietf.org; Wed, 23 Jul 2003 10:35:11 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 19fKho-000554-00 for ieprep@ietf.org; Wed, 23 Jul 2003 10:35:00 -0400 Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 7534E67103; Wed, 23 Jul 2003 11:03:45 -0400 (EDT) Date: Wed, 23 Jul 2003 10:34:30 -0400 Subject: Re: [Ieprep] Multiple instances of EF Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ieprep To: Mpierce1@aol.com From: RJ Atkinson In-Reply-To: <105.3343fa3b.2c4fe830@aol.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, Jul 23, 2003, at 09:31 America/Montreal, Mpierce1@aol.com wrote: > Guess I'm thinking of the use of the multiple queues for voice, since > that was the subject here (emergeny calls). While it is true that the > lower "priority" queue could meet the criteria for EF for some other > constant bit rate service with much less stringent delay requirements, > I > don't believe it could meet the requirements for voice. I know of deployed DoD voice/IP applications whose requirements are well below even needing *any* form of DiffServ, so I do not believe the claim that only one queue of EF will meet 'voice requirements' is very generally true. The claim might be true for some particular vocoder algorithm, though no particular algorithm or other qualification was made clear in the quoted text. To some of us, such a lack of resilience would be a large clue to use a different vocoder algorithm. A number of ITU-T vocoder algorithms appear to lack resilience -- not surprising since many (all ?) of them were designed for the circuit-switched phone system. Folks here might really want to grab a copy of NRL's Ivox and play with it. It has a range of vocoders (several proprietary to DoD). The software is freely available for a number of OS/CPU platforms and it works quite well. (Google for "NRL IVOX" and you should turn it up :-). Cheers, Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 23 11:08:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16377 for ; Wed, 23 Jul 2003 11:08:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLDt-0006Zg-PN for ieprep-archive@odin.ietf.org; Wed, 23 Jul 2003 11:08:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NF89uR025266 for ieprep-archive@odin.ietf.org; Wed, 23 Jul 2003 11:08:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLDt-0006Yf-MB for ieprep-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 11:08:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16359 for ; Wed, 23 Jul 2003 11:08:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fLDp-0005La-00 for ieprep-web-archive@ietf.org; Wed, 23 Jul 2003 11:08:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fLDk-0005LX-00 for ieprep-web-archive@ietf.org; Wed, 23 Jul 2003 11:08:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLDk-0006Xz-PE; Wed, 23 Jul 2003 11:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLDd-0006Xh-Me for ieprep@optimus.ietf.org; Wed, 23 Jul 2003 11:07:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16351 for ; Wed, 23 Jul 2003 11:07:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fLDb-0005LJ-00 for ieprep@ietf.org; Wed, 23 Jul 2003 11:07:51 -0400 Received: from mtahqs3.ncr.disa.mil ([164.117.144.157] helo=pfwhqs1.ncr.disa.mil) by ietf-mx with smtp (Exim 4.12) id 19fLDQ-0005L4-00 for ieprep@ietf.org; Wed, 23 Jul 2003 11:07:40 -0400 Received: from mtahqs3.ncr.disa.mil by pfwhqs1.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 23 Jul 2003 15:09:18 UT Received: by mtahqs3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 11:07:16 -0400 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02EF4F31@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'RJ Atkinson'" Cc: "'Mpierce1@aol.com'" , "'ieprep@ietf.org'" Subject: RE: [Ieprep] Multiple instances of EF Date: Wed, 23 Jul 2003 11:07:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Ran, Question for clarification: EF is for voice bearer. What about voice-related signaling streams? How are they handled at the routing layer? Thanks, An -----Original Message----- From: RJ Atkinson [mailto:rja@extremenetworks.com] Sent: Wednesday, July 23, 2003 10:35 AM To: Mpierce1@aol.com Cc: ieprep Subject: Re: [Ieprep] Multiple instances of EF On Wednesday, Jul 23, 2003, at 09:31 America/Montreal, Mpierce1@aol.com wrote: > Guess I'm thinking of the use of the multiple queues for voice, since > that was the subject here (emergeny calls). While it is true that the > lower "priority" queue could meet the criteria for EF for some other > constant bit rate service with much less stringent delay requirements, > I > don't believe it could meet the requirements for voice. I know of deployed DoD voice/IP applications whose requirements are well below even needing *any* form of DiffServ, so I do not believe the claim that only one queue of EF will meet 'voice requirements' is very generally true. The claim might be true for some particular vocoder algorithm, though no particular algorithm or other qualification was made clear in the quoted text. To some of us, such a lack of resilience would be a large clue to use a different vocoder algorithm. A number of ITU-T vocoder algorithms appear to lack resilience -- not surprising since many (all ?) of them were designed for the circuit-switched phone system. Folks here might really want to grab a copy of NRL's Ivox and play with it. It has a range of vocoders (several proprietary to DoD). The software is freely available for a number of OS/CPU platforms and it works quite well. (Google for "NRL IVOX" and you should turn it up :-). Cheers, Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 23 12:59:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19740 for ; Wed, 23 Jul 2003 12:59:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMxh-0003QU-0R for ieprep-archive@odin.ietf.org; Wed, 23 Jul 2003 12:59:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NGxWg7013166 for ieprep-archive@odin.ietf.org; Wed, 23 Jul 2003 12:59:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMxg-0003QH-Sd for ieprep-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 12:59:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19721 for ; Wed, 23 Jul 2003 12:59:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMxB-0003L1-2U; Wed, 23 Jul 2003 12:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMxA-0003Kq-4q for ieprep@optimus.ietf.org; Wed, 23 Jul 2003 12:59:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19711 for ; Wed, 23 Jul 2003 12:58:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fMx8-000690-00 for ieprep@ietf.org; Wed, 23 Jul 2003 12:58:58 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 19fMwx-00068x-00 for ieprep@ietf.org; Wed, 23 Jul 2003 12:58:47 -0400 Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id F35FE67103; Wed, 23 Jul 2003 13:27:36 -0400 (EDT) Date: Wed, 23 Jul 2003 12:58:20 -0400 Subject: Re: [Ieprep] Multiple instances of EF Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'ieprep@ietf.org'" To: "Nguyen, An" From: RJ Atkinson In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D02EF4F31@emshqs1.ncr.disa.mil> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, Jul 23, 2003, at 11:07 America/Montreal, Nguyen, An wrote: > Question for clarification: EF is for voice bearer. > What about voice-related signaling streams? > How are they handled at the routing layer? Any or all configuration of "active queuing" [1] is a decision made individually by each network operator. IETF normally does not try to tell any network operator how to configure, deploy, or operate their network(s). So those streams could be handled in any way that the operator chose to configure their network. If the question is about what options exist, I address that in more detail below. If the question is about what is deployed, the operators are in a better position to talk about that. QoS capabilities of networking equipment (e.g. switches, routers) varies a great deal. Equipment built on commodity switch/router silicon (e.g. inexpensive stuff bought at retail stores) often looks more or less like this: - one queue per port (i.e. no QoS) - two queues per port (i.e. very limited QoS) - no 'packet classification' [2] capability or very limited packet classification capability - only one form of queue management available (WFQ might be most common) Equipment built on vendor-designed proprietary silicon (e.g. Extreme, Juniper) often has more capabilities: - 4 or 8 queues per port - ability to classify packets/frames based on multiple header fields such as - 802.1p precedence - IP ToS byte - IP Addresses (source &/or dest) - upper-protocol (TCP, UDP, SCTP) - application port (source &/or dest) - multiple queue management algorithms (WFQ, RED, & WRED are all pretty common) The ability to (re-)mark the IP ToS byte or 802.1p precedence field based on classification is not uncommon, but is certainly not available in all current equipment. In the more QoS-capable equipment, it certainly would be possible to classify any traffic that used predictable port/protocol combinations and either raise or lower the priority of that traffic, subject that traffic to active queuing, mark IP ToS/802.1p precedence bits, or otherwise apply QoS to that traffic. Operators likely would want to test the behaviour of equipment before selecting it for deployment and before enabling or configuring QoS on that equipment, of course. [1] Meaning DiffServ of any type, Class-based Queing in routers, or anything similar that uses more than one queue per port and some form of queue management. Commonly implemented queue management techniques include WFQ, RED, WRED. [2] Packet Classification normally means the ability to look at a packet (or frame in the case of an L2 switch), the header fields, and then sort the packet (or frame) into the appropriate queue (possibly including re-marking the IP ToS byte or 802.1p precedence field as well). Personally, I think the notion that 'only EF is suitable for voice' is confused at best. My own experience is that one can configure DiffServ in such a way that it is not really terribly useful for anything -- and also that one can configure DiffServ so that it adds a lot of value. I think too much attention to EF or AF (or other PHB) often can confuse the issues rather than simplify them. I've seen AF-compliant queuing used with voice -- and work well. I have also seen EF-compliant queuing used with voice -- and work poorly. The DoD reportedly has had significant experience with the IP precedence values defined in RFC-791 -- and as near as I've heard that worked well (and occurred before the IETF even created a DiffServ WG). As far as I know, most of that experience was on Proteon boxes -- whose OSPF supported ToS-based path selection (e.g. so delay sensitive traffic would use undersea cable between JP and US, while some other traffic would tend to go via SATCOM). I think that the ACC boxen might also have supported those OSPF enhancements, but I'm not certain. Ran Atkinson rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jul 23 13:10:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19988 for ; Wed, 23 Jul 2003 13:10:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fN7w-0003xB-Je for ieprep-archive@odin.ietf.org; Wed, 23 Jul 2003 13:10:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NHA8DE015195 for ieprep-archive@odin.ietf.org; Wed, 23 Jul 2003 13:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fN7w-0003x0-Eo for ieprep-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 13:10:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19972 for ; Wed, 23 Jul 2003 13:10:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fN7u-0006CX-00 for ieprep-web-archive@ietf.org; Wed, 23 Jul 2003 13:10:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fN7p-0006CU-00 for ieprep-web-archive@ietf.org; Wed, 23 Jul 2003 13:10:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fN7p-0003vO-TY; Wed, 23 Jul 2003 13:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fN7f-0003uD-Qr for ieprep@optimus.ietf.org; Wed, 23 Jul 2003 13:09:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19963 for ; Wed, 23 Jul 2003 13:09:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fN7d-0006CN-00 for ieprep@ietf.org; Wed, 23 Jul 2003 13:09:49 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 19fN7T-0006CK-00 for ieprep@ietf.org; Wed, 23 Jul 2003 13:09:39 -0400 Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 0174667103; Wed, 23 Jul 2003 13:38:43 -0400 (EDT) Date: Wed, 23 Jul 2003 13:09:27 -0400 Subject: Re: [Ieprep] Multiple instances of EF Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'ieprep@ietf.org'" To: RJ Atkinson From: RJ Atkinson In-Reply-To: Message-Id: <6A9E33C6-BD30-11D7-860A-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, Jul 23, 2003, at 12:58 America/Montreal, RJ Atkinson wrote: > In the more QoS-capable equipment, it certainly would be > possible to classify any traffic that used predictable > port/protocol combinations and either raise or lower the > priority of that traffic, subject that traffic to active > queuing, mark IP ToS/802.1p precedence bits, or otherwise > apply QoS to that traffic. One challenge to ISPs that use the above approach to classify traffic for certain port/protocols (e.g. telephony signalling) would be that individuals using other applications (e.g. multimedia file-sharing applications) would probably configure their applications to use those same port/protocol values in order to obtain the preferred service for non-legitimate traffic. That is a kind of denial-of-service attack, one that has been discussed various places (e.g. IEPG) in the past. A second challenge is that if a backbone is typical -- and is over-provisioned -- then traffic that is queued specially could well have worse performance/QoS results than the best-effort traffic. This is a counter-intuitive result, but has been reported as experimental result in some cases (again, this was from an in-person discussion at an IEPG meeting a while back). So it is really not clear that there would be benefit to deploying any of this QoS stuff in an inter-domain context. Within a single administrative domain, the operator could theoretically force applications to only use protocol/port combinations that were approved by the powers-that-be for that administrative domain -- though this could be pretty hard to achieve in practice if one's domain had significant deployment size. Cheers, Ran Atkinson rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Jul 29 09:08:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21796 for ; Tue, 29 Jul 2003 09:08:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUDA-0002Qg-6p for ieprep-archive@odin.ietf.org; Tue, 29 Jul 2003 09:08:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TD8GTv009334 for ieprep-archive@odin.ietf.org; Tue, 29 Jul 2003 09:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUDA-0002QT-1m for ieprep-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 09:08:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21782 for ; Tue, 29 Jul 2003 09:08:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hUD8-0005Ij-00 for ieprep-web-archive@ietf.org; Tue, 29 Jul 2003 09:08:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hUD7-0005If-00 for ieprep-web-archive@ietf.org; Tue, 29 Jul 2003 09:08:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUCu-0002P0-S4; Tue, 29 Jul 2003 09:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUCQ-0002Hj-U0 for ieprep@optimus.ietf.org; Tue, 29 Jul 2003 09:07:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21762 for ; Tue, 29 Jul 2003 09:07:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hUCP-0005IJ-00 for ieprep@ietf.org; Tue, 29 Jul 2003 09:07:29 -0400 Received: from portal.east.saic.com ([198.151.13.15]) by ietf-mx with smtp (Exim 4.12) id 19hUCO-0005IF-00 for ieprep@ietf.org; Tue, 29 Jul 2003 09:07:28 -0400 Received: from mcl-its-dq.saic.com by portal.east.saic.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 29 Jul 2003 09:07:28 -0400 Received: from mcl-its-ieg01.mail.saic.com by mcl-its-dq.saic.com for ieprep@ietf.org; Tue, 29 Jul 2003 09:06:21 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.21) with SMTP id M2003072909061820307 ; Tue, 29 Jul 2003 09:06:18 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 09:06:19 -0400 Message-Id: From: "King, Kimberly S." To: "'Allison Mankin '" , "'jon.peterson@neustar.biz '" Cc: "'sob@harvard.edu'" , "'ieprep@ietf.org'" Date: Tue, 29 Jul 2003 09:06:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] IEPREP Vienna meeting summary Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , The Internet Emergency Preparedness (IEPREP) meeting consisted of 2 presentations and a discussion. The first was given by Ken Carlberg who went over changes to both the general and IP telephony requirements for IEPREP. There were no objections to the document substance. In addition, he discussed individual contribution on stub domains. The second contribution was given by Janet Gunn about the draft written by McGregor, Kaczmarek, Berg and Gunn on MPLS IP bridging scenarios for IEPREP. During the discussion it was pointed out that the draft proposed modifying existing IETF protocols and that any such modification was outside the scope of the IEPREP WG charter. It was suggested that the authors break up the ID into multiple smaller IDs that focused on requirements for individual IETF protocols. It was also noted that some parts of the ID (for example using SIP to notify end users) did not seem to be relevant to the specific bridging context the ID was addressing. Scott Bradner then initiated a discussion of High Availability Networks. He went over general design concepts in IP networks that lead to resilient networks. He then asked the working group if they thought IEPREP needed to do anything in writing documents to help network operators build such networks. The working group pointed out that ISPs tend to provide these capabilities in order to support their customers. But it was pointed out that some of the newer ISP players might not have the background to understand the importance of redundant network designs. The conclusion of the discussion was that IEPREP did not have any additional role in defining documents for High Availability Networks but that such documents might be a reasonable topic for some O&M area working group. -----Original Message----- From: Allison Mankin To: tsv-chairs@ietf.org Cc: jon.peterson@neustar.biz Sent: 7/24/2003 11:42 AM Subject: Pre-minutes highlights of your meetings Hi, Transport Area Chairs, A number of you have already sent us summaries of your working groups. Please send a brief, pre-minutes narrative of the major decisions and events of the meeting to Jon and me. It can really just cover selected consenses, and/or controversies. Highlights. It is also a useful item to send to your working groups, suitably labelled. We'd like to have this before July 31. Next time, with more notice, we'll ask for it within a week of the IETF meeting. Milestone updates are important at this time too. Send them to iesg-secretary, cc the ADs. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Jul 29 09:11:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21955 for ; Tue, 29 Jul 2003 09:11:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUFx-0002Yr-5K for ieprep-archive@odin.ietf.org; Tue, 29 Jul 2003 09:11:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TDB9Vk009839 for ieprep-archive@odin.ietf.org; Tue, 29 Jul 2003 09:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUFx-0002Yc-1z for ieprep-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 09:11:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21935 for ; Tue, 29 Jul 2003 09:11:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hUFu-0005Ln-00 for ieprep-web-archive@ietf.org; Tue, 29 Jul 2003 09:11:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hUFu-0005Lj-00 for ieprep-web-archive@ietf.org; Tue, 29 Jul 2003 09:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUFp-0002Wd-AP; Tue, 29 Jul 2003 09:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUFZ-0002VX-Pe for ieprep@optimus.ietf.org; Tue, 29 Jul 2003 09:10:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21924 for ; Tue, 29 Jul 2003 09:10:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hUFY-0005LP-00 for ieprep@ietf.org; Tue, 29 Jul 2003 09:10:44 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx with esmtp (Exim 4.12) id 19hUFX-0005LM-00 for ieprep@ietf.org; Tue, 29 Jul 2003 09:10:43 -0400 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 29 Jul 2003 09:10:43 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.21) with SMTP id M2003072909104123337 ; Tue, 29 Jul 2003 09:10:41 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 09:10:42 -0400 Message-Id: From: "King, Kimberly S." To: "'ieprep@ietf.org'" Cc: "'Allison Mankin '" , "'jon.peterson@neustar.biz '" , "'sob@harvard.edu'" Date: Tue, 29 Jul 2003 09:10:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] IEPREP Vienna meeting minutes Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Carlberg presentation Basic telephony and general requirements were acceptable (i.e., no objections) to the working group. The framework will undergo another pass through. Polk - raised the issue that the IETF use terms in alignment with the ITU. The ITU uses the initialism TDR (telecommunications for disaster relief) vs. ETS. Carlberg stub domain presentation Berg - wants to know if access links and transit are part of some IEPREP document, Scott says within a domain but not in plan to go beyond single domain. Desire has been expressed but not enough meet in traction to go further. Scott feels the intention is both stub domains and transit over a single domain. Polk - wants to know EF relationship and things like MPLS ideas. Gunn presentation Polk - This document proposes extensions to a lot of existing protocols, and a BCP is intended to use existing technology in its practices. The ideas in this document might be better served if the ideas were broken up, replaced by requirements, and moved into the appropriate working groups for consideration. If the resulting mechanisms are standardized, then the document can be revived in IEPREP for consideration. Further, the point is that this document only proposed solutions, which are not appropriate. In order for this document to have any use it must be made up of requirements. Bradner - This document, as is, has no path forward. The use of experimental codepoints makes it such that it won't be made into an RFC. Also, a best common practices document must be possible with existing technology, and due to the fact that you are using experimental codepoints, you don't meet that requirement. If the media gateway is smart enough to differentiate between ETS and non-ETS traffic, then the IP portion is not relevant, as two tunnels can be created (1 - ETS; 1 - non ETS), and manage the priority in that way. Henry (MCI) - There are no IP phones in the architecture, and therefore the model is bad. Also, it doesn't consider cable networks at all. Scott Bradner said that it was "a scenario that needs to be addressed, but not the only one." Dick Knight - asked a clarification on the requirement in the proposed BCP for the use of M2UA rather M3UA. Dick stated that M2UA emulates SS7 MTP2 level (Signaling Transport - Link Level) so that an existing SS7 MTP3 (Signaling Transport - Network Level) can be used without it knowing that it is operating in an IP packet environment. Similarly, M3UA emulates the Signaling Network Level of SS7, so that ISUP and other Application Parts of the SS7 stack, can be used without knowledge of the underlying IP network. Janet's presentation explicitly stated that M2UA MUST be used in order to preserve SS7 ISUP parameters. Dick pointed out that whether M2UA or M3UA is used, the ISUP parameters are unaffected. He asked for an explanation of this requirement. Dick Knight also said "People are using M3UA or M2PA. Nobody is using M2UA." Also "There is no point in using the (current) SIP emergency header if you are going to a CSN phone. The SIP emergency notification will never get there. The SIP emergency notification only makes sense if it is going to a SIP phone." Bradner presentation Scott went over general concepts of multi-homing user sites and avoiding single points of failure in general. These types of techniques lead to resilient networks. He then asked the working group if they thought IEPREP needed to do anything in writing documents to help network operators build such networks. The working group pointed out that ISPs tend to provide these capabilities in order to support their customers. Nothing in their provisioning was particularly relevant to physical emergencies as IP networks already route around failures and handle problems with infrastructure (e.g., backhoe fiber cuts) on a daily basis without customer impact. The conclusion of the discussion was that IEPREP did not have any additional role in defining documents for High Availability Networks. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Jul 29 09:55:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22823 for ; Tue, 29 Jul 2003 09:55:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUw9-0003dD-O1 for ieprep-archive@odin.ietf.org; Tue, 29 Jul 2003 09:54:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TDsj5I013953 for ieprep-archive@odin.ietf.org; Tue, 29 Jul 2003 09:54:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUw9-0003cy-KH for ieprep-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 09:54:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22806 for ; Tue, 29 Jul 2003 09:54:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hUw7-0005fx-00 for ieprep-web-archive@ietf.org; Tue, 29 Jul 2003 09:54:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hUw7-0005fu-00 for ieprep-web-archive@ietf.org; Tue, 29 Jul 2003 09:54:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUvR-0003Zn-JZ; Tue, 29 Jul 2003 09:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUvD-0003ZM-BN for ieprep@optimus.ietf.org; Tue, 29 Jul 2003 09:53:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22776 for ; Tue, 29 Jul 2003 09:53:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hUv8-0005ep-00 for ieprep@ietf.org; Tue, 29 Jul 2003 09:53:42 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 19hUv8-0005el-00 for ieprep@ietf.org; Tue, 29 Jul 2003 09:53:42 -0400 Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 004C767108; Tue, 29 Jul 2003 10:23:51 -0400 (EDT) Date: Tue, 29 Jul 2003 09:53:35 -0400 Subject: Re: [Ieprep] IEPREP Vienna meeting minutes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'ieprep@ietf.org'" To: "King, Kimberly S." From: RJ Atkinson In-Reply-To: Message-Id: <0C3D2BF9-C1CC-11D7-8D25-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday, Jul 29, 2003, at 09:10 America/Montreal, King, Kimberly S. wrote: > Carlberg stub domain presentation > > Berg - wants to know if access links and transit are part of some > IEPREP > document, Scott says within a domain but not in plan to go beyond > single > domain. Desire has been expressed but not enough meet in traction to > go > further. Scott feels the intention is both stub domains and transit > over a > single domain. I'm unable to parse/lex: "Desire has been expressed but not enough meet in traction to go further." Which desire was expressed ? What does "not enough meet in traction" mean ? Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jul 31 15:27:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10340 for ; Thu, 31 Jul 2003 15:27:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ59-0001CE-56 for ieprep-archive@odin.ietf.org; Thu, 31 Jul 2003 15:27:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VJRN17004598 for ieprep-archive@odin.ietf.org; Thu, 31 Jul 2003 15:27:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ59-0001C5-16 for ieprep-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 15:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10260 for ; Thu, 31 Jul 2003 15:27:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iJ57-0006nD-00 for ieprep-web-archive@ietf.org; Thu, 31 Jul 2003 15:27:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iJ57-0006n1-00 for ieprep-web-archive@ietf.org; Thu, 31 Jul 2003 15:27:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ4n-0001Aa-FV; Thu, 31 Jul 2003 15:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ3y-00019n-5H for ieprep@optimus.ietf.org; Thu, 31 Jul 2003 15:26:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10150 for ; Thu, 31 Jul 2003 15:26:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iJ3w-0006lF-00 for ieprep@ietf.org; Thu, 31 Jul 2003 15:26:08 -0400 Received: from chntex04.is.dyncorp.com ([131.131.133.208]) by ietf-mx with esmtp (Exim 4.12) id 19iJ3v-0006lC-00 for ieprep@ietf.org; Thu, 31 Jul 2003 15:26:07 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id <3S5QM9CW>; Thu, 31 Jul 2003 15:24:00 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AAAC@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'ieprep@ietf.org'" Date: Thu, 31 Jul 2003 15:23:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] Telephony Framework document and Megaco Priorities Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , The Telephony Framework document says (about MEGACO): "The protocol does not specify individual values for priority. We also do not recommend the definition of a well known value for the MEGAGO priority. Any values set should be a function of any SLAs that have been established regarding the handling of emergency traffic. In addition, given that priority values denote precedence (according to the Megaco protocol), then by default the ETS telephony data flows should probably receive the same priority as other non- emergency calls. This approach follows the objective of not relying on preemption as the default treatment of emergency-related." But the Megaco document (3525) says "The priority is used for a Context in order to provide the MG with information about a certain precedence handling for a Context." Nothing about preemption. Therefore it seems to me that "denoting precedence" is exactly what we DO want to do in the ETS/TDR context. ---------------------------------------------------------------------------- ------------ 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. ---------------------------------------------------------------------------- ------------ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep

-----Original Message-----
From: RJ Atkinson [mailto:rja@extremenetworks.com]
Sent: Wednesday, July 02, 2003 10:25 AM
To: Janet Gunn
Cc: ieprep@ietf.org
Subject: Re: [Ieprep] IP Bridging Configuration = Guidance for IEPREP Telephony