From ieprep-admin@ietf.org Mon Jul 1 06:38:22 2002 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 GAA22269 for ; Mon, 1 Jul 2002 06:38:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19196; Mon, 1 Jul 2002 06:38:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19160 for ; Mon, 1 Jul 2002 06:38:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22047; Mon, 1 Jul 2002 06:37:35 -0400 (EDT) Message-Id: <200207011037.GAA22047@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: Mon, 01 Jul 2002 06:37:35 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-security-01.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --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 : A Security Framework for Emergency Communications Author(s) : I. Brown Filename : draft-ietf-ieprep-security-01.txt Pages : 16 Date : 28-Jun-02 The Public Switched Telephone Network includes several mechanisms that increase the probability of completion for telephone calls made by authorised disaster relief personnel during emergencies such as hurricanes or terrorist attacks. This memo describes the security requirements of providing this functionality in private and public IP networks, and how these requirements can be met using existing protocols. It also specifies which enhancements are necessary to these protocols to allow enhanced functionality such as roaming access. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-security-01.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-security-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ieprep-security-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20020628142600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-security-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-security-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142600.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailman-owner@ietf.org Mon Jul 1 06:47:57 2002 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 GAA23595 for ; Mon, 1 Jul 2002 06:47:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25235 for ; Mon, 1 Jul 2002 06:48:45 -0400 (EDT) Date: Mon, 1 Jul 2002 06:48:45 -0400 (EDT) Message-Id: <200207011048.GAA25235@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ieprep-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ieprep-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ****************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ****************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ieprep-web-archive@ietf.org: List Password // URL ---- -------- ieprep@ietf.org fPSM https://www1.ietf.org/mailman/options/ieprep/ieprep-web-archive@ietf.org From ieprep-admin@ietf.org Mon Jul 1 07:00:44 2002 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 HAA24844 for ; Mon, 1 Jul 2002 07:00:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00898; Mon, 1 Jul 2002 07:01:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00857 for ; Mon, 1 Jul 2002 07:01:03 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24773 for ; Mon, 1 Jul 2002 07:00:14 -0400 (EDT) Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g61B0wD11797; Mon, 1 Jul 2002 12:00:58 +0100 From: "Alistair Munro" To: "'RJ Atkinson'" , "'senthil ayyasamy'" Cc: "'ieprep'" Subject: RE: doubts (was orginally ..Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt) Date: Mon, 1 Jul 2002 12:03:51 +0100 Message-ID: <005701c220ee$fc216ef0$31281eac@degree2.com> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <5A7ACA0E-8B61-11D6-BE16-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi All, I'm perplexed about the discussion of network deployments in the context of the Baker/beard draft. It appears to have started in a a message (from Ran?) that noted: "An underlying issue with this document is the assumption that backbones might be under-provisioned." I can't see anything in the text to imply this, quite the reverse in fact. Section 1.1 could be reworded to better motivate the use of DiffServ when congestion occurs as a service differentiator supporting a certain QoS model. Maybe, also, the title of the draft should be changed to: Recommended Methods of Service Differentiation in IEPS Using DiffServ I don't get the point of the exchanges on over/under-provisioning, QoS, statmux, etc. I guess you can observe most of the examples mentioned regularly or from time to time, but so what? The value of the draft is that its recommendations will ensure that services continue to operate when congestion *does* occur - if there is no congestion then you can't tell that they are being used. The only major problem I have in practice is that DSCPs are interpreted locally per hop and misconfiguration may make a forwarding element's anti-congestion measures kick in. But this is not something you can assess by measuring backbone/access network loading, and the weakness is mentioned in section 1. and section 3. I would agree that a poorly planned, and/or badly deployed and/or overloaded network does require attention, (probably more money), but this is an operational issue that no number of I-Ds, RFCs, BCPs will address (nor should). Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On > Behalf Of RJ Atkinson > Sent: 29 June 2002 14:09 > To: senthil ayyasamy > Cc: ieprep > Subject: Re: doubts (was orginally ..Re: [Ieprep] > draft-ietf-ieprep-requirements-00.txt) > > > > On Saturday, June 29, 2002, at 12:38 , senthil ayyasamy wrote: > > Service providers overbook their access networks. > > Some providers underprovision ("overbook") their access > networks. Some providers overprovision their access networks. > > Both situations exist in the deployed Internet. As noted > before, I've personally deployed numerous MANs that were > overprovisioned (because it was cheaper to do that than to > deploy/operate QoS). > > > Like how you increase the robustness in the core for supporting > > emergency traffic (as mentioned by you), you can get > service from more > > than one service providers at the cost of increasing the AS > > connectivity complexity for robustness at the access.Will this be a > > factor too ???. > > I can't speak for folks who might want to purchase > IEPREP services, not least because that is a large and very > diverse set of folks, particularly since IETF needs to > consider the issue globally, not just with a US focus. I > doubt that every country will have the same deployment > practices with regards to IEPREP. > > Ran > rja@extremenetworks.com > > > _______________________________________________ > 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 ieprep-admin@ietf.org Mon Jul 1 19:51:28 2002 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 TAA10090 for ; Mon, 1 Jul 2002 19:51:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20978; Mon, 1 Jul 2002 19:50:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20944 for ; Mon, 1 Jul 2002 19:50:55 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10068; Mon, 1 Jul 2002 19:50:05 -0400 (EDT) Received: from FRED-W2K6.cisco.com (dhcp-128-107-163-14.cisco.com [128.107.163.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g61No1hJ004992; Mon, 1 Jul 2002 16:50:01 -0700 (PDT) Message-Id: <5.1.1.6.2.20020628085532.02950f30@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 01 Jul 2002 17:28:00 -0700 To: ieprep@ietf.org, agenda@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] Revised Yokohama IEPREP meeting agenda Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org We will have a joint meeting with sipping on Tuesday at the IETF, I believe in the 17:00-18:00 slot, to discuss the issue of applying MLPP etc policy to calls. Per the agenda at http://www.ietf.org/meetings/agenda_54.html, we have two slots, at 15:30 on Wednesday and 15:30 on Thursday; the latter has MBONE support. I propose that we plan to spend them so: Wednesday: agenda bashing 5 minutes Fred Baker AD Discussion 15 minutes Scott Bradner draft-ietf-ieprep-security-00.txt 20 minutes Ian Brown draft-ietf-ieprep-requirements-00.txt 20 minutes Hal Folts, Cory Beard draft-ietf-ieprep-framework-02.txt 20 minutes Ken Carlberg draft-carlberg-ieprep-elastic-requirements-00.txt 20 minutes Ken Carlberg ---------- 100 minutes Thursday: draft-schulzrinne-ieprep-resource-req-00.txt 20 minutes Henning Schulzrinne draft-berg-ieprep-sip-isup-gap-analysis-00.txt 20 minutes Janet Gunn, Dennis Berg draft-ietf-ieprep-packet-marking-policy-00.txt 20 minutes Fred Baker draft-ietf-ieprep-reflexive-dscp-00.txt 10 minutes Fred Baker, Rei Atarashi T&C Draft directions 10 minutes Ian Brown ---------- 80 minutes Depending on how timing goes (I suspect the timings suggested are "optimistic" in some cases) we may get into these drafts draft-talauliker-ieprep-diffserv-00.txt draft-ayyasamy-ieprep-isp-recommend-00.txt By "discuss", I mean just that - I am expecting no presentations at this meeting per se, but rather for the document authors to lead a discussion of their draft looking for holes and general sign-off. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jul 2 17:01:09 2002 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 RAA15209 for ; Tue, 2 Jul 2002 17:01:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23651; Tue, 2 Jul 2002 16:56:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23617 for ; Tue, 2 Jul 2002 16:56:40 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14873 for ; Tue, 2 Jul 2002 16:55:51 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 16:55:19 -0400 Message-ID: From: "Gunn, Janet NE" To: "'Fred Baker'" , senthil ayyasamy Cc: ieprep@ietf.org Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy -00.txt Date: Tue, 2 Jul 2002 16:55:09 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org I am slightly confused. Are you proposing a mapping between "user class" and "traffic class"? And if you have a session between users of different user classes, is the class for the traffic based on the class of the sender? The class of the receiver? The "max" of the sender and receiver? The "min"? Or is that a case by case policy, based on each user's SLA? Does a particular user always have the same class? (For instance, under GETS, the same authorized user can choose whether to make a GETS call or a non-GETS call. This SHOULD be based on two criteria- Am I experiencing congestion? Is this an emergency related call? If you make ALL CALLS from an "authenticate ETS user" have a particular (privileged in some way) class, this is an inherently different approach.) None of this was explicitly clear to me in reading the document, and I confess I had difficulty figuring out what it had to do with emergency services. After reading the email exchanges it is clearer, but that needs to be clarified in the document. Janet -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Wednesday, June 26, 2002 11:15 AM To: senthil ayyasamy Cc: ieprep@ietf.org Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt At 02:37 AM 6/26/2002 -0700, senthil ayyasamy wrote: >DSCP used from X-->Y >and Y-->X can be different. they certainly can, and right now usually are. But service providers deploying diffserv tell me that this is not necessarily the service they want to offer. They want to be able to offer varying grades of service to users paying varying amounts of money. > I misunderstood that the whole work is *ONLY* to >maintain same DSCP on both directions. yes, and also to say what that DSCP is based on some concept of user class. If, for example, I have a user class which is "authenticated ETS user" and another user class which is "random person", the traffic in the first class might go as AF11 and the second as AF12 (same queue, slightly more prone to loss). not that this would be important in a group such as this :^) _______________________________________________ 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 ieprep-admin@ietf.org Tue Jul 2 17:26:39 2002 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 RAA16417 for ; Tue, 2 Jul 2002 17:26:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25473; Tue, 2 Jul 2002 17:27:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25441 for ; Tue, 2 Jul 2002 17:27:01 -0400 (EDT) Received: from web20803.mail.yahoo.com (web20803.mail.yahoo.com [216.136.226.192]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16385 for ; Tue, 2 Jul 2002 17:26:11 -0400 (EDT) Message-ID: <20020702212658.52497.qmail@web20803.mail.yahoo.com> Received: from [134.193.24.37] by web20803.mail.yahoo.com via HTTP; Tue, 02 Jul 2002 14:26:58 PDT Date: Tue, 2 Jul 2002 14:26:58 -0700 (PDT) From: senthil ayyasamy Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy -00.txt To: "Gunn, Janet NE" , "'Fred Baker'" Cc: ieprep@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org This is my understanding from the draft: *The whole purpose of Reflexive DSCP policy is to suggest ways for accomodating bi-directional flows in a diffserv domain ( which is uni-directional). Bi-directional communication is very necessary for emergency services.* --- "Gunn, Janet NE" wrote: > I am slightly confused. Are you proposing a mapping > between "user class" > and "traffic class"? > > And if you have a session between users of different > user classes, is the > class for the traffic based on the class of the > sender? The class of the > receiver? The "max" of the sender and receiver? The > "min"? Or is that a case > by case policy, based on each user's SLA? Does a > particular user always > have the same class? > (For instance, under GETS, the same authorized user > can choose whether to > make a GETS call or a non-GETS call. This SHOULD be > based on two criteria- > Am I experiencing congestion? > Is this an emergency related call? > > If you make ALL CALLS from an "authenticate ETS > user" have a particular > (privileged in some way) class, this is an > inherently different approach.) > > None of this was explicitly clear to me in reading > the document, and I > confess I had difficulty figuring out what it had to > do with emergency > services. After reading the email exchanges it is > clearer, but that needs > to be clarified in the document. > > Janet > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, June 26, 2002 11:15 AM > To: senthil ayyasamy > Cc: ieprep@ietf.org > Subject: Re: [Ieprep] I-D > ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt > > > At 02:37 AM 6/26/2002 -0700, senthil ayyasamy wrote: > >DSCP used from X-->Y > >and Y-->X can be different. > > they certainly can, and right now usually are. But > service providers > deploying diffserv tell me that this is not > necessarily the service they > want to offer. They want to be able to offer varying > grades of service to > users paying varying amounts of money. > > > I misunderstood that the whole work is *ONLY* > to > >maintain same DSCP on both directions. > > yes, and also to say what that DSCP is based on some > concept of user class. > If, for example, I have a user class which is > "authenticated ETS user" and > another user class which is "random person", the > traffic in the first class > might go as AF11 and the second as AF12 (same queue, > slightly more prone to > loss). > > not that this would be important in a group such as > this :^) > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep ===== Ayyasamy Senthilkumar M.S.(Computer Networking) UMKC,MO. ----------------------------- An expert is a man who has made all the mistakes that can be made in a very narrow field. --Niels Bohr. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jul 2 18:12:32 2002 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 SAA18750 for ; Tue, 2 Jul 2002 18:12:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27739; Tue, 2 Jul 2002 18:05:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27705 for ; Tue, 2 Jul 2002 18:05:57 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18458 for ; Tue, 2 Jul 2002 18:05:09 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g62M5KhJ011970; Tue, 2 Jul 2002 15:05:20 -0700 (PDT) Message-Id: <5.1.1.6.2.20020702150349.027afb58@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 02 Jul 2002 15:05:16 -0700 To: "Gunn, Janet NE" From: Fred Baker Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy -00.txt Cc: ieprep@ietf.org In-Reply-To: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 04:55 PM 7/2/2002 -0400, Gunn, Janet NE wrote: >I am slightly confused. Are you proposing a mapping between "user class" >and "traffic class"? I am proposing traffic classes, and figure that an authenticated user can make sure that s/he is in the "committed" portion of the traffic class. I have yet to see a substantiated argument for user class as a separate DSCP, or an internet draft suggesting that a user class should get its own DSCP. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 3 00:05:45 2002 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 AAA02925 for ; Wed, 3 Jul 2002 00:05:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16450; Wed, 3 Jul 2002 00:01:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16416 for ; Wed, 3 Jul 2002 00:01:44 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02814 for ; Wed, 3 Jul 2002 00:00:55 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 00:00:29 -0400 Message-ID: From: "Gunn, Janet NE" To: "'Fred Baker'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy -00.txt Date: Wed, 3 Jul 2002 00:00:18 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org OK. What, if anything, is the expected relationship between these traffic classes, and preferential "call admission" treatment? It seems (at least on the surface) that a "call" in a traffic class that requires "committed" bandwidth would have a smaller chance of being accepted (than a "call" of a traffic class that will accept "non-comitted" bandwidth). So we would still need some way to identify "calls" that need preferential treatment for call admission. You seem to be suggesting (and it is certainly the intuititive expectation) that the ETS traffic class should have more committed bandwidth than ordinary traffic. But it has been suggested by someone else that (under at least some circumstances) Emergency traffic calls should be allowed to drop MORE packets without dropping the "call". I guess that is "policy" rather than protocol, and identifying traffic classes would allow you to do either. Janet -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Tuesday, July 02, 2002 6:05 PM To: Gunn, Janet NE Cc: ieprep@ietf.org Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy -00.txt At 04:55 PM 7/2/2002 -0400, Gunn, Janet NE wrote: >I am slightly confused. Are you proposing a mapping between "user class" >and "traffic class"? I am proposing traffic classes, and figure that an authenticated user can make sure that s/he is in the "committed" portion of the traffic class. I have yet to see a substantiated argument for user class as a separate DSCP, or an internet draft suggesting that a user class should get its own DSCP. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 3 01:15:39 2002 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 BAA05099 for ; Wed, 3 Jul 2002 01:15:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26916; Wed, 3 Jul 2002 01:14:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26867 for ; Wed, 3 Jul 2002 01:14:06 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05058 for ; Wed, 3 Jul 2002 01:13:15 -0400 (EDT) Received: from FRED-W2K6.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with SMTP id g635DRhJ019841; Tue, 2 Jul 2002 22:13:27 -0700 (PDT) Message-Id: <5.1.1.6.2.20020702221056.025b3220@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 02 Jul 2002 22:13:26 -0700 To: "Gunn, Janet NE" From: Fred Baker Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy -00.txt Cc: ieprep@ietf.org In-Reply-To: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 12:00 AM 7/3/2002 -0400, Gunn, Janet NE wrote: >OK. > >What, if anything, is the expected relationship between these traffic >classes, and preferential "call admission" treatment? The only calls I know of are in VoIP and video. in that case, you get bandwidth or you doin't in the admission process; once you have bandwidth, you have bandwidth, and there is no requirement for a separate data stream type. The ones that have committed bandwidth - AF classes - don't have calls. They are internet data. They have SLAs, and if your SLA requires you to get a certain committed and a certain excess bandwidth, other traffic would become excess so yours would be committed - just like Frame Relay. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 3 15:32:54 2002 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 PAA02157 for ; Wed, 3 Jul 2002 15:32:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07610; Wed, 3 Jul 2002 15:32:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07583 for ; Wed, 3 Jul 2002 15:32:27 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02069 for ; Wed, 3 Jul 2002 15:31:37 -0400 (EDT) Received: from FRED-W2K6.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with SMTP id g63JVkhJ025343; Wed, 3 Jul 2002 12:31:46 -0700 (PDT) Message-Id: <5.1.1.6.2.20020703114609.01afee98@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 03 Jul 2002 12:31:44 -0700 To: "Gunn, Janet NE" , ieprep@ietf.org From: Fred Baker Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy -00.txt In-Reply-To: <5.1.1.6.2.20020702221056.025b3220@mira-sjcm-4.cisco.com> References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 10:13 PM 7/2/2002 -0700, Fred Baker wrote: >The only calls I know of are in VoIP and video. in that case, you get >bandwidth or you doin't in the admission process; once you have bandwidth, >you have bandwidth, and there is no requirement for a separate data stream >type. > >The ones that have committed bandwidth - AF classes - don't have calls. >They are internet data. They have SLAs, and if your SLA requires you to >get a certain committed and a certain excess bandwidth, other traffic >would become excess so yours would be committed - just like Frame Relay. Let me clarify, because in making a reference to Frame Relay I was picking up on some points and dropping others, and probably really confused you. The model behind EF is that of a constant bit rate circuit. In extending it to use AF services in video, the intent is to make a VBR circuit - AF provides the counterpart to the CLP flag in ATM. In both cases, however, there are three requirements: - the network has to agree that a particular call should get a certain bandwidth (done through admission - SIP or RSVP), - it needs to ensure that admitted traffic gets minimal jitter or delay (done through queuing - diffserv) - it needs to ensure that unadmitted traffic cannot abuse that service (done through policing) One question, relevant to Mike Pierce's proposals, has to do with why the admission might be done using SIP or RSVP vs using a separate DSCP. That comes down to how one determines whether someone is authorized to use a certain DSCP. I can check that once and put the result into a access control list, or I can verify on every packet. I think you'll agree it wants to be checked once. That is, almost in its definition, the process of admission. Let's talk a little about GETS and similar functions. When you place a telephone call using a circuit network, you touch some buttons, and a switch decides whether you should get the call (admission). If it admits you, you don't get a special circuit; you get a circuit like any other circuit, although it may have interesting routing. When you place a telephone call using at ATM network, you similarly talk to a switch (admission) to route the CBR circuit that will carry the AAL2 data stream, but once it is routed, the CBR stream isn't any different than any other CBR stream - it is just a CBR stream. In both cases, there are questions of potentially preempting another circuit or CBR VC, of taking reserved bandwidth because you are authorized to do so, routing through a network that is not available to other calls, or being held a few seconds to get access to the bandwidth of the next person to hang up the phone. I submit that IP's EF service is most similar to the ATM case. You are going to admit or not admit the call, and there may be some interesting things done to enhance the probability of accepting the call. But once the call as been admitted, it has the bandwidth it needs. There is no reason to have a separate mark on the data, any more than there is a need to have a special kind of CBR circuit for emergency AAL2 traffic in an ATM network. The requirement simply doesn't exist. Mark it EF(voice) or AF4(video), as I have suggested, and you are done. The model behind AF (RFC 2597) is that there is a service level agreement which, at minimum, says that traffic might arrive at any rate, and will be divided into two or more subsets with different markings. The expectation in that RFC is that this will be rate-based - traffic arriving at an edge device (what Frame Relay or ATM would call the DCE), which might be the router in front of the end system, or might be the edge interface on an ISP, or a number of other places, is measured according to its arrival rate, and at most bps of traffic is marked "committed", at most is marked with the next level, and so on until one runs out of levels. At any point in the network where congestion occurs, an active queue management such as Weighted RED is applied which results in packet marking (ECN) or loss being sent back to the sources sending at the highest rates, to get them to moderate their transmission. Relevant references include RFCs 3168, 2309, 2581, and 2582. This is like Frame Relay up to this point; it is explicitly designed on Frame Relay's DE service and on ATM's VBR services. It differs from those in that there is no concept of a circuit in a connectionless network, but the model works reasonably well. What I would do, to modify that for ETS from a generalized source, is say that the traffic accepted into the "committed" subset includes at most bps, and by definition it includes traffic from/to authenticated and authorized systems. There is an interesting question on how the authentication takes place, but the point here is that their traffic is accepted as committed, potentially pushing other traffic to the "excess" position. That said, it has not been shown, at least to my satisfaction, that Internet sources and sinks operate on the same basis as telephone system sources and sinks. I don't think folks randomly wander in and place calls, other than in a telephony environment. There is instant messaging, which at least as it exists today is largely a corporate offering entirely within AOL, Yahoo, or whoever, and those corporations can do things they deem appropriate. There are e911 services at web sites, and those web sites can prioritize things as they please. There is use of the Internet backbone for a variety of functions, but I don't see statistical evidence that the backbone itself becomes significantly congested, even under extreme load and in the presence of tens of simultaneous fiber cuts. What becomes congested is access links (loss and delay) and servers (flash crowds, thrashing). The servers can prioritize their user's sessions as they will; that is not a traffic issue and has no bearing on this document. In the access links, the issue is essentially what traffic is more subject to delay or loss, and the servers and the edge routers are in a position to manage that within the diffserv architecture. But at the end of the day, the issue is whether a particular instance of an application will get certain service, or get less service, and exactly what service it needs. The diffserv architecture focuses on this "how to best serve the application" in describing a per-hop behavior. If you want a DSCP for a class of user, here's what I need. Go read RFC 3246, 2597, and 2474, and see what goes into an analysis of a per-hop behavior. Then come up with an internet draft that describes exactly what you expect the router to do on a per-packet basis because you happen to be an authenticated user. Do simulations and live fire tests, as have been done by myself and others in researching these PHBs, to demonstrate that they actually do what you expect them to do. I, being one who has contributed to each of those RFCs and has some experience in doing this, think you will find this hard to do without knowledge of the application, and in the end I think you might agree that the approach I have taken is actually best for the individual and the total traffic. This is not intended to be a put-down or an arrogant statement, though it may come across as one. I'm telling you that you are coming from some premises that IMHO don't necessarily hold water, and the proposers of that model have not actually done the work to demonstrate their case. That is partly why it took so long to charter the working group, and why the current set of drafts don't reflect the user model you expect. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 3 16:31:41 2002 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 QAA05318 for ; Wed, 3 Jul 2002 16:31:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12237; Wed, 3 Jul 2002 16:32:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12207 for ; Wed, 3 Jul 2002 16:32:13 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05312 for ; Wed, 3 Jul 2002 16:31:25 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA14782; Wed, 3 Jul 2002 13:31:08 -0700 (PDT) Message-Id: <4.1.20020703152642.09f0b698@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 03 Jul 2002 15:31:02 -0500 To: goldmans@agcs.com, Ken Carlberg From: "James M. Polk" Subject: Re: [Ieprep] comments on draft-schulzrinne-ieprep-resource-req Cc: ieprep@ietf.org In-Reply-To: <3D1F6B26.35EE57E9@agcs.com> References: <13214.1025432944@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 01:33 PM 6/30/2002 -0700, Stuart (Stu) Goldman wrote: >Ken, > >You make an excellent point. If we were to attempt to replicate in >detail security requirements/issues in each and every document, it is likely >that the text would be slightly different as the security requirements >evolved. By pointing to a single source one avoids the unintended differences. I believe this can easily be referenced in the next rev of this ID, as well the text separating the motivation for the RP Header mechanism (the original request of the Chair and AD for this ID) from the requirement of its usage within IEPREP - if this effort passes through the meat-grinder of our upcoming Yokohama meeting on enough of a positive note :-/ > >Ken Carlberg wrote: > >> > -Also, I think that the requirement implied in number 3 is cumbersome >> > and poorly stated. >> > what is the requirement here? is this a requirement that session setup >> > via SIP may need appropriate QoS marked or requested? if it is, say so >> > directly. >> >> as I read the draft, items 1 through 4 of the Introduction seemed more >> aimed at providing motivation for the R-P mechanism, as opposed to >> requirements. after points 1-4, actual requirements are stated. one >> thing that may help is to divide the Intro section into two parts: >> 1. Introduction, and 2. Requirements >> >> > - the security requirements are WAY underspecified. >> >> would it be possible to simply point to Ian Brown's draft >> and expand it if necessary to address >> the security concerns you may have? my personal view is that I would be >> a bit weary of placing a lot of security work in a requirements doc >> for a labeling mechanism. mind you, I'm not saying that security is >> a non-issue (actually, its quite critical). but I think because we have >> a number of drafts that need to address the subject, it would be easier to >> have consensus on a single document as opposed to trying to replicate in >> detail security requirements/issues in each and every document. >> >> my 2 cents, >> >> -ken >> >> _______________________________________________ >> Ieprep mailing list >> Ieprep@ietf.org >> https://www1.ietf.org/mailman/listinfo/ieprep > ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Senior Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jul 4 14:23:24 2002 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 OAA22521 for ; Thu, 4 Jul 2002 14:23:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01224; Thu, 4 Jul 2002 13:20:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01194 for ; Thu, 4 Jul 2002 13:20:46 -0400 (EDT) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21549 for ; Thu, 4 Jul 2002 13:19:57 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <3C2RMKJ0>; Thu, 4 Jul 2002 13:20:45 -0400 Message-ID: From: "Folts, Harold" To: "'RJ Atkinson'" , ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Thu, 4 Jul 2002 13:20:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Friday, June 28, 2002 4:39 PM > To: ieprep > Subject: [Ieprep] draft-ietf-ieprep-requirements-00.txt > > > > An underlying issue with this document is the > assumption that backbones might be under-provisioned. > > Many large backbones are in fact over-provisioned. > That is, they have more capacity than they have maximum > potential offered load. In many cases, this capacity is built > on multiple wide-area SONET rings, so that even an earthquake > or smallish tactical nuclear bombs would not cause them to be > underprovisioned.[1] This may be the case today, but I do not think we can assume this indefinitely. As usage expands, service providers may not invest in continued bandwidth expansion, but will put the increased revenues to the bottom line like most profitable business will do. > > In such a network, QoS is not really a meaningful > concept. It seems to me that an operator with such a network > might well be able to provide the services desired for IEPREP > without making any special provisions in their network (other > than ensuring robust overprovisioning continues to be the case). Again good for today, but for serious disaster situations, we have to consider the doomsday scenario as a practical matter. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jul 4 20:17:22 2002 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 UAA28174 for ; Thu, 4 Jul 2002 20:17:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17183; Thu, 4 Jul 2002 20:17:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17148 for ; Thu, 4 Jul 2002 20:17:22 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28166 for ; Thu, 4 Jul 2002 20:16:32 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 8218C67103; Thu, 4 Jul 2002 20:54:58 -0400 (EDT) Date: Thu, 4 Jul 2002 20:16:49 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep To: "Folts, Harold" From: RJ Atkinson In-Reply-To: Message-Id: <7FD5A4DE-8FAC-11D6-82FD-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Thursday, July 4, 2002, at 01:20 PM, Folts, Harold wrote: > This may be the case today, but I do not think we can assume this > indefinitely. As usage expands, service providers may not invest in > continued bandwidth expansion, but will put the increased revenues to > the > bottom line like most profitable business will do. Hal, The backbones that I know of that are over-provisioned are over-provisioned because that is the profitable approach. That is, they've done the math and it is cheaper to over-provision than to have a congested backbone. The economic trends are such that this is becoming even more profitable than it was several years ago. So your belief that they will under-provision their core backbones flies in the face of all available economic data and their general goal of profitability for IP backbones. (To pick one example, cost of a 10 Gbps interface dropped in about half during the past 18 months -- directly due to the presence of 10 GigE, which can be carried in a WAN via various DWDM systems. WAN dark fibre costs are also a lot lower today than several years ago.) Note well that I distinguish a core backbone from an access network throughout this thread. > Again good for today, but for serious disaster situations, we have to > consider the doomsday scenario as a practical matter. You missed the point entirely, I'm afraid. The over-provisioned backbones I know of can put the *whole max load* on a single trunk (and have path diverse trunks in parallel). So there is no "partial failure" mode possible that would create congestion in the core backbone. They've either got at least one path still up in a disaster (in which case that one path has sufficient capacity to handle max offered load) or they have no path up. In either scenario, QoS is simply not useful. Again, access networks today tend to be different and tend to be under-provisioned -- but most usually the under-provisioned segments do not belong to real Tier-1 ISPs, but rather to smaller regional ISPs. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jul 4 21:07:41 2002 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 VAA28717 for ; Thu, 4 Jul 2002 21:07:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19044; Thu, 4 Jul 2002 21:05:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19007 for ; Thu, 4 Jul 2002 21:05:14 -0400 (EDT) Received: from web20807.mail.yahoo.com (web20807.mail.yahoo.com [216.136.226.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28683 for ; Thu, 4 Jul 2002 21:04:24 -0400 (EDT) Message-ID: <20020705010514.75644.qmail@web20807.mail.yahoo.com> Received: from [134.193.6.40] by web20807.mail.yahoo.com via HTTP; Thu, 04 Jul 2002 18:05:14 PDT Date: Thu, 4 Jul 2002 18:05:14 -0700 (PDT) From: senthil ayyasamy Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt To: RJ Atkinson , "Folts, Harold" Cc: ieprep In-Reply-To: <7FD5A4DE-8FAC-11D6-82FD-00039357A82A@extremenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Let me provide some facts to butteress Ran's points. I am talking only about the core networks. 1. All the tier-1 service providers use over-provisioing for a healthy core. Even if they use QoS technologies, it is used as a secondary option. 2. ISP's using MPLS and related technologies tend to use only explicit routing option which requires manual configuration. I dont think this will be of much use to emergency service unless otherwise you reserve that explict path for emergency use. 3. Also one cannot easily give priority by manipulating OSPF weights. over-provisioning is the base condition for employing such techniques. Service providers recompute weights only when some new routers are introduced to re-adjust the whole topology. So providing priority by OSPF weight optimization is also ruled out. 4. Dynamic QoS routing schemes: One can do academic research on possible use of QoS routing schemes for giving priority and pre-emption. But the fact still remains that *QoS routing is the much researched and nill implemented technique*. The simple reason being people often prefer manual configurations than complex QoS mechanisms. 5. Diffserv mechanisms: I am not aware of its deployment details. But this might be a possible place for use. But still it will be useful only at the access as the core tend to be over-provisioned. I think both requirement draft and fred's draft suggests over-provisioning as a possible technique. So the problem is only at the access. Most of the IEPREP outputs will be most applicable for access providers only. As for as transit is concerned, I am little hesistant. Some persons in this list have commented that service providers has a tendeny to keep the congestion at the transit. But as ran said, transit is also over-provisioned and IETF cannot suggest any recommendation for transit as such. > The backbones that I know of that are > over-provisioned are > over-provisioned because that is the profitable > approach. That is, > they've done the math and it is cheaper to > over-provision than > to have a congested backbone. The economic trends > are such that > this is becoming even more profitable than it was > several years ago. > > So your belief that they will under-provision their > core > backbones flies in the face of all available > economic data > and their general goal of profitability for IP > backbones. > (To pick one example, cost of a 10 Gbps interface > dropped in about half > during the past 18 months -- directly due to the > presence of 10 GigE, > which can be carried in a WAN via various DWDM > systems. WAN dark > fibre costs are also a lot lower today than several > years ago.) > > Note well that I distinguish a core backbone from > an access > network throughout this thread. > > > Again good for today, but for serious disaster > situations, we have to > > consider the doomsday scenario as a practical > matter. > > You missed the point entirely, I'm afraid. The > over-provisioned > backbones I know of can put the *whole max load* on > a single trunk (and > have > path diverse trunks in parallel). So there is no > "partial failure" mode > possible that would create congestion in the core > backbone. They've > either got > at least one path still up in a disaster (in which > case that one path has > sufficient capacity to handle max offered load) or > they have no path up. > In either scenario, QoS is simply not useful. > > Again, access networks today tend to be different > and tend to be > under-provisioned -- but most usually the > under-provisioned segments > do not belong to real Tier-1 ISPs, but rather to > smaller regional ISPs. > > Ran > rja@extremenetworks.com > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jul 4 21:20:13 2002 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 VAA28853 for ; Thu, 4 Jul 2002 21:20:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19296; Thu, 4 Jul 2002 21:12:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19262 for ; Thu, 4 Jul 2002 21:12:16 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28775 for ; Thu, 4 Jul 2002 21:11:26 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 2232867103; Thu, 4 Jul 2002 21:49:54 -0400 (EDT) Date: Thu, 4 Jul 2002 21:11:44 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "Folts, Harold" , ieprep To: senthil ayyasamy From: RJ Atkinson In-Reply-To: <20020705010514.75644.qmail@web20807.mail.yahoo.com> Message-Id: <2BFC4B75-8FB4-11D6-82FD-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Thursday, July 4, 2002, at 09:05 PM, senthil ayyasamy wrote: > But as ran said, transit is also > over-provisioned and IETF cannot suggest any > recommendation for transit as such. To be clear, I said that in many cases transit is also over-provisioned, particularly so with private peering (which is now dominant over exchange points as a way Tier-1s exchange traffic among themselves). I am not omniscient, so I've tried to be careful not to claim that all core links or all core transit is over-provisioned even among the Tier-1 operators. For some Tier-1s I believe that they really do over-engineer, based on knowledge of their networks and practices, for other Tier-1 operators I'm not as well informed as for the first set. However, this misses my main original point, which is that QoS is a mechanism and is not a requirement. The requirement is "availability" and there are several mechanism an operator might choose to meet that requirement, including but not limited to QoS, over-engineering, or other methods. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jul 4 21:23:34 2002 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 VAA28899 for ; Thu, 4 Jul 2002 21:23:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19494; Thu, 4 Jul 2002 21:23:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19459 for ; Thu, 4 Jul 2002 21:23:07 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28880 for ; Thu, 4 Jul 2002 21:22:17 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g651N4q18268 for ieprep@ietf.org; Thu, 4 Jul 2002 21:23:04 -0400 (EDT) Date: Thu, 4 Jul 2002 21:23:04 -0400 (EDT) From: Scott Bradner Message-Id: <200207050123.g651N4q18268@newdev.harvard.edu> To: ieprep@ietf.org Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org I think that Ran may well be right about the current architecture of large U.S. ISPs (significantally over provisioned backbones) since it agrees with what I have been told by people involved in managing some of those backbones but I am not sure that Ran being right on this has much impact on teh world that ieprep needs to worry about. As Ran points out, access networks are frequently under-provisioned as do the networks of smaller US and some non-US ISPs ieprep has to assume that the networks over which ieprep services will be needed are not all over provisioned and may be congested. That congestion might or might not be generated by some emergency situation - I'm not sure that makes any diference. Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jul 4 21:25:48 2002 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 VAA29010 for ; Thu, 4 Jul 2002 21:25:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19590; Thu, 4 Jul 2002 21:25:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19554 for ; Thu, 4 Jul 2002 21:25:40 -0400 (EDT) Received: from web20802.mail.yahoo.com (web20802.mail.yahoo.com [216.136.226.191]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28951 for ; Thu, 4 Jul 2002 21:24:50 -0400 (EDT) Message-ID: <20020705012538.12424.qmail@web20802.mail.yahoo.com> Received: from [134.193.6.40] by web20802.mail.yahoo.com via HTTP; Thu, 04 Jul 2002 18:25:38 PDT Date: Thu, 4 Jul 2002 18:25:38 -0700 (PDT) From: senthil ayyasamy Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt To: RJ Atkinson Cc: "Folts, Harold" , ieprep In-Reply-To: <2BFC4B75-8FB4-11D6-82FD-00039357A82A@extremenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > However, this misses my main original point, which > is that QoS > is a mechanism and is not a requirement. The > requirement is > "availability" and there are several mechanism an > operator might > choose to meet that requirement, including but not > limited to QoS, > over-engineering, or other methods. I accept that requirement draft should take no position about a deployment issue and have to be generic. But, cant a requirement draft give some possible examples about mode of deployment? ===== Ayyasamy Senthilkumar M.S.(Computer Networking) UMKC,MO. ----------------------------- An expert is a man who has made all the mistakes that can be made in a very narrow field. --Niels Bohr. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jul 5 11:54:07 2002 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 LAA00996 for ; Fri, 5 Jul 2002 11:54:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08925; Fri, 5 Jul 2002 11:43:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08892 for ; Fri, 5 Jul 2002 11:43:25 -0400 (EDT) Received: from bootstrap.agcs.com (bootstrap.agcs.com [130.131.48.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00170 for ; Fri, 5 Jul 2002 11:42:33 -0400 (EDT) Received: from pxmail2.agcs.com (pxmail2.agcs.com [130.131.52.2]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id IAA00035 for ; Fri, 5 Jul 2002 08:43:21 -0700 (MST) Received: from mkultra ([130.131.166.68]) by pxmail2.agcs.com (Netscape Messaging Server 4.15 pxmail2 Mar 5 2002 15:11:07) with SMTP id GYS90900.89J for ; Fri, 5 Jul 2002 08:43:21 -0700 Received: FROM agcs.com BY mkultra ; Fri Jul 05 08:43:16 2002 -0700 Message-ID: <3D25BEA6.435AA477@agcs.com> Date: Fri, 05 Jul 2002 08:43:34 -0700 From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Folts Harold" CC: "'RJ Atkinson'" , ieprep Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Folks, As an old engineer, I understand the frustration. The requirements given for the Ark were quite specific. So many cubits by so many. Don't worry, if you just follow the specifications all the animals will fit. I believe even the type of wood to be used was specified. Building the Ark would have been much more difficult if the requirements did not include any implementation aspects at all, and just said it needed to be "big enough and strong enough" to hold an unspecified number of animals for an unspecified time during unspecified weather conditions. Until we can get the terrorists to provide details on their pending attacks, we have to work from vague, "unspecified" requirements which lead some of us to try to do the very best we can by installing as much protection as we can envision in the absence of a requirement that specifies at what point in the escalating doomsday scenarios it is ok for the system to fail emergency communications. A great deal of money was "wasted" yesterday in the US providing protection against 4th of July attacks that failed to materialize. The people who said that the protection was beyond what was needed were indeed right. I can only say that we are in difficult times and perhaps we too should error a bit more on the side of preparing for more dire scenarios. I would rather "waste" some time and money over hardening, than to find that my emergency communications breakdown during a really, really bad emergency. "Folts, Harold" wrote: > > -----Original Message----- > > From: RJ Atkinson [mailto:rja@extremenetworks.com] > > Sent: Friday, June 28, 2002 4:39 PM > > To: ieprep > > Subject: [Ieprep] draft-ietf-ieprep-requirements-00.txt > > > > > > > > An underlying issue with this document is the > > assumption that backbones might be under-provisioned. > > > > Many large backbones are in fact over-provisioned. > > That is, they have more capacity than they have maximum > > potential offered load. In many cases, this capacity is built > > on multiple wide-area SONET rings, so that even an earthquake > > or smallish tactical nuclear bombs would not cause them to be > > underprovisioned.[1] > > This may be the case today, but I do not think we can assume this > indefinitely. As usage expands, service providers may not invest in > continued bandwidth expansion, but will put the increased revenues to the > bottom line like most profitable business will do. > > > > > In such a network, QoS is not really a meaningful > > concept. It seems to me that an operator with such a network > > might well be able to provide the services desired for IEPREP > > without making any special provisions in their network (other > > than ensuring robust overprovisioning continues to be the case). > > Again good for today, but for serious disaster situations, we have to > consider the doomsday scenario as a practical matter. > > Hal > > _______________________________________________ > 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 ieprep-admin@ietf.org Fri Jul 5 13:32:09 2002 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 NAA05679 for ; Fri, 5 Jul 2002 13:32:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14449; Fri, 5 Jul 2002 13:24:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14416 for ; Fri, 5 Jul 2002 13:24:50 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05339 for ; Fri, 5 Jul 2002 13:23:59 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id 9CB6667103; Fri, 5 Jul 2002 14:02:27 -0400 (EDT) Date: Fri, 5 Jul 2002 13:24:13 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "Folts Harold" , ieprep To: goldmans@agcs.com From: RJ Atkinson In-Reply-To: <3D25BEA6.435AA477@agcs.com> Message-Id: <06640302-903C-11D6-898B-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, July 5, 2002, at 11:43 AM, Stuart (Stu) Goldman wrote: > Building the Ark would have been much > more difficult if the requirements did not include any implementation > aspects > at all, and just said it needed to be "big enough and strong enough" to > hold > an unspecified number of animals for an unspecified time during > unspecified > weather conditions. Stu, The flaw in your analogy is that in this case there are a whole slew of parallel documents that outline various implementation approaches to meeting the requirements. So the proposal is not that implementation approaches be undocumented, but rather that we crisply separate the requirements into one document and the various ideas on implementation approaches into other documents. > Until we can get the terrorists to provide details on their pending > attacks, > we have to work from vague, "unspecified" requirements which lead some > of us > to try to do the very best we can by installing as much protection as > we can > envision in the absence of a requirement that specifies at what point > in the > escalating doomsday scenarios it is ok for the system to fail emergency > communications. That's just bogus in this context. A classic big red herring. In the example on the floor, it doesn't matter which attacks someone uses on a large ISP where each trunk can handle max load for their core. Either there is at least one trunk, in which case there won't be any congestion XOR there are no trunks in which case neither QoS nor anything else will help. If NCS will focus on requirements and give implementers flexibility about how to meet them, then it will surely be lower cost to me as a US taxpayer. In any event, IETF is working on an *international* standard and different countries have very different requirements (e.g. I'm told Swedish requirements do not resemble NCS's requirements particularly closely). If NCS can't bring itself emotionally to work within a framework where we separate requirements from implementation details, then what remains is purely a contractual matter for NCS & contractors AND there is no IETF standards content left so this list can be shutdown. Ran rja@extremenetworks.com PS: I remain impressed by the amount of taxpayer dollars NCS is spending to try to pack this working group. Sad, but impressed. :-( _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jul 5 13:33:17 2002 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 NAA05725 for ; Fri, 5 Jul 2002 13:33:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15219; Fri, 5 Jul 2002 13:33:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15183 for ; Fri, 5 Jul 2002 13:33:19 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05699 for ; Fri, 5 Jul 2002 13:32:29 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id 6C2CD67103; Fri, 5 Jul 2002 14:11:03 -0400 (EDT) Date: Fri, 5 Jul 2002 13:32:49 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep@ietf.org To: Scott Bradner From: RJ Atkinson In-Reply-To: <200207050123.g651N4q18268@newdev.harvard.edu> Message-Id: <39C1F846-903D-11D6-898B-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Thursday, July 4, 2002, at 09:23 PM, Scott Bradner wrote: > ieprep has to assume that the networks over which ieprep services > will be needed are not all over provisioned and may be congested. > That congestion might or might not be generated by some emergency > situation - I'm not sure that makes any diference. Fine, but mechanisms (e.g. QoS) should be discussed in separate documents from the high-level requirements document. Right now we don't have a high-level requirements document -- instead we have a document that claims to be high-level requirements but instead mixes and confuses mechanisms with requirements. This is a serious bug, one which that document's authors seem disinclined to respond to when I raised it in the past. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jul 5 13:56:20 2002 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 NAA07016 for ; Fri, 5 Jul 2002 13:56:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15672; Fri, 5 Jul 2002 13:44:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15637 for ; Fri, 5 Jul 2002 13:44:38 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06214 for ; Fri, 5 Jul 2002 13:43:48 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g65HiYv03235; Fri, 5 Jul 2002 19:44:34 +0200 (MEST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g65HiYP22219; Fri, 5 Jul 2002 19:44:34 +0200 (MEST) Received: from cs.columbia.edu ([139.21.148.232]) by mail-y.mchp.siemens.de with ESMTP id g65HiYJu013986; Fri, 5 Jul 2002 19:44:34 +0200 (MET DST) Message-ID: <3D25DAD3.2030806@cs.columbia.edu> Date: Fri, 05 Jul 2002 13:43:47 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson CC: ieprep Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt References: <06640302-903C-11D6-898B-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit > That's just bogus in this context. A classic big red herring. In > the example > on the floor, it doesn't matter which attacks someone uses on a large > ISP where each > trunk can handle max load for their core. Either there is at least one > trunk, > in which case there won't be any congestion XOR there are no trunks in > which case > neither QoS nor anything else will help. Curiosity item: At least from looking at various big-ISP maps (like the one formerly starting with U), it is quite common that a single POP-to-POP connection is Nxsomething, e.g., NxOC-3 or NxOC192. Thus, it seems at least plausible that there could suddenly M, where M << N and M > 0, parallel links. If these are all in the same fiber bundle or even just wavelengths on the same fiber, this may be unlikely, but I thought that load balancing across (logically) parallel links that are physically diverse was fairly common for quick recovery. Also, for any interesting network, even if overdimensioned, you can take out enough links so that (parts of) the network remain connected, through more than one hop, but at significantly reduced capacity. Are you claiming that all (good) ISPs are designed so that any still-connected network, regardless of which combination of links your adversary can take out, can carry the busy hour load? Henning _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jul 5 15:57:58 2002 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 PAA14345 for ; Fri, 5 Jul 2002 15:57:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21391; Fri, 5 Jul 2002 15:58:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21359 for ; Fri, 5 Jul 2002 15:58:06 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14301 for ; Fri, 5 Jul 2002 15:57:14 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id E30AA67103; Fri, 5 Jul 2002 16:35:49 -0400 (EDT) Date: Fri, 5 Jul 2002 15:57:34 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ieprep To: Henning Schulzrinne From: RJ Atkinson In-Reply-To: <3D25DAD3.2030806@cs.columbia.edu> Message-Id: <72CC362C-9051-11D6-898B-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Friday, July 5, 2002, at 01:43 PM, Henning Schulzrinne wrote: > Are you claiming that all (good) ISPs are designed so that any > still-connected network, > regardless of which combination of links your adversary can take out, > can carry the busy hour load? No, I'm claiming that several existing ISPs are designed today such that any single backbone link can carry the full max offered load across that link (e.g. Atlanta -- Dallas), even if all other parallel links (e.g. Atlanta -- St Louis -- Dallas) are taken out (e.g. by a backhoe cutting a fibre bundle). [1] And typically the NxOC-(speed) links are actually provisioned as N wavelengths on a shared DWDM system using a single shared fibre pair. So if a backhoe hits or a DWDM box fails or a router fails, all of those parallel links drop together. In some cases, the operators are waiting for vendors to ship OC-768 POS interfaces so they can get rid of the 4xOC-192 links used today. I don't see a lot of NxOC-3, NxOC-12, or NxOC-48 links today -- simply because it is usually cheaper (both capital and operating costs) to simply deploy one of the next larger standard OC-(speed) interfaces than to deploy NxOC-(smaller speed) interfaces. But this is all sidebar, the issue is whether QoS is a requirement or a mechanism. I submit that QoS is a mechanism for ensuring availability, not a requirement in and of itself. Ran rja@extremenetworks.com [1] By the way, backhoes appear to be the biggest risk going to Internet connectivity. Most regular attendees of NANOG or such like will agree. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jul 6 13:29:47 2002 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 NAA26168 for ; Sat, 6 Jul 2002 13:29:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19775; Sat, 6 Jul 2002 13:29:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19744 for ; Sat, 6 Jul 2002 13:29:55 -0400 (EDT) Received: from kc-msxproto4.kc.umkc.edu (kc-msxproto4.kc.umkc.edu [134.193.143.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26151 for ; Sat, 6 Jul 2002 13:29:05 -0400 (EDT) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxproto4.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905); Sat, 6 Jul 2002 12:29:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Sat, 6 Jul 2002 12:29:54 -0500 Message-ID: Thread-Topic: [Ieprep] draft-ietf-ieprep-requirements-00.txt Thread-Index: AcIkSob/EzD7jPQLSnGl3yGPUiqBVgAxHYdw From: "Beard, Cory" To: "RJ Atkinson" Cc: X-OriginalArrivalTime: 06 Jul 2002 17:29:54.0915 (UTC) FILETIME=[BE1F3330:01C22512] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA19745 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Friday, July 05, 2002 12:33 PM > Fine, but mechanisms (e.g. QoS) should be discussed in separate > documents from the high-level requirements document. Right now > we don't have a high-level requirements document -- instead we > have a document that claims to be high-level requirements but > instead mixes and confuses mechanisms with requirements. This > is a serious bug, one which that document's authors seem disinclined > to respond to when I raised it in the past. Ran, As one of the authors, I am still unclear about your problems with the requirements document. Let me step through the draft. Section 1 is the introduction. I assume you have no problems with that, since all it does is put the problem in context. Section 2 lists requirements at the highest level - availability, dependability, authorized access, security protection, and privacy. I assume you have no problems with those. These are exactly what you have been saying you want to see. Section 3 seems to be where you have a problem. It does discuss QoS mechanisms, but it starts with, "it is assumed that networks will experience temporary scarcity of resources, especially because of damaged infrastructure and high demand immediately following a disaster. If a service provider employs an over provisioning approach to provide emergency services so that resources are never scarce, some of the following requirements might not be necessary." I do not see why this section would be a problem given that it starts with this caveat that it may only apply to some implementations. Section 4 simply gives providers the *opportunity if they wish* to differentiate their services based on applications or traffic types. I do not see why there should be a problem here. Section 5 lists the policy decisions providers need to make. It does not tell them how to make the decisions, it only requires that they openly describe the policies they are using. No problem here? Section 6 gives some application (not implementation) examples. Section 7 closes. No problem here? I TOTALLY agree with your concerns and perspectives on the issues, but do not understand your objections with the document. It would be very helpful if you could give specific comments about specific sections, instead of generic criticisms. Then we can address your comments and move forward to make appropriate adjustments. Do you think we should we remove Section 3? Should the whole document only be Section 2? Is your only problem just some of the way the introduction is written? Cory Beard _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jul 6 14:53:28 2002 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 OAA28569 for ; Sat, 6 Jul 2002 14:53:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20693; Sat, 6 Jul 2002 13:50:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20660 for ; Sat, 6 Jul 2002 13:50:28 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26703 for ; Sat, 6 Jul 2002 13:49:37 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 22A8667103; Sat, 6 Jul 2002 14:28:20 -0400 (EDT) Date: Sat, 6 Jul 2002 13:49:53 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: "Beard, Cory" From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Saturday, July 6, 2002, at 01:29 PM, Beard, Cory wrote: > As one of the authors, I am still unclear about your problems with the > requirements document. Let me step through the draft. Cory, There is a missing opening section, which I would call SCOPE. The main text in the SCOPE section ought to read something like this: Nothing in this document is applicable to an IP network that does not claim to offer emergency network services. This document describes high-level requirements for IP networks that do claim to offer emergency network services. Examples of emergency network services are provided elsewhere [other document cite]. Possible mechanisms for deploying emergency IP network services are discussed elsewhere [optional: other document citations]. > Section 1 is the introduction. I assume you have no problems with that, > since all it does is put the problem in context. I think it is a bit long and confusing. I also think it confuses telephony issues (e.g. current US GETS) with network issues. I would like to see this improved, but it is not my main concern with your document. > Section 2 lists requirements at the highest level - availability, > dependability, authorized access, security protection, and privacy. I > assume you have no problems with those. These are exactly what you have > been saying you want to see. This section is closer than most, but delves into mechanisms here and there. > Section 3 seems to be where you have a problem. It does discuss QoS > mechanisms, but it starts with, "it is assumed that networks will > experience temporary scarcity of resources, especially because of > damaged infrastructure and high demand immediately following a disaster. > If a service provider employs an over provisioning approach to provide > emergency services so that resources are never scarce, some of the > following requirements might not be necessary." I do not see why this > section would be a problem given that it starts with this caveat that it > may only apply to some implementations. Section 3 should be moved into one or more separate documents, because it does not describe *requirements* but instead describes *mechanisms*. A requirements document ought be just that -- a *requirements* document. This section is too detailed about mechanisms. Section 2 was very much closer to the mark for requirements. > Section 4 simply gives providers the *opportunity if they wish* to > differentiate their services based on applications or traffic types. I > do not see why there should be a problem here. This also should be in a separate document. It is essentially providing some sidebar information from the authors, rather than *requirements* for an IP network operator. > Section 5 lists the policy decisions providers need to make. It does > not tell them how to make the decisions, it only requires that they > openly describe the policies they are using. No problem here? This is not as bad as 3, but it is not clear to me that a provider inherently *needs* to make each of these decisions, particularly if the IEprep service is considered from a global perspective rather than a US-centric perspective. This section seems quite US-centric. > Section 6 gives some application (not implementation) examples. Section > 7 closes. No problem here? Please move Section 6 into a separate document with examples of IEprep applications. I'd suggest combining it with a bunch of the material currently in Section 1. > I TOTALLY agree with your concerns and perspectives on the issues, but > do not understand your objections with the document. Hopefully this note will help. > It would be very helpful if you could give specific comments about > specific sections, instead of generic criticisms. Then we can address > your comments and move forward to make appropriate adjustments. I did offer a fair bit of detail once before, but maybe that note got lost. > Do you think we should we remove Section 3? Should the whole document > only be Section 2? Is your only problem just some of the way the > introduction is written? I've outlined specific changes above. I'll take an editorial pass at the whole thing and see if I can't mail a strawman revised version out later this weekend. Please keep in mind that my concern here is mostly to have the requirements document be clear, thin, and focused. If one feels that it is important to have detailed discussion of other material, that other can better be placed into separate documents (cross-referencing as appropriate). Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun Jul 7 09:24:05 2002 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 JAA21049 for ; Sun, 7 Jul 2002 09:24:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05719; Sun, 7 Jul 2002 09:23:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05685 for ; Sun, 7 Jul 2002 09:23:49 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21035 for ; Sun, 7 Jul 2002 09:22:56 -0400 (EDT) Received: from async101-12.nas.onetel.net.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Sun, 7 Jul 2002 14:23:44 +0100 From: Ian Brown To: ieprep Date: Sun, 7 Jul 2002 14:23:13 +0100 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.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Ieprep] Terms of reference draft Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Unfortunately I didn't have time to get a first pass done on the terms of reference draft before the ID cutoff date. But so that everyone can see what's happening with it, I've put the current version at http://www.cs.ucl.ac.uk/staff/I.Brown/draft-ietf-ieprep-reference-00.txt Suggestions for other terms that should be included (along with definitions if you like), as well as comments and improvements, are all welcome. I'll then do a proper -00 ID submission after the Yokohama meeting. Thanks, Ian. -- Abstract An Emergency Telecommunications Service gives authorised emergency personnel a higher probability of successful communication under high network load conditions. This document explains the different terms and acronyms used in defining and implementing this service, and is intended to be used as a common basis for negotiations when governments are contracting with telecommunications operators to provide the service. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jul 8 05:14:41 2002 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 FAA08705 for ; Mon, 8 Jul 2002 05:14:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03999; Mon, 8 Jul 2002 05:11:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03970 for ; Mon, 8 Jul 2002 05:11:35 -0400 (EDT) Received: from cygnus.degree2.com (host195-89-159-99.uk.regusnet.com [195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08623 for ; Mon, 8 Jul 2002 05:10:42 -0400 (EDT) Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g689BWD18548; Mon, 8 Jul 2002 10:11:32 +0100 From: "Alistair Munro" To: "'Ian Brown'" , "'ieprep'" Subject: RE: [Ieprep] Terms of reference draft Date: Mon, 8 Jul 2002 10:14:36 +0100 Message-ID: <000101c2265f$e1555610$31281eac@degree2.com> 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, Build 10.0.2627 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Ian, A few comments: 1. "Terms of Reference" is confusing (to me) as a title and objective. What about "Glossary of Terms for Emergency Telecommunications Services"? 2. (Abstract) I wouldn't use it as a "common basis for negotiations" - "list of common terms and their meanings" possibly? It looks as if it will be very useful as a sanity check of things you have to know to be able to tender/procure - can we try to capture this objective somehow? Replace "governments" with "emergency service providers". 3. (Definitions) - assorted niggles, in no particular order: ISUP - The ISUP spec includes several protocols and ISUP is (in my book) an application that sits on top of SCCP (which is also a sort of transport protocol), to support services using ISDN. This will be useful if you pick out what precisely is relevant to ETS, e.g as you do for GSM with MLPP, or refer forwards to the specific use of the reference made in NS/EP. GSM - replace the first sentence by "The family of ETSI standards for 1st generation digital mobile telecommunications, used in many countries around the world for public land mobile networks." ETSI has designed several "wireless telephony" standards. The GSM gurus will be rsing out of their graves even now... DiffServ - delete "scalable". I'm not saying it can't be implemented in a scalable way but the mechanism is fairly limited. PHB - the node applies the PHB to the class identified by the DSCP, which may be defined for several flow aggregates. This may be pedantic but see, e.g., the Annex to the EF RFC. Traffic class - again, the DSCP defines the quality to be given to a packet. The traffic class is a field that can contain a DSCP, i.e. just a packet marking, which *may* relate to an aggregate. SS7 - SS7 is a lot more than a standard for signalling and it is impossible (IMO) to overstate its significance in telecommunications in general - the definition understates its importance. It supports ISDN (q.v.), MAP in GSM, IN functions via TCAP, maintenance of links between switches, etc., etc. It is commonly operated over IP networks these days. I'm not quite sure how to capture this - give me some time to think about it. In general: this is a useful contribution that I hope can be progressed to WG draft quickly. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jul 8 05:28:44 2002 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 FAA08903 for ; Mon, 8 Jul 2002 05:28:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01500; Mon, 8 Jul 2002 04:28:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01466 for ; Mon, 8 Jul 2002 04:28:00 -0400 (EDT) Received: from cygnus.degree2.com (host195-89-159-99.uk.regusnet.com [195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07840 for ; Mon, 8 Jul 2002 04:27:04 -0400 (EDT) Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g688RWD17521; Mon, 8 Jul 2002 09:27:32 +0100 From: "Alistair Munro" To: "'RJ Atkinson'" , "'Beard, Cory'" Cc: Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Mon, 8 Jul 2002 09:30:36 +0100 Message-ID: <000001c22659$bc4ad1c0$31281eac@degree2.com> 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, Build 10.0.2627 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Ran, If you are preparing some detailed changes to this draft than I will hold fire on some other minor wording changes that I wanted to send in. In general and as I have said in the past, I find the draft useful and informative. For an ISP or implementer of emergency services it explains the main issues and would assist in (respectively) responding to, or preparing, an operational requirement. In particular I don't want this to become a set of MUST requirements. I think it is reasonable to refer to standardised solutions and mechanisms, as it may well be a functional requirement to have these mechanisms to implement emergency services. On specific sections: 1. Move 1.1 to 6 (subsection of 6.4?), retitled as GETS - it is an example and is not about "Current PSTN Capabilities". 2. OK. 3. Contrary to your suggestions, I would keep this and rename it "Service Differentiation for Control and Delivery". 3.1, 3.2: "Should" is too strong. Replace with "MAY" 4. Subsume into 3, i.e. 4.1 -> 3.4, 4.2 -> 3.5. Delete introductory paragraph "In addition..." 5. OK by me. We have been into all this US-centric stuff before. I don't find it US-centric at all. 6. OK. 7. OK, 8. Delete - it doesn't add any value to 2.4. As an implementer, I need to have guidance on security, service differentiation, priority/pre-emption at application level, and we are seeing outputs emerging on these. This draft is a good introduction and complement to these specific protocol practices. It should be kept intact. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jul 8 07:42:23 2002 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 HAA10985 for ; Mon, 8 Jul 2002 07:42:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10496; Mon, 8 Jul 2002 07:41:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10462 for ; Mon, 8 Jul 2002 07:41:40 -0400 (EDT) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10967 for ; Mon, 8 Jul 2002 07:40:47 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <3PXK0PZV>; Mon, 8 Jul 2002 07:41:32 -0400 Message-ID: From: "Folts, Harold" To: "'Ian Brown'" , ieprep Subject: RE: [Ieprep] Terms of reference draft Date: Mon, 8 Jul 2002 07:41:31 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Ian Brown [mailto:I.Brown@cs.ucl.ac.uk] > Sent: Sunday, July 07, 2002 9:23 AM > To: ieprep > Subject: [Ieprep] Terms of reference draft > > > Unfortunately I didn't have time to get a first pass done on > the terms of > reference draft before the ID cutoff date. But so that > everyone can see > what's happening with it, I've put the current version at > http://www.cs.ucl.ac.uk/staff/I.Brown/draft-ietf-ieprep-refere > nce-00.txt > > Suggestions for other terms that should be included (along > with definitions > if you like), as well as comments and improvements, are all > welcome. I'll > then do a proper -00 ID submission after the Yokohama meeting. > > Thanks, > > Ian. > -- > Abstract > > An Emergency Telecommunications Service gives authorised emergency > personnel a higher probability of successful communication under > high network load conditions. This document explains the different > terms and acronyms used in defining and implementing this service, > and is intended to be used as a common basis for negotiations when > governments are contracting with telecommunications operators to > provide the service. > > Looks like a good start to this useful effort. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jul 8 09:04:11 2002 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 JAA12807 for ; Mon, 8 Jul 2002 09:04:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14790; Mon, 8 Jul 2002 09:02:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14758 for ; Mon, 8 Jul 2002 09:02:07 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12741 for ; Mon, 8 Jul 2002 09:01:14 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 9B52A67103; Mon, 8 Jul 2002 09:40:08 -0400 (EDT) Date: Mon, 8 Jul 2002 09:01:16 -0400 Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: "Alistair Munro" From: RJ Atkinson In-Reply-To: <000001c22659$bc4ad1c0$31281eac@degree2.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit On Monday, July 8, 2002, at 04:30 AM, Alistair Munro wrote: > I think it is reasonable to refer to standardised solutions and > mechanisms, as it may well be a functional requirement to have these > mechanisms to implement emergency services. I think it is fine to have some example solutions, in separate documents. I object pretty strongly to the standard mandating a particular mechanism because network designs and circumstances vary so widely. > 3. Contrary to your suggestions, I would keep this and rename it > "Service Differentiation for Control and Delivery". > 3.1, 3.2: "Should" is too strong. Replace with "MAY" I don't propose dropping it, but rather moving it into a separate document. > 5. OK by me. We have been into all this US-centric stuff before. I don't > find it US-centric at all. Some other Europeans do find it US-centric. > As an implementer, I need to have guidance on security, service > differentiation, priority/pre-emption at application level, and we are > seeing outputs emerging on these. This draft is a good introduction and > complement to these specific protocol practices. It should be kept > intact. The deployment guidance is fine and useful, but needs to be in separate documents -- so that requirements (i.e. MUST items) are separated from options (i.e. other items). Thanks for your note. It is helpful to have specific understandings of the differences in perspective. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jul 8 09:44:04 2002 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 JAA14324 for ; Mon, 8 Jul 2002 09:44:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17455; Mon, 8 Jul 2002 09:44:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17415 for ; Mon, 8 Jul 2002 09:44:17 -0400 (EDT) Received: from cygnus.degree2.com (host195-89-159-99.uk.regusnet.com [195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14278 for ; Mon, 8 Jul 2002 09:43:25 -0400 (EDT) Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g68DiFD23461; Mon, 8 Jul 2002 14:44:15 +0100 From: "Alistair Munro" To: "'RJ Atkinson'" Cc: Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Mon, 8 Jul 2002 14:47:19 +0100 Message-ID: <001401c22685$fac956c0$31281eac@degree2.com> 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, Build 10.0.2627 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Ran, > > I think it is reasonable to refer to standardised solutions and > > mechanisms, as it may well be a functional requirement to > have these > > mechanisms to implement emergency services. > > I think it is fine to have some example solutions, in > separate documents. I object pretty strongly to the standard > mandating a particular mechanism because network designs and > circumstances vary so widely. > Section 3 seems, (to me), to say packets should (I prefer MAY) be given differential treatment but it does not mandate anything specific - my reading is that the only requirement is to give emergency traffic a better-than-best-effort service and the mechanism is not mandated. However the DSCP marking *is* a standard and if used, SHOULD be used according to best practice. This is one of the sections that I have some alternate words for, pending your own input. > > 3. Contrary to your suggestions, I would keep this and rename it > > "Service Differentiation for Control and Delivery". 3.1, > 3.2: "Should" > > is too strong. Replace with "MAY" > > I don't propose dropping it, but rather moving it into a > separate document. > Sorry, I did not express myself too well. I meant: keep it in this document. Keeping everything together makes for easier maintenance. > > 5. OK by me. We have been into all this US-centric stuff before. I > > don't find it US-centric at all. > > Some other Europeans do find it US-centric. > I would be interested to review any proposed text changes that generalise it. > > The deployment guidance is fine and useful, but needs to be > in separate documents -- so that requirements (i.e. MUST > items) are separated from options (i.e. other items). > I'm happy to see MAYs and SHOULDs in this document, which is, after all, only going to be an Informational RFC. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jul 9 10:34:41 2002 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 KAA26973 for ; Tue, 9 Jul 2002 10:34:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07005; Tue, 9 Jul 2002 10:30:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11347 for ; Mon, 8 Jul 2002 14:33:53 -0400 (EDT) Received: from kc-msxproto2.kc.umkc.edu (kc-msxproto2.kc.umkc.edu [134.193.143.159]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00409 for ; Mon, 8 Jul 2002 14:33:00 -0400 (EDT) Received: from KC-MAIL2.kc.umkc.edu ([134.193.143.162] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 13:33:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: Wednesday June 26th - [Ieprep] I-D ACTION:draft-talauliker-ieprep-diffserv-00.txt Date: Mon, 8 Jul 2002 13:33:44 -0500 Message-ID: Thread-Topic: RE: Wednesday June 26th - [Ieprep] I-D ACTION:draft-talauliker-ieprep-diffserv-00.txt Thread-Index: AcImrf1WveboWE9aR42gnoLmr6SDdw== From: "Talauliker, Salil Ulhas (UMKC-Student)" To: Cc: X-OriginalArrivalTime: 08 Jul 2002 18:33:44.0801 (UTC) FILETIME=[FDBCED10:01C226AD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id OAA11348 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit Dear Dr.Munro, This is in response to you comment below about using DSCP mechanisms for its original purpose dated Wednesday June 26th. > The Talauliker draft seems to be about priority using DSCPs and RED mechanisms. I would prefer to use them > their best advantage in doing what they were designed for without imposing a secondary purpose on them. Priority > a different issue and known to be difficult to resolve. Did I mistake what was written? Sir, I'd like to point out that your comment has the answer to the issue that you raise. I would like to stress the following first: 1. We here at UMKC agree with you that Priority is definitely a difficult issue to resolve. 2. My draft is focussed on Internet Emergency provision issues rather than "Priority" in particular. 3. And I have mentioned in my draft that no current "standard" mechanism exists that treats this problem. 4. The draft is focussed towards providing Priority Treatment in a Diffserv environment using CURRENT available practices. Hence I have proposed the idea of extending the RED mechanism to solve the problem of priority. At the current time this seems to be the best approach in a DIFFSERV domain. The stream of new RED-related papers from Infocom 2002 has strengthened our original belief in RED as a viable option. I would also like to point out that we are not talking about a particular implementation of RED by a firm. Instead we are talking about RED and its variants as known to IETF and the networking community. I appreciate your comments and would like to add that we are open for further comments and suggestions from you. Thanks, Salil Talauliker University of Missouri-Kansas City sut0b6@umkc.edu References: draft-talauliker-ieprep-diffserv-00.txt _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jul 9 10:49:36 2002 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 KAA27600 for ; Tue, 9 Jul 2002 10:49:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08364; Tue, 9 Jul 2002 10:49:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08277 for ; Tue, 9 Jul 2002 10:49:47 -0400 (EDT) Received: from cygnus.degree2.com (host195-89-159-99.uk.regusnet.com [195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27593 for ; Tue, 9 Jul 2002 10:48:54 -0400 (EDT) Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g69EnfD19759; Tue, 9 Jul 2002 15:49:41 +0100 From: "Alistair Munro" To: "'Talauliker, Salil Ulhas \(UMKC-Student\)'" Cc: Subject: RE: Wednesday June 26th - [Ieprep] I-D ACTION:draft-talauliker-ieprep-diffserv-00.txt Date: Tue, 9 Jul 2002 15:52:46 +0100 Message-ID: <005d01c22758$496694a0$31281eac@degree2.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA08280 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit Dear Salil, Thank your for your feedback and observations on my comments. I'm happy to accept your view of the purpose of the draft. My comments on it were concerned with its value as current best practice - I like the ideas in it but I may not get time and resource to do all the study that seems to be implied. There are probably people who know better about this than I do as I have never used RIO and I don't know who implements it. Is there an RFC for it? Do others have comments? Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com > -----Original Message----- > From: Talauliker, Salil Ulhas (UMKC-Student) [mailto:sut0b6@umkc.edu] > Sent: 08 July 2002 19:34 > To: alistair.munro@degree2.com > Cc: ieprep@ietf.org > Subject: RE: Wednesday June 26th - [Ieprep] I-D > ACTION:draft-talauliker-ieprep-diffserv-00.txt > > > Dear Dr.Munro, > > This is in response to you comment below about using DSCP > mechanisms for its original purpose dated Wednesday June 26th. > > > The Talauliker draft seems to be about priority using DSCPs and RED > > mechanisms. I would prefer to use them their best > advantage in doing > > what they were designed for without imposing a secondary purpose on > > them. Priority a different issue and known to be difficult > to resolve. > > Did I mistake what was written? > > Sir, I'd like to point out that your comment has the answer > to the issue that you raise. I would like to stress the > following first: > > 1. We here at UMKC agree with you that Priority is definitely > a difficult issue to resolve. 2. My draft is focussed on > Internet Emergency provision issues rather than "Priority" in > particular. 3. And I have mentioned in my draft that no > current "standard" mechanism exists that treats this problem. > 4. The draft is focussed towards providing Priority Treatment > in a Diffserv environment using CURRENT available practices. > > Hence I have proposed the idea of extending the RED mechanism > to solve the problem of priority. At the current time this > seems to be the best approach in a DIFFSERV domain. The > stream of new RED-related papers from Infocom 2002 has > strengthened our original belief in RED as a viable option. I > would also like to point out that we are not talking about a > particular implementation of RED by a firm. Instead we are > talking about RED and its variants as known to IETF and the > networking community. > > I appreciate your comments and would like to add that we are > open for further comments and suggestions from you. > > Thanks, > > Salil Talauliker > University of Missouri-Kansas City > sut0b6@umkc.edu > > References: draft-talauliker-ieprep-diffserv-00.txt > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jul 9 17:17:59 2002 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 RAA17825 for ; Tue, 9 Jul 2002 17:17:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09854; Tue, 9 Jul 2002 17:18:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09818 for ; Tue, 9 Jul 2002 17:18:19 -0400 (EDT) Received: from web20804.mail.yahoo.com (web20804.mail.yahoo.com [216.136.226.193]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17812 for ; Tue, 9 Jul 2002 17:17:24 -0400 (EDT) Message-ID: <20020709211814.94310.qmail@web20804.mail.yahoo.com> Received: from [134.193.128.30] by web20804.mail.yahoo.com via HTTP; Tue, 09 Jul 2002 14:18:14 PDT Date: Tue, 9 Jul 2002 14:18:14 -0700 (PDT) From: senthil ayyasamy Subject: RE: Wednesday June 26th - [Ieprep] I-D ACTION:draft-talauliker-ieprep-diffserv-00.txt To: Alistair Munro , "'Talauliker, Salil Ulhas \(UMKC-Student\)'" Cc: ieprep@ietf.org In-Reply-To: <005d01c22758$496694a0$31281eac@degree2.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > I have never used RIO and I don't know > who implements it. Is there an RFC for it? Do others > have comments? RIO is an academic work from MIT's lcs lab. Their is an IEEE TON paper on RIO by clark et all. D. Clark, W. Fang, "Explicit Allocation of Best Effort Packet Delivery Service", IEEE/ACM Transactions on Networking, August 1998, Vol 6. No. 4, pp. 362-373. It is widely used as RED with drop precedence. It was used for providing rate adaptation in differentited services [RFC 2963]. It is the base for effective use of many works on three color markers. I have no details with repect to deployment. But analysing emergency service with respect to drop precedence is interesting. It can provide some useful insight to both academic and engineering community for possible use of various AQM variants towards ieprep. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 10 03:03:51 2002 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 DAA23299 for ; Wed, 10 Jul 2002 03:03:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02024; Wed, 10 Jul 2002 03:01:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01992 for ; Wed, 10 Jul 2002 03:01:15 -0400 (EDT) Received: from cygnus.degree2.com (host195-89-159-99.uk.regusnet.com [195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23189 for ; Wed, 10 Jul 2002 03:00:21 -0400 (EDT) Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g6A71AD30721; Wed, 10 Jul 2002 08:01:10 +0100 From: "Alistair Munro" To: "'senthil ayyasamy'" , "'Talauliker, Salil Ulhas \(UMKC-Student\)'" Cc: Subject: RE: Wednesday June 26th - [Ieprep] I-D ACTION:draft-talauliker-ieprep-diffserv-00.txt Date: Wed, 10 Jul 2002 08:02:08 +0100 Message-ID: <001b01c227df$b4ddcbe0$31281eac@degree2.com> 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <20020709211814.94310.qmail@web20804.mail.yahoo.com> Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Senthil, Thanks very much for this. Speaking as an implementer, I feel that output from this group should position itself as far as possible as standalone documents. RFC2963 contains both theory, practice and configurations with minimal need to dig around in the library. If Salil's draft can be extended to include similar detail then I believe that it will be very valuable. Regards, AListair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On > Behalf Of senthil ayyasamy > Sent: 09 July 2002 22:18 > To: Alistair Munro; 'Talauliker, Salil Ulhas (UMKC-Student)' > Cc: ieprep@ietf.org > Subject: RE: Wednesday June 26th - [Ieprep] I-D > ACTION:draft-talauliker-ieprep-diffserv-00.txt > > > > > I have never used RIO and I don't know > > who implements it. Is there an RFC for it? Do others > > have comments? > RIO is an academic work from MIT's lcs lab. Their > is an IEEE TON paper on RIO by clark et all. > > D. Clark, W. Fang, "Explicit Allocation of Best Effort > Packet Delivery Service", IEEE/ACM Transactions on > Networking, August 1998, Vol 6. No. 4, pp. 362-373. > > It is widely used as RED with drop precedence. It was > used for providing rate adaptation in differentited > services [RFC 2963]. It is the base for effective use > of many works on three color markers. > > I have no details with repect to deployment. > > But analysing emergency service with respect to drop > precedence is interesting. It can provide some useful > insight to both academic and engineering community for > possible use of various AQM variants towards ieprep. > > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com > > _______________________________________________ > 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 ieprep-admin@ietf.org Wed Jul 10 10:12:33 2002 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 KAA03414 for ; Wed, 10 Jul 2002 10:12:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27968; Wed, 10 Jul 2002 10:11:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27934 for ; Wed, 10 Jul 2002 10:11:57 -0400 (EDT) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03343 for ; Wed, 10 Jul 2002 10:11:02 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <3PXLBGSQ>; Wed, 10 Jul 2002 10:11:54 -0400 Message-ID: From: "Folts, Harold" To: "'senthil ayyasamy'" Cc: ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Wed, 10 Jul 2002 10:11:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: senthil ayyasamy [mailto:mplsgeek@yahoo.com] > Sent: Friday, June 28, 2002 8:56 PM > To: RJ Atkinson; ieprep > Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt > > Some of the relevant issues: > - At emergency times,if in some case,expected load > exceeds the backbone capacity,how quickly you can > increase the backbone capacity. > If you cannot bring the network to normality within > a short time scale,one have to go for QoS /traffic > engineering options. > > Also,remember we are trying to give priority to > emergency traffic and not create a robust network > which will be a answer to all sort of congestion > problems. > > - Access has the only option of using QoS to > prioritize emergency traffic. > > - one should have a effective co-operation between > service providers to accomodate emergency traffic.This > can be addressed by means of peering or service level agreements only. > These are important points that must be taken into consideration. Overprovisioning is not the single solution. As previsously pointed out in another email to the list, not all networks are over provisioned. Lots of unused bandwidth is widely available so it does not cost any more at the moment to use it for over provisioning. But as traffic demand in the marketplace increases over time, the excess bandwidth will soon disappear. Then it may not be cost effective to expand bandwidth just for over provisioning. Ensuring that emergency recovery communications can get through heavy congestion in timely response to a serious disaster is critically important. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 10 10:17:07 2002 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 KAA03822 for ; Wed, 10 Jul 2002 10:17:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28958; Wed, 10 Jul 2002 10:15:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28925 for ; Wed, 10 Jul 2002 10:15:41 -0400 (EDT) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03663 for ; Wed, 10 Jul 2002 10:14:46 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id <3PXLBGYH>; Wed, 10 Jul 2002 10:15:39 -0400 Message-ID: From: "Folts, Harold" To: "'RJ Atkinson'" Cc: ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Wed, 10 Jul 2002 10:15:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Friday, July 05, 2002 1:24 PM > To: goldmans@agcs.com > Cc: Folts Harold; ieprep > Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt > > (e.g. I'm told Swedish requirements do not > resemble NCS's > requirements > particularly closely). Not in the specification for Sweden's ETS that I have read. I am working closely with many countries in the ITU-T and ETSI on the ETS issues. The basic ETS requirements as they have been stated have an excellent international concensus. > If NCS can't bring itself > emotionally to work > within a > framework where we separate requirements from implementation details, > then what remains > is purely a contractual matter for NCS & contractors AND there is no > IETF standards content > left so this list can be shutdown. Ran, I refer you back to my ID draft-folts-ieprep-requirements-00.txt that we reviewed at the May ieprep interim meeting. There were no suggestions of implementation included. I believe it is exactly what you are looking for. In fact the effective "Scope" at the beginning of the document was very close in context to your suggestion in your email of 28 June. Is this what you want to see in the requirements ID? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 10 10:23:07 2002 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 KAA04076 for ; Wed, 10 Jul 2002 10:23:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29442; Wed, 10 Jul 2002 10:20:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29413 for ; Wed, 10 Jul 2002 10:20:50 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03939 for ; Wed, 10 Jul 2002 10:19:54 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 10:19:03 -0400 Message-ID: From: "Gunn, Janet NE" To: "'Folts, Harold'" , "'senthil ayyasamy'" Cc: ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Wed, 10 Jul 2002 10:18:54 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Do we also have to consider the possibility of "some kind of virus" (terrorist inspired or otherwise) generating a large amount of traffic, and "using up" the overprovisioning? Or is that a red-herring? Janet -----Original Message----- From: Folts, Harold [mailto:foltsh@ncs.gov] Sent: Wednesday, July 10, 2002 10:12 AM To: 'senthil ayyasamy' Cc: ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt > -----Original Message----- > From: senthil ayyasamy [mailto:mplsgeek@yahoo.com] > Sent: Friday, June 28, 2002 8:56 PM > To: RJ Atkinson; ieprep > Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt > > Some of the relevant issues: > - At emergency times,if in some case,expected load > exceeds the backbone capacity,how quickly you can > increase the backbone capacity. > If you cannot bring the network to normality within > a short time scale,one have to go for QoS /traffic > engineering options. > > Also,remember we are trying to give priority to > emergency traffic and not create a robust network > which will be a answer to all sort of congestion > problems. > > - Access has the only option of using QoS to > prioritize emergency traffic. > > - one should have a effective co-operation between > service providers to accomodate emergency traffic.This > can be addressed by means of peering or service level agreements only. > These are important points that must be taken into consideration. Overprovisioning is not the single solution. As previsously pointed out in another email to the list, not all networks are over provisioned. Lots of unused bandwidth is widely available so it does not cost any more at the moment to use it for over provisioning. But as traffic demand in the marketplace increases over time, the excess bandwidth will soon disappear. Then it may not be cost effective to expand bandwidth just for over provisioning. Ensuring that emergency recovery communications can get through heavy congestion in timely response to a serious disaster is critically important. Hal _______________________________________________ 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 ieprep-admin@ietf.org Wed Jul 10 11:16:24 2002 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 LAA06412 for ; Wed, 10 Jul 2002 11:16:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06469; Wed, 10 Jul 2002 11:16:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06435 for ; Wed, 10 Jul 2002 11:16:32 -0400 (EDT) Received: from bootstrap.agcs.com (bootstrap.agcs.com [130.131.48.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06401 for ; Wed, 10 Jul 2002 11:15:35 -0400 (EDT) Received: from pxmail2.agcs.com (pxmail2.agcs.com [130.131.52.2]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id IAA15653 for ; Wed, 10 Jul 2002 08:16:27 -0700 (MST) Received: from mkultra ([130.131.166.68]) by pxmail2.agcs.com (Netscape Messaging Server 4.15 pxmail2 Mar 5 2002 15:11:07) with SMTP id GZ1H3600.FMF for ; Wed, 10 Jul 2002 08:16:18 -0700 Received: FROM agcs.com BY mkultra ; Wed Jul 10 08:16:17 2002 -0700 Message-ID: <3D2C4FCF.43D4A861@agcs.com> Date: Wed, 10 Jul 2002 08:16:31 -0700 From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gunn Janet NE" CC: "'Folts Harold'" , "'senthil ayyasamy'" , ieprep Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Janet, If the purpose of the service is to provide emergency communication during a disaster, including a terrorist attack, I don't think it makes good sense to rule out a coordinated physical attack along with a DDoS and virus, etc. If we can think of it, so can the bad guys. "Gunn, Janet NE" wrote: > Do we also have to consider the possibility of "some kind of virus" > (terrorist inspired or otherwise) generating a large amount of traffic, and > "using up" the overprovisioning? > > Or is that a red-herring? > > Janet > > -----Original Message----- > From: Folts, Harold [mailto:foltsh@ncs.gov] > Sent: Wednesday, July 10, 2002 10:12 AM > To: 'senthil ayyasamy' > Cc: ieprep > Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt > > > -----Original Message----- > > From: senthil ayyasamy [mailto:mplsgeek@yahoo.com] > > Sent: Friday, June 28, 2002 8:56 PM > > To: RJ Atkinson; ieprep > > Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt > > > > Some of the relevant issues: > > - At emergency times,if in some case,expected load > > exceeds the backbone capacity,how quickly you can > > increase the backbone capacity. > > If you cannot bring the network to normality within > > a short time scale,one have to go for QoS /traffic > > engineering options. > > > > Also,remember we are trying to give priority to > > emergency traffic and not create a robust network > > which will be a answer to all sort of congestion > > problems. > > > > - Access has the only option of using QoS to > > prioritize emergency traffic. > > > > - one should have a effective co-operation between > > service providers to accomodate emergency traffic.This > > can be addressed by means of peering or service level agreements only. > > > > These are important points that must be taken into consideration. > > Overprovisioning is not the single solution. As previsously pointed out in > another email to the list, not all networks are over provisioned. Lots of > unused bandwidth is widely available so it does not cost any more at the > moment to use it for over provisioning. But as traffic demand in the > marketplace increases over time, the excess bandwidth will soon disappear. > Then it may not be cost effective to expand bandwidth just for over > provisioning. > > Ensuring that emergency recovery communications can get through heavy > congestion in timely response to a serious disaster is critically important. > > Hal > > _______________________________________________ > 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 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 10 12:27:11 2002 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 MAA09901 for ; Wed, 10 Jul 2002 12:27:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16756; Wed, 10 Jul 2002 12:24:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16722 for ; Wed, 10 Jul 2002 12:24:16 -0400 (EDT) Received: from web20810.mail.yahoo.com (web20810.mail.yahoo.com [216.136.226.199]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09698 for ; Wed, 10 Jul 2002 12:23:20 -0400 (EDT) Message-ID: <20020710162409.79534.qmail@web20810.mail.yahoo.com> Received: from [134.193.24.34] by web20810.mail.yahoo.com via HTTP; Wed, 10 Jul 2002 09:24:09 PDT Date: Wed, 10 Jul 2002 09:24:09 -0700 (PDT) From: senthil ayyasamy Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt To: goldmans@agcs.com, Gunn Janet NE Cc: "'Folts Harold'" , "'senthil ayyasamy'" , ieprep In-Reply-To: <3D2C4FCF.43D4A861@agcs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org I accept that code-red and nimada had more effect on the net than disaster events. But, cyberattacks seems too broad to cover in a WG such as this one. Their are many better places to discuss them (ICMP traceback, IPPT, partly by psamp&IPFIX, many CERT initiatives.) The only issue of interest to ieprep community is *differentiating flash crowds/emergency traffic with DDOS attacks* at the access. I think the present charter doesnt allow even this one. --- "Stuart (Stu) Goldman" wrote: > Janet, > > If the purpose of the service is to provide > emergency communication during a > disaster, including a terrorist attack, I don't > think it makes good sense to > rule out a coordinated physical attack along with a > DDoS and virus, etc. If we > can think of it, so can the bad guys. > "Gunn, Janet NE" wrote: > > > Do we also have to consider the possibility of > "some kind of virus" > > (terrorist inspired or otherwise) generating a > large amount of traffic, and > > "using up" the overprovisioning? > > > > Or is that a red-herring? __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 10 15:00:55 2002 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 PAA15554 for ; Wed, 10 Jul 2002 15:00:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29970; Wed, 10 Jul 2002 15:00:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29925 for ; Wed, 10 Jul 2002 15:00:24 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15502 for ; Wed, 10 Jul 2002 14:59:29 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 14:57:47 -0400 Message-ID: From: "Gunn, Janet NE" To: "'senthil ayyasamy'" , goldmans@agcs.com Cc: "'Folts Harold'" , ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Wed, 10 Jul 2002 14:57:36 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Senthil, My point was more that the possibility of virus attacks makes the assumption that "the core is overprovisioned and will never be short of bandwidth for emergency services" a bit less sure. Janet -----Original Message----- From: senthil ayyasamy [mailto:mplsgeek@yahoo.com] Sent: Wednesday, July 10, 2002 12:24 PM To: goldmans@agcs.com; Gunn, Janet NE Cc: 'Folts Harold'; 'senthil ayyasamy'; ieprep Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt I accept that code-red and nimada had more effect on the net than disaster events. But, cyberattacks seems too broad to cover in a WG such as this one. Their are many better places to discuss them (ICMP traceback, IPPT, partly by psamp&IPFIX, many CERT initiatives.) The only issue of interest to ieprep community is *differentiating flash crowds/emergency traffic with DDOS attacks* at the access. I think the present charter doesnt allow even this one. --- "Stuart (Stu) Goldman" wrote: > Janet, > > If the purpose of the service is to provide > emergency communication during a > disaster, including a terrorist attack, I don't > think it makes good sense to > rule out a coordinated physical attack along with a > DDoS and virus, etc. If we > can think of it, so can the bad guys. > "Gunn, Janet NE" wrote: > > > Do we also have to consider the possibility of > "some kind of virus" > > (terrorist inspired or otherwise) generating a > large amount of traffic, and > > "using up" the overprovisioning? > > > > Or is that a red-herring? __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 10 17:33:20 2002 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 RAA20594 for ; Wed, 10 Jul 2002 17:33:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11459; Wed, 10 Jul 2002 17:32:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11425 for ; Wed, 10 Jul 2002 17:32:24 -0400 (EDT) Received: from web20803.mail.yahoo.com (web20803.mail.yahoo.com [216.136.226.192]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20550 for ; Wed, 10 Jul 2002 17:31:29 -0400 (EDT) Message-ID: <20020710213222.98950.qmail@web20803.mail.yahoo.com> Received: from [134.193.24.44] by web20803.mail.yahoo.com via HTTP; Wed, 10 Jul 2002 14:32:22 PDT Date: Wed, 10 Jul 2002 14:32:22 -0700 (PDT) From: senthil ayyasamy Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt To: "Gunn, Janet NE" , goldmans@agcs.com Cc: "'Folts Harold'" , ieprep In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > My point was more that the possibility of virus > attacks makes the > assumption that "the core is overprovisioned and > will never be short of > bandwidth for emergency services" a bit less sure. To add some more points : Solutions for virus attacks are pretty difficult at the stage. The virus attack taxonomy has to be defined well before considering that work. Read the following recent USENIX paper on how distributed and random the worm attacks (in our case by bad elements/terrorists) turn out that their is nill possibility of finding a solution. http://www.icir.org/vern/papers/cdc-usenix-sec02/index.html The below work explains how a worm can make internet paralyzed within 15 minutes ( possibility). http://www.cs.berkeley.edu/~nweaver/warhol.html Coming back to our point, worm/viruses/cyberattacks by bad elements will SURELY consume the bandwidth and will have greater impact if it happens on days like 9/11. But, unfortunatley their is no effective solution to avoid them. So, the only thing that can be done is make sure emergency traffic gets priority to other and affected at the least by worms. But it is still difficult. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 10 17:49:45 2002 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 RAA21050 for ; Wed, 10 Jul 2002 17:49:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12071; Wed, 10 Jul 2002 17:50:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12041 for ; Wed, 10 Jul 2002 17:50:09 -0400 (EDT) Received: from kc-msxproto4.kc.umkc.edu (kc-msxproto4.kc.umkc.edu [134.193.143.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21035 for ; Wed, 10 Jul 2002 17:49:13 -0400 (EDT) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxproto4.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 16:50:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Wed, 10 Jul 2002 16:50:04 -0500 Message-ID: Thread-Topic: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Thread-Index: AcImgCIL2UUl6Oo3RB2nbhayvm3kEgB2ULJgAACOhFA= From: "Beard, Cory" To: "RJ Atkinson" , "ieprep" X-OriginalArrivalTime: 10 Jul 2002 21:50:05.0292 (UTC) FILETIME=[C048B2C0:01C2285B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA12042 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Monday, July 08, 2002 8:01 AM > > I think it is fine to have some example solutions, in separate documents. > I object pretty strongly to the standard mandating a particular mechanism > because network designs and circumstances vary so widely. It would be fine with me to have examples in separate documents. That is really up to the chair how many documents he wants to produce. But if two documents are produced that really need to be read together to be understood, then would it not be better to have them merged? Maybe we could restructure the document to have an examples section that is completely separate from the requirements sections. Hal felt the examples should be removed from the main text. I believe the examples serve to clarify what the requirement is saying and illustrate some of the options available in meeting the requirement. Cory _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 10 17:50:21 2002 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 RAA21093 for ; Wed, 10 Jul 2002 17:50:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12180; Wed, 10 Jul 2002 17:50:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12147 for ; Wed, 10 Jul 2002 17:50:53 -0400 (EDT) Received: from kc-msxproto2.kc.umkc.edu (kc-msxproto2.kc.umkc.edu [134.193.143.159]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21074 for ; Wed, 10 Jul 2002 17:49:57 -0400 (EDT) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 16:50:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Wed, 10 Jul 2002 16:50:49 -0500 Message-ID: Thread-Topic: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Thread-Index: AcIoRB05ab7Mx8fyRvCQd3EpgwYdqwAFBntAAADkWFA= From: "Beard, Cory" To: "ieprep" , "Gunn, Janet NE" X-OriginalArrivalTime: 10 Jul 2002 21:50:49.0741 (UTC) FILETIME=[DAC713D0:01C2285B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA12148 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Gunn, Janet NE [mailto:Janet.Gunn@DynCorp.com] > Sent: Wednesday, July 10, 2002 1:58 PM > > My point was more that the possibility of virus attacks makes the > assumption that "the core is overprovisioned and will never be short of > bandwidth for emergency services" a bit less sure. > Janet, My challenge to you or Stu is to prepare a design criteria by which overprovisioning would be *acceptable*. It is another issue to see if a service provider could actually provision to that level (which you doubt). How about this (as Ran said) - the sum of all access rates is less than the rate of the core link? Maybe the core also has to be fully connected, so no merging of bulk traffic streams occurs in the core? Cory _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 10 17:53:14 2002 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 RAA21217 for ; Wed, 10 Jul 2002 17:53:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12004; Wed, 10 Jul 2002 17:47:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11968 for ; Wed, 10 Jul 2002 17:47:53 -0400 (EDT) Received: from kc-msxproto2.kc.umkc.edu (kc-msxproto2.kc.umkc.edu [134.193.143.159]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20984 for ; Wed, 10 Jul 2002 17:46:56 -0400 (EDT) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 16:47:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Wed, 10 Jul 2002 16:47:47 -0500 Message-ID: Thread-Topic: [Ieprep] draft-ietf-ieprep-requirements-00.txt Thread-Index: AcIoM0ZIKvSn30/HQbGME9ofAFvSDQAI9D8gAAEQ7GA= From: "Beard, Cory" To: "ieprep" , "Fred Baker" X-OriginalArrivalTime: 10 Jul 2002 21:47:48.0237 (UTC) FILETIME=[6E97C3D0:01C2285B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA11969 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > I have used the term "glittering generality" in the past; I still think > the > requirements stated are difficult to implement against. So what is the difference between a glittering generality and a high level requirement? Cory _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jul 10 18:20:40 2002 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 SAA22051 for ; Wed, 10 Jul 2002 18:20:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13668; Wed, 10 Jul 2002 18:20:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13633 for ; Wed, 10 Jul 2002 18:20:58 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22021 for ; Wed, 10 Jul 2002 18:20:01 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn1-740.cisco.com [10.21.98.228]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6AMKNhJ010173; Wed, 10 Jul 2002 15:20:23 -0700 (PDT) Message-Id: <5.1.1.6.2.20020710181431.02ab5de0@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 10 Jul 2002 18:20:21 -0400 To: "Beard, Cory" From: Fred Baker Subject: Re: [Ieprep] draft-ietf-ieprep-requirements-00.txt Cc: "ieprep" In-Reply-To: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 04:47 PM 7/10/2002 -0500, Beard, Cory wrote: >So what is the difference between a glittering generality and a high >level requirement? Let me answer with an example. If you tell me "must be able to authenticate 100,000 users at 1000 authentications per second with essentially zero probability of a false authentication", I can propose a number of potential implementations, and I can tell you whether I achieved that. If you tell me "must cryptographically authenticate using the AES...", you have specified a solution, and I can't propose an alternative such as one-time passwords. If you tell me "must be able to authenticate folks", I dunno, is it OK if I call their wives and ask them to come look at the guy and vouch that he's their respective husband? I need to know what problem needs to be solved, and I need to be able to tell whether I have solved it. The statement needs to be sufficiently open-ended to allow creativity in solving it, and needs to be realistic, but it needs to be specific enough so that if I produce a solution that solves the statement, it will in fact make you happy with the resulting system. I'm looking for a set of statements that tell me (a) what problem needs to be solved (b) enough discussion so that I can directly understand the alternatives and trade-offs (c) no early binding to a solution (d) what, if I don't achieve it, makes a proposed solution untenable _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jul 11 01:15:54 2002 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 BAA00546 for ; Thu, 11 Jul 2002 01:15:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10745; Thu, 11 Jul 2002 01:15:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21046 for ; Wed, 10 Jul 2002 20:45:29 -0400 (EDT) Received: from kc-msxproto4.kc.umkc.edu (kc-msxproto4.kc.umkc.edu [134.193.143.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24899 for ; Wed, 10 Jul 2002 20:44:35 -0400 (EDT) Received: from KC-MAIL2.kc.umkc.edu ([134.193.143.162] RDNS failed) by kc-msxproto4.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 19:45:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Wed, 10 Jul 2002 19:45:27 -0500 Message-ID: Thread-Topic: Re: draft-talauliker-ieprep-diffserv-00.txt Thread-Index: AcIodC1rGFcWtvJXTSWbANm/o99lnw== From: "Talauliker, Salil Ulhas (UMKC-Student)" To: X-OriginalArrivalTime: 11 Jul 2002 00:45:27.0951 (UTC) FILETIME=[404709F0:01C22874] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id UAA21047 Subject: [Ieprep] Re: draft-talauliker-ieprep-diffserv-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit Dear Fred, This is in response to your comment below on Friday, June 28 about my draft draft-talauliker-ieprep-diffserv-00.txt. > I'm not sure what the intersection of talauliker and baker's drafts are; > from my perspective, it sounds like a submission to diffserv more than a > submission to ieprep. We'll discuss it given time, and see what we want to > with it. I note that diffserv didn't choose to standardize the RIO > chanism, or Cisco's WRED mechanism, or Lucent's approach, or the approach > commended by Van and Kathy called RED-Lite, or any of a list of others. > Diffserv rather chose to identify AQM mechanisms as a class of equally > acceptable algorithms. I also note that there is little substantive > difference between what this proposes and an AF service which treats all > emergency traffic as AFn1 traffic. This draft is very much a submission to the IEPREP cause. If you notice, the draft is suggesting a solution for providing priority treatment for EMERGENCY TRAFFIC in a SPECIFIC domain - i.e. a DIFFSERV domain. We are also working on finding a solution for the same problem in a current "best effort network". However the solution space for best effort gets mired by the orthogonal issues like ISP compliance and economic feasibility etc. Although I cannot disagree that the draft can also be submitted to a purely diffserv WG. > I note that diffserv didn't choose to standardize the RIO > chanism, or Cisco's WRED mechanism, or Lucent's approach, or the approach > commended by Van and Kathy called RED-Lite, or any of a list of others. > Diffserv rather chose to identify AQM mechanisms as a class of equally > acceptable algorithms. I completely agree with this remark of yours as far as the Diffserv idealogy is concerned. However theres some misunderstanding of my ideas here. The draft is NOT proposing any proprietary solution from the list that you mentioned above. Rather it is proposing the use of RIO - (a much useful RED variant) - as a technology, an idea - not RED as a product developed by some company. I would like to reiterate that RFC 2597 recommends that AQM be used to realize the multiple DP in the AF PHB and that the most widely used AQM scheme is RED. We at UMKC have done a preliminary evaluation of the several ways to extend RED to a Multilevel RED (MRED) algorithm suitable for the AF PHB. And based upon our finding this draft suggests the use of RIO (RED with in/out) to protect Emergency traffic. > I also note that there is little substantive > difference between what this proposes and an AF service which treats all > emergency traffic as AFn1 traffic. I strongly disagree with this comment for the following reasons: 1. This draft does not say that we assign ALL emergency traffic with the highest possible AF codepoint such as say AFn1. Thats definitely NOT the case. We have clearly stated that the traffic conditioner used at the ingress router in a Diffserv domain would mark the incoming flows with appropriate AF/EF codepoints, NOT necessarily with AFn1. And we also mentioned in the draft that a standard allocation policy does not exist although you have given a good example configuration in draft-baker-ieps-requirements-00.txt. 2. Secondly we do NOT say give lowest drop precedence color to ALL emergency traffic. Instead the draft proposes a MULTI-LEVEL drop precedence over AF/EF queues. So it is quite possible that while an Emergency Voice packet might get GREEN color, another Emergency packet, say an Email packet, might be given YELLOW color. As of now, we are open to such a coloring scheme - again for the lack of any standard coloring scheme. This draft is fairly influenced by the idea mentioned in section 3.3 of "draft-beard-ieprep-requirements-00.txt" that >>-> Quality of service for emergency communication services does not >>-> necessarily mean better quality of voice/video as compared to what >>-> is available to normal users. The same QoS classes, which are >>-> already defined for normal traffic, can be utilized for emergency >>-> traffic as well. The fundamental quality of service requirement for >>-> priority traffic is this - better than best effort service. All this effort is based on one assumption that - simply assigning ALL Emergency traffic to AFn1 will NOT solve the problem EFFICIENTLY. If however you think my approach is wrong, then please let me know and also suggest an alternative if possible. Also if you think its appropriate then these ideas can be merged with your draft - which might be a good idea too! I understand that what I am proposing is to use Diffserv for a purpose that it was not designed for. And the networking community is not going to be very happy about it. But thats the best that can be done today if we want to provide a Priority (aka differentiated) Service to Emergency traffic in a Differentiated domain. Being the coauthor of the Diffserv RFC, you are the best person who can guide me in this. Any questions comments are very welcome. Regards, Salil Talauliker School of Interdisciplinary Computing and Engineering University of Missouri-Kansas City. sut0b6@umkc.edu References: ---------- draft-talauliker-ieprep-diffserv-00.txt draft-baker-ieps-requirements-00.txt draft-beard-ieprep-requirements-00.txt _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jul 11 10:39:52 2002 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 KAA19351 for ; Thu, 11 Jul 2002 10:39:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11906; Thu, 11 Jul 2002 10:40:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11872 for ; Thu, 11 Jul 2002 10:40:07 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19318 for ; Thu, 11 Jul 2002 10:39:14 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 10:38:33 -0400 Message-ID: From: "Gunn, Janet NE" To: "'Beard, Cory'" , ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Thu, 11 Jul 2002 10:38:23 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org I guess I am still not being clear. While overprovisioning is definitely a "good thing" from a performance perspective, it is not a panacea. No matter what the ratio of core capacity to edge capacity, I suspect that SOMEONE could come up with a "virus" (using that term in its most general sense) which could use up enough of the core capacity to cause congestion. For instance, it is within the realms of possibility for malicious code (or even an innocent error) to corrupt switches and routers. Remember when an entire frame relay network went down due to a software upgrade? So adding more capacity isn't the only answer. And implementing security measures isn't the only answer. It would also be a "good thing" to have some sort of contingency plan for what to do (specifically for IEPREP traffic) IF there is congestion in the core. To make a (rough) historical analogy, the Maginot line was a "good thing", but it wasn't sufficient. And making the Maginot line taller and more heavily armed wouldn't have helped. What would have helped would have been to have some contingency plans for what to do IF the Germans got through/around the Maginot line. That is my only point. Anytime someone says "X can't happen, therefore I am not going to worry about X", I start to worry. Now, maybe the probability of something/someone causing congestion in the core is so low, and the cost of any kind of contingency plan (whether just for IEPREP, or for all legitimate traffic) is so high that "we just have to live with it." OK, that I can accept. But not even EXAMINING possible contingency plans because "it can't happen" seems short sighted to me. Congestion is much more likely at the edges, and our primary focus should be there. But we shouldn't ignore the core. Janet -----Original Message----- From: Beard, Cory [mailto:beardc@umkc.edu] Sent: Wednesday, July 10, 2002 5:51 PM To: ieprep; Gunn, Janet NE Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt > -----Original Message----- > From: Gunn, Janet NE [mailto:Janet.Gunn@DynCorp.com] > Sent: Wednesday, July 10, 2002 1:58 PM > > My point was more that the possibility of virus attacks makes the > assumption that "the core is overprovisioned and will never be short of > bandwidth for emergency services" a bit less sure. > Janet, My challenge to you or Stu is to prepare a design criteria by which overprovisioning would be *acceptable*. It is another issue to see if a service provider could actually provision to that level (which you doubt). How about this (as Ran said) - the sum of all access rates is less than the rate of the core link? Maybe the core also has to be fully connected, so no merging of bulk traffic streams occurs in the core? Cory _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jul 11 15:51:37 2002 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 PAA03086 for ; Thu, 11 Jul 2002 15:51:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12496; Thu, 11 Jul 2002 15:51:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12460 for ; Thu, 11 Jul 2002 15:51:31 -0400 (EDT) Received: from roam.psg.com ([61.193.166.83]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03013 for ; Thu, 11 Jul 2002 15:50:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17Sjxo-0004yK-00; Thu, 11 Jul 2002 12:50:56 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Gunn, Janet NE" Cc: "'Beard, Cory'" , ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt References: Message-Id: Date: Thu, 11 Jul 2002 12:50:56 -0700 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit > No matter what the ratio of core capacity to edge capacity, I suspect that > SOMEONE could come up with a "virus" (using that term in its most general > sense) which could use up enough of the core capacity to cause congestion. and similarly, someone could come up with an attack on the complex qos systems you seem to be advocating to overcome this. randy _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jul 11 16:11:54 2002 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 QAA04035 for ; Thu, 11 Jul 2002 16:11:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13847; Thu, 11 Jul 2002 16:12:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13816 for ; Thu, 11 Jul 2002 16:12:09 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03996 for ; Thu, 11 Jul 2002 16:11:15 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 16:10:53 -0400 Message-ID: From: "Gunn, Janet NE" To: "'Randy Bush'" Cc: "'Beard, Cory'" , ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Thu, 11 Jul 2002 16:10:44 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org I am NOT advocating any particular solution. I just don't want to see it dismissed as a "non-problem". Yes, complex QoS systems would also be vulnerable to targeted attacks. I am not sure which (monopolizing core capacity, or disrupting QoS systems) is a more inviting target- I guess it depends on the attacker's motives. And personally I think that (for IP telephony, at least) variants on the "call setup" process would be more useful than complex QoS systems. For instance I recently read an article (it is sitting on my dining room table at home, so I don't have the reference handy) about schemes for finding alternate paths when RSVP can't find the needed capacity on the primary route. (I'll post the reference tonight.) I am not necessarily advocating that either. I just don't think that "congestion in the core" should be completely ignored. Janet -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Thursday, July 11, 2002 3:51 PM To: Gunn, Janet NE Cc: 'Beard, Cory'; ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt > No matter what the ratio of core capacity to edge capacity, I suspect that > SOMEONE could come up with a "virus" (using that term in its most general > sense) which could use up enough of the core capacity to cause congestion. and similarly, someone could come up with an attack on the complex qos systems you seem to be advocating to overcome this. randy _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Fri Jul 12 08:32:36 2002 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 IAA19486 for ; Fri, 12 Jul 2002 08:32:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12953; Fri, 12 Jul 2002 08:27:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12919 for ; Fri, 12 Jul 2002 08:27:57 -0400 (EDT) Received: from chntex03.is.dyncorp.com (host-133-209.is.dyncorp.com [131.131.133.209] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19247 for ; Fri, 12 Jul 2002 08:27:01 -0400 (EDT) Received: by chntex03.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jul 2002 08:26:40 -0400 Message-ID: From: "Gunn, Janet NE" To: "Gunn, Janet NE" , "'Randy Bush'" Cc: "'Beard, Cory'" , ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt Date: Fri, 12 Jul 2002 08:26:26 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org The June 2002 issue of IEEE Communications has a sereis of articles on QoS Routing, which is what caught my attenetion. -----Original Message----- From: Gunn, Janet NE Sent: Thursday, July 11, 2002 4:11 PM To: 'Randy Bush' Cc: 'Beard, Cory'; ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt I am NOT advocating any particular solution. I just don't want to see it dismissed as a "non-problem". Yes, complex QoS systems would also be vulnerable to targeted attacks. I am not sure which (monopolizing core capacity, or disrupting QoS systems) is a more inviting target- I guess it depends on the attacker's motives. And personally I think that (for IP telephony, at least) variants on the "call setup" process would be more useful than complex QoS systems. For instance I recently read an article (it is sitting on my dining room table at home, so I don't have the reference handy) about schemes for finding alternate paths when RSVP can't find the needed capacity on the primary route. (I'll post the reference tonight.) I am not necessarily advocating that either. I just don't think that "congestion in the core" should be completely ignored. Janet -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Thursday, July 11, 2002 3:51 PM To: Gunn, Janet NE Cc: 'Beard, Cory'; ieprep Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt > No matter what the ratio of core capacity to edge capacity, I suspect that > SOMEONE could come up with a "virus" (using that term in its most general > sense) which could use up enough of the core capacity to cause congestion. and similarly, someone could come up with an attack on the complex qos systems you seem to be advocating to overcome this. randy _______________________________________________ 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 ieprep-admin@ietf.org Fri Jul 12 12:55:25 2002 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 MAA03378 for ; Fri, 12 Jul 2002 12:55:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04688; Fri, 12 Jul 2002 12:55:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04654 for ; Fri, 12 Jul 2002 12:55:44 -0400 (EDT) Received: from kc-msxproto4.kc.umkc.edu (kc-msxproto4.kc.umkc.edu [134.193.143.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03335 for ; Fri, 12 Jul 2002 12:54:48 -0400 (EDT) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxproto4.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 11:55:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Ieprep] Re: draft-talauliker-ieprep-diffserv-00.txt Date: Fri, 12 Jul 2002 11:55:42 -0500 Message-ID: Thread-Topic: [Ieprep] Re: draft-talauliker-ieprep-diffserv-00.txt Thread-Index: AcIodC1rGFcWtvJXTSWbANm/o99lnwBTaxxg From: "Beard, Cory" To: Cc: "Talauliker, Salil Ulhas (UMKC-Student)" X-OriginalArrivalTime: 12 Jul 2002 16:55:43.0469 (UTC) FILETIME=[F5D7E1D0:01C229C4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA04655 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit Fred and Alistair. To be clear, our idea is to use AF classes for some emergency traffic, some of which would use AFn1. We go beyond that to say, however, that AF should be implemented in a more limited way than RFC 2597 specifies. Simply giving highest drop precedence to emergency traffic is not enough. We need to use a scheme that effectively protects emergency traffic in AF queues. Therefore, we propose the use of mechanisms that treat precedence in a multi-level fashion where high loads from lower drop precedences do not substantially affect higher drop precedence traffic. Many RED variants use a single queue fill metric to apply dropping to all precedence levels. A multi-level approach uses multiple queue fill metrics, one per drop precedence level. Variants of this approach have been called RIO (RED with In and Out), MRED (Multi-level RED), etc. As for this being a BCP, we follow Scott's comment in Minneapolis that a BCP is not so much "best current practice" as it is "best current thinking" or "best current recommendations". The goal of this document, therefore, is to say "This is the ieprep WG's recommendation on how to support emergency services using Diffserv." The draft is decidedly lacking in simulation results, since they are not complete yet. We could have waited until later to submit the draft, but wanted to be timely with the activity and goals of the WG. Besides, we do not believe the conclusions would change, just the specifics of a preferred MRED algorithm and drop threshold levels/shaping functions. Cory ----- Dr. Cory Beard Assistant Professor Division of Computer Science/Eletrical Engineering School of Interdisciplinary Computing and Engineering University of Missouri-Kansas City (816) 235-1550, Fax: (816) 235-1260 http://unofficial.umkc.edu/beardc/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jul 15 19:45:57 2002 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 TAA20231 for ; Mon, 15 Jul 2002 19:45:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05233; Mon, 15 Jul 2002 19:45:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05201 for ; Mon, 15 Jul 2002 19:45:47 -0400 (EDT) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20225 for ; Mon, 15 Jul 2002 19:44:51 -0400 (EDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 17UFWo-0003Nr-00; Mon, 15 Jul 2002 19:45:18 -0400 Date: Mon, 15 Jul 2002 19:45:18 -0400 (EDT) From: Sean Donelan To: "Gunn, Janet NE" cc: "'Folts, Harold'" , "'senthil ayyasamy'" , ieprep Subject: Red Herring RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org On Wed, 10 Jul 2002, Gunn, Janet NE wrote: > Do we also have to consider the possibility of "some kind of virus" > (terrorist inspired or otherwise) generating a large amount of traffic, and > "using up" the overprovisioning? > > Or is that a red-herring? Its a red herring. The existing GETS service has a number of vulnerabilities, including "some kind of virus" terrorist inspired or otherwise. Bill Gates will pay everyone $1,000 who can guess the secret code number by dialing the special number 1-710-627-4387 and entering your guess. Enter as often as you can. No purchase necessary. Depsite the fact the engineers could not solve every potential problem someone could think up, GETS was deployed with those vulnerabilities. Heck, GETS still has problems with 710 special access code not being recognized by some switches. It is extremely unlikely all problems will ever be solved. The question remains, what problem are you trying to solve? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From daemon@optimus.ietf.org Wed Jul 17 01:47:13 2002 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 BAA12987 for ; Wed, 17 Jul 2002 01:47:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA29407 for ieprep-archive@odin.ietf.org; Wed, 17 Jul 2002 01:48:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29359; Wed, 17 Jul 2002 01:46:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29329 for ; Wed, 17 Jul 2002 01:46:33 -0400 (EDT) Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12953 for ; Wed, 17 Jul 2002 01:45:34 -0400 (EDT) Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 01:46:31 -0400 Message-ID: From: "Folts, Harold" To: "ieprep List (E-mail)" Date: Wed, 17 Jul 2002 01:46:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C22D55.4C7AC6E0" Subject: [Ieprep] Revised Rqmts ID Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org 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_000_01C22D55.4C7AC6E0 Content-Type: text/plain; charset="iso-8859-1" I have just uploaded a proposed revision to the revised requirements ID as a result of discussions on the side with several people this week for discussion during the ieprep meeting this afternoon. It is available at: ftp://iepscheme.net/pub/ieps/docs/draft-ietf-ieprep-requirements-hfedits.pdf ------_=_NextPart_000_01C22D55.4C7AC6E0 Content-Type: application/octet-stream; name="Folts, Hal.vcf" Content-Disposition: attachment; filename="Folts, Hal.vcf" BEGIN:VCARD VERSION:2.1 N;ENCODING=QUOTED-PRINTABLE:;=01 REV:20010930T194720Z END:VCARD ------_=_NextPart_000_01C22D55.4C7AC6E0-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From daemon@ns.ietf.org Thu Jul 18 03:42:58 2002 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 DAA25197 for ; Thu, 18 Jul 2002 03:42:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA15660 for ieprep-archive@odin.ietf.org; Thu, 18 Jul 2002 03:43:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15639; Thu, 18 Jul 2002 03:43:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15607 for ; Thu, 18 Jul 2002 03:43:23 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25191 for ; Thu, 18 Jul 2002 03:42:24 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6I7glOu000154; Thu, 18 Jul 2002 00:42:47 -0700 (PDT) Received: from Rohan (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAN58205; Thu, 18 Jul 2002 00:41:40 -0700 (PDT) Date: Thu, 18 Jul 2002 16:42:08 +0900 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: rohan@cisco.com To: ieprep@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Subject: [Ieprep] pointers to sip change and calling party category mapping to the tel URL Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi, As I mentioned at the meeting today in reference to the ISUP-SIP Gap analysis, we have a process established for dealing with changes and extensions to SIP. Since many of you are new to the IETF, I am providing a pointer to this process: http://search.ietf.org/internet-drafts/draft-tsvarea-sipchange-02.txt The often mentioned proposal for a Resource-Priority header is an individual internet draft which may be a completely reasonable mechanism to address the IEPREP requirements, but cannot be evaluated or progress until we see the relevant requirements. also relevant to the draft there is an individual I-D that describes mapping the Calling Party Category to parameters in the tel URL: http://search.ietf.org/internet-drafts/draft-peterson-tel-cpc-00.txt hope this helps. thanks, -rohan _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From daemon@optimus.ietf.org Wed Jul 24 15:29:36 2002 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 PAA29093 for ; Wed, 24 Jul 2002 15:29:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19136 for ieprep-archive@odin.ietf.org; Wed, 24 Jul 2002 15:30:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18768; Wed, 24 Jul 2002 15:29:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18738 for ; Wed, 24 Jul 2002 15:29:28 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29069 for ; Wed, 24 Jul 2002 15:28:24 -0400 (EDT) Received: from FRED-W2K6.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with SMTP id g6OJSuhJ021287 for ; Wed, 24 Jul 2002 12:28:56 -0700 (PDT) Message-Id: <5.1.1.6.2.20020724122725.00aa49a8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 24 Jul 2002 12:28:54 -0700 To: ieprep@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] minutes Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Before I post the minutes to minutes@ietf.org, I'd appreciate any comments on them. ftp://ftpeng.cisco.com/fred/ieprep-july/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From daemon@optimus.ietf.org Wed Jul 24 15:45:13 2002 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 PAA29673 for ; Wed, 24 Jul 2002 15:45:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20032 for ieprep-archive@odin.ietf.org; Wed, 24 Jul 2002 15:46:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19977; Wed, 24 Jul 2002 15:45:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19930 for ; Wed, 24 Jul 2002 15:45:26 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29630 for ; Wed, 24 Jul 2002 15:44:21 -0400 (EDT) Received: from FRED-W2K6.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with SMTP id g6OJirhJ002024; Wed, 24 Jul 2002 12:44:53 -0700 (PDT) Message-Id: <5.1.1.6.2.20020724124030.023eb8e8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 24 Jul 2002 12:44:51 -0700 To: "ieprep List (E-mail)" From: Fred Baker Subject: Re: [Ieprep] Revised Rqmts ID Cc: "ieprep List (E-mail)" In-Reply-To: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 09:46 AM 7/16/2002 -0400, Folts, Harold wrote: >I have just uploaded a proposed revision to the revised requirements ID as a >result of discussions on the side with several people this week for >discussion during the ieprep meeting this afternoon. It is available at: > >ftp://iepscheme.net/pub/ieps/docs/draft-ietf-ieprep-requirements-hfedits.pdf Let's have a fairly focused discussion on this document. The question before the house is: having read it, - does it give us enough of an overview, in the user requirements section, so that we can intuitively understand the issues? - does it tell us what technical problem needs to be solved in clear enough language that we can propose mechanisms to solve it? - does it give us enough information to help us decide which among multiple possible solutions is appropriate? - what detail is present that isn't related to requirements? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From daemon@optimus.ietf.org Wed Jul 24 16:43:53 2002 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 QAA02100 for ; Wed, 24 Jul 2002 16:43:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24184 for ieprep-archive@odin.ietf.org; Wed, 24 Jul 2002 16:44:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24157; Wed, 24 Jul 2002 16:43:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24125 for ; Wed, 24 Jul 2002 16:43:11 -0400 (EDT) Received: from cygnus.degree2.com (host195-89-159-99.uk.regusnet.com [195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02070 for ; Wed, 24 Jul 2002 16:42:05 -0400 (EDT) Received: from kohoutek (cygnus.degree2.com [172.30.10.1]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g6OKgeD10639; Wed, 24 Jul 2002 21:42:40 +0100 From: "Alistair Munro" To: "'Fred Baker'" , "'ieprep List \(E-mail\)'" Cc: "'ieprep List \(E-mail\)'" Subject: RE: [Ieprep] Revised Rqmts ID Date: Wed, 24 Jul 2002 21:44:51 +0100 Message-ID: <001801c23352$f623ee80$5f1b290c@kohoutek> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <5.1.1.6.2.20020724124030.023eb8e8@mira-sjcm-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi All, I have spotted a number of minor editorials in Hal's revised draft that I could fix more easily if I had the txt version. Can Hal supply this? Back on topic, some initial suggestions: > > - does it give us enough of an overview, in the user > requirements section, so that we can intuitively > understand the issues? I would prefer to see the security issues extracted as a separate item in the list. Currently they seem to be split between (8) and (10), plus any additional text appropriate from Ian's draft (as was suggested at the meeting). Remove section 8. Item 4: is a bit discursive. Suggest: "Emergency communications sessions to receive preferential treatment to improve probability of connection completion and normal termination over normal sessions under conditions of congestion or saturation". In relation to this, keep 5.4 where it is. Item 6: reword - there is no user requirement to transit multiple providers, but we expect it to happen. Suggest: "Transparent national and international access to emergency services implying cooperation between service providers under some circumstances". " > - does it tell us what technical problem needs to be solved in > clear enough language that we can propose mechanisms to solve it? I find the list clear enough and complete at a top level. I think the drafts from Ken and Ian provide a good basis for tutorial material on the solution space to meet these requirements without imposing constraints while highlighting issues - I promised Ken some input on this. Is it considered the right way to go? > - does it give us enough information to help us decide which > among multiple possible solutions is appropriate? I would prefer not to have this sort of material in the requirements. Having spent the effort to get solutions out of this draft, maybe there is now too little information but IMO it's better that way. > - what detail is present that isn't related to requirements? I am happy with the non-requirements text. Mostly it is useful background and motivation. I still think section 1.1 should be retitled "GETS - a motivating example" but I'm happy to keep it in section 1. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From daemon@optimus.ietf.org Wed Jul 24 17:24:23 2002 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 RAA03061 for ; Wed, 24 Jul 2002 17:24:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26719 for ieprep-archive@odin.ietf.org; Wed, 24 Jul 2002 17:25:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26656; Wed, 24 Jul 2002 17:24:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26628 for ; Wed, 24 Jul 2002 17:24:31 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03011 for ; Wed, 24 Jul 2002 17:23:25 -0400 (EDT) Received: from FRED-W2K6.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with SMTP id g6OLNqhJ016230; Wed, 24 Jul 2002 14:23:52 -0700 (PDT) Message-Id: <5.1.1.6.2.20020724134736.03b7fd20@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 24 Jul 2002 14:23:50 -0700 To: "Alistair Munro" From: Fred Baker Subject: RE: [Ieprep] Revised Rqmts ID Cc: ieprep@ietf.org In-Reply-To: <001801c23352$f623ee80$5f1b290c@kohoutek> References: <5.1.1.6.2.20020724124030.023eb8e8@mira-sjcm-4.cisco.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org At 09:44 PM 7/24/2002 +0100, Alistair Munro wrote: > > - does it give us enough information to help us decide which > > among multiple possible solutions is appropriate? > >I would prefer not to have this sort of material in the requirements. >Having spent the effort to get solutions out of this draft, maybe there >is now too little information but IMO it's better that way. There is a bit of a balance that has to be struck there, I agree, but in my opinion it is possible to place requirements that help us sort out solutions without specifying the solutions to be sorted out. Take one example, one I mentioned in a too-hasty note a couple of weeks ago. As a user requirement, Hal says (2)Capability to rapidly authenticate users who are authorized to have access to emergency telecommunication services and to ensure maintenance of the user authentication in processing emergency communication through the network infrastructure. And as technical requirements Hal has three numbered but empty sections that say 3.2.3 Authentication of user/application 3.2.6 Preserving authentication during transit 3.2.7 Authorization of users for specific services/privileges I find myself itching for some definitions. How "rapidly" must users be authenticated? Is this a matter of a couple of folks coming an hour apart to get a cookie that will serve them all day, or 10,000 folks, each coming for a separate cookie for each transaction, and by the way each producing transactions as quickly as they can wave a stylus on their PDAs? How strong of authentication is required? In the PSTN, for GETS, we use a proof-by-assertion mechanism in calling the 710 area code, and then punch in a 32 digit number read off the back of a credit card. This is presumably sufficient in the PSTN, but I have to say I think it might be mostly because of the extreme limitations on the things that can present calls in the PSTN. As noted during the meeting, there are issues with that approach in the IP Network - you'd be amazed how many apparent calls to the 710 area code a script kiddie can generate if one were to put his or her mind to it. So what I get out of the draft is that, since nothing else is said, GETS uses a credit card with a PIN code on it, and that is probably fine for the IP Internet. But sez me who knows that script kiddies perpetrate thousands to tens of thousands of denial of service attacks in the Internet every week, and are deliberately destructive, I don't think that's adequate (humorous aside at http://ars.userfriendly.org/cartoons/?id=20010523). So I find myself wondering whether http://www.ietf.org/internet-drafts/draft-peterson-sip-identity-01.txt presents a useful direction - I know Rohan Mahy thinks it does. The issues I'm bringing out here, I suspect, are in fact *requirements* that the system must respond to. Not to say "thou shalt do Peterson's thing", but "it's fairly important that a script kiddie not be able to take out the ETS infrastructure". "Authorization of users..." by whom? Is there more than one server (say, one for US NCS, another for UK's counterpart, and others for other such entities), or is there one server for the whole world? What is a user? Is it a person, or are anonymous persons or groups of persons reasonable to discuss? "Preserving authentication during transit" - transit between what and what? Between IP networks? Between from the Internet to the PSTN? From the PSTN to the Internet? From PSTN to PSTN though the Internet? At what point is re-authentication acceptable? For example, if I have strong authentication like Peterson in the Internet and I hand the call off to the PSTN, it's likely to have a 710 area code in it... It seems that we can place requirements here that help us sort out the applicability of separate solutions without going into the solutions themselves. In the above discussion I have mentioned two solutions - one to say that it appears to be accepted but I have a problem with it as a solution, and one to say that it is a potential solution on the table without saying anything about it. I suspect that I could have had the discussion without mentioning the latter at all, if I was sure that everyone knew about the existence of such potential solutions. My point is to get the requirements detailed enough that we can actually analyze the applicability of solutions, without having the requirements say "implement my solution". _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From daemon@optimus.ietf.org Wed Jul 24 17:51:29 2002 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 RAA03482 for ; Wed, 24 Jul 2002 17:51:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA28112 for ieprep-archive@odin.ietf.org; Wed, 24 Jul 2002 17:52:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28054; Wed, 24 Jul 2002 17:50:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28020 for ; Wed, 24 Jul 2002 17:50:30 -0400 (EDT) Received: from cygnus.degree2.com (host195-89-159-99.uk.regusnet.com [195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03467 for ; Wed, 24 Jul 2002 17:49:24 -0400 (EDT) Received: from kohoutek (cygnus.degree2.com [172.30.10.1]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g6OLoOD11380; Wed, 24 Jul 2002 22:50:24 +0100 From: "Alistair Munro" To: "'Fred Baker'" Cc: Subject: RE: [Ieprep] Revised Rqmts ID Date: Wed, 24 Jul 2002 22:52:35 +0100 Message-ID: <002401c2335c$6c815be0$5f1b290c@kohoutek> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <5.1.1.6.2.20020724134736.03b7fd20@mira-sjcm-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit Hi Fred, > > > - does it give us enough information to help us > decide which > > > among multiple possible solutions is appropriate? > > > >I would prefer not to have this sort of material in the > requirements. > >Having spent the effort to get solutions out of this draft, > maybe there > >is now too little information but IMO it's better that way. > > There is a bit of a balance that has to be struck there, I > agree, but in my > opinion it is possible to place requirements that help us sort out > solutions without specifying the solutions to be sorted out. > Yes, there is an issue of balance and I'm struggling a bit with it right now. I think the 3.2.n subsections are the right place to restore it and I'll put some suggestions together. I think we could focus on parameters appropriate to the sub-sections, possible performance bounds and risks, i.e. what the solution should do and should not do - requirements that sort sheep solutions from goats (as you suggest). Your example gives me some ideas for these bits and some material that could also complement Ian's security draft. Let me chew over it a while until tomorrow. Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From daemon@optimus.ietf.org Thu Jul 25 07:41:55 2002 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 HAA29190 for ; Thu, 25 Jul 2002 07:41:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA20340 for ieprep-archive@odin.ietf.org; Thu, 25 Jul 2002 07:43:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20278; Thu, 25 Jul 2002 07:42:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20247 for ; Thu, 25 Jul 2002 07:42:20 -0400 (EDT) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29180; Thu, 25 Jul 2002 07:41:13 -0400 (EDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 07:42:18 -0400 Message-ID: From: "Folts, Harold" To: "'Alistair Munro'" , "'Fred Baker'" , "'ieprep List (E-mail)'" Cc: "'ieprep List (E-mail)'" Subject: RE: [Ieprep] Revised Rqmts ID Date: Thu, 25 Jul 2002 07:42:16 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Alistair Munro [mailto:alistair.munro@degree2.com] > Sent: Wednesday, July 24, 2002 4:45 PM > To: 'Fred Baker'; 'ieprep List (E-mail)' > Cc: 'ieprep List (E-mail)' > Subject: RE: [Ieprep] Revised Rqmts ID > > > Hi All, > > I have spotted a number of minor editorials in Hal's revised > draft that > I could fix more easily if I had the txt version. Can Hal supply this? I am now preparing the .txt edition of the ID. I hope to post it Monday. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From daemon@optimus.ietf.org Thu Jul 25 08:11:10 2002 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 IAA00299 for ; Thu, 25 Jul 2002 08:11:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21857 for ieprep-archive@odin.ietf.org; Thu, 25 Jul 2002 08:12:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21606; Thu, 25 Jul 2002 08:08:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21580 for ; Thu, 25 Jul 2002 08:08:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29981; Thu, 25 Jul 2002 08:07:18 -0400 (EDT) Message-Id: <200207251207.IAA29981@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: Thu, 25 Jul 2002 08:07:18 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-01.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org --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 : Recommended Packet Marking Policy Author(s) : F. Baker Filename : draft-ietf-ieprep-packet-marking-policy-01.txt Pages : 20 Date : 24-Jul-02 This paper summarizes a recommended correlation of applications to Differentiated Service Code Points. There is no intrinsic requirement that individual DSCPs correspond to given applications, but as a policy it is useful if they can be applied consistently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-packet-marking-policy-01.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-packet-marking-policy-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ieprep-packet-marking-policy-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20020724142953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-packet-marking-policy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-packet-marking-policy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724142953.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From daemon@optimus.ietf.org Sat Jul 27 18:54:12 2002 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 SAA08431 for ; Sat, 27 Jul 2002 18:54:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA26485 for ieprep-archive@odin.ietf.org; Sat, 27 Jul 2002 18:55:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26433; Sat, 27 Jul 2002 18:50:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26402 for ; Sat, 27 Jul 2002 18:50:45 -0400 (EDT) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08407 for ; Sat, 27 Jul 2002 18:49:37 -0400 (EDT) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 17YaOX-0003x0-00 for ieprep@ietf.org; Sat, 27 Jul 2002 18:50:41 -0400 Date: Sat, 27 Jul 2002 18:50:41 -0400 (EDT) From: Sean Donelan To: ieprep@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ieprep] SOS: Secure Overlay Services Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org Another proposal supporting emergency services http://www.acm.org/sigcomm/sigcomm2002/papers/sos.html _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From daemon@optimus.ietf.org Sat Jul 27 21:06:20 2002 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 VAA09634 for ; Sat, 27 Jul 2002 21:06:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA00644 for ieprep-archive@odin.ietf.org; Sat, 27 Jul 2002 21:07:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00623; Sat, 27 Jul 2002 21:06:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00591 for ; Sat, 27 Jul 2002 21:06:21 -0400 (EDT) Received: from web20804.mail.yahoo.com (web20804.mail.yahoo.com [216.136.226.193]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09626 for ; Sat, 27 Jul 2002 21:05:15 -0400 (EDT) Message-ID: <20020728010621.86238.qmail@web20804.mail.yahoo.com> Received: from [134.193.27.31] by web20804.mail.yahoo.com via HTTP; Sat, 27 Jul 2002 18:06:21 PDT Date: Sat, 27 Jul 2002 18:06:21 -0700 (PDT) From: senthil ayyasamy Subject: Re: [Ieprep] SOS: Secure Overlay Services To: Sean Donelan , ieprep@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Internet Emergency Preparedness Working Group X-BeenThere: ieprep@ietf.org > Another proposal supporting emergency services > > http://www.acm.org/sigcomm/sigcomm2002/papers/sos.html > These days one can find lot of literature relating to prevention of DDoS attacks and other types of malicious intrusions. Pick a topic..You can find a work relating to fault tolerance and robustness. Some people even call for *robustness considerations* like *security considerations* in IETF RFCs :-).The research starts from exterme networking, sensor networks, peer to peer, CDN and many types of resilent overlay networks. But these technologies are in research stage and doesnt consider practical requirements. The above sigcomm 2002 paper is one among them providing fault tolerance in overlay networks. But one important property which overlay networks doesnt concur but is otherwise paramount to internet : *scalability* and if you go by randy et all arch guidelines draft: overlay networks will increase the *complexity*. But an interesting research topic. - senthil __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep