From daemon@optimus.ietf.org Fri Mar 8 02:29: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 CAA24143 for ; Fri, 8 Mar 2002 02:29:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA07016 for diffserv-archive@odin.ietf.org; Fri, 8 Mar 2002 02:29:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05259; Fri, 8 Mar 2002 01:55:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05217 for ; Fri, 8 Mar 2002 01:55:17 -0500 (EST) Received: from augean.eleceng.adelaide.edu.au (augean.eleceng.adelaide.edu.au [129.127.28.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15597; Fri, 8 Mar 2002 01:55:09 -0500 (EST) Received: from eleceng.adelaide.edu.au (citr2.eleceng.adelaide.edu.au [129.127.29.38]) by augean.eleceng.adelaide.edu.au (8.10.1/8.10.1/ElecEng-1.0) with ESMTP id g286scU11950; Fri, 8 Mar 2002 17:24:38 +1030 (CST) Message-ID: <3C88602F.C9B9968B@eleceng.adelaide.edu.au> Date: Fri, 08 Mar 2002 17:24:39 +1030 From: Amoakoh Gyasi-Agyei Organization: Centre for Internet Technology Research (CITR) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Amoakoh , diffserv@ietf.org, diffserv-admin@ietf.org Subject: [Diffserv] Wireless Diffserv (WDS) Literature Content-Type: multipart/mixed; boundary="------------28A0E3DF4960A9DCADA1F684" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------28A0E3DF4960A9DCADA1F684 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Comrades: For those of you that inquired about lit on WDS (wireless diffserv) recently, the ff. lit. may be helpful, thanks. (1) Architecture and experimental framework for supporting QoS in wireless networks using differentiated services Mahadevan-I; Sivalingam-KM, Mobile-Networks-and-Applications. vol.6, no.4; 2001; p.385-95 (2) Analytical model for an assured forwarding differentiated service over wireless links Chan-E; Hong-X, IEE-Proceedings-Communications. vol.148, no.1; Feb. 2001; p.19-23 (3) Supporting service differentiation in wireless packet networks using distributed control Veres-A; Campbell-AT; Barry-M; Li-Hsiang-Sun IEEE-Journal-on-Selected-Areas-in-Communications. vol.19, no.10; Oct. 2001; p.2081-93 Also, some of the publications of Prof Sivalingam at this site "http://www.eecs.wsu.edu/~dawn/wireless-pubs.html" seem quite helpful. Perhaps we can think of forming a WDS discussion/working group about this time. -AGA _______________________________________________________ Amoakoh Gyasi-Agyei Centre for Internet Technology Research (CITR)/Centre for Telecom Information Networking (CTIN) Electrical & Electronic Enginnering Department Adelaide University Level 5, 10 Pulteney St., Adelaide 5000 Tel: +61 8 8303 6902 (office) Tel: +61 402 638 141 (mbl) Tel: +61 8 8271 4534 (home) Fax: +61 8 8303 4405 (office) http://aaron.eleceng.adelaide.edu.au/Personal/amoakoh/ --------------28A0E3DF4960A9DCADA1F684 Content-Type: text/x-vcard; charset=us-ascii; name="amoakoh.vcf" Content-Description: Card for Amoakoh Gyasi-Agyei Content-Disposition: attachment; filename="amoakoh.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Gyasi-Agyei;Amoakoh tel;cell:+61 402 638 141 tel;fax:+61 8 8303 4405 tel;work:+61 8 8303 6209 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:Amoakoh@eleceng.adelaide.edu.au fn:Amoakoh end:vcard --------------28A0E3DF4960A9DCADA1F684-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Mar 8 04:31: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 EAA26959 for ; Fri, 8 Mar 2002 04:31:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16040 for diffserv-archive@odin.ietf.org; Fri, 8 Mar 2002 04:31:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14240; Fri, 8 Mar 2002 04:15:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14209 for ; Fri, 8 Mar 2002 04:15:18 -0500 (EST) Received: from tssg.wit.ie (tssg.wit.ie [193.1.185.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26564 for ; Fri, 8 Mar 2002 04:15:15 -0500 (EST) Received: from aquex ([10.37.1.90]) by tssg.wit.ie (8.11.6/8.11.6/SuSE Linux 0.5) with SMTP id g289GGi01162 for ; Fri, 8 Mar 2002 09:16:16 GMT From: "Chamil PW Kulatunga" To: Date: Fri, 8 Mar 2002 09:19:26 -0000 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: [Diffserv] Linux TC Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi DiffServ members, I want to get implementation informations on Linux DiffServ qdisc dsmark. Thnaks. Chamil _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Mar 8 05:49: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 FAA28344 for ; Fri, 8 Mar 2002 05:49:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA21738 for diffserv-archive@odin.ietf.org; Fri, 8 Mar 2002 05:49:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19381; Fri, 8 Mar 2002 05:17:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19352 for ; Fri, 8 Mar 2002 05:17:30 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27778 for ; Fri, 8 Mar 2002 05:17:27 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA11100; Fri, 8 Mar 2002 11:16:59 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA63074 from ; Fri, 8 Mar 2002 11:16:53 +0100 Message-Id: <3C888F87.901FF328@hursley.ibm.com> Date: Fri, 08 Mar 2002 11:16:39 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Chamil PW Kulatunga Cc: diffserv@ietf.org Subject: Re: [Diffserv] Linux TC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Please try the diffserv implementation list, not the standardization list... http://www.atnf.csiro.au/news/exploders/dsimplementation.html Brian Carpenter diffserv WG chair Chamil PW Kulatunga wrote: > > Hi DiffServ members, > > I want to get implementation informations on Linux DiffServ qdisc dsmark. > > Thnaks. > > Chamil > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Mar 8 07:43: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 HAA01989 for ; Fri, 8 Mar 2002 07:43:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA28480 for diffserv-archive@odin.ietf.org; Fri, 8 Mar 2002 07:43:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25157; Fri, 8 Mar 2002 06:56:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25127 for ; Fri, 8 Mar 2002 06:56:31 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29288; Fri, 8 Mar 2002 06:56:29 -0500 (EST) Message-Id: <200203081156.GAA29288@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 08 Mar 2002 06:56:29 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-06.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Differentiated Services Quality of Service Policy Information Base Author(s) : M. Fine, K. McCloghrie et al. Filename : draft-ietf-diffserv-pib-06.txt Pages : 94 Date : 07-Mar-02 This document describes a Policy Information Base (PIB) for a device implementing the Differentiated Services Architecture. The Policy Rule Classes defined here provide policy control of resources implementing the Differentiated Services Architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-06.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-diffserv-pib-06.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-diffserv-pib-06.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: <20020307115856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307115856.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sat Mar 9 14:18: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 OAA14986 for ; Sat, 9 Mar 2002 14:18:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06929 for diffserv-archive@odin.ietf.org; Sat, 9 Mar 2002 14:18:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06260; Sat, 9 Mar 2002 14:03:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06232 for ; Sat, 9 Mar 2002 14:03:11 -0500 (EST) Received: from hotmail.com (f221.pav1.hotmail.com [64.4.31.221]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14495 for ; Sat, 9 Mar 2002 14:03:07 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 9 Mar 2002 11:02:39 -0800 Received: from 35.9.41.133 by pv1fd.pav1.hotmail.msn.com with HTTP; Sat, 09 Mar 2002 19:02:39 GMT X-Originating-IP: [35.9.41.133] From: "M Rashid Qazi" To: diffserv@ietf.org Date: Sat, 09 Mar 2002 19:02:39 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 09 Mar 2002 19:02:39.0213 (UTC) FILETIME=[FB8B71D0:01C1C79C] Subject: [Diffserv] one basic question Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org
Hi All,
I am working with some pricing project for differentiated services and utilizing NS2 software for that. My question is somewhat very basic, but I didnt found any info for that.
In a diffserv domain, the packets can be catagorized or prioritized, but is this prioritization can be implent on a single source -destination pair? or we can enqueued packets on the basis of their Flow IDs (fid) containing source -destination address and their port numbers?
If I have three types of packets (with different bitrate) coming from a single node to an edge router (regardless from where they belong originally or how the streams are generated) , but every type is carrying a different fid, is that possible that I can assign every priority queue to every single type at the edge router?
 
Thanks for your support
rashid..

Get your FREE download of MSN Explorer at http://explorer.msn.com.
_______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Mar 11 00:27: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 AAA21343 for ; Mon, 11 Mar 2002 00:27:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA02618 for diffserv-archive@odin.ietf.org; Mon, 11 Mar 2002 00:27:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00865; Sun, 10 Mar 2002 23:58:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00834 for ; Sun, 10 Mar 2002 23:58:23 -0500 (EST) Received: from ganesh.ctd.hctech.com ([202.54.64.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21042 for ; Sun, 10 Mar 2002 23:58:17 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 10:28:20 +0530 Message-ID: From: "Ramakrishnan.R (Networking) - CTD, Chennai." To: M Rashid Qazi Cc: diffserv@ietf.org Subject: RE: [Diffserv] one basic question Date: Mon, 11 Mar 2002 10:25:00 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C8B8.E637D180" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@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_001_01C1C8B8.E637D180 Content-Type: text/plain; charset="iso-8859-1" Hi Rashid, As for as diffserv is considered, the treatment is given separately for the packets based ONLY on DSCP value. However, if your router exists in the edge of the DS domain, you can give different treatments based on Source/Destination Pair. However, this violates the diffserv implementation because diffserv is solely for flow aggregates. Am i correct? Regards Ramki -----Original Message----- From: M Rashid Qazi [mailto:qmrashid@hotmail.com] Sent: Sunday, March 10, 2002 12:33 AM To: diffserv@ietf.org Subject: [Diffserv] one basic question Hi All, I am working with some pricing project for differentiated services and utilizing NS2 software for that. My question is somewhat very basic, but I didnt found any info for that. In a diffserv domain, the packets can be catagorized or prioritized, but is this prioritization can be implent on a single source -destination pair? or we can enqueued packets on the basis of their Flow IDs (fid) containing source -destination address and their port numbers? If I have three types of packets (with different bitrate) coming from a single node to an edge router (regardless from where they belong originally or how the streams are generated) , but every type is carrying a different fid, is that possible that I can assign every priority queue to every single type at the edge router? Thanks for your support rashid.. _____ Get your FREE download of MSN Explorer at http://explorer.msn.com . _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.ht ml ------_=_NextPart_001_01C1C8B8.E637D180 Content-Type: text/html; charset="iso-8859-1"
Hi Rashid,
As for as diffserv is considered, the treatment is given separately for the packets based ONLY on DSCP value. However, if your router exists in the edge of the DS domain, you can give different treatments based on Source/Destination Pair. However, this violates the diffserv implementation because diffserv is solely for flow aggregates.
 
Am i correct?
 
Regards
Ramki
-----Original Message-----
From: M Rashid Qazi [mailto:qmrashid@hotmail.com]
Sent: Sunday, March 10, 2002 12:33 AM
To: diffserv@ietf.org
Subject: [Diffserv] one basic question

Hi All,
I am working with some pricing project for differentiated services and utilizing NS2 software for that. My question is somewhat very basic, but I didnt found any info for that.
In a diffserv domain, the packets can be catagorized or prioritized, but is this prioritization can be implent on a single source -destination pair? or we can enqueued packets on the basis of their Flow IDs (fid) containing source -destination address and their port numbers?
If I have three types of packets (with different bitrate) coming from a single node to an edge router (regardless from where they belong originally or how the streams are generated) , but every type is carrying a different fid, is that possible that I can assign every priority queue to every single type at the edge router?
 
Thanks for your support
rashid..

Get your FREE download of MSN Explorer at http://explorer.msn.com.
_______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
------_=_NextPart_001_01C1C8B8.E637D180-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Mar 11 05:08: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 FAA03130 for ; Mon, 11 Mar 2002 05:08:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA29865 for diffserv-archive@odin.ietf.org; Mon, 11 Mar 2002 05:08:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28113; Mon, 11 Mar 2002 04:52:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28082 for ; Mon, 11 Mar 2002 04:52:50 -0500 (EST) Received: from cgprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02838 for ; Mon, 11 Mar 2002 04:52:41 -0500 (EST) Received: from [193.136.92.65] (HELO trantor.it.pt) by cgprelay.ua.pt (CommuniGate Pro SMTP 3.5.6) with ESMTP id 1646239; Mon, 11 Mar 2002 09:52:30 +0000 Received: from laika (laika.av.it.pt [193.136.92.207]) by trantor.it.pt (sendmail) with SMTP id F30752C1A; Mon, 11 Mar 2002 09:50:58 +0000 (PWT) From: "Emanuel Moreira" To: "Ramakrishnan.R (Networking) - CTD, Chennai." , "M Rashid Qazi" Cc: Subject: RE: [Diffserv] one basic question Date: Mon, 11 Mar 2002 09:50:54 -0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1C8E2.3C73CA30" 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 V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1C8E2.3C73CA30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi, But the source/destination addresses or the source/destination port or any other pair of information, that helps to classify the packets and so to create a flow can be used, and does not violate the diffserv implementation, correct? -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Ramakrishnan.R (Networking) - CTD, Chennai. Sent: segunda-feira, 11 de Março de 2002 4:55 To: M Rashid Qazi Cc: diffserv@ietf.org Subject: RE: [Diffserv] one basic question Hi Rashid, As for as diffserv is considered, the treatment is given separately for the packets based ONLY on DSCP value. However, if your router exists in the edge of the DS domain, you can give different treatments based on Source/Destination Pair. However, this violates the diffserv implementation because diffserv is solely for flow aggregates. Am i correct? Regards Ramki -----Original Message----- From: M Rashid Qazi [mailto:qmrashid@hotmail.com] Sent: Sunday, March 10, 2002 12:33 AM To: diffserv@ietf.org Subject: [Diffserv] one basic question Hi All, I am working with some pricing project for differentiated services and utilizing NS2 software for that. My question is somewhat very basic, but I didnt found any info for that. In a diffserv domain, the packets can be catagorized or prioritized, but is this prioritization can be implent on a single source -destination pair? or we can enqueued packets on the basis of their Flow IDs (fid) containing source -destination address and their port numbers? If I have three types of packets (with different bitrate) coming from a single node to an edge router (regardless from where they belong originally or how the streams are generated) , but every type is carrying a different fid, is that possible that I can assign every priority queue to every single type at the edge router? Thanks for your support rashid.. ---------------------------------------------------------------------------- Get your FREE download of MSN Explorer at http://explorer.msn.com. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.ht ml ------=_NextPart_000_0005_01C1C8E2.3C73CA30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
But=20 the source/destination addresses or the = source/destination port=20 or any other pair of information, that helps to classify the = packets=20 and so to create a flow can be used, and does not violate the diffserv=20 implementation, correct?
-----Original Message-----
From: = diffserv-admin@ietf.org=20 [mailto:diffserv-admin@ietf.org]On Behalf Of Ramakrishnan.R=20 (Networking) - CTD, Chennai.
Sent: segunda-feira, 11 de = Mar=E7o de=20 2002 4:55
To: M Rashid Qazi
Cc:=20 diffserv@ietf.org
Subject: RE: [Diffserv] one basic=20 question

Hi=20 Rashid,
As = for as diffserv=20 is considered, the treatment is given separately for the packets=20 based ONLY on DSCP value. However, if your router exists in the = edge of=20 the DS domain, you can give different treatments based on = Source/Destination=20 Pair. However, this violates the diffserv implementation because = diffserv is=20 solely for flow aggregates.
 
Am i=20 correct?
 
Regards
Ramki
-----Original Message-----
From: M Rashid Qazi=20 [mailto:qmrashid@hotmail.com]
Sent: Sunday, March 10, 2002 = 12:33=20 AM
To: diffserv@ietf.org
Subject: [Diffserv] one = basic=20 question

Hi All,
I am working with some pricing project for differentiated = services and=20 utilizing NS2 software for that. My question is somewhat very basic, = but I=20 didnt found any info for that.
In a diffserv domain, the packets can be catagorized or = prioritized,=20 but is this prioritization can be implent on a single source = -destination=20 pair? or we can enqueued packets on the basis of their Flow IDs = (fid)=20 containing source -destination address and their port numbers?
If I have three types of packets (with different bitrate) = coming from a=20 single node to an edge router (regardless from where they belong = originally=20 or how the streams are generated) , but every type is carrying a = different=20 fid, is that possible that I can assign every priority queue to = every single=20 type at the edge router?
 
Thanks for your support
rashid..

Get your FREE download of MSN Explorer at http://explorer.msn.com.
__= _____________________________________________=20 diffserv mailing list diffserv@ietf.org=20 https://www1.ietf.org/mailman/listinfo/diffserv Archive:=20 = http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist= .html=20
------=_NextPart_000_0005_01C1C8E2.3C73CA30-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Mar 11 06: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 GAA04279 for ; Mon, 11 Mar 2002 06:05:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA05276 for diffserv-archive@odin.ietf.org; Mon, 11 Mar 2002 06:05:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03557; Mon, 11 Mar 2002 05:51:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03532 for ; Mon, 11 Mar 2002 05:51:38 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03978 for ; Mon, 11 Mar 2002 05:51:30 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA13346; Mon, 11 Mar 2002 11:51:01 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26642 from ; Mon, 11 Mar 2002 11:50:56 +0100 Message-Id: <3C8C8C02.29F213FC@hursley.ibm.com> Date: Mon, 11 Mar 2002 11:50:42 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Emanuel Moreira Cc: "Ramakrishnan.R (Networking) - CTD, Chennai." , M Rashid Qazi , diffserv@ietf.org Subject: Re: [Diffserv] one basic question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This conversation has been redirected to the diffserv-interest list To Subscribe: diffserv-interest-request@ietf.org Rgds Brian Carpenter diffserv WG co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Wed Mar 13 21:52:46 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 VAA28825 for ; Wed, 13 Mar 2002 21:52:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA08109 for diffserv-archive@odin.ietf.org; Wed, 13 Mar 2002 21:52:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07205; Wed, 13 Mar 2002 21:38:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07169 for ; Wed, 13 Mar 2002 21:38:05 -0500 (EST) Received: from smtp.postech.ac.kr (smtp1.postech.ac.kr [141.223.2.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28562 for ; Wed, 13 Mar 2002 21:38:00 -0500 (EST) Received: from comus (comus.postech.ac.kr [141.223.92.55]) by smtp.postech.ac.kr (v3smtp 8.11.6.4/8.11.1) with SMTP id g2E2g6b12525 for ; Thu, 14 Mar 2002 11:42:06 +0900 (KST) From: "Geunhyung Kim" To: "diffserv" Date: Thu, 14 Mar 2002 11:31:49 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id VAA07171 Subject: [Diffserv] it's only test mail Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit None of us is as smart as all of us ========================================== Geunhyung Kim E-mail: geunkim@postech.edu Tel: +82-54-279-5655 Fax: +82-54-279-5699 Networking & Distributed Systems Lab. CSE POSTECH =========================================== _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Wed Mar 13 22:27: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 WAA29290 for ; Wed, 13 Mar 2002 22:27:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA10461 for diffserv-archive@odin.ietf.org; Wed, 13 Mar 2002 22:27:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09331; Wed, 13 Mar 2002 22:11:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09299 for ; Wed, 13 Mar 2002 22:11:15 -0500 (EST) Received: from smtp.postech.ac.kr (smtp1.postech.ac.kr [141.223.2.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29002 for ; Wed, 13 Mar 2002 22:11:12 -0500 (EST) Received: from comus (comus.postech.ac.kr [141.223.92.55]) by smtp.postech.ac.kr (v3smtp 8.11.6.4/8.11.1) with SMTP id g2E3FLb13445 for ; Thu, 14 Mar 2002 12:15:21 +0900 (KST) From: "Geunhyung Kim" To: "diffserv" Date: Thu, 14 Mar 2002 12:05:05 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id WAA09300 Subject: [Diffserv] Question about Assured service Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hello All, I have some questions about classes about Assured service. In RFC, four service classes and three drop preferences are defined. I don't make a figure how to differentiate the service classes. Which parameters can be used to differentiate the four service classes. Best regards, Geunhyung None of us is as smart as all of us ========================================== Geunhyung Kim E-mail: geunkim@postech.edu Tel: +82-54-279-5655 Fax: +82-54-279-5699 Networking & Distributed Systems Lab. CSE POSTECH =========================================== _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 14 02:08: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 CAA11645 for ; Thu, 14 Mar 2002 02:08:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA02734 for diffserv-archive@odin.ietf.org; Thu, 14 Mar 2002 02:08:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA01412; Thu, 14 Mar 2002 01:54:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA01381 for ; Thu, 14 Mar 2002 01:54:25 -0500 (EST) Received: from mailweb15.rediffmail.com ([203.199.83.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03378 for ; Thu, 14 Mar 2002 01:54:18 -0500 (EST) Received: (qmail 5108 invoked by uid 510); 14 Mar 2002 06:51:56 -0000 Date: 14 Mar 2002 06:51:56 -0000 Message-ID: <20020314065156.5106.qmail@mailweb15.rediffmail.com> Received: from unknown (202.54.64.9) by rediffmail.com via HTTP; 14 Mar 2002 06:51:56 -0000 MIME-Version: 1.0 From: "Manish Ramesh K" Reply-To: "Manish Ramesh K" To: diffserv@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Diffserv] Weighted Fair Queuing and AF PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org hi how can one implement AF PHB using Weighted Fair Queuing schduling discipline??.how different will it be if EF PHB is also supported?.thanks in advance Manish. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 14 04:33: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 EAA13407 for ; Thu, 14 Mar 2002 04:33:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12434 for diffserv-archive@odin.ietf.org; Thu, 14 Mar 2002 04:33:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10337; Thu, 14 Mar 2002 04:17:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10126 for ; Thu, 14 Mar 2002 04:16:28 -0500 (EST) Received: from satanas.hds.utc.fr (satanas.hds.utc.fr [195.83.157.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12982; Thu, 14 Mar 2002 04:16:20 -0500 (EST) Received: from pcaaron.utc.fr (pcaaron.gi.utc [172.17.2.141]) by satanas.hds.utc.fr (Postfix) with ESMTP id 7071C5C24; Thu, 14 Mar 2002 10:16:11 +0100 (MET) Message-Id: <5.1.0.14.2.20020314031051.02269810@pophds.gi.utc> X-Sender: striegel@pophds.gi.utc X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Mar 2002 03:15:28 -0600 To: "Geunhyung Kim" , "diffserv" , diffserv-interest@ietf.org From: Aaron D Striegel Subject: Re: [Diffserv] Question about Assured service In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This conversation has been redirected to the diffserv-interest list To Subscribe: diffserv-interest-request@ietf.org Thanks Aaron Striegel DS mailing list admin _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 14 04:34: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 EAA13430 for ; Thu, 14 Mar 2002 04:34:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12505 for diffserv-archive@odin.ietf.org; Thu, 14 Mar 2002 04:34:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10495; Thu, 14 Mar 2002 04:18:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10237 for ; Thu, 14 Mar 2002 04:17:08 -0500 (EST) Received: from satanas.hds.utc.fr (satanas.hds.utc.fr [195.83.157.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12991; Thu, 14 Mar 2002 04:17:05 -0500 (EST) Received: from pcaaron.utc.fr (pcaaron.gi.utc [172.17.2.141]) by satanas.hds.utc.fr (Postfix) with ESMTP id 3C3625C10; Thu, 14 Mar 2002 10:16:57 +0100 (MET) Message-Id: <5.1.0.14.2.20020314031546.0220b628@pophds.gi.utc> X-Sender: striegel@pophds.gi.utc X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Mar 2002 03:16:16 -0600 To: "Manish Ramesh K" , diffserv@ietf.org, diffserv-interest@ietf.org From: Aaron D Striegel Subject: Re: [Diffserv] Weighted Fair Queuing and AF PHB In-Reply-To: <20020314065156.5106.qmail@mailweb15.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This conversation has been redirected to the diffserv-interest list To Subscribe: diffserv-interest-request@ietf.org Thanks Aaron Striegel DS mailing list admin _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Mar 18 09:48: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 JAA06273 for ; Mon, 18 Mar 2002 09:48:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07203 for diffserv-archive@odin.ietf.org; Mon, 18 Mar 2002 09:48:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05368; Mon, 18 Mar 2002 09:22:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04931 for ; Mon, 18 Mar 2002 09:13:28 -0500 (EST) Received: from roam.psg.com (exim@roam.psg.com.ietf53.cw.net [166.63.185.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05652 for ; Mon, 18 Mar 2002 09:13:23 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 4.00) id 16mxt8-0002PM-00; Mon, 18 Mar 2002 08:13:26 -0600 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Message-Id: Date: Mon, 18 Mar 2002 08:13:26 -0600 Content-Transfer-Encoding: 7bit Subject: [Diffserv] why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit wearing my iesg hat but being just a stupid operator, i am trying to understand the pib/mib controversy. fyi, i currently use snmp heavily for monitoring devices on my network. i configure using large db-driven code and spew text-based cli to the devices. let's assume i want to take the leap to a binary, as opposed to textual, configuration language. i.e. for some reason(s) [which we will PLEASE NOT discuss here] i decide to move from pushing text-based cli configs out to pushing a binary format. hence, i would have to push my vendors to implement snmp/cops writes for all configuration aspects of all devices. this would be big cost for both me and for my vendors. why would cops/pibs be significantly better (remember it has to replace my current investment, so it can not be 'just as good') than snmp/mibs? randy _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Mar 18 11:46: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 LAA10513 for ; Mon, 18 Mar 2002 11:46:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15449 for diffserv-archive@odin.ietf.org; Mon, 18 Mar 2002 11:46:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12954; Mon, 18 Mar 2002 11:16:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12926 for ; Mon, 18 Mar 2002 11:16:25 -0500 (EST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08653 for ; Mon, 18 Mar 2002 11:16:19 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2IGG6h11417 for ; Mon, 18 Mar 2002 16:16:10 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2IGF5S03144 for ; Mon, 18 Mar 2002 16:15:05 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031808193426771 ; Mon, 18 Mar 2002 08:19:34 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 08:16:10 -0800 Message-ID: <59885C5E3098D511AD690002A5072D3C0451B938@orsmsx111.jf.intel.com> From: "Hahn, Scott" To: Randy Bush , rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Date: Mon, 18 Mar 2002 08:16:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Randy, Here is a list that Dave Durham recently sent to the RAP mailing list that answers your question. -Scott -------------------------- * COPS-PR supports a completely transactional model: o Messages represent atomic transactions. o All parts of a transaction either succeed or fail. o On failure, the device automatically rolls-back to its last operational state. o The server can also quickly switch between provisioned contexts (eg. from day policies to night policies). o Failures and errors are very precisely reported PEP to PDP. o Supports large transactions. o Implementations do not worry about caching random attributes waiting for a complete transaction (as is a problem for SNMP), everything in the transaction comes at once in one message. * COPS-PR supports structured row-level access: o A row represents an atomic unit for data communication. o There is no need for rowstatus, owner strings and the like. o A row is essentially an indivisible structured data type. o OID data is sent only once per row, representing a 10x gain in on-the-wire efficiency over SNMP for e.g. a packet classifier filter w/ 10 fields. * COPS-PR supports multi-manager control without the danger of corruption: o Each PDP has its own data instance space on the PEP which cannot be manipulated by other PDPs. o PDPs data instances are isolated by the message-level client-type field. * Completely event-driven: o There is no polling in COPS-PR. o PEPs notify PDPs only when there is something to report and vice versa. o Persistent TCP connection means no 3-way handshake overhead for messages. o TCP heartbeat verifies aggregate communication over the connection and confirms operational status. * Multiple Levels of security: o COPS intrinsically provides message-level integrity with PEP and PDP authentication. o COPS over TLS provides additional level of authentication and private communication. o IPSec provides yet another level of authentication and privacy. o ... All communication is secure before the first COPS-PR message is even exchanged. * Object-Oriented Data Model and Data Definition Language. o COPS-PR via the SPPI improves the state of the art over the SNMP SMI. - Allows inheritance of data structures. - Allows typed references. - Allows structured containment. - Allows typed associations. - Allows typed groupings. - Adds support for Integer64 and other basic data types. - Maximizes reuse of data definitions. o Via the framework PIB provides a data model that can be reused/shared across PIBs for common/redundant policy functions and definitions. o All new PIB definitions can integrate with existing PIB definitions to add features and capabilities. o Common data-path theme throughout COPS-PR PIBs. * Capabilities Reporting: o COPS-PR via the framework PIB provides a mechanism by which the PEP clearly yet generically describes what PIBs and parts of PIBs it supports. o Both semantic and syntactic capabilities are generically communicated PEP to PDP. * COPS-PR integrates event outsourcing and provisioning: o Eg. when an RSVP message is signaled & outsourced PEP-PDP, a diffserv provisioning policy can be pushed down. o Integrated provisioning and outsourcing can be accomplished over one message RTT. One RTT is critical when the time granularity for allocation of resources is dictated by, for example, call setup time. o Policy usage information can be used to signal a policy change. * COPS provides built-in synchronization and failover: o PEP automatically moves to backup PDPs on failure. o PDP quickly synchronizes state with PEP after communication failure. - Quick last transaction ID verifies PEP state. - PDP can resynchronize all or any selected state. o Enables quick TCP session recovery. * COPS-PR inherently was designed to run over reliable transport via TCP. Well, anyway, these are some of the main reasons for COPS-PR that come to my mind. Cheers, -Dave > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, March 18, 2002 6:13 AM > To: rap@ops.ietf.org; diffserv@ietf.org > Cc: ipsec-policy@vpnc.org > Subject: why i should like pibs > > > wearing my iesg hat but being just a stupid operator, i am trying to > understand the pib/mib controversy. fyi, i currently use snmp heavily > for monitoring devices on my network. i configure using > large db-driven > code and spew text-based cli to the devices. > > let's assume i want to take the leap to a binary, as opposed > to textual, > configuration language. i.e. for some reason(s) [which we will PLEASE > NOT discuss here] i decide to move from pushing text-based cli configs > out to pushing a binary format. > > hence, i would have to push my vendors to implement snmp/cops > writes for > all configuration aspects of all devices. this would be big cost for > both me and for my vendors. > > why would cops/pibs be significantly better (remember it has > to replace > my current investment, so it can not be 'just as good') than > snmp/mibs? > > randy > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Mar 18 12:45:00 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 MAA13058 for ; Mon, 18 Mar 2002 12:44:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21609 for diffserv-archive@odin.ietf.org; Mon, 18 Mar 2002 12:45:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20063; Mon, 18 Mar 2002 12:28:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20034 for ; Mon, 18 Mar 2002 12:28:13 -0500 (EST) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12402 for ; Mon, 18 Mar 2002 12:28:09 -0500 (EST) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g2IHRwUu014377; Mon, 18 Mar 2002 18:27:58 +0100 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g2IHRwS30425; Mon, 18 Mar 2002 18:27:58 +0100 Date: Mon, 18 Mar 2002 18:27:58 +0100 Message-Id: <200203181727.g2IHRwS30425@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: scott.hahn@intel.com CC: rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org In-reply-to: <59885C5E3098D511AD690002A5072D3C0451B938@orsmsx111.jf.intel.com> (scott.hahn@intel.com) References: <59885C5E3098D511AD690002A5072D3C0451B938@orsmsx111.jf.intel.com> Subject: [Diffserv] Re: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> Hahn, Scott writes: Scott> Randy, Here is a list that Dave Durham recently sent to the RAP Scott> mailing list that answers your question. [...] Some of the things on the list are equally true for SNMP/MIBs (e.g. messages are atomic transactions) while some other things are IMHO misleading (e.g. inheritance of data structures in SPPI is just not the kind of inheritance we are used to in the OO world). /js -- Juergen Schoenwaelder _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Mar 18 13:51:56 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 NAA15245 for ; Mon, 18 Mar 2002 13:51:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26009 for diffserv-archive@odin.ietf.org; Mon, 18 Mar 2002 13:51:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24686; Mon, 18 Mar 2002 13:34:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24655 for ; Mon, 18 Mar 2002 13:34:03 -0500 (EST) Received: from mx03.gis.net (mx03.gis.net [208.218.130.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14620 for ; Mon, 18 Mar 2002 13:33:56 -0500 (EST) Received: from callisto.jdscons.com ([216.243.57.15]) by mx03.gis.net; Mon, 18 Mar 2002 13:33:50 -0500 (EST) From: Jon Saperia Reply-To: saperia@jdscons.com To: Randy Bush , rap@ops.ietf.org, diffserv@ietf.org Date: Mon, 18 Mar 2002 13:16:22 -0500 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain Cc: ipsec-policy@vpnc.org, snmpconf@snmpconf.com References: In-Reply-To: MIME-Version: 1.0 Message-Id: <02031813325100.00987@callisto.jdscons.com> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Diffserv] Re: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit On Mon, 18 Mar 2002, Randy Bush wrote: > > why would cops/pibs be significantly better (remember it has to replace > my current investment, so it can not be 'just as good') than snmp/mibs? > > randy Randy you may recall discussions on this topic several years ago and the internet drafts published by various parties about the merits of a COPS versus SNMP approach. I co-authored one of those now expired drafts with Juergen. Time and events have overtaken some of the material in the draft but here is a URL to a site that has a post script version of the original ID that discusses your questions. http://www.ibr.cs.tu-bs.de/vs/papers/policy-tr-00-02.ps.gz Since publication of those early drafts, SNMPCONF has incorportated some of the changes suggested and the COPS folks have made improvements in that approach as well. I suspect part of what you have to figure out in the context of your question is: Is there an advantage that remains with a PIB approach, and if there is one does it ofset the balance of the cost you point to. The data in the document may be helpful. Further a read of the current SNMPCONF documents on the WG web site may be helpful. Even though there is probably duplication is the mail lists, I have copied the SNMPCONF WG on this since it is relevant to the work that is taking place there. /jon ---- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Mar 18 15:10: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 PAA18277 for ; Mon, 18 Mar 2002 15:10:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02477 for diffserv-archive@odin.ietf.org; Mon, 18 Mar 2002 15:10:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00600; Mon, 18 Mar 2002 14:49:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00569 for ; Mon, 18 Mar 2002 14:49:45 -0500 (EST) Received: from hqmail01.ellacoya.com (hqmail01out.ellacoya.com [64.223.136.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17424 for ; Mon, 18 Mar 2002 14:49:41 -0500 (EST) Received: by hqmail01.ellacoya.com with Internet Mail Service (5.5.2655.55) id ; Mon, 18 Mar 2002 14:45:16 -0500 Message-ID: From: "Weiss, Walter" To: "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Date: Mon, 18 Mar 2002 14:45:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Randy, I have two responses. 1. Political: Why are you asking? Why do you keep asking? And more importantly why, based on your criteria, haven't you asked for every non-monitoring MIB, or for various other works such as Policy Framework. I don't mind if we want to have a substantive discussion around the evolution of configuration management if you applied your own metrics consistently. If you believe that none of these technologies meet's your requirements, then freeze them all. At least then there will be some pressure on all the parties to converge to a common approach. Personally, I believe your question is a waste of time since the existing IETF process addresses your question when there is sufficient implementation to transition standards from proposed standards to draft standards. Certainly there have been lot's of standards that have never made it past proposed for the very reasons you describe. 2. Technical: Given your role, I would not expect you to use this PIB. The very argument justifying DiffServ is the same one that Operators use to manage their networks. Both share the goal of making the core of the network static and stupid (minimal configuration). By recognizing that the core should be kept as simple as possible, we also all understand that removing complexity from the core only moves the complexity to some other location: the edge. If the edge must configure bindings of QoS, Security, Access Control, Tunneling, Usage Accounting, etc, this drives specific requirements that COPS-PR comes closest to meeting. I could go into all the details here, but given that this thread inevitably de-evolves to the usual suspects and the usual posturing, I have serious doubts about the value of going into any more details. regards, -Walter > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, March 18, 2002 9:13 AM > To: rap@ops.ietf.org; diffserv@ietf.org > Cc: ipsec-policy@vpnc.org > Subject: why i should like pibs > > > wearing my iesg hat but being just a stupid operator, i am trying to > understand the pib/mib controversy. fyi, i currently use snmp heavily > for monitoring devices on my network. i configure using > large db-driven > code and spew text-based cli to the devices. > > let's assume i want to take the leap to a binary, as opposed > to textual, > configuration language. i.e. for some reason(s) [which we will PLEASE > NOT discuss here] i decide to move from pushing text-based cli configs > out to pushing a binary format. > > hence, i would have to push my vendors to implement snmp/cops > writes for > all configuration aspects of all devices. this would be big cost for > both me and for my vendors. > > why would cops/pibs be significantly better (remember it has > to replace > my current investment, so it can not be 'just as good') than > snmp/mibs? > > randy > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Mar 18 17:12: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 RAA22332 for ; Mon, 18 Mar 2002 17:12:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12034 for diffserv-archive@odin.ietf.org; Mon, 18 Mar 2002 17:12:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10011; Mon, 18 Mar 2002 16:58:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07203 for ; Mon, 18 Mar 2002 16:14:43 -0500 (EST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20446 for ; Mon, 18 Mar 2002 16:14:35 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2ILDP600862 for ; Mon, 18 Mar 2002 21:13:25 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2ILFEs22072 for ; Mon, 18 Mar 2002 21:15:14 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031813175625098 ; Mon, 18 Mar 2002 13:17:56 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 13:14:32 -0800 Message-ID: <090528C807DBD511A78200508B68D7A8157FC5@orsmsx112.jf.intel.com> From: "Yavatkar, Raj" To: "'Weiss, Walter'" , "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: RE: [Diffserv] RE: why i should like pibs Date: Mon, 18 Mar 2002 13:14:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Walter: Thanks for a really nice summary. I continue to be amazed at how Randy is applying a set of inconsistent standards to this work vs other work being done. Rob Coltun put the current state of IETF well in his departing message -- I was hoping that would wake up IESG to move away from such political shenanigans to getting work done especially when vendors with products or implementations are working towards standardization. Raj -----Original Message----- From: Weiss, Walter [mailto:wweiss@Ellacoya.com] Sent: Monday, March 18, 2002 11:45 AM To: 'Randy Bush'; rap@ops.ietf.org; diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: [Diffserv] RE: why i should like pibs Randy, I have two responses. 1. Political: Why are you asking? Why do you keep asking? And more importantly why, based on your criteria, haven't you asked for every non-monitoring MIB, or for various other works such as Policy Framework. I don't mind if we want to have a substantive discussion around the evolution of configuration management if you applied your own metrics consistently. If you believe that none of these technologies meet's your requirements, then freeze them all. At least then there will be some pressure on all the parties to converge to a common approach. Personally, I believe your question is a waste of time since the existing IETF process addresses your question when there is sufficient implementation to transition standards from proposed standards to draft standards. Certainly there have been lot's of standards that have never made it past proposed for the very reasons you describe. 2. Technical: Given your role, I would not expect you to use this PIB. The very argument justifying DiffServ is the same one that Operators use to manage their networks. Both share the goal of making the core of the network static and stupid (minimal configuration). By recognizing that the core should be kept as simple as possible, we also all understand that removing complexity from the core only moves the complexity to some other location: the edge. If the edge must configure bindings of QoS, Security, Access Control, Tunneling, Usage Accounting, etc, this drives specific requirements that COPS-PR comes closest to meeting. I could go into all the details here, but given that this thread inevitably de-evolves to the usual suspects and the usual posturing, I have serious doubts about the value of going into any more details. regards, -Walter > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, March 18, 2002 9:13 AM > To: rap@ops.ietf.org; diffserv@ietf.org > Cc: ipsec-policy@vpnc.org > Subject: why i should like pibs > > > wearing my iesg hat but being just a stupid operator, i am trying to > understand the pib/mib controversy. fyi, i currently use snmp heavily > for monitoring devices on my network. i configure using > large db-driven > code and spew text-based cli to the devices. > > let's assume i want to take the leap to a binary, as opposed > to textual, > configuration language. i.e. for some reason(s) [which we will PLEASE > NOT discuss here] i decide to move from pushing text-based cli configs > out to pushing a binary format. > > hence, i would have to push my vendors to implement snmp/cops > writes for > all configuration aspects of all devices. this would be big cost for > both me and for my vendors. > > why would cops/pibs be significantly better (remember it has > to replace > my current investment, so it can not be 'just as good') than > snmp/mibs? > > randy > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.ht ml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Mar 18 17:56:03 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 RAA24226 for ; Mon, 18 Mar 2002 17:56:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA16329 for diffserv-archive@odin.ietf.org; Mon, 18 Mar 2002 17:56:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14891; Mon, 18 Mar 2002 17:41:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14859 for ; Mon, 18 Mar 2002 17:41:13 -0500 (EST) Received: from hotmail.com (f50.pav1.hotmail.com [64.4.31.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23586 for ; Mon, 18 Mar 2002 17:41:09 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Mar 2002 14:40:42 -0800 Received: from 35.9.41.135 by pv1fd.pav1.hotmail.msn.com with HTTP; Mon, 18 Mar 2002 22:40:42 GMT X-Originating-IP: [35.9.41.135] From: "M Rashid Qazi" To: diffserv@ietf.org Date: Mon, 18 Mar 2002 22:40:42 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 18 Mar 2002 22:40:42.0953 (UTC) FILETIME=[EFC77B90:01C1CECD] Subject: [Diffserv] One more basic thing to understand Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org

One more basic question of mine is; If my one source , sending two different flows or different streams say stream1 and stream2 , is that possible to prioritize the packets of stream 1 over stream 2 at DS edge router , so that packets generated from same source , but belongs to stream1 goes in to red queue, and from stream 2 goes in to yellow or red queue.? or it just need me to put DSCP for AF11 on ToS byte of packets from stream 1, and DSCP  for AF12 on stream2 packets

thanks

 

rashid


Chat with friends online, try MSN Messenger: Click Here
_______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Mar 18 18:11: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 RAA22331 for ; Mon, 18 Mar 2002 17:12:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12039 for diffserv-archive@odin.ietf.org; Mon, 18 Mar 2002 17:12:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09967; Mon, 18 Mar 2002 16:58:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06630 for ; Mon, 18 Mar 2002 16:03:36 -0500 (EST) Received: from kanatamail.kanata.unispherenetworks.ca ([204.92.244.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20041 for ; Mon, 18 Mar 2002 16:03:31 -0500 (EST) Received: by kanatamail.kanata.unispherenetworks.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 16:03:05 -0500 Message-ID: From: "Bokaemper, Martin" To: "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Date: Mon, 18 Mar 2002 16:03:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > wearing my iesg hat but being just a stupid operator, i am > trying to understand the pib/mib controversy. > fyi, i currently use snmp heavily for monitoring devices > on my network. i configure using large db-driven code > and spew text-based cli to the devices. [...] > why would cops/pibs be significantly better (remember it has > to replace my current investment, so it can not be 'just as > good') than snmp/mibs? In my view COPS and PIBs don't provide very significant advantages for the generic configuration of the whole device. The main advantage of COPS is the state keeping capability - the PDP can make 'immediate' decisions based on the up-to-date knowledge of the PEPs state. This is obviously useful for COPS/RSVP and the outsourcing model, but also applies to COPS-PR. Up-to-date state and immediate provisioning is required for some applications that usually only affect small parts of a devices configuration. The rest of the configuration is (mostly) static and COPS offers little advantages there. For the static configuration, something built on top of the OPS-NM work seems to be the most promising path to me. Martin. -- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Mar 18 18:21:06 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 SAA25175 for ; Mon, 18 Mar 2002 18:21:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA18917 for diffserv-archive@odin.ietf.org; Mon, 18 Mar 2002 18:21:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17050; Mon, 18 Mar 2002 18:01:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17010 for ; Mon, 18 Mar 2002 18:01:30 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24391 for ; Mon, 18 Mar 2002 18:01:25 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id AAA159332; Tue, 19 Mar 2002 00:00:42 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2IN0fI125616; Tue, 19 Mar 2002 00:00:41 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26082 from ; Tue, 19 Mar 2002 00:00:38 +0100 Message-Id: <3C967184.41C12D4C@hursley.ibm.com> Date: Tue, 19 Mar 2002 00:00:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Yavatkar, Raj" Cc: "'Weiss, Walter'" , "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Subject: Re: [Diffserv] RE: why i should like pibs References: <090528C807DBD511A78200508B68D7A8157FC5@orsmsx112.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Let's try to stick to technical issues please, at least if you want to keep the diffserv list on this thread. The technical issue is: does COPS-PR have *significant* technical advantages over the existing alternatives, that would justify the added mechanisms and complexity? Brian "Yavatkar, Raj" wrote: > > Hi Walter: > > Thanks for a really nice summary. I continue to be amazed at how Randy is > applying a set of inconsistent standards to this work vs other work being > done. Rob Coltun put the current state of IETF well in his departing message > -- I was hoping that would wake up IESG to move away from such political > shenanigans to getting work done especially when vendors with products or > implementations are working towards standardization. > > Raj > > -----Original Message----- > From: Weiss, Walter [mailto:wweiss@Ellacoya.com] > Sent: Monday, March 18, 2002 11:45 AM > To: 'Randy Bush'; rap@ops.ietf.org; diffserv@ietf.org > Cc: ipsec-policy@vpnc.org > Subject: [Diffserv] RE: why i should like pibs > > Randy, > > I have two responses. > > 1. Political: > Why are you asking? Why do you keep asking? And more importantly why, based > on your criteria, haven't you asked for every non-monitoring MIB, or for > various other works such as Policy Framework. I don't mind if we want to > have a substantive discussion around the evolution of configuration > management if you applied your own metrics consistently. If you believe that > none of these technologies meet's your requirements, then freeze them all. > At least then there will be some pressure on all the parties to converge to > a common approach. Personally, I believe your question is a waste of time > since the existing IETF process addresses your question when there is > sufficient implementation to transition standards from proposed standards to > draft standards. Certainly there have been lot's of standards that have > never made it past proposed for the very reasons you describe. > > 2. Technical: > Given your role, I would not expect you to use this PIB. The very argument > justifying DiffServ is the same one that Operators use to manage their > networks. Both share the goal of making the core of the network static and > stupid (minimal configuration). By recognizing that the core should be kept > as simple as possible, we also all understand that removing complexity from > the core only moves the complexity to some other location: the edge. If the > edge must configure bindings of QoS, Security, Access Control, Tunneling, > Usage Accounting, etc, this drives specific requirements that COPS-PR comes > closest to meeting. I could go into all the details here, but given that > this thread inevitably de-evolves to the usual suspects and the usual > posturing, I have serious doubts about the value of going into any more > details. > > regards, > > -Walter > > > -----Original Message----- > > From: Randy Bush [mailto:randy@psg.com] > > Sent: Monday, March 18, 2002 9:13 AM > > To: rap@ops.ietf.org; diffserv@ietf.org > > Cc: ipsec-policy@vpnc.org > > Subject: why i should like pibs > > > > > > wearing my iesg hat but being just a stupid operator, i am trying to > > understand the pib/mib controversy. fyi, i currently use snmp heavily > > for monitoring devices on my network. i configure using > > large db-driven > > code and spew text-based cli to the devices. > > > > let's assume i want to take the leap to a binary, as opposed > > to textual, > > configuration language. i.e. for some reason(s) [which we will PLEASE > > NOT discuss here] i decide to move from pushing text-based cli configs > > out to pushing a binary format. > > > > hence, i would have to push my vendors to implement snmp/cops > > writes for > > all configuration aspects of all devices. this would be big cost for > > both me and for my vendors. > > > > why would cops/pibs be significantly better (remember it has > > to replace > > my current investment, so it can not be 'just as good') than > > snmp/mibs? > > > > randy _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Mar 18 18:23: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 SAA25262 for ; Mon, 18 Mar 2002 18:23:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA19180 for diffserv-archive@odin.ietf.org; Mon, 18 Mar 2002 18:23:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17831; Mon, 18 Mar 2002 18:09:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17795 for ; Mon, 18 Mar 2002 18:09:45 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24637 for ; Mon, 18 Mar 2002 18:09:39 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id AAA147936; Tue, 19 Mar 2002 00:09:07 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2IN97o57340; Tue, 19 Mar 2002 00:09:07 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA76382 from ; Tue, 19 Mar 2002 00:09:05 +0100 Message-Id: <3C96737E.10C8388F@hursley.ibm.com> Date: Tue, 19 Mar 2002 00:08:46 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: M Rashid Qazi Cc: diffserv@ietf.org Subject: Re: [Diffserv] One more basic thing to understand References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit If they are on different ports, the edge classifier can be configured to classify the two streams differently. "Prioritize" is the wrong word. Diffserv is not a simple priority system. Please direct any follow-up discussion to the diffserv-interest@ietf.org list To Subscribe: diffserv-intrerest-request@ietf.org In Body: subscribe your_email_address Brian Carpenter diffserv co-chair M Rashid Qazi wrote: > > One more basic question of mine is; If my one source , sending two different flows or different streams say stream1 and > stream2 , is that possible to prioritize the packets of stream 1 over stream 2 at DS edge router , so that packets generated > from same source , but belongs to stream1 goes in to red queue, and from stream 2 goes in to yellow or red queue.? or it just > need me to put DSCP for AF11 on ToS byte of packets from stream 1, and DSCP for AF12 on stream2 packets > > thanks > > > > rashid > > ------------------------------------------------------------------------------------------------------------------------------ > Chat with friends online, try MSN Messenger: Click Here > _______________________________________________ diffserv mailing list diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv Archive: > http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 19 03:03: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 DAA16817 for ; Tue, 19 Mar 2002 03:03:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA25884 for diffserv-archive@odin.ietf.org; Tue, 19 Mar 2002 03:03:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24516; Tue, 19 Mar 2002 02:46:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24073 for ; Mon, 18 Mar 2002 19:39:07 -0500 (EST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27418 for ; Mon, 18 Mar 2002 19:39:01 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2J0cpO02357 for ; Tue, 19 Mar 2002 00:38:52 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2J0dci06334 for ; Tue, 19 Mar 2002 00:39:38 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031816422521696 ; Mon, 18 Mar 2002 16:42:25 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 16:39:00 -0800 Message-ID: <090528C807DBD511A78200508B68D7A8157FD6@orsmsx112.jf.intel.com> From: "Yavatkar, Raj" To: "'Brian E Carpenter'" , "Yavatkar, Raj" Cc: "'Weiss, Walter'" , "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Subject: RE: [Diffserv] RE: why i should like pibs Date: Mon, 18 Mar 2002 16:38:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian: This work got chartered more than two years back. The technical issue you list was discussed at the beginning when existing alternatives had to be listed and proposed work had to be justified. I am sure IESG took a look at this before chartering the work. We had discussion on this topic many times before and as Walter says, it goes down to same supsects with same posturing. The fact is that real vendors with real products see the need for this work. I wish all the discussions and posturing at IETF (especially by IESG members) was purely technical -- we need to address somewhere how IESG works and how a single individual or two can hold up the work by many others. Raj -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Monday, March 18, 2002 3:00 PM To: Yavatkar, Raj Cc: 'Weiss, Walter'; 'Randy Bush'; rap@ops.ietf.org; diffserv@ietf.org; ipsec-policy@vpnc.org Subject: Re: [Diffserv] RE: why i should like pibs Let's try to stick to technical issues please, at least if you want to keep the diffserv list on this thread. The technical issue is: does COPS-PR have *significant* technical advantages over the existing alternatives, that would justify the added mechanisms and complexity? Brian "Yavatkar, Raj" wrote: > > Hi Walter: > > Thanks for a really nice summary. I continue to be amazed at how Randy is > applying a set of inconsistent standards to this work vs other work being > done. Rob Coltun put the current state of IETF well in his departing message > -- I was hoping that would wake up IESG to move away from such political > shenanigans to getting work done especially when vendors with products or > implementations are working towards standardization. > > Raj > > -----Original Message----- > From: Weiss, Walter [mailto:wweiss@Ellacoya.com] > Sent: Monday, March 18, 2002 11:45 AM > To: 'Randy Bush'; rap@ops.ietf.org; diffserv@ietf.org > Cc: ipsec-policy@vpnc.org > Subject: [Diffserv] RE: why i should like pibs > > Randy, > > I have two responses. > > 1. Political: > Why are you asking? Why do you keep asking? And more importantly why, based > on your criteria, haven't you asked for every non-monitoring MIB, or for > various other works such as Policy Framework. I don't mind if we want to > have a substantive discussion around the evolution of configuration > management if you applied your own metrics consistently. If you believe that > none of these technologies meet's your requirements, then freeze them all. > At least then there will be some pressure on all the parties to converge to > a common approach. Personally, I believe your question is a waste of time > since the existing IETF process addresses your question when there is > sufficient implementation to transition standards from proposed standards to > draft standards. Certainly there have been lot's of standards that have > never made it past proposed for the very reasons you describe. > > 2. Technical: > Given your role, I would not expect you to use this PIB. The very argument > justifying DiffServ is the same one that Operators use to manage their > networks. Both share the goal of making the core of the network static and > stupid (minimal configuration). By recognizing that the core should be kept > as simple as possible, we also all understand that removing complexity from > the core only moves the complexity to some other location: the edge. If the > edge must configure bindings of QoS, Security, Access Control, Tunneling, > Usage Accounting, etc, this drives specific requirements that COPS-PR comes > closest to meeting. I could go into all the details here, but given that > this thread inevitably de-evolves to the usual suspects and the usual > posturing, I have serious doubts about the value of going into any more > details. > > regards, > > -Walter > > > -----Original Message----- > > From: Randy Bush [mailto:randy@psg.com] > > Sent: Monday, March 18, 2002 9:13 AM > > To: rap@ops.ietf.org; diffserv@ietf.org > > Cc: ipsec-policy@vpnc.org > > Subject: why i should like pibs > > > > > > wearing my iesg hat but being just a stupid operator, i am trying to > > understand the pib/mib controversy. fyi, i currently use snmp heavily > > for monitoring devices on my network. i configure using > > large db-driven > > code and spew text-based cli to the devices. > > > > let's assume i want to take the leap to a binary, as opposed > > to textual, > > configuration language. i.e. for some reason(s) [which we will PLEASE > > NOT discuss here] i decide to move from pushing text-based cli configs > > out to pushing a binary format. > > > > hence, i would have to push my vendors to implement snmp/cops > > writes for > > all configuration aspects of all devices. this would be big cost for > > both me and for my vendors. > > > > why would cops/pibs be significantly better (remember it has > > to replace > > my current investment, so it can not be 'just as good') than > > snmp/mibs? > > > > randy _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.ht ml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 19 04:32:56 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 EAA18306 for ; Tue, 19 Mar 2002 04:32:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA01588 for diffserv-archive@odin.ietf.org; Tue, 19 Mar 2002 04:32:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00029; Tue, 19 Mar 2002 04:12:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29991 for ; Tue, 19 Mar 2002 04:12:53 -0500 (EST) Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17957 for ; Tue, 19 Mar 2002 04:12:50 -0500 (EST) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.52 2002/03/01 19:20:46 root Exp $) with SMTP id JAA18335 for ; Tue, 19 Mar 2002 09:12:22 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031901182932665 ; Tue, 19 Mar 2002 01:18:29 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 01:12:22 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DEC2@FMSMSX34> From: "Durham, David" To: Randy Bush , rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Date: Tue, 19 Mar 2002 01:12:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The Industry Realities COPS-PR & its PIBs Address: Dynamic Edge vs. Static Core - * COPS exists to address the Dynamic Provisioning needs of the Network's Edge. - Access Control Requests (from a variety of signaled protocols) - Controlled allocation of network resources - Micro-flow to aggregate traffic characterization - QoS - Security - Tunneling - Usage feedback * Meanwhile the Network Core tends to be static and deal with traffic aggregates being mainly concerned with routing & moving packets as fast as possible with minimal overhead. ... And ... It's a Multi-protocol World, COPS-PR is the Integrator. It closes the loop by tying together diverse signaling and provisioning mechanisms. Access control/session initiation/QoS requests come in and dynamically allocating/provisioning device resources based on policy goes out. Finally policy usage feedback closes the loop. Qualitative: * Enables entirely new classes of dynamic and integrated services that would not be possible without it. * It can integrate resource allocation and control for pretty much every in-band + out-of-band signaling protocol AND pretty much any form of resource Provisioning (eg. DiffServ). * BIG and RELIABLE TRANSACTIONS with rollback, failover and synchronization built-in. * It just works. It pulls outsourcing and provisioning together in one nice state-driven solution. Stateful means it maintains the state of all sessions on a device at all times as well as the resources they consume. * Completely event driven. * Device capabilities reporting is integral to the PIBs. Everything the device can syntactically parse and semantically do is precisely yet generically reported to the PDP. * Implementations are easy... COPS-PR sends you all your data in one complete reliable transaction. SNMP can throw all your attributes into a blender, so your implementation needs to be able to unscramble what comes out the other side, loss and all. * Three levels of easily understandable security. * New and improved data model and definition language with a consistent theme of a data-flow throughout. Enables better and improved tools over SNMP to make the job of implementers and users even easier! * Solves the multi-manager problem, data instances cannot overlap managers in COPS-PR and, thus, managers cannot step on one-another's toes. * NO row-status, owner description strings, storage-types, etc. to deal with AT ALL... And good riddance. Quantitative: * It can do one RTT provisioning based on outsourced events = well within call-setup time = as fast as is possible between two remote systems. * Intrinsically 10x more efficient on the wire than SNMP (1/10th the data to xfer) for e.g. the ever common DiffServ IP-filter tables. Efficiency multiplies with the more attributes you have in a row. * Faster, better & more. Change 10000 DiffServ Filter+meter+action entries through a T1 line with a 10msec RTT for 48byte packets: SNMP=((10000*8*498)/1540000)+((2*10000)/100)=226 Seconds. COPS=((10000*8*(498/10))/1540000)=2.59 Seconds. Is 100x improvement sufficiently better? And the multiple goes up with the more data you xfer. ... adding bandwidth doesn't help, it's that dang RTT. -Dave > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, March 18, 2002 6:13 AM > To: rap@ops.ietf.org; diffserv@ietf.org > Cc: ipsec-policy@vpnc.org > Subject: why i should like pibs > > wearing my iesg hat but being just a stupid operator, i am trying to > understand the pib/mib controversy. fyi, i currently use snmp heavily > for monitoring devices on my network. i configure using large db-driven > code and spew text-based cli to the devices. > > let's assume i want to take the leap to a binary, as opposed to textual, > configuration language. i.e. for some reason(s) [which we will PLEASE > NOT discuss here] i decide to move from pushing text-based cli configs > out to pushing a binary format. > > hence, i would have to push my vendors to implement snmp/cops writes for > all configuration aspects of all devices. this would be big cost for > both me and for my vendors. > > why would cops/pibs be significantly better (remember it has to replace > my current investment, so it can not be 'just as good') than snmp/mibs? > > randy _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 19 06:03: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 GAA19280 for ; Tue, 19 Mar 2002 06:03:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA06774 for diffserv-archive@odin.ietf.org; Tue, 19 Mar 2002 06:03:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05061; Tue, 19 Mar 2002 05:40:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04959 for ; Tue, 19 Mar 2002 05:40:17 -0500 (EST) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18909 for ; Tue, 19 Mar 2002 05:40:13 -0500 (EST) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g2JAe4Uu020053; Tue, 19 Mar 2002 11:40:04 +0100 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g2JAe4n10879; Tue, 19 Mar 2002 11:40:04 +0100 Date: Tue, 19 Mar 2002 11:40:04 +0100 Message-Id: <200203191040.g2JAe4n10879@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: david.durham@intel.com CC: randy@psg.com, rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org In-reply-to: <10C8636AE359D4119118009027AE99870DA5DEC2@FMSMSX34> (david.durham@intel.com) References: <10C8636AE359D4119118009027AE99870DA5DEC2@FMSMSX34> Subject: [Diffserv] Re: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> Durham, David writes: Dave> * Faster, better & more. Very impressive. Dave> Change 10000 DiffServ Filter+meter+action Dave> entries through a T1 line with a 10msec RTT for 48byte packets: Dave> SNMP=((10000*8*498)/1540000)+((2*10000)/100)=226 Seconds. Dave> COPS=((10000*8*(498/10))/1540000)=2.59 Seconds. Is 100x Dave> improvement sufficiently better? And the multiple goes up with Dave> the more data you xfer. ... adding bandwidth doesn't help, it's Dave> that dang RTT. Even with SNMP over UDP, you can stream set requests as long as they are independent of each other (which I guess is true if you populate a DiffServ filter table). Since you did not take TCP acks into account, I would say the second term is in equation (1) is 0 if you are smart enough. With SNMP over TCP, the difference also boils down to the reduced OID overhead in COPS-PR, which is probably not that much an issue on the T1 link. Anyway, I agree with other folks that it is pointless to redo all the discussions of the past so I better stop this. From my perspective, the major technical contribution of COPS-PR over SNMP is: a) TCP transport for large transactions when the network is up and running. b) Reduced OID overhead and less degrees of freedom to achieve the same thing. c) Slightly improved data definition language - but nothing which gives us real reusable and extensible data structures. d) State sharing and one manager assumption. e) Some failover support built into the protoco. Items a) and b) are technically easy to support in SNMP. The real problem here is the "SNMP community process" which is in blocking mode for several years now for various non-technical reasons. Item c) contains some minor enhancements over SMIv2 but if people want a really improved data definition language, then the SMIng WG is the place to go (sure, I am biased on this ;-). Items d) and e) are more interesting to implement in an SNMP world since one of the fundamentals in SNMP is the multi-manager assumption. Sure, one can setup existing SNMP access control to allow only one manager and one can define notifications to signal state changes - but this is not hard wired into the protocol (and I guess it will never be). The same is true for failover handling - it is not part of the SNMP protocol but can be built around it. Perhaps one could do interesting things by actually running SNMP over SCTP, which is perhaps theoretically much better suited for management purposes than UDP and TCP... [Perhaps this is closer to the technical summary Randy asked for.] /js -- Juergen Schoenwaelder _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 19 08:08:46 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 IAA20897 for ; Tue, 19 Mar 2002 08:08:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13272 for diffserv-archive@odin.ietf.org; Tue, 19 Mar 2002 08:08:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11901; Tue, 19 Mar 2002 07:48:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11869 for ; Tue, 19 Mar 2002 07:48:36 -0500 (EST) Received: from mx03.gis.net (mx03.gis.net [208.218.130.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20597 for ; Tue, 19 Mar 2002 07:48:33 -0500 (EST) Received: from callisto.jdscons.com ([216.243.57.15]) by mx03.gis.net; Tue, 19 Mar 2002 07:48:21 -0500 (EST) From: Jon Saperia Reply-To: saperia@jdscons.com To: Brian E Carpenter , "Yavatkar, Raj" , snmpconf@snmp.com Subject: Re: [Diffserv] RE: why i should like pibs Date: Tue, 19 Mar 2002 07:41:19 -0500 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain Cc: "'Weiss, Walter'" , "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org References: <090528C807DBD511A78200508B68D7A8157FC5@orsmsx112.jf.intel.com> <3C967184.41C12D4C@hursley.ibm.com> In-Reply-To: <3C967184.41C12D4C@hursley.ibm.com> MIME-Version: 1.0 Message-Id: <02031907472202.01787@callisto.jdscons.com> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit I am confused by this posting. In 1999 there was considerable debate on this subject and it went on for quite some time. I very much doubt that there will be new issues raised. The technical details are in the record and I just do not see what value there is in discussing them over again. Could you or Randy explain how the IESG has changed its position, if at all. At an OPS area open meeting about a year ago, I left with the impression that the ADs for O&M were going to support multiple approaches (at least for some time). Has this position changed? If so what is the decision the IESG and/or the DiffServ WG attempting to make? /jon On Mon, 18 Mar 2002, Brian E Carpenter wrote: > Let's try to stick to technical issues please, at least if > you want to keep the diffserv list on this thread. > > The technical issue is: does COPS-PR have *significant* technical > advantages over the existing alternatives, that would justify > the added mechanisms and complexity? > > Brian > > "Yavatkar, Raj" wrote: > > > > Hi Walter: > > > > Thanks for a really nice summary. I continue to be amazed at how Randy is > > applying a set of inconsistent standards to this work vs other work being > > done. Rob Coltun put the current state of IETF well in his departing message > > -- I was hoping that would wake up IESG to move away from such political > > shenanigans to getting work done especially when vendors with products or > > implementations are working towards standardization. > > > > Raj > > > > -----Original Message----- > > From: Weiss, Walter [mailto:wweiss@Ellacoya.com] > > Sent: Monday, March 18, 2002 11:45 AM > > To: 'Randy Bush'; rap@ops.ietf.org; diffserv@ietf.org > > Cc: ipsec-policy@vpnc.org > > Subject: [Diffserv] RE: why i should like pibs > > > > Randy, > > > > I have two responses. > > > > 1. Political: > > Why are you asking? Why do you keep asking? And more importantly why, based > > on your criteria, haven't you asked for every non-monitoring MIB, or for > > various other works such as Policy Framework. I don't mind if we want to > > have a substantive discussion around the evolution of configuration > > management if you applied your own metrics consistently. If you believe that > > none of these technologies meet's your requirements, then freeze them all. > > At least then there will be some pressure on all the parties to converge to > > a common approach. Personally, I believe your question is a waste of time > > since the existing IETF process addresses your question when there is > > sufficient implementation to transition standards from proposed standards to > > draft standards. Certainly there have been lot's of standards that have > > never made it past proposed for the very reasons you describe. > > > > 2. Technical: > > Given your role, I would not expect you to use this PIB. The very argument > > justifying DiffServ is the same one that Operators use to manage their > > networks. Both share the goal of making the core of the network static and > > stupid (minimal configuration). By recognizing that the core should be kept > > as simple as possible, we also all understand that removing complexity from > > the core only moves the complexity to some other location: the edge. If the > > edge must configure bindings of QoS, Security, Access Control, Tunneling, > > Usage Accounting, etc, this drives specific requirements that COPS-PR comes > > closest to meeting. I could go into all the details here, but given that > > this thread inevitably de-evolves to the usual suspects and the usual > > posturing, I have serious doubts about the value of going into any more > > details. > > > > regards, > > > > -Walter > > > > > -----Original Message----- > > > From: Randy Bush [mailto:randy@psg.com] > > > Sent: Monday, March 18, 2002 9:13 AM > > > To: rap@ops.ietf.org; diffserv@ietf.org > > > Cc: ipsec-policy@vpnc.org > > > Subject: why i should like pibs > > > > > > > > > wearing my iesg hat but being just a stupid operator, i am trying to > > > understand the pib/mib controversy. fyi, i currently use snmp heavily > > > for monitoring devices on my network. i configure using > > > large db-driven > > > code and spew text-based cli to the devices. > > > > > > let's assume i want to take the leap to a binary, as opposed > > > to textual, > > > configuration language. i.e. for some reason(s) [which we will PLEASE > > > NOT discuss here] i decide to move from pushing text-based cli configs > > > out to pushing a binary format. > > > > > > hence, i would have to push my vendors to implement snmp/cops > > > writes for > > > all configuration aspects of all devices. this would be big cost for > > > both me and for my vendors. > > > > > > why would cops/pibs be significantly better (remember it has > > > to replace > > > my current investment, so it can not be 'just as good') than > > > snmp/mibs? > > > > > > randy > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- ---- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 19 09:28:26 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 JAA22658 for ; Tue, 19 Mar 2002 09:28:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18492 for diffserv-archive@odin.ietf.org; Tue, 19 Mar 2002 09:28:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17243; Tue, 19 Mar 2002 09:10:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17204 for ; Tue, 19 Mar 2002 09:10:49 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22204 for ; Tue, 19 Mar 2002 09:10:46 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id PAA74790; Tue, 19 Mar 2002 15:08:50 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2JE8lt27464; Tue, 19 Mar 2002 15:08:47 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA66420 from ; Tue, 19 Mar 2002 15:08:37 +0100 Message-Id: <3C974652.D23D7C46@hursley.ibm.com> Date: Tue, 19 Mar 2002 15:08:18 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: saperia@jdscons.com Cc: "Yavatkar, Raj" , snmpconf@snmp.com, "'Weiss, Walter'" , "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Subject: Re: [Diffserv] RE: why i should like pibs References: <090528C807DBD511A78200508B68D7A8157FC5@orsmsx112.jf.intel.com> <3C967184.41C12D4C@hursley.ibm.com> <02031907472202.01787@callisto.jdscons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The diffserv WG isn't taking any decision - we have completed our work on the diffserv PIB and submitted it to the IESG. As for the IESG's intentions, it is for them to reply. Brian Jon Saperia wrote: > > I am confused by this posting. In 1999 there was considerable debate on this > subject and it went on for quite some time. I very much doubt that there will > be new issues raised. The technical details are in the record and I just do not > see what value there is in discussing them over again. Could you or Randy > explain how the IESG has changed its position, if at all. At an OPS area open > meeting about a year ago, I left with the impression that the ADs for O&M were > going to support multiple approaches (at least for some time). Has this > position changed? If so what is the decision the IESG and/or the DiffServ WG > attempting to make? > > /jon > > On Mon, 18 Mar 2002, Brian E Carpenter wrote: > > Let's try to stick to technical issues please, at least if > > you want to keep the diffserv list on this thread. > > > > The technical issue is: does COPS-PR have *significant* technical > > advantages over the existing alternatives, that would justify > > the added mechanisms and complexity? > > > > Brian > > > > "Yavatkar, Raj" wrote: > > > > > > Hi Walter: > > > > > > Thanks for a really nice summary. I continue to be amazed at how Randy is > > > applying a set of inconsistent standards to this work vs other work being > > > done. Rob Coltun put the current state of IETF well in his departing message > > > -- I was hoping that would wake up IESG to move away from such political > > > shenanigans to getting work done especially when vendors with products or > > > implementations are working towards standardization. > > > > > > Raj > > > > > > -----Original Message----- > > > From: Weiss, Walter [mailto:wweiss@Ellacoya.com] > > > Sent: Monday, March 18, 2002 11:45 AM > > > To: 'Randy Bush'; rap@ops.ietf.org; diffserv@ietf.org > > > Cc: ipsec-policy@vpnc.org > > > Subject: [Diffserv] RE: why i should like pibs > > > > > > Randy, > > > > > > I have two responses. > > > > > > 1. Political: > > > Why are you asking? Why do you keep asking? And more importantly why, based > > > on your criteria, haven't you asked for every non-monitoring MIB, or for > > > various other works such as Policy Framework. I don't mind if we want to > > > have a substantive discussion around the evolution of configuration > > > management if you applied your own metrics consistently. If you believe that > > > none of these technologies meet's your requirements, then freeze them all. > > > At least then there will be some pressure on all the parties to converge to > > > a common approach. Personally, I believe your question is a waste of time > > > since the existing IETF process addresses your question when there is > > > sufficient implementation to transition standards from proposed standards to > > > draft standards. Certainly there have been lot's of standards that have > > > never made it past proposed for the very reasons you describe. > > > > > > 2. Technical: > > > Given your role, I would not expect you to use this PIB. The very argument > > > justifying DiffServ is the same one that Operators use to manage their > > > networks. Both share the goal of making the core of the network static and > > > stupid (minimal configuration). By recognizing that the core should be kept > > > as simple as possible, we also all understand that removing complexity from > > > the core only moves the complexity to some other location: the edge. If the > > > edge must configure bindings of QoS, Security, Access Control, Tunneling, > > > Usage Accounting, etc, this drives specific requirements that COPS-PR comes > > > closest to meeting. I could go into all the details here, but given that > > > this thread inevitably de-evolves to the usual suspects and the usual > > > posturing, I have serious doubts about the value of going into any more > > > details. > > > > > > regards, > > > > > > -Walter > > > > > > > -----Original Message----- > > > > From: Randy Bush [mailto:randy@psg.com] > > > > Sent: Monday, March 18, 2002 9:13 AM > > > > To: rap@ops.ietf.org; diffserv@ietf.org > > > > Cc: ipsec-policy@vpnc.org > > > > Subject: why i should like pibs > > > > > > > > > > > > wearing my iesg hat but being just a stupid operator, i am trying to > > > > understand the pib/mib controversy. fyi, i currently use snmp heavily > > > > for monitoring devices on my network. i configure using > > > > large db-driven > > > > code and spew text-based cli to the devices. > > > > > > > > let's assume i want to take the leap to a binary, as opposed > > > > to textual, > > > > configuration language. i.e. for some reason(s) [which we will PLEASE > > > > NOT discuss here] i decide to move from pushing text-based cli configs > > > > out to pushing a binary format. > > > > > > > > hence, i would have to push my vendors to implement snmp/cops > > > > writes for > > > > all configuration aspects of all devices. this would be big cost for > > > > both me and for my vendors. > > > > > > > > why would cops/pibs be significantly better (remember it has > > > > to replace > > > > my current investment, so it can not be 'just as good') than > > > > snmp/mibs? > > > > > > > > randy > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > -- > ---- > Jon Saperia > > saperia@jdscons.com > Phone: 617-744-1079 > Fax: 617-249-0874 > http://www.jdscons.com _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Mar 19 14:18:19 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 OAA01085 for ; Tue, 19 Mar 2002 14:18:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10338 for diffserv-archive@odin.ietf.org; Tue, 19 Mar 2002 14:18:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09300; Tue, 19 Mar 2002 14:04:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02912 for ; Tue, 19 Mar 2002 12:14:55 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27807 for ; Tue, 19 Mar 2002 12:14:52 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GT800J01D4DE5@firewall.wcom.com> for diffserv@ietf.org; Tue, 19 Mar 2002 17:12:13 +0000 (GMT) Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GT800I66D3ZQU@firewall.wcom.com>; Tue, 19 Mar 2002 17:12:13 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GT800F01D3R7K@pmismtp05.wcomnet.com>; Tue, 19 Mar 2002 17:11:56 +0000 (GMT) Received: from dgmexch09.wcomnet.com ([166.38.58.240]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GT8006NGD3UIV@pmismtp05.wcomnet.com>; Tue, 19 Mar 2002 17:11:55 +0000 (GMT) Received: by DGMEXCH09.wcomnet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 17:12:01 +0000 Content-return: allowed Date: Tue, 19 Mar 2002 17:11:54 +0000 From: "Rawlins, Diana" To: "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Message-id: <492EB4A3F68CD411ABE800508B69362E64841A@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_Jt3dJ3Vk11iFgbhVpagZ3Q)" Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@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. --Boundary_(ID_Jt3dJ3Vk11iFgbhVpagZ3Q) Content-type: text/plain; CHARSET=us-ascii I'm not wild about the binary either, but SMIv3 was chosen back in the days when Moore's Law was just taking off. I think an xml based structure over a reliable TLS or authenticated/encrypted counterpart would be great! The advantage I get with a PIB is a COPS protocol. The protocol informs me if my transaction succeeded, or not. It enforces a single connection between the client-server so I know the origin of the updates and I get the nice side-effect of concurrency control. It gives me a feedback mechanism on how the policy is doing if I so desire it. -Diana -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, March 18, 2002 8:13 AM To: rap@ops.ietf.org; diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: why i should like pibs wearing my iesg hat but being just a stupid operator, i am trying to understand the pib/mib controversy. fyi, i currently use snmp heavily for monitoring devices on my network. i configure using large db-driven code and spew text-based cli to the devices. let's assume i want to take the leap to a binary, as opposed to textual, configuration language. i.e. for some reason(s) [which we will PLEASE NOT discuss here] i decide to move from pushing text-based cli configs out to pushing a binary format. hence, i would have to push my vendors to implement snmp/cops writes for all configuration aspects of all devices. this would be big cost for both me and for my vendors. why would cops/pibs be significantly better (remember it has to replace my current investment, so it can not be 'just as good') than snmp/mibs? randy --Boundary_(ID_Jt3dJ3Vk11iFgbhVpagZ3Q) Content-type: text/html; CHARSET=us-ascii Content-Transfer-Encoding: quoted-printable RE: why i should like pibs

I'm not wild about the binary either, but SMIv3 was = chosen back in the days when Moore's Law was just taking off. I think = an xml based structure over a reliable TLS or authenticated/encrypted = counterpart would be great!

 
The advantage I get with a PIB is a COPS protocol. = The protocol informs me if my transaction succeeded, or not. It = enforces a single connection between the client-server so I know the = origin of the updates and I get the nice side-effect of concurrency = control. It gives me a feedback mechanism on how the policy is doing if = I so desire it.

 
-Diana

-----Original Message-----
From: Randy Bush [mailto:randy@psg.com]
Sent: Monday, March 18, 2002 8:13 AM
To: rap@ops.ietf.org; diffserv@ietf.org
Cc: ipsec-policy@vpnc.org
Subject: why i should like pibs

wearing my iesg hat but being just a stupid operator, = i am trying to
understand the pib/mib controversy.  fyi, i = currently use snmp heavily
for monitoring devices on my network.  i = configure using large db-driven
code and spew text-based cli to the devices.

let's assume i want to take the leap to a binary, as = opposed to textual,
configuration language.  i.e. for some = reason(s) [which we will PLEASE
NOT discuss here] i decide to move from pushing = text-based cli configs
out to pushing a binary format.

hence, i would have to push my vendors to implement = snmp/cops writes for
all configuration aspects of all devices.  this = would be big cost for
both me and for my vendors.

why would cops/pibs be significantly better (remember = it has to replace
my current investment, so it can not be 'just as = good') than snmp/mibs?

randy

= --Boundary_(ID_Jt3dJ3Vk11iFgbhVpagZ3Q)-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 19 23:13:00 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 XAA14077 for ; Tue, 19 Mar 2002 23:13:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA07646 for diffserv-archive@odin.ietf.org; Tue, 19 Mar 2002 23:13:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07031; Tue, 19 Mar 2002 23:02:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07001 for ; Tue, 19 Mar 2002 23:02:01 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13851 for ; Tue, 19 Mar 2002 23:01:57 -0500 (EST) From: Man.M.Li@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2K44JQ14716 for ; Tue, 19 Mar 2002 22:04:19 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Mar 2002 22:01:59 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Mar 2002 22:01:58 -0600 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="iso-8859-1" Date: Tue, 19 Mar 2002 23:01:57 -0500 Message-ID: Thread-Topic: why i should like pibs Thread-Index: AcHOh8rWfbkohePWSTOxuHnRyLcUewBOSbHA To: , , Cc: X-OriginalArrivalTime: 20 Mar 2002 04:01:58.0753 (UTC) FILETIME=[FB76E510:01C1CFC3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA07002 Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit David Durham's list is comprehensive enough. How much more does IESG need? Since as many indicated that it is probably pointless to re-open all the discussions, why can't we just move the Framework and Diffserv PIBs to ps and let the market decide the usefulness of PIBs instead of trying to decide for the market? Man Li -----Original Message----- From: ext Randy Bush [mailto:randy@psg.com] Sent: March 18, 2002 09:13 AM To: rap@ops.ietf.org; diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: why i should like pibs wearing my iesg hat but being just a stupid operator, i am trying to understand the pib/mib controversy. fyi, i currently use snmp heavily for monitoring devices on my network. i configure using large db-driven code and spew text-based cli to the devices. let's assume i want to take the leap to a binary, as opposed to textual, configuration language. i.e. for some reason(s) [which we will PLEASE NOT discuss here] i decide to move from pushing text-based cli configs out to pushing a binary format. hence, i would have to push my vendors to implement snmp/cops writes for all configuration aspects of all devices. this would be big cost for both me and for my vendors. why would cops/pibs be significantly better (remember it has to replace my current investment, so it can not be 'just as good') than snmp/mibs? randy _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 20 13:18: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 NAA08955 for ; Wed, 20 Mar 2002 13:18:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02205 for diffserv-archive@odin.ietf.org; Wed, 20 Mar 2002 13:18:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00390; Wed, 20 Mar 2002 12:52:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00356 for ; Wed, 20 Mar 2002 12:52:36 -0500 (EST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07762 for ; Wed, 20 Mar 2002 12:52:33 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2KHpJ905132 for ; Wed, 20 Mar 2002 17:51:19 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2KHpQk28484 for ; Wed, 20 Mar 2002 17:51:26 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002032009555915974 ; Wed, 20 Mar 2002 09:55:59 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 09:52:33 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> From: "Durham, David" To: Juergen Schoenwaelder Cc: randy@psg.com, rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Date: Wed, 20 Mar 2002 09:52:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Actually, I did some pings and found my 10ms RTT was unrealistic. 100ms is more like it. At 100ms RTT, things get much worse for the SNMP equation for the configuration example I described: SNMP=2026 Seconds (over half an hour!) COPS=2.59 Seconds Now we're talking 1000x faster... > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: Tuesday, March 19, 2002 2:40 AM > > Dave> Change 10000 DiffServ Filter+meter+action > Dave> entries through a T1 line with a 10msec RTT for 48byte packets: > Dave> SNMP=((10000*8*498)/1540000)+((2*10000)/100)=226 Seconds. > Dave> COPS=((10000*8*(498/10))/1540000)=2.59 Seconds. Is 100x > Dave> improvement sufficiently better? And the multiple goes up with > Dave> the more data you xfer. ... adding bandwidth doesn't help, it's > Dave> that dang RTT. > > Even with SNMP over UDP, you can stream set requests as long as they > are independent of each other (which I guess is true if you populate a > DiffServ filter table). Since you did not take TCP acks into account, > I would say the second term is in equation (1) is 0 if you are smart > enough. With SNMP over TCP, the difference also boils down to the > reduced OID overhead in COPS-PR, which is probably not that much an > issue on the T1 link. Anyway, I agree with other folks that it is > pointless to redo all the discussions of the past so I better stop > this. > [Dave] TCP ACKs piggyback on messages going the other way. TCP is quite efficient in that way. Actually, I think I was far too kind in my calculations. Just the other day an operator said SNMP implementations can take hours to update his big BGP tables. Clearly with SNMP, results will vary. While with COPS-PR, it's the TCP stack that matters, and that makes it a no-brainer for implementations. Remember also that COPS-PR presents a transactional model to the user, while SNMP simply provides a get/set interface, so it's not just an implementation issue; it's a presentation issue as well. [Dave] The SNMP example gets far worse when you have to consider the multiple manager problem. Now you will have to hold each of the 30000 row status variables until the transaction completes, and reset them thereafter. In such cases you also will have to constantly check that some other manager didn't come and munge your configuration. This quickly becomes an unmanageable situation, and I cannot write an equation that is long enough to adequately express that problem. > From my perspective, the major technical contribution of COPS-PR over > SNMP is: > > a) TCP transport for large transactions when the network is up and > running. > > b) Reduced OID overhead and less degrees of freedom to achieve the same > thing. > > c) Slightly improved data definition language - but nothing which gives > us real reusable and extensible data structures. > [Dave] I disagree. You certainly do get full reusability and extensible data structures. The reusability is both syntactic and semantic. > d) State sharing and one manager assumption. > [Dave] One manager for its set of instance data (so there is no danger of configuration corruption). The COPS-PR protocol supports 64000 managers per device. > e) Some failover support built into the protoco. > > Items a) and b) are technically easy to support in SNMP. The real > problem here is the "SNMP community process" which is in blocking mode > for several years now for various non-technical reasons. > [Dave] By the time you integrate all the COPS-PR features and advancements into SNMP, you still get COPS-PR, just 5 years too late. But, perhaps the best reason of all for COPS-PR and PIBs is that you don't have the "SNMP community process" that you just described. > Item c) contains some minor enhancements over SMIv2 but if people want > a really improved data definition language, then the SMIng WG is the > place to go (sure, I am biased on this ;-). > [Dave]Yes, go to the SMIng WG, that's where the good stuff is being done ;-) _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 20 15:15:56 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 PAA13080 for ; Wed, 20 Mar 2002 15:15:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09541 for diffserv-archive@odin.ietf.org; Wed, 20 Mar 2002 15:15:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07961; Wed, 20 Mar 2002 14:58:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05875 for ; Wed, 20 Mar 2002 14:15:43 -0500 (EST) Received: from mailhost2.unispherenetworks.com (mailhost2.unispherenetworks.com [65.194.140.138]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10705 for ; Wed, 20 Mar 2002 14:15:40 -0500 (EST) Received: by email2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <19PHH410>; Wed, 20 Mar 2002 08:53:31 -0500 Message-ID: <9DCB6C9DC7C3D311B835009027DE069F04D3DFDA@email2.it.west.unispherenetworks.com> From: "Moisand, Jerome" To: "'Man.M.Li@nokia.com'" , randy@psg.com, rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Date: Wed, 20 Mar 2002 08:53:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Sounds to be the wise approach... Can't agree more. Jerome Moisand Unisphere Networks -----Original Message----- From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] Sent: Tuesday, March 19, 2002 11:02 PM To: randy@psg.com; rap@ops.ietf.org; diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: RE: why i should like pibs David Durham's list is comprehensive enough. How much more does IESG need? Since as many indicated that it is probably pointless to re-open all the discussions, why can't we just move the Framework and Diffserv PIBs to ps and let the market decide the usefulness of PIBs instead of trying to decide for the market? Man Li -----Original Message----- From: ext Randy Bush [mailto:randy@psg.com] Sent: March 18, 2002 09:13 AM To: rap@ops.ietf.org; diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: why i should like pibs wearing my iesg hat but being just a stupid operator, i am trying to understand the pib/mib controversy. fyi, i currently use snmp heavily for monitoring devices on my network. i configure using large db-driven code and spew text-based cli to the devices. let's assume i want to take the leap to a binary, as opposed to textual, configuration language. i.e. for some reason(s) [which we will PLEASE NOT discuss here] i decide to move from pushing text-based cli configs out to pushing a binary format. hence, i would have to push my vendors to implement snmp/cops writes for all configuration aspects of all devices. this would be big cost for both me and for my vendors. why would cops/pibs be significantly better (remember it has to replace my current investment, so it can not be 'just as good') than snmp/mibs? randy ======================================= This email message is for the sole use of the intended recipient (s) and may contain confidential and privileged information, including without limitation, Confidential and/or Proprietary Information belonging to Unisphere Networks, Inc. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 20 15:37: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 PAA14026 for ; Wed, 20 Mar 2002 15:37:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11761 for diffserv-archive@odin.ietf.org; Wed, 20 Mar 2002 15:37:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09999; Wed, 20 Mar 2002 15:23:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09950 for ; Wed, 20 Mar 2002 15:23:06 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13430 for ; Wed, 20 Mar 2002 15:23:04 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2KKLpm26357; Wed, 20 Mar 2002 15:21:51 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKMV3R42; Wed, 20 Mar 2002 15:21:42 -0500 Received: from tweedy.NortelNetworks.com (artpt63y.us.nortel.com [47.140.54.70]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HB94TSBL; Wed, 20 Mar 2002 15:21:41 -0500 Message-Id: <5.0.0.25.0.20020320151351.02865c30@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 20 Mar 2002 15:20:09 -0500 To: "Moisand, Jerome" From: Kwok Ho Chan Cc: "'Man.M.Li@nokia.com'" , randy@psg.com, rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org In-Reply-To: <9DCB6C9DC7C3D311B835009027DE069F04D3DFDA@email2.it.west.un ispherenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Agreeing on the approach of progressing both draft-ietf-rap-frameworkpib and draft-ietf-diffserv-pib as Proposed Standards. And let the market decide. -- Kwok -- At 08:53 AM 3/20/02 -0500, Moisand, Jerome wrote: >Sounds to be the wise approach... Can't agree more. > >Jerome Moisand >Unisphere Networks > >-----Original Message----- >From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] >Sent: Tuesday, March 19, 2002 11:02 PM >To: randy@psg.com; rap@ops.ietf.org; diffserv@ietf.org >Cc: ipsec-policy@vpnc.org >Subject: RE: why i should like pibs > > >David Durham's list is comprehensive enough. How much more does IESG need? >Since as many indicated that it is probably pointless to re-open all the >discussions, why can't we just move the Framework and Diffserv PIBs to ps >and let the market decide the usefulness of PIBs instead of trying to decide >for the market? > >Man Li > >-----Original Message----- >From: ext Randy Bush [mailto:randy@psg.com] >Sent: March 18, 2002 09:13 AM >To: rap@ops.ietf.org; diffserv@ietf.org >Cc: ipsec-policy@vpnc.org >Subject: why i should like pibs > > >wearing my iesg hat but being just a stupid operator, i am trying to >understand the pib/mib controversy. fyi, i currently use snmp heavily >for monitoring devices on my network. i configure using large db-driven >code and spew text-based cli to the devices. > >let's assume i want to take the leap to a binary, as opposed to textual, >configuration language. i.e. for some reason(s) [which we will PLEASE >NOT discuss here] i decide to move from pushing text-based cli configs >out to pushing a binary format. > >hence, i would have to push my vendors to implement snmp/cops writes for >all configuration aspects of all devices. this would be big cost for >both me and for my vendors. > >why would cops/pibs be significantly better (remember it has to replace >my current investment, so it can not be 'just as good') than snmp/mibs? > >randy > > > >======================================= >This email message is for the sole use of the intended recipient (s) and may >contain confidential and privileged information, including without >limitation, Confidential and/or Proprietary Information belonging to >Unisphere Networks, Inc. Any unauthorized review, use, disclosure or >distribution is prohibited. If you are not the intended recipient, please >contact the sender by reply email and destroy all copies of the original >message. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 20 17:33:38 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 RAA17739 for ; Wed, 20 Mar 2002 17:33:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19720 for diffserv-archive@odin.ietf.org; Wed, 20 Mar 2002 17:33:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18226; Wed, 20 Mar 2002 17:18:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18201 for ; Wed, 20 Mar 2002 17:18:22 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17191 for ; Wed, 20 Mar 2002 17:18:18 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16noPV-0001FT-00 for ; Wed, 20 Mar 2002 23:18:21 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16noPV-0000hV-00 for ; Wed, 20 Mar 2002 23:18:21 +0100 Received: from tpce10.ipv6.tm.uka.de ([127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g2KMIKf01033 for ; Wed, 20 Mar 2002 23:18:20 +0100 Message-Id: <200203202218.g2KMIKf01033@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 20 Mar 2002 23:18:20 +0100 From: Roland Bless Content-Transfer-Encoding: 8bit Subject: [Diffserv] (Forwarded) I-D ACTION:draft-bless-diffserv-multicast-03.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hi, now that most of the WG items are done, we'd like to publish an informational RFC on a more detailed analysis of multicast in DiffServ networks (remember 46th IETF meeting). Currently, we removed our particular solution from the previous version and we are working on a more generic description of our proposal (I talked to Bill Fenner about this). If it is fine to have an informational RFC just on the problem description w/o a proposed solution, we'd like to get two separate RFCs on that, one for the problem, one for a solution. Regards, Roland ------- Forwarded Message A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Multicast in Differentiated Services Networks Author(s) : R. Bless, K. Wehrle Filename : draft-bless-diffserv-multicast-03.txt Pages : 23 Date : 07-Mar-02 This document presents some of the problems which will arise when IP Multicast is used in DiffServ networks without taking special provisions into account for supplying multicast services. Although the basic DS forwarding mechanisms also work with IP Multicast, some facts have to be considered which are related to the provisioning of multicast resources. The presented problems mainly lead to situations in which other service users are affected adversely in their experienced quality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bless-diffserv-multicast-03.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-bless-diffserv-multicast-03.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-bless-diffserv-multicast-03.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: <20020307120300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bless-diffserv-multicast-03.txt - --OtherAccess Content-Type: Message/External-body; name="draft-bless-diffserv-multicast-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307120300.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 21 05:48:35 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 FAA08489 for ; Thu, 21 Mar 2002 05:48:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01529 for diffserv-archive@odin.ietf.org; Thu, 21 Mar 2002 05:48:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00182; Thu, 21 Mar 2002 05:26:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00151 for ; Thu, 21 Mar 2002 05:26:51 -0500 (EST) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08173 for ; Thu, 21 Mar 2002 05:26:47 -0500 (EST) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g2LAQh7V031396; Thu, 21 Mar 2002 11:26:43 +0100 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g2LAQg612161; Thu, 21 Mar 2002 11:26:42 +0100 Date: Thu, 21 Mar 2002 11:26:42 +0100 Message-Id: <200203211026.g2LAQg612161@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: david.durham@intel.com CC: randy@psg.com, rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org In-reply-to: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> (david.durham@intel.com) References: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> Subject: [Diffserv] Re: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org [ Based on Dave Durhams comments, I will update my attempt to summarize the major technical contributions of COPS-PR over SNMP. I will do so on the only so that we can stop these cross posts. Below are just my hopefully final comments on Dave's numbers. ] >>>>> Durham, David writes: Dave> Actually, I did some pings and found my 10ms RTT was Dave> unrealistic. 100ms is more like it. At 100ms RTT, things get Dave> much worse for the SNMP equation for the configuration example I Dave> described: Dave> SNMP=2026 Seconds (over half an hour!) COPS=2.59 Seconds Dave> Now we're talking 1000x faster... I probably do not understand your equations. There is the actual transmission time Tx and the propagation delay Tp. We have n = number of filter entries m = size of a single filter entry s = "speed" of the link r = round trip time If I understand you correctly, you assume: Tx_s = (n * m) / s # SNMP n messages of size m Tx_c = (n * m/10) / s # COPS filters are 10 times smaller Obviously: Tx_c = 1/10 Tx_s You also seem to assume: Tp_s = (2 * n) * r # SNMP sequential one set a time Tp_c = 0 # COPS does not need a round trip In case this is your model (forgive me if I messed it up), I think it is an over-simplification and the numbers you get out of it do not impress me that much. (Did you ever calculate how big your TCP window must be to do your example in one^H^H^Hzero RTT?) Still I agree (and have ever done so in the past) with the qualitative statment "COPS-PR is faster due to larger transactions and the TCP transport in cases the network is running normally". Dave> Remember also that COPS-PR presents a transactional model to the Dave> user, while SNMP simply provides a get/set interface, so it's Dave> not just an implementation issue; it's a presentation issue as Dave> well. I never got that into my brain. An SNMP SET is a single transaction just as a COPS-PR DEC is a single transaction. The difference is just the message sizes you can use. /js -- Juergen Schoenwaelder _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 21 12:18:43 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 MAA18234 for ; Thu, 21 Mar 2002 12:18:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24809 for diffserv-archive@odin.ietf.org; Thu, 21 Mar 2002 12:18:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21587; Thu, 21 Mar 2002 11:59:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21549 for ; Thu, 21 Mar 2002 11:59:47 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17426 for ; Thu, 21 Mar 2002 11:59:41 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2LGx9208287; Thu, 21 Mar 2002 11:59:09 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GWB0P0G7; Thu, 21 Mar 2002 11:59:09 -0500 Received: from tweedy.NortelNetworks.com (artpt5w7.us.nortel.com [47.140.53.69]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HB94TTMD; Thu, 21 Mar 2002 11:59:07 -0500 Message-Id: <5.0.0.25.0.20020321114636.025e83f0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Mar 2002 11:57:35 -0500 To: Randy Bush From: Kwok Ho Chan Cc: rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Randy: There have been some informational responses with regard to the your question. Does the information help? Are there other information that you think we can provide to help our ADs? Please see this as an attempt to help our ADs. Thanks! -- Kwok -- At 08:13 AM 3/18/02 -0600, Randy Bush wrote: >wearing my iesg hat but being just a stupid operator, i am trying to >understand the pib/mib controversy. fyi, i currently use snmp heavily >for monitoring devices on my network. i configure using large db-driven >code and spew text-based cli to the devices. > >let's assume i want to take the leap to a binary, as opposed to textual, >configuration language. i.e. for some reason(s) [which we will PLEASE >NOT discuss here] i decide to move from pushing text-based cli configs >out to pushing a binary format. > >hence, i would have to push my vendors to implement snmp/cops writes for >all configuration aspects of all devices. this would be big cost for >both me and for my vendors. > >why would cops/pibs be significantly better (remember it has to replace >my current investment, so it can not be 'just as good') than snmp/mibs? > >randy _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 21 12:19:02 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 MAA18267 for ; Thu, 21 Mar 2002 12:19:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24828 for diffserv-archive@odin.ietf.org; Thu, 21 Mar 2002 12:19:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23269; Thu, 21 Mar 2002 12:05:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23184 for ; Thu, 21 Mar 2002 12:04:59 -0500 (EST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17634 for ; Thu, 21 Mar 2002 12:04:48 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2LH4WW09793 for ; Thu, 21 Mar 2002 17:04:32 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2LH3bL26009 for ; Thu, 21 Mar 2002 17:03:37 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002032109035005192 ; Thu, 21 Mar 2002 09:03:50 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 09:04:45 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F048E76F9@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'Juergen Schoenwaelder'" Cc: "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Date: Thu, 21 Mar 2002 09:04:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Juergen, I've added some items in addition to what you've enumerated. Some of these are direct effects of the PIB data model, and some of them because of usage of the data model with COPS-PR. a. I think the PIB data model is better since: a.1. Other additions which formalize Pointers, typed and untyped, Tag-Groups and single-inheritance (via EXTENDS) allow code generation by an algorithm to generate entire funtional PIB layers over COPS-PR, and make processing of PIB transactions and error handling easier. a.2. PIB PRCs do not require some SMIv2 column attributes which are needed there due to multi-managers support, and hence do not have that complexity. b. Reuse of 'all'(a special client-type) and other assigned client-type PIBs via Client-type infrastructure that allows the work by a wg of subject-matter experts, to be reused by another group that needs those entire modules or specific PRCs defined within them. c. Some of the advantages of the framework-pib (which is specified as an 'all' client-type) and hence the advantages are distributed to other PIBs also are: c.1. Facility to report subject-matter specific capabilities and PRC and/or attribute level implementation limitations which allows the PDP to validate configuration for a device to be configured effectively and unambigously amongst heterogeneous devices to which that configuration applies. c.2. Facility to install multiple contexts of device configuration (with one active configuration context) and the ability to switch between them with very small decisions. This helps in bulk configuration. d. Ability to outsource requests or provision decisions using the same data model, which gives you more than just yes/no answers for resource allocation. e. Allows resource management interaction at a PDP which may be managing multiple resources (or client-types)-which gives one the facility to build a closed-feedback system where one client-type interaction may cause a change in another client-type. This bullet point talks to the state maintenance point that many people mentioned. These I think are in addition to what you and Dave have mentioned. Ravi -----Original Message----- From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] Sent: Thursday, March 21, 2002 2:30 AM To: david.durham@intel.com Cc: rap@ops.ietf.org Subject: Re: why i should like pibs I tried to incorporate Dave's feedback and here is my updated list of the major technical contributions of COPS-PR over SNMP: a) TCP transport for large transactions when the network is up and running. b) Reduced OID overhead and less degrees of freedom to achieve the same thing. c) Improved data definition language. (There is disagreement how much improvement there really is.) d) State sharing and one manager assumption for a given set of instance data. e) Some failover support built into the protocol. Dave, do you agree with this revised list? /js -- Juergen Schoenwaelder _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 21 12:33:27 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 MAA18798 for ; Thu, 21 Mar 2002 12:33:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26594 for diffserv-archive@odin.ietf.org; Thu, 21 Mar 2002 12:33:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24877; Thu, 21 Mar 2002 12:19:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24846 for ; Thu, 21 Mar 2002 12:19:22 -0500 (EST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18285 for ; Thu, 21 Mar 2002 12:19:18 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2LHJ7e21015 for ; Thu, 21 Mar 2002 17:19:07 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2LHIC813515 for ; Thu, 21 Mar 2002 17:18:12 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002032109224803836 ; Thu, 21 Mar 2002 09:22:48 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 09:19:20 -0800 Message-ID: <59885C5E3098D511AD690002A5072D3C0451C172@orsmsx111.jf.intel.com> From: "Hahn, Scott" To: rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Date: Thu, 21 Mar 2002 09:19:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I would like to say that this question bothers me. The term *significant* is a highly subjective term that will be interpreted in different ways by different people. The *significant* attribute that might convince you, Randy, to make a purchase are probably a completely different set of *significant* attributes that would affect my (or someone else's) purchase. I think the key point is that the IESG has chartered the working groups. The COPS documents that are currently in front of the IESG are part of the charters of the WG's involved. The IESG accepted these charters with these documents as work items. And finally, the WG chairs were asked by the IESG to request from the community at large for a count of companies that are planning implementations of the protocol which resulted in a number of positive responses. There are obviously volunteers from the IETF community willing to do the work. I would like to see the IESG let the market decide whether the advantages of using COPS and COPS-PR for configuration make it a success or not. -Scott _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 21 12:44:31 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 MAA19324 for ; Thu, 21 Mar 2002 12:44:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27858 for diffserv-archive@odin.ietf.org; Thu, 21 Mar 2002 12:44:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26331; Thu, 21 Mar 2002 12:31:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26296 for ; Thu, 21 Mar 2002 12:31:29 -0500 (EST) Received: from roam.psg.com (exim@[166.63.190.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18753 for ; Thu, 21 Mar 2002 12:31:25 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 4.00) id 16o6PK-0000Uw-00; Thu, 21 Mar 2002 11:31:22 -0600 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kwok Ho Chan Cc: rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org References: <5.0.0.25.0.20020321114636.025e83f0@zbl6c002.corpeast.baynetworks.com> Message-Id: Date: Thu, 21 Mar 2002 11:31:22 -0600 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > There have been some informational responses with regard to the your > question. indeed. all sorts of information :-). (not to worry, i am quite thick skinned as well as thick headed) i am really trying to blank my mind to history etc., and take a raw look at these things. as i am an engineer not a marketeer, if i have to sell it to the iesg/iab, i need to believe it. and to believe it, i have to try to understand it. so the input is *very* much appreciated. apologies for asking that the input be in email. but it forces a record, and the openness keeps people somewhat honest. it also gives us an opportunity to practice working politely despite disagreements. it is hard to think deeply during ietf week. over the next three weeks, i have two 30+ hour plane rides and a bit of calm time, in which i hope to read and think calmly. thanks for your patience. randy _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 21 16: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 QAA26628 for ; Thu, 21 Mar 2002 16:49:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15035 for diffserv-archive@odin.ietf.org; Thu, 21 Mar 2002 16:49:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12702; Thu, 21 Mar 2002 16:13:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12671 for ; Thu, 21 Mar 2002 16:13:38 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25715 for ; Thu, 21 Mar 2002 16:13:33 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2LLD4113329 for ; Thu, 21 Mar 2002 16:13:05 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 22:13:03 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: rap@ops.ietf.org Cc: diffserv@ietf.org, ipsec-policy@vpnc.org Date: Thu, 21 Mar 2002 22:13:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org All, Let me post to these lists a similar statement as I made in the RAP WG meeting at this 53rd IETF, so that everyone has the same info. Here we go. I would prefer to have andy reactions (if any) posted to just one mailing list (the RAP wg mailing list). When the WG completed WG Last Call and reached consensus on the FRAMEWORK PIB, the WG chairs asked me (the primary AD for the WG) to consider this document for Proposed Standard. Normally I then review and ask for IETF wide Last Call and if no valid objections are received, then I put the document on the IESG agenda for approval. My current evaluation however for this document at this time is as follows: - If we look at the NM related activities, then we can see that for SNMP/MIBs, the majority of work/time/effort is spent in the MIB development. It also touches on virtually all WGs. Same will be true for COPS-PR/PIBs if we start to put PIBs on the standareds track. This could be a VERY BIG thing. In SNMP, the real investment is in MIBs. This is true for MIB design (IETF), for vendor implementation effort, and for user deployment. If IETF working groups start to develop PIBs they would be faced with significant extra, and in many cases, redundant effort - We have accepted COPS and COPS-PR 2-3 years ago as PS. That was the start of a duplicate approach, which only provides marginal improvement in some areas, and possibly a negative effect in some other areas. - We have also accepted SPPI as a duplicate approach, again with only marginal improvement. It allows to define PIBs, most of which I think can also be done with MIBs or better/different MIB design. - Note that PIBs are basically intended for configuring network devices and services. - Two years back, the ADs and Diffserv WG chairs agreed to do a MIB and a PIB for standards track. And we agreed with the RAP WG to develop a set of base PIBs for standards track. - Meanwhile, we have seen: - Some key players withdrew from COPS and PIBs approach They claim there is no market, and with reduced budgets there is no place to just do multiple solutions to same address space. - In most cases, PIB development is done by different people than MIB development, if we're lucky they talk to each other. - WGs in general have very little interest in MIBs or in PIBs, let alone both. - Operators (ISPs) tell us they do not see much use for binary interfaces (be it SNMP/MIBs or COPS-PR/PIBs or other) to configure their network devices/services. The reality is that they use (and expect to have to continue to use) ASCII based CLI-type interfaces (Maybe ASCII should read human readable) - We have started an effort to try and consolidate SMI and SPPI We may want to await the results before we invest in the standardization of PIBs. - The NM community in the IETF (lots of SNMP folk, but COPS, Policy WG and Operators are participating too) are trying to come up with some vision/framework to address Operator (ISP) concerns. Discussions is only in beginning stages and not any IETF sanctioned status yet. - IAB is planning a NM Architecture Workshop this summer (as announced at the IAB plenary on Wednesday March 20th) - We (the IETF/IESG) are to decide on the first IETF produced PIBs. If we approve them as standards track, then: - I suspect we will find a lot of duplicate work, i.e. MIBs and PIBs, to be designed, tested, handled-for-stds-track approval - Vendors and users may be faced with the big duplicate investment. They can opt to not do so, but of course the more PIBs we approve as stds track, the more the pressure will be put on them. - We are telling the market that we cannot decide and let them do it. Maybe this is OK. But not in my mind, I do not think we do the IETF community or the world a favor by approving this duplicate approach As a result, I cannot propose to the ISG to approve the FRMAEWORK-PIB (or any PIBs for that matter) on the standards track at this point in time. I strongly recommend to publish them as Informational for now. We can revisit this after we get some better architectural guidelines/help from the current actitivities that are taking place in informal gatherings and the upcoming IAB NM Workshop. I understand that this is sort of "breaking the contract" with the RAP WG on my part. But the situation has changed quite a bit from 2 years ago when we started down this path (agreed on the WG charter). Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 21 17:37: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 RAA27984 for ; Thu, 21 Mar 2002 17:37:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18905 for diffserv-archive@odin.ietf.org; Thu, 21 Mar 2002 17:37:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17397; Thu, 21 Mar 2002 17:20:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17367 for ; Thu, 21 Mar 2002 17:20:19 -0500 (EST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27358 for ; Thu, 21 Mar 2002 17:20:12 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2LMIxH00371 for ; Thu, 21 Mar 2002 22:18:59 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2LMJ6C26962 for ; Thu, 21 Mar 2002 22:19:06 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002032114194032410 ; Thu, 21 Mar 2002 14:19:40 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 14:20:14 -0800 Message-ID: <10C8636AE359D4119118009027AE99870DA5DED4@FMSMSX34> From: "Durham, David" To: "Wijnen, Bert (Bert)" , rap@ops.ietf.org Cc: diffserv@ietf.org, ipsec-policy@vpnc.org Date: Thu, 21 Mar 2002 14:20:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] RE: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Reaction (sorry): I must remind Bert that he did advocate moving the DiffServ MIB along on standards track despite it has demonstrated NO ADOPTION FOR CONFIGURATION. Whereas the DiffServ PIB has ALREADY demonstrated significant enough adoption to move to DRAFT STANDARD... And yet this door is now being shut. If it becomes a BIG THING, it means the industry has in fact decided! Why should one stand in the way and prevent this from happening? The simple reason is that PIBs are easier to write and easier to use, and that's why, despite the downfall of the Internet economy, they continue grow and to amaze with their resilience. Artificially cutting them off at the knees is simply not the IETF way. -Dave > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, March 21, 2002 1:13 PM > To: rap@ops.ietf.org > Cc: diffserv@ietf.org; ipsec-policy@vpnc.org > Subject: RE: why i should like pibs > > All, > > Let me post to these lists a similar statement as I made in the > RAP WG meeting at this 53rd IETF, so that everyone has the same > info. Here we go. I would prefer to have andy reactions (if any) > posted to just one mailing list (the RAP wg mailing list). > > When the WG completed WG Last Call and reached consensus on > the FRAMEWORK PIB, the WG chairs asked me (the primary AD > for the WG) to consider this document for Proposed Standard. > Normally I then review and ask for IETF wide Last Call and > if no valid objections are received, then I put the document > on the IESG agenda for approval. > > My current evaluation however for this document at this time > is as follows: > - If we look at the NM related activities, then we can see > that for SNMP/MIBs, the majority of work/time/effort is > spent in the MIB development. It also touches on virtually > all WGs. Same will be true for COPS-PR/PIBs if we start to > put PIBs on the standareds track. > This could be a VERY BIG thing. In SNMP, the real investment > is in MIBs. This is true for MIB design (IETF), for vendor > implementation effort, and for user deployment. If IETF > working groups start to develop PIBs they would be faced > with significant extra, and in many cases, redundant effort > - We have accepted COPS and COPS-PR 2-3 years ago as PS. > That was the start of a duplicate approach, which only > provides marginal improvement in some areas, and possibly > a negative effect in some other areas. > - We have also accepted SPPI as a duplicate approach, again > with only marginal improvement. It allows to define PIBs, > most of which I think can also be done with MIBs or > better/different MIB design. > - Note that PIBs are basically intended for configuring > network devices and services. > - Two years back, the ADs and Diffserv WG chairs agreed to do > a MIB and a PIB for standards track. And we agreed with the > RAP WG to develop a set of base PIBs for standards track. > - Meanwhile, we have seen: > - Some key players withdrew from COPS and PIBs approach > They claim there is no market, and with reduced budgets > there is no place to just do multiple solutions to same > address space. > - In most cases, PIB development is done by different people > than MIB development, if we're lucky they talk to each other. > - WGs in general have very little interest in MIBs or in PIBs, > let alone both. > - Operators (ISPs) tell us they do not see much use for binary > interfaces (be it SNMP/MIBs or COPS-PR/PIBs or other) to > configure their network devices/services. The reality is that > they use (and expect to have to continue to use) ASCII based > CLI-type interfaces (Maybe ASCII should read human readable) > - We have started an effort to try and consolidate SMI and SPPI > We may want to await the results before we invest in the > standardization of PIBs. > - The NM community in the IETF (lots of SNMP folk, but COPS, > Policy WG and Operators are participating too) are trying to > come up with some vision/framework to address Operator (ISP) > concerns. Discussions is only in beginning stages and not any > IETF sanctioned status yet. > - IAB is planning a NM Architecture Workshop this summer (as > announced at the IAB plenary on Wednesday March 20th) > - We (the IETF/IESG) are to decide on the first IETF produced PIBs. > If we approve them as standards track, then: > - I suspect we will find a lot of duplicate work, i.e. MIBs and > PIBs, to be designed, tested, handled-for-stds-track approval > - Vendors and users may be faced with the big duplicate investment. > They can opt to not do so, but of course the more PIBs we approve > as stds track, the more the pressure will be put on them. > - We are telling the market that we cannot decide and let them do it. > Maybe this is OK. But not in my mind, I do not think we do the > IETF community or the world a favor by approving this duplicate > approach > > As a result, I cannot propose to the ISG to approve the FRMAEWORK-PIB > (or any PIBs for that matter) on the standards track at this point > in time. I strongly recommend to publish them as Informational for > now. We can revisit this after we get some better architectural > guidelines/help from the current actitivities that are taking > place in informal gatherings and the upcoming IAB NM Workshop. > > I understand that this is sort of "breaking the contract" with > the RAP WG on my part. But the situation has changed quite a bit > from 2 years ago when we started down this path (agreed on the WG > charter). > > Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 21 18:33: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 SAA29876 for ; Thu, 21 Mar 2002 18:33:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23132 for diffserv-archive@odin.ietf.org; Thu, 21 Mar 2002 18:33:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21515; Thu, 21 Mar 2002 18:16:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21478 for ; Thu, 21 Mar 2002 18:16:09 -0500 (EST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29366 for ; Thu, 21 Mar 2002 18:16:05 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id AAA81232; Fri, 22 Mar 2002 00:15:33 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2LNFWF109790; Fri, 22 Mar 2002 00:15:32 +0100 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA75304 from ; Fri, 22 Mar 2002 00:15:29 +0100 Message-Id: <3C9A697D.E7C80228@hursley.ibm.com> Date: Fri, 22 Mar 2002 00:15:09 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Subject: Re: [Diffserv] RE: why i should like pibs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit "Wijnen, Bert (Bert)" wrote: ... > In most cases, PIB development is done by different people > than MIB development, if we're lucky they talk to each other. er, of the three authors of the diffserv MIB, two are also authors of the diffserv PIB, one of them being the active document editor. The PIB has been updated less frequently than the MIB, but it has been tracking it. > - WGs in general have very little interest in MIBs or in PIBs, > let alone both. But as you observed, diffserv was firmly requested by its ADs to develop a MIB and a PIB in parallel, and we did so, and it was a lot of work. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 21 21:45:06 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 VAA04795 for ; Thu, 21 Mar 2002 21:45:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA02441 for diffserv-archive@odin.ietf.org; Thu, 21 Mar 2002 21:45:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00899; Thu, 21 Mar 2002 21:22:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20108 for ; Thu, 21 Mar 2002 17:58:23 -0500 (EST) Received: from mailhost2.unispherenetworks.com (mailhost2.unispherenetworks.com [65.194.140.138]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28709 for ; Thu, 21 Mar 2002 17:58:18 -0500 (EST) Received: by email2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 17:57:51 -0500 Message-ID: <9DCB6C9DC7C3D311B835009027DE069F04D3DFFF@email2.it.west.unispherenetworks.com> From: "Moisand, Jerome" To: rap@ops.ietf.org Cc: diffserv@ietf.org, ipsec-policy@vpnc.org Date: Thu, 21 Mar 2002 17:57:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: why i should like pibs --- AAARRRGH - ENOUGH! ;-) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Ok, this must be the 100th e-mail on this discussion (or close ;-). May I suggest that we all take a few weeks to think about it and people with enough motivation will develop clean, structured and (hopefully) factual arguments one way or the other? Bert summary is very helpful by clearly characterizing the points of concerns. One may agree or not, but we know what to discuss. I'm afraid that the flurry of e-mails for the last few days and the format of some of the statements being made, clearly show we're all somehow over-reacting, knee-jerk-reacting, etc. So taking a bit more time to digest Bert summary, and develop structured responses (pros & cons & new points if any) should lead to a more fruitful discussion. Consequently, may I suggest that the status of these (much debated) I-Ds is kept open for a few more weeks or months? Maybe until the next IETF meeting? Is this a neutral (hence reasonable) enough approach? Jerome PS. In the mean time, I guess I know why "we should not like mibs and pibs"... The topic generates way too many e-mails... ok, just kidding! ;-) -----Original Message----- From: Durham, David [mailto:david.durham@intel.com] Sent: Thursday, March 21, 2002 5:20 PM To: Wijnen, Bert (Bert); rap@ops.ietf.org Cc: diffserv@ietf.org; ipsec-policy@vpnc.org Subject: RE: why i should like pibs Reaction (sorry): I must remind Bert that he did advocate moving the DiffServ MIB along on standards track despite it has demonstrated NO ADOPTION FOR CONFIGURATION. Whereas the DiffServ PIB has ALREADY demonstrated significant enough adoption to move to DRAFT STANDARD... And yet this door is now being shut. If it becomes a BIG THING, it means the industry has in fact decided! Why should one stand in the way and prevent this from happening? The simple reason is that PIBs are easier to write and easier to use, and that's why, despite the downfall of the Internet economy, they continue grow and to amaze with their resilience. Artificially cutting them off at the knees is simply not the IETF way. -Dave > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, March 21, 2002 1:13 PM > To: rap@ops.ietf.org > Cc: diffserv@ietf.org; ipsec-policy@vpnc.org > Subject: RE: why i should like pibs > > All, > > Let me post to these lists a similar statement as I made in the > RAP WG meeting at this 53rd IETF, so that everyone has the same > info. Here we go. I would prefer to have andy reactions (if any) > posted to just one mailing list (the RAP wg mailing list). > > When the WG completed WG Last Call and reached consensus on > the FRAMEWORK PIB, the WG chairs asked me (the primary AD > for the WG) to consider this document for Proposed Standard. > Normally I then review and ask for IETF wide Last Call and > if no valid objections are received, then I put the document > on the IESG agenda for approval. > > My current evaluation however for this document at this time > is as follows: > - If we look at the NM related activities, then we can see > that for SNMP/MIBs, the majority of work/time/effort is > spent in the MIB development. It also touches on virtually > all WGs. Same will be true for COPS-PR/PIBs if we start to > put PIBs on the standareds track. > This could be a VERY BIG thing. In SNMP, the real investment > is in MIBs. This is true for MIB design (IETF), for vendor > implementation effort, and for user deployment. If IETF > working groups start to develop PIBs they would be faced > with significant extra, and in many cases, redundant effort > - We have accepted COPS and COPS-PR 2-3 years ago as PS. > That was the start of a duplicate approach, which only > provides marginal improvement in some areas, and possibly > a negative effect in some other areas. > - We have also accepted SPPI as a duplicate approach, again > with only marginal improvement. It allows to define PIBs, > most of which I think can also be done with MIBs or > better/different MIB design. > - Note that PIBs are basically intended for configuring > network devices and services. > - Two years back, the ADs and Diffserv WG chairs agreed to do > a MIB and a PIB for standards track. And we agreed with the > RAP WG to develop a set of base PIBs for standards track. > - Meanwhile, we have seen: > - Some key players withdrew from COPS and PIBs approach > They claim there is no market, and with reduced budgets > there is no place to just do multiple solutions to same > address space. > - In most cases, PIB development is done by different people > than MIB development, if we're lucky they talk to each other. > - WGs in general have very little interest in MIBs or in PIBs, > let alone both. > - Operators (ISPs) tell us they do not see much use for binary > interfaces (be it SNMP/MIBs or COPS-PR/PIBs or other) to > configure their network devices/services. The reality is that > they use (and expect to have to continue to use) ASCII based > CLI-type interfaces (Maybe ASCII should read human readable) > - We have started an effort to try and consolidate SMI and SPPI > We may want to await the results before we invest in the > standardization of PIBs. > - The NM community in the IETF (lots of SNMP folk, but COPS, > Policy WG and Operators are participating too) are trying to > come up with some vision/framework to address Operator (ISP) > concerns. Discussions is only in beginning stages and not any > IETF sanctioned status yet. > - IAB is planning a NM Architecture Workshop this summer (as > announced at the IAB plenary on Wednesday March 20th) > - We (the IETF/IESG) are to decide on the first IETF produced PIBs. > If we approve them as standards track, then: > - I suspect we will find a lot of duplicate work, i.e. MIBs and > PIBs, to be designed, tested, handled-for-stds-track approval > - Vendors and users may be faced with the big duplicate investment. > They can opt to not do so, but of course the more PIBs we approve > as stds track, the more the pressure will be put on them. > - We are telling the market that we cannot decide and let them do it. > Maybe this is OK. But not in my mind, I do not think we do the > IETF community or the world a favor by approving this duplicate > approach > > As a result, I cannot propose to the ISG to approve the FRMAEWORK-PIB > (or any PIBs for that matter) on the standards track at this point > in time. I strongly recommend to publish them as Informational for > now. We can revisit this after we get some better architectural > guidelines/help from the current actitivities that are taking > place in informal gatherings and the upcoming IAB NM Workshop. > > I understand that this is sort of "breaking the contract" with > the RAP WG on my part. But the situation has changed quite a bit > from 2 years ago when we started down this path (agreed on the WG > charter). > > Bert ======================================= This email message is for the sole use of the intended recipient (s) and may contain confidential and privileged information, including without limitation, Confidential and/or Proprietary Information belonging to Unisphere Networks, Inc. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Mar 25 15:05:42 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 PAA00146 for ; Mon, 25 Mar 2002 15:05:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06649 for diffserv-archive@odin.ietf.org; Mon, 25 Mar 2002 15:05:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00402; Mon, 25 Mar 2002 14:43:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02894 for ; Mon, 25 Mar 2002 10:54:24 -0500 (EST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15975 for ; Mon, 25 Mar 2002 10:54:19 -0500 (EST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Mon, 25 Mar 2002 16:53:42 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8202007974@lat3721.rd.francetelecom.fr> From: JACQUENET Christian FTRD/DMI/CAE To: "'diffserv@ietf.org'" , "'ipsec-policy@vpnc.org'" Date: Mon, 25 Mar 2002 16:53:55 +0100 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e7b4c597-3f3f-11d6-ac22-00508b692753" Subject: [Diffserv] TR: Support to the PIB standardisation effort (long message) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@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. ------=_NextPartTM-000-e7b4c597-3f3f-11d6-ac22-00508b692753 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D415.44DCD750" ------_=_NextPart_001_01C1D415.44DCD750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, There has been some discussion recently on the rap mailing list about = the usefulness of promoting the PIB standardisation effort, and I've just realized that the message I sent today may be worth sending it to the diffserv and ipsp mailing lists as well - my apologies for any = inconvenience this may have caused. Best regards, Christian. > -----Message d'origine----- > De : JACQUENET Christian FTRD/DMI/CAE =20 > Envoy=E9 : lundi 25 mars 2002 11:53 > =C0 : 'rap@ops.ietf.org'; 'Randy Bush'; 'Wijnen, Bert (Bert)' > Objet : Support to the PIB standardisation effort (long message) > Importance : Haute >=20 > Dear colleagues, >=20 > After having attended the IETF 53 rap meeting (but not having found = the > time to check all the messages on this topic), I'd like to share my = humble > thoughts on the PIB standardisation effort with the rap community > (apologies for a late jumping into this dicussion). >=20 > My personal 12-year experience of designing and deploying IP networks = and > services has led to the following facts and observations: >=20 > 1. I'm not aware of a single network operator/service provider that = uses > SNMP for configuration purposes. Two main reasons for this: > * The network devices CANNOT be configured via SNMP, because of > vendors' technological choices. SNMP is (can) only (be) used for the = "F" > function of the FCAPS sequence of the management area (e.g. we've = been > performing a quick dump on the ifTable on a daily basis for years), > * SNMP is not supported by a reliable transport mode, which is an > issue for conveying configuration information towards operational > equipment, not to mention the security issues. >=20 > 2. As a consequence of the above, we've been using vendor-specific = CLI > syntax for configuration purposes, hence the need to develop a high = level > of expertise that has to be replicated for each technology being used = by > our networks and services.=20 >=20 > 3. As the Internet is becoming a privileged support for a wide range = of > service offerings, ranging from dial-up access to more sophisticated > services like QoS-based IP VPNs, the magnitude of the aforementioned = CLI > usage has dramatically increased, as well as the time to actually > configure all the devices involved in the provisioning of a given = service > accordingly.=20 > To give an example, the deployment of an IPSec-based IP VPN that: > * Interconnects 10 sites > * *Only* supports manual key configuration > * Imposes static routing (because of the vendor's implementation, but > that's another question) > * Is partially meshed > * Supports Internet access > * Supports dial-up IP VPN users (hence the possible use of another > kind of equipment, as well as a L2TP-declined configuration = information) > ...takes something like 4 to 6 hours to *prepare* the configuration = files, > not to mention the additional features like QoS management and the = user > profile management (including specific filters). We then need to = download > the files to the appropriate devices and check the IP connectivity, = as > well as the overall correctness of the configuration information.=20 > Obviously, this is the kind of task that has to be repeated for every = IP > VPN sold, not to mention the available option of other technologies = (e.g. > 2547-based IP VPNs), depending on the size of the VPN, amongst other > considerations that include traffic engineering aspects. >=20 > 4. As a consequence of fact #3, the search for automation (of service > provisioning) has rapidly become one of our most important Graal = quests, > not only because such automation is expected to dramatically reduce = the > cost of deploying (and exploiting) a wide range of service offerings, = but > also because the level of implementation-specific expertise required = to > deploy such services has become incompatible with the "level of = knowledged > people/number of people working in our TAC" ratio. >=20 > 5. As an additional consequence of facts #2 and #4, we've decided to > investigate the COPS-PR track, because of the nicely formulated = arguments > that David (Durham) and others have already exposed on this mailing = list, > but also because the COPS-PR specification effort is on the standards > track (at least it used to be).=20 > This is why we specified, developed and implemented an IP Traffic > Engineering PIB (see > = http://search.ietf.org/internet-drafts/draft-jacquenet-ip-te-pib-01.txt)= . > This is also why we developed and implemented the IPSec PIB, = currently > being standardised in the ipsp working group. This effort has led to = the > development of prototypes that have shown something between a 1:1000 = and > 1:10000 ratio for the provisioning of the corresponding configuration > information to the network devices we currently operate in our = networks, > i.e. a COPS-PR-based dynamic provisioning scheme has yielded a 1000 = to > 10000 faster configuration task than the CLI-based approach (by using > standardised formatted data), with all the guarantees provided, as = far as > the actual processing by the network devices is concerned. > We've also demonstrated these prototypes to our operational branches = who > have shown a strong interest in this technology, especially when > mentioning that such effort is supported by a couple of IETF working > groups. >=20 > Now, to briefly answer to a couple of comments that have been made = during > the rap WG meeting in Minneapolis: >=20 > * It is untrue that vendors are reluctant to implement COPS-PR as = well > as the approriate PIB modules. I'm not supposed to make any kind of > advertisement on this list, but we've been evaluating a couple of > commercially available solutions that implement a sometimes adapted > version of the DiffServ PIB, and I'm also aware of several other = vendors > that claim that kind of support. > * I have to say that the argument (apparently developed by some > network operators) of the need for a single protocol is pathetic: the > "one-size-fits-all" has *never* existed (see the RADIUS, TACACS, = DIAMETER > options for user/device identification/authentication, the > IPCP/RADIUS-inferred IPCP/DHCP options for address allocation, the > RIP/OSPF/IS-IS options for intra-domain routing, etc.), and I = personnally > find VERY useful the existence of such various options, because we = can > make them adapt to a range of specific environments, hence, for = example, > the co-existence of different routing protocols within our domain(s). >=20 > We've been involved in the COPS-PR development stuff for more than = two > years, and our first results have proven very encouraging (including = from > a scalability perspective). >=20 > So, YES, I FULLY support the PIB standardisation effort within the = IETF, > and I would feel very frustrated if the IESG decided, for some = reason, to > abandon such a strategic standardisation effort. I also regret that = only a > few working groups have adopted this PIB standardisation effort. >=20 > Comments welcome. >=20 > Best regards, >=20 > Christian Jacquenet > France Telecom R & D >=20 >=20 >=20 > _________________ ________ ______ ______ > /_____________ /__ /_ _ / / / / / Christian "I'm a = ZZ > Fan" Jacquenet > /_________/ / / / / / / / / /__/ France Telecom R = & D > DMI/SIR > / / /___/__/___/_____/_/__/____ "It's not jewelry = she's > talkin' about, > /__/ /__________________________/_ It really don't = cost > that much." =20 > /_______________________________/ - Pearl necklace. >=20 ------_=_NextPart_001_01C1D415.44DCD750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TR: Support to the PIB standardisation effort (long = message)

Folks,

There has been = some discussion recently on the rap mailing list about the usefulness = of promoting the PIB standardisation effort, and I've just realized = that the message I sent today may be worth sending it to the diffserv = and ipsp mailing lists as well - my apologies for any inconvenience = this may have caused.

Best = regards,

Christian.

 -----Message d'origine-----
De=A0:    = JACQUENET Christian FTRD/DMI/CAE  =
Envoy=E9=A0:        lundi 25 mars 2002 = 11:53
=C0=A0:     'rap@ops.ietf.org'; 'Randy Bush'; 'Wijnen, = Bert (Bert)'
Objet=A0: Support to the PIB standardisation effort = (long message)
Importance=A0:    Haute

Dear colleagues,

After having attended the IETF = 53 rap meeting (but not having found the time to check all the messages = on this topic), I'd like to share my humble thoughts on the PIB = standardisation effort with the rap community (apologies for a late = jumping into this dicussion).

My personal 12-year experience = of designing and deploying IP networks and services has led to the = following facts and observations:

1. I'm not aware of a single = network operator/service provider that uses SNMP for configuration = purposes. Two main reasons for this:

  • The network devices CANNOT = be configured via SNMP, because of vendors' technological choices. SNMP = is (can) only (be) used for the "F" function of the FCAPS = sequence of the management area (e.g. we've been performing a quick = dump on the ifTable on a daily basis for years),
  • SNMP is not supported by a = reliable transport mode, which is an issue for conveying configuration = information towards operational equipment, not to mention the security = issues.

2. As a consequence of the = above, we've been using vendor-specific CLI syntax for configuration = purposes, hence the need to develop a high level of expertise that has = to be replicated for each technology being used by our networks and = services.

3. As the Internet is becoming a = privileged support for a wide range of service offerings, ranging from = dial-up access to more sophisticated services like QoS-based IP VPNs, = the magnitude of the aforementioned CLI usage has dramatically = increased, as well as the time to actually configure all the devices = involved in the provisioning of a given service accordingly. =

To give an example, the = deployment of an IPSec-based IP VPN that:

  • Interconnects 10 = sites
  • *Only* supports manual key = configuration
  • Imposes static routing (because = of the vendor's implementation, but that's another = question)
  • Is partially meshed
  • Supports Internet = access
  • Supports dial-up IP VPN users = (hence the possible use of another kind of equipment, as well as a = L2TP-declined configuration information)

...takes something like 4 to 6 = hours to *prepare* the configuration files, not to mention the = additional features like QoS management and the user profile management = (including specific filters). We then need to download the files to the = appropriate devices and check the IP connectivity, as well as the = overall correctness of the configuration information.

Obviously, this is the kind of = task that has to be repeated for every IP VPN sold, not to mention the = available option of other technologies (e.g. 2547-based IP VPNs), = depending on the size of the VPN, amongst other considerations that = include traffic engineering aspects.

4. As a consequence of fact #3, = the search for automation (of service provisioning) has rapidly become = one of our most important Graal quests, not only because such = automation is expected to dramatically reduce the cost of deploying = (and exploiting) a wide range of service offerings, but also because = the level of implementation-specific expertise required to deploy such = services has become incompatible with the "level of knowledged = people/number of people working in our TAC" ratio.

5. As an additional consequence = of facts #2 and #4, we've decided to investigate the COPS-PR track, = because of the nicely formulated arguments that David (Durham) and = others have already exposed on this mailing list, but also because the = COPS-PR specification effort is on the standards track (at least it = used to be).

This is why we specified, = developed and implemented an IP Traffic Engineering PIB (see http://search.ietf.org/internet-drafts/draft-jacquenet= -ip-te-pib-01.txt). This is also why we developed and implemented = the IPSec PIB, currently being standardised in the ipsp working group. = This effort has led to the development of prototypes that have shown = something between a 1:1000 and 1:10000 ratio for the provisioning of = the corresponding configuration information to the network devices we = currently operate in our networks, i.e. a COPS-PR-based dynamic provisioning scheme = has yielded a 1000 to 10000 faster configuration task than the = CLI-based approach (by using standardised formatted = data), with all the = guarantees provided, as far as the actual processing by the network = devices is concerned.

We've also demonstrated these = prototypes to our operational branches who have shown a strong interest = in this technology, especially when mentioning that such effort is = supported by a couple of IETF working groups.

Now, to briefly answer to a = couple of comments that have been made during the rap WG meeting in = Minneapolis:

  • It is untrue that vendors = are reluctant to implement COPS-PR as well as the approriate PIB = modules. I'm not supposed to make any kind of advertisement on this = list, but we've been evaluating a couple of commercially available = solutions that implement a sometimes adapted version of the DiffServ = PIB, and I'm also aware of several other vendors that claim that kind = of support.
  • I have to say that the argument = (apparently developed by some network operators) of the need for a = single protocol is pathetic: the "one-size-fits-all" has = *never* existed (see the RADIUS, TACACS, DIAMETER options for = user/device identification/authentication, the IPCP/RADIUS-inferred = IPCP/DHCP options for address allocation, the RIP/OSPF/IS-IS options = for intra-domain routing, etc.), and I personnally find VERY useful the = existence of such various options, because we can make them adapt to a = range of specific environments, hence, for example, the co-existence of = different routing protocols within our domain(s).

We've been involved in the = COPS-PR development stuff for more than two years, and our first = results have proven very encouraging (including from a scalability = perspective).

So, YES, I FULLY support the PIB = standardisation effort within the IETF, and I would feel very = frustrated if the IESG decided, for some reason, to abandon such a = strategic standardisation effort. I also regret that only a few working = groups have adopted this PIB standardisation effort.

Comments welcome.

Best regards,

Christian Jacquenet
France Telecom R & D



    = _________________    ________  ______  = ______
   = /_____________   /__ /_    _ / = /     / /     /   = Christian "I'm a ZZ Fan" Jacquenet
      = /_________/  /  /   /  /   /  = /  / /  /__/    France Telecom R & D = DMI/SIR
           &= nbsp;   /  /  = /___/__/___/_____/_/__/____   "It's not jewelry she's = talkin' about,
           &= nbsp;  /__/  /__________________________/_ It really don't = cost that much." 
           &= nbsp;    /_______________________________/ - Pearl = necklace.

------_=_NextPart_001_01C1D415.44DCD750-- ------=_NextPartTM-000-e7b4c597-3f3f-11d6-ac22-00508b692753-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 26 03:17:03 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 DAA27131 for ; Tue, 26 Mar 2002 03:17:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA01727 for diffserv-archive@odin.ietf.org; Tue, 26 Mar 2002 03:17:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26619; Tue, 26 Mar 2002 02:57:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26579 for ; Tue, 26 Mar 2002 02:57:00 -0500 (EST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26848 for ; Tue, 26 Mar 2002 02:56:55 -0500 (EST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 26 Mar 2002 13:44:24 +0530 Received: from abdulmk (abdulmk.future.futsoft.com [10.4.8.10]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g2Q7u3e30124 for ; Tue, 26 Mar 2002 13:26:03 +0530 From: "Abdul Malick" To: Date: Tue, 26 Mar 2002 13:22:00 +0530 Message-Id: MIME-Version: 1.0 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 V5.00.2919.6600 Importance: Normal In-Reply-To: <3C9A697D.E7C80228@hursley.ibm.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Question on RSVP DiffServ Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hello all, I have a clarrification regarding the use of RSVP for DiffServ: The rfcs 2996 and 2998 talk about the usage of RSVP in mapping IntServ over DiffServ networks. One of the approaches is based on the BRs of the DiffServ domain being able to understand RSVP messages and add DCLASS object(eggress BR) in the RESV message (after mapping the InServ service to DiffServ PHB(s)). My doubt is, can't we use this approach for a pure DiffServ network where we could add an object similar to the DCLASS object in the PATH message that would allow us to signal reservations for a particular PSC or a set of PSCs. May be this could be done as a result of the negotiation of a Pipe SLA. Each DS domain can apply their local remarking if the DSCP values used in the neighboring domains are known before hand. This could improve the predictability and also avoid over provisioning and other problems that we face with static provisioning. Please pardon me if this has been already discussed or sounds too silly for wasting any time on. Expecting some reply, Warm Regards, Malick. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 26 09:11: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 JAA03544 for ; Tue, 26 Mar 2002 09:11:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26133 for diffserv-archive@odin.ietf.org; Tue, 26 Mar 2002 09:11:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15305; Tue, 26 Mar 2002 08:32:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15263 for ; Tue, 26 Mar 2002 08:32:39 -0500 (EST) Received: from smtp.postech.ac.kr (smtp1.postech.ac.kr [141.223.2.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01822 for ; Tue, 26 Mar 2002 08:32:37 -0500 (EST) Received: from comus (comus.postech.ac.kr [141.223.92.55]) by smtp.postech.ac.kr (v3smtp 8.11.6.4/8.11.1) with SMTP id g2QDasi27920 for ; Tue, 26 Mar 2002 22:36:54 +0900 (KST) From: "Geunhyung Kim" To: "diffserv" Date: Tue, 26 Mar 2002 22:26:44 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id IAA15264 Subject: [Diffserv] Question about re-ordering in AF Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hello All, RFC2597 recommend the ordering of packet should be remained. In the AF PHB, there may be marked packet. Does that ordering cosider the marked packet also ? Thanks in advance Geunhyung None of us is as smart as all of us ========================================== Geunhyung Kim E-mail: geunkim@postech.edu Tel: +82-54-279-5655 Fax: +82-54-279-5699 Networking & Distributed Systems Lab. CSE POSTECH =========================================== _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 26 10:23: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 KAA06310 for ; Tue, 26 Mar 2002 10:23:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA16008 for diffserv-archive@odin.ietf.org; Tue, 26 Mar 2002 10:23:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07329; Tue, 26 Mar 2002 09:55:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07285 for ; Tue, 26 Mar 2002 09:55:31 -0500 (EST) Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04965 for ; Tue, 26 Mar 2002 09:55:29 -0500 (EST) From: Black_David@emc.com Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 09:54:34 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293764A@CORPMX14> To: abdulmk@future.futsoft.com, diffserv@ietf.org Subject: RE: [Diffserv] Question on RSVP DiffServ Date: Tue, 26 Mar 2002 09:54:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Abdul, > I have a clarification regarding the use of RSVP for DiffServ: > > The rfcs 2996 and 2998 talk about the usage of RSVP in mapping IntServ over > DiffServ networks. One of the approaches is based on the BRs of the DiffServ > domain being able to understand RSVP messages and add DCLASS object(eggress > BR) in the RESV message (after mapping the InServ service to DiffServ > PHB(s)). > > My doubt is, can't we use this approach for a pure DiffServ network where we > could add an object similar to the DCLASS object in the PATH message that > would allow us to signal reservations for a particular PSC or a set of PSCs. > > May be this could be done as a result of the negotiation of a > Pipe SLA. This sort of approach could be used, but the DCLASS object is somewhat problematic for this purpose. The next paragraph touches on the issue: > Each DS domain can apply their local remarking if the DSCP values used in > the neighboring domains are known before hand. This could improve the > predictability and also avoid over provisioning and other problems that we > face with static provisioning. The issue with the DCLASS object is that the meaning of a DSCP value is specific to each diffserv domain. The DCLASS object assumes RSVP's hop by hop processing model, and specifically that if it crosses a diffserv domain boundary, the relevant diffserv edge nodes will process the RSVP messages modifying the DSCP(s) in the DCLASS object as necessary. If this is not done, it's easy to get confused about which diffserv domain should be used to interpret the contents of a DCLASS object. FWIW, the scenario that motivated the specification of the DCLASS object has exactly one diffserv domain, making this confusion impossible. One can expect that some of the diffserv edge nodes will be rather busy doing other things (e.g., traffic forwarding, routing updates) and won't want to handle RSVP. The preferred approach for signaling diffserv QoS across diffserv domain boundaries is to use PHBIDs as defined in RFC 3140, and that definition has been carefully worded so that it could be used to signal IP Precedence if that were desired. PHBID-based signaling could run among QoS managers in different diffserv domains without worrying about domain boundary crossings making a hash of interpreting the DSCP values. > Please pardon me if this has been already discussed or sounds too silly for > wasting any time on. It makes some sense to me - a good step would be to write a draft for an RSVP object to carry one or more PHBIDs and see how much interest there is in implementing and using it. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 26 11:19: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 LAA09134 for ; Tue, 26 Mar 2002 11:19:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02741 for diffserv-archive@odin.ietf.org; Tue, 26 Mar 2002 11:19:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25606; Tue, 26 Mar 2002 10:55:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25471 for ; Tue, 26 Mar 2002 10:55:45 -0500 (EST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07909 for ; Tue, 26 Mar 2002 10:55:42 -0500 (EST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 26 Mar 2002 21:43:10 +0530 Received: from abdulmk (abdulmk.future.futsoft.com [10.4.8.10]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g2QFsme28647; Tue, 26 Mar 2002 21:24:48 +0530 From: "Abdul Malick" To: , Subject: RE: [Diffserv] Question on RSVP DiffServ Date: Tue, 26 Mar 2002 21:20:47 +0530 Message-Id: MIME-Version: 1.0 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 V5.00.2919.6600 Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0293764A@CORPMX14> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hello David, Thanks a tonn for your response. I had already considered interdomain DSCP compatibility and hence mentioned that we can use PSC (instead of DSCP). Thanks for the reference to the exact rfc (PHBID). Also i had given DCLASS only as an example. I am sure we have to device some new object that can be put into the PATH message. Actually i am concerned about the inherent overhead that RSVP would introduce in the core with this approach. But since RSVP has already been accepted for MPLS in core, i hope its OK. I will wait for further responses and propose a draft, if this idea is welcomed. Thanks and Regards, Malick. -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Black_David@emc.com Sent: Tuesday, 26 March 2002 8:25 PM To: abdulmk@future.futsoft.com; diffserv@ietf.org Subject: RE: [Diffserv] Question on RSVP DiffServ Abdul, > I have a clarification regarding the use of RSVP for DiffServ: > > The rfcs 2996 and 2998 talk about the usage of RSVP in mapping IntServ over > DiffServ networks. One of the approaches is based on the BRs of the DiffServ > domain being able to understand RSVP messages and add DCLASS object(eggress > BR) in the RESV message (after mapping the InServ service to DiffServ > PHB(s)). > > My doubt is, can't we use this approach for a pure DiffServ network where we > could add an object similar to the DCLASS object in the PATH message that > would allow us to signal reservations for a particular PSC or a set of PSCs. > > May be this could be done as a result of the negotiation of a > Pipe SLA. This sort of approach could be used, but the DCLASS object is somewhat problematic for this purpose. The next paragraph touches on the issue: > Each DS domain can apply their local remarking if the DSCP values used in > the neighboring domains are known before hand. This could improve the > predictability and also avoid over provisioning and other problems that we > face with static provisioning. The issue with the DCLASS object is that the meaning of a DSCP value is specific to each diffserv domain. The DCLASS object assumes RSVP's hop by hop processing model, and specifically that if it crosses a diffserv domain boundary, the relevant diffserv edge nodes will process the RSVP messages modifying the DSCP(s) in the DCLASS object as necessary. If this is not done, it's easy to get confused about which diffserv domain should be used to interpret the contents of a DCLASS object. FWIW, the scenario that motivated the specification of the DCLASS object has exactly one diffserv domain, making this confusion impossible. One can expect that some of the diffserv edge nodes will be rather busy doing other things (e.g., traffic forwarding, routing updates) and won't want to handle RSVP. The preferred approach for signaling diffserv QoS across diffserv domain boundaries is to use PHBIDs as defined in RFC 3140, and that definition has been carefully worded so that it could be used to signal IP Precedence if that were desired. PHBID-based signaling could run among QoS managers in different diffserv domains without worrying about domain boundary crossings making a hash of interpreting the DSCP values. > Please pardon me if this has been already discussed or sounds too silly for > wasting any time on. It makes some sense to me - a good step would be to write a draft for an RSVP object to carry one or more PHBIDs and see how much interest there is in implementing and using it. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.ht ml *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 26 11:35: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 LAA10214 for ; Tue, 26 Mar 2002 11:35:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07177 for diffserv-archive@odin.ietf.org; Tue, 26 Mar 2002 11:35:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02373; Tue, 26 Mar 2002 11:18:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02333 for ; Tue, 26 Mar 2002 11:18:48 -0500 (EST) Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09069 for ; Tue, 26 Mar 2002 11:18:45 -0500 (EST) From: Black_David@emc.com Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2QGIC417045; Tue, 26 Mar 2002 11:18:12 -0500 (EST) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g2QGI9729065; Tue, 26 Mar 2002 11:18:12 -0500 (EST) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 11:17:43 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293764F@CORPMX14> To: abdulmk@future.futsoft.com, diffserv@ietf.org Subject: RE: [Diffserv] Question on RSVP DiffServ Date: Tue, 26 Mar 2002 11:17:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org One more comment: > Actually i am concerned about the inherent overhead that RSVP would > introduce in the core with this approach. But since RSVP has already been > accepted for MPLS in core, i hope its OK. Just to be clear, MPLS uses RSVP for traffic engineering purposes. RSVP for every microflow won't scale in the core, so use of RSVP for QoS negotiation has to be at some traffic aggregate level, which is what I believe Abdul intended. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Mar 26 13:15: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 NAA17152 for ; Tue, 26 Mar 2002 13:15:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08066 for diffserv-archive@odin.ietf.org; Tue, 26 Mar 2002 13:15:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03039; Tue, 26 Mar 2002 12:58:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02946 for ; Tue, 26 Mar 2002 12:58:27 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16342 for ; Tue, 26 Mar 2002 12:58:25 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA14215; Tue, 26 Mar 2002 12:57:54 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA05500; Tue, 26 Mar 2002 12:57:55 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Mar 2002 12:57:48 -0500 Message-ID: <313680C9A886D511A06000204840E1CF76B9D7@whq-msgusr-02.pit.comms.marconi.com> From: "Iren, Sami" To: "'Geunhyung Kim'" , diffserv Subject: RE: [Diffserv] Question about re-ordering in AF Date: Tue, 26 Mar 2002 12:57:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ks_c_5601-1987" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Geunhyung: The ordering within the same AF PSC (e.g., AF1) should be maintained regardless of the drop precedence (color) of the packet. By "marked packet" if you mean packets that are marked with a different drop precedence (color) due to policing or some other means, the answer is yes as long as they all belong to the same PSC (e.g., AF1). I hope this helps. Regards, --Sami > -----Original Message----- > From: Geunhyung Kim [mailto:geunkim@postech.ac.kr] > Sent: Tuesday, March 26, 2002 8:27 AM > To: diffserv > Subject: [Diffserv] Question about re-ordering in AF > > > Hello All, > > RFC2597 recommend the ordering of packet should be remained. > In the AF PHB, there may be marked packet. > > Does that ordering cosider the marked packet also ? > > Thanks in advance > > Geunhyung > > None of us is as smart as all of us > ========================================== > Geunhyung Kim > > E-mail: geunkim@postech.edu > > Tel: +82-54-279-5655 > Fax: +82-54-279-5699 > > Networking & Distributed Systems Lab. > CSE > POSTECH > =========================================== > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www.ietf.org/mail-archive/working-groups/diffserv/curre nt/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Mar 26 17:17: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 RAA27515 for ; Tue, 26 Mar 2002 17:17:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14021 for diffserv-archive@odin.ietf.org; Tue, 26 Mar 2002 17:17:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08619; Tue, 26 Mar 2002 16:58:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08525 for ; Tue, 26 Mar 2002 16:58:21 -0500 (EST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26868 for ; Tue, 26 Mar 2002 16:58:16 -0500 (EST) Received: from study ([24.128.201.164]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020326215625.BDYZ2626.rwcrmhc51.attbi.com@study>; Tue, 26 Mar 2002 21:56:25 +0000 Message-ID: <007601c1d510$48304300$650a0a0a@ne.client2.attbi.com> From: "Walter Weiss" To: , "DiffServ2" , References: Date: Tue, 26 Mar 2002 16:50:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: why i should like pibs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Bert, This is a thoughtful and rational justification to your position. If I may paraphrase, your primary concerns are: 1. That the level of interest in this new approach is currently low. 2. That the value is low given the overlap with MIBs. 3. That the incremental cost of developing PIBs for all areas in the IETF is huge. Let's consider this from the operations perspective. First of all, the pervasive perspective that there is only one operations organization is very misleading. In fact, most providers have multiple operations organizations. One organization may be responsible for a given backbone while other organizations within the same provider are responsible for specific businesses (some regulated and some not), and business models. In many cases, there are even multiple backbone organizations. These organizations all have different needs and some are grossly under-represented in our discussions. In my opinion, this is primarily because many are interested in service deployments/revenue generation and less interested in low level transport issues. This perspective has been reinforced by a variety of discussions I have had with several Tier 1 providers. Hence, a true understanding of operational needs is far beyond our grasp because we don't have a statistically significant sample or a true understanding of actual operational models. Therefore, drawing conclusions about the value of COPS or PIBS to operators is premature. That said, I would like commend both Bert and Randy for the initiative they have shown in trying to better understand operational environments and requirements. I would also like to consider this issue from a requirements perspective. In my view, we can divide operational needs into four areas: Stats Collection, Events, Static config and Dynamic config. Stats Collection has the following characteristics. It is non-real-time, it consumes lots of bandwidth, and it is not transactional. They are more suitable to a protocol like TCP that is sensative to congestion control, which explains why stats are often sent with FTP rather than SNMP. Events are real time, small and infrequent messages and non-transactional. They require guaranteed delivery irrespective of network congestion or loss. This application is ideally suited to the capabilities of SNMP, which is why it is so broadly deployed for this purpose. Static config is performed in the core of networks where network stability is critical. This means infrequent changes and the changes that are made are typically at the transport level (links, routes, route policies, and filters). Static config messages require transactional and non-real time messaging. The configurations are complicated. CLI is prefered over SNMP because the language is simpler than attribute level pokes, because textual is not significantly more overhead than binary and because the language provides an abstraction. Dynamic config occurs and the edges and focuses exclusively on dynamic service deployment. It requires frequent updates. In some cases frequent means every time a user logs in, in other cases it means when a VPN is bound to a new user, and in other cases every time a service is activated (a telephone call is made). In this environment, which not adequately addressed with current technologies, config changes must be performed quickly to accommodate systems or users waiting for authorization (login, call setup delay, etc.) Further, because the configurations are relatively complex, they need large multi-packet messaging and transactional capabilities. Finally, because most service changes are transitory (when the call completes, the configs should be uninstalled), a mechanism that simplifies this process is ideal. IMO, given the requirements, COPS-PR is the optimal choice amongst the available alternatives. However, I do not believe it is a suitable technology for the other three operational issues. Given the diverse requirements for each aspect of NM, I would suggest that there is no silver bullet here. No single protocol, transport, or language can viably meet all the requirements of every aspect of NM. I would also like to reconsider Bert's points. First, I would agree that the level of interest in COPS-PR is relatively small. However, I would argue that this is because Dynamic Config is only starting to become important as mappings for QoS, Security, and Tunneling are coming to the forefront. Second, I disagree that there is overlap with PIBs. While the DiffServ PIB and MIB are nearly identical, this was done because it was assumed that they were both addressing the config space that CLI is so clearly dominating. In the absense of a common model for all config, I believe this was a mistake. Given the unique applicability of COPS-PR, PIBs should be defined specifically for this purpose and only this purpose. On Bert's third point, I would argue that the investment in PIBs is far smaller than he suggests. Given the specific scope of applicability, PIBs would not be appropriate for most IETF activities involving failure events or static config (routing, transport and applications). Hence, the number of PIBs is relatively small. Further, I do not believe that any of the alternatives on the table can meet these requirements to the extent that COPS-PR can. I would agree with Juergen that what we have today is a hodge-podge of protocols and mechanisms for configuration management and little incentive for changing the situation. As such, I see two alternatives: 1. We can use COPS-PR and restrict it specifically to the area that it addresses most effectively: dynamic config management (at the network edge). 2. We can block progress on all config drafts/standards to motivate a solution to Juergen's larger issue of concerted participation in a single and uniform set of standards. We could also block the advancement of COPS-PR. However, that prevents us from addressing the dynamic config space and does not advance an alternative. It also does nothing about the overall progress in the O&M area that Juergen alluded to. This was in essence the point I was trying to make in my earlier message to Randy. regards, -Walter > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, March 21, 2002 4:13 PM > To: rap@ops.ietf.org > Cc: diffserv@ietf.org; ipsec-policy@vpnc.org > Subject: RE: why i should like pibs > > > All, > > Let me post to these lists a similar statement as I made in the > RAP WG meeting at this 53rd IETF, so that everyone has the same > info. Here we go. I would prefer to have andy reactions (if any) > posted to just one mailing list (the RAP wg mailing list). > > When the WG completed WG Last Call and reached consensus on > the FRAMEWORK PIB, the WG chairs asked me (the primary AD > for the WG) to consider this document for Proposed Standard. > Normally I then review and ask for IETF wide Last Call and > if no valid objections are received, then I put the document > on the IESG agenda for approval. > > My current evaluation however for this document at this time > is as follows: > - If we look at the NM related activities, then we can see > that for SNMP/MIBs, the majority of work/time/effort is > spent in the MIB development. It also touches on virtually > all WGs. Same will be true for COPS-PR/PIBs if we start to > put PIBs on the standareds track. > This could be a VERY BIG thing. In SNMP, the real investment > is in MIBs. This is true for MIB design (IETF), for vendor > implementation effort, and for user deployment. If IETF > working groups start to develop PIBs they would be faced > with significant extra, and in many cases, redundant effort > - We have accepted COPS and COPS-PR 2-3 years ago as PS. > That was the start of a duplicate approach, which only > provides marginal improvement in some areas, and possibly > a negative effect in some other areas. > - We have also accepted SPPI as a duplicate approach, again > with only marginal improvement. It allows to define PIBs, > most of which I think can also be done with MIBs or > better/different MIB design. > - Note that PIBs are basically intended for configuring > network devices and services. > - Two years back, the ADs and Diffserv WG chairs agreed to do > a MIB and a PIB for standards track. And we agreed with the > RAP WG to develop a set of base PIBs for standards track. > - Meanwhile, we have seen: > - Some key players withdrew from COPS and PIBs approach > They claim there is no market, and with reduced budgets > there is no place to just do multiple solutions to same > address space. > - In most cases, PIB development is done by different people > than MIB development, if we're lucky they talk to each other. > - WGs in general have very little interest in MIBs or in PIBs, > let alone both. > - Operators (ISPs) tell us they do not see much use for binary > interfaces (be it SNMP/MIBs or COPS-PR/PIBs or other) to > configure their network devices/services. The reality is that > they use (and expect to have to continue to use) ASCII based > CLI-type interfaces (Maybe ASCII should read human readable) > - We have started an effort to try and consolidate SMI and SPPI > We may want to await the results before we invest in the > standardization of PIBs. > - The NM community in the IETF (lots of SNMP folk, but COPS, > Policy WG and Operators are participating too) are trying to > come up with some vision/framework to address Operator (ISP) > concerns. Discussions is only in beginning stages and not any > IETF sanctioned status yet. > - IAB is planning a NM Architecture Workshop this summer (as > announced at the IAB plenary on Wednesday March 20th) > - We (the IETF/IESG) are to decide on the first IETF produced PIBs. > If we approve them as standards track, then: > - I suspect we will find a lot of duplicate work, i.e. MIBs and > PIBs, to be designed, tested, handled-for-stds-track approval > - Vendors and users may be faced with the big duplicate investment. > They can opt to not do so, but of course the more PIBs we approve > as stds track, the more the pressure will be put on them. > - We are telling the market that we cannot decide and let them do it. > Maybe this is OK. But not in my mind, I do not think we do the > IETF community or the world a favor by approving this duplicate > approach > > As a result, I cannot propose to the ISG to approve the FRMAEWORK-PIB > (or any PIBs for that matter) on the standards track at this point > in time. I strongly recommend to publish them as Informational for > now. We can revisit this after we get some better architectural > guidelines/help from the current actitivities that are taking > place in informal gatherings and the upcoming IAB NM Workshop. > > I understand that this is sort of "breaking the contract" with > the RAP WG on my part. But the situation has changed quite a bit > from 2 years ago when we started down this path (agreed on the WG > charter). > > Bert > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Mar 26 22:25:26 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 WAA05261 for ; Tue, 26 Mar 2002 22:25:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA02081 for diffserv-archive@odin.ietf.org; Tue, 26 Mar 2002 22:25:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24055; Tue, 26 Mar 2002 21:54:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24002 for ; Tue, 26 Mar 2002 21:54:44 -0500 (EST) Received: from Bayou.UH.EDU (Creek.UH.EDU [129.7.235.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04953 for ; Tue, 26 Mar 2002 21:54:38 -0500 (EST) Received: from localhost (mrpatil@localhost) by Bayou.UH.EDU (8.11.6/8.11.6) with ESMTP id g2R2qRP542103 for ; Tue, 26 Mar 2002 20:52:27 -0600 (CST) Date: Tue, 26 Mar 2002 20:52:27 -0600 (CST) From: Mandar R Patil To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Actual implementation of diffserv Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Friends: Some questions related to diffserv. Hope those will be answered. I am reading lot about diffserv and quality of service over IP. Very good technology bound to change networking standards. I want to know whether any enterprising networks as well as ISPs in US implements this. Which are those networks in US using diffserv in thier networks. CISCO is providing Cisco IOS Software Release 12.1(5)T for this. There may be other products also following RFC 2475 standards. Are these products actually used and where in US? Thanks in advance! Mandar _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 27 03:44:08 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 DAA19483 for ; Wed, 27 Mar 2002 03:44:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA16854 for diffserv-archive@odin.ietf.org; Wed, 27 Mar 2002 03:44:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11624; Wed, 27 Mar 2002 03:31:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28904 for ; Tue, 26 Mar 2002 20:10:34 -0500 (EST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01968; Tue, 26 Mar 2002 20:10:28 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g2R1ATR01007; Tue, 26 Mar 2002 17:10:29 -0800 (PST) Message-Id: <200203270110.g2R1ATR01007@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 26 Mar 2002 17:10:28 -0800 From: RFC Editor Subject: [Diffserv] RFC 3248 on Delay Bound alternative revision of RFC 2598 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3248 Title: A Delay Bound alternative revision of RFC 2598 Author(s): G. Armitage, B. Carpenter, A. Casati, J. Crowcroft, J. Halpern, B. Kumar, J. Schnizlein Status: Informational Date: March 2002 Mailbox: garmitage@swin.edu.au, brian@hursley.ibm.com, acasati@lucent.com, J.Crowcroft@cs.ucl.ac.uk, joel@longsys.com, brijesh@coronanetworks.com, john.schnizlein@cisco.com Pages: 11 Characters: 21597 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-diffserv-efresolve-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3248.txt For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB. This document is a product of the Differentiated Services Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020326170820.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3248 --OtherAccess Content-Type: Message/External-body; name="rfc3248.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020326170820.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 27 03:44: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 DAA19514 for ; Wed, 27 Mar 2002 03:44:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA16857 for diffserv-archive@odin.ietf.org; Wed, 27 Mar 2002 03:44:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11840; Wed, 27 Mar 2002 03:31:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29582 for ; Tue, 26 Mar 2002 20:12:48 -0500 (EST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02009; Tue, 26 Mar 2002 20:12:41 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g2R1ChR02290; Tue, 26 Mar 2002 17:12:43 -0800 (PST) Message-Id: <200203270112.g2R1ChR02290@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 26 Mar 2002 17:12:43 -0800 From: RFC Editor Subject: [Diffserv] RFC 3247 on Supplemental Information Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3247 Title: Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior) Author(s): A. Charny, J. Bennet, K. Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C. Kalmanek, K. Ramakrishnan Status: Informational Date: March 2002 Mailbox: acharny@cisco.com, jcrb@motorola.com, Kent.Benson@tellabs.com, jean-yves.leboudec@epfl.ch, angela.chiu@celion.com, bill.courtney@trw.com, sahram_davari@pmc-sierra.com, vfiroiu@nortelnetworks.com, crk@research.att.com, kk@teraoptic.com Pages: 25 Characters: 53786 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-diffserv-ef-supplemental-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3247.txt This document was written during the process of clarification of RFC 2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. This document is a product of the Differentiated Services Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020326171054.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3247 --OtherAccess Content-Type: Message/External-body; name="rfc3247.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020326171054.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 27 03:44: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 DAA19498 for ; Wed, 27 Mar 2002 03:44:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA16848 for diffserv-archive@odin.ietf.org; Wed, 27 Mar 2002 03:44:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11974; Wed, 27 Mar 2002 03:31:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00218 for ; Tue, 26 Mar 2002 20:15:05 -0500 (EST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02100; Tue, 26 Mar 2002 20:15:02 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g2R1F4R03077; Tue, 26 Mar 2002 17:15:04 -0800 (PST) Message-Id: <200203270115.g2R1F4R03077@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 26 Mar 2002 17:15:03 -0800 From: RFC Editor Subject: [Diffserv] RFC 3246 on An Expedited Forwarding PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3246 Title: An Expedited Forwarding PHB (Per-Hop Behavior) Author(s): B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis Status: Standards Track Date: March 2002 Mailbox: bsd@cisco.com, acharny@cisco.com, jcrb@motorola.com, Kent.Benson@tellabs.com, jean-yves.leboudec@epfl.ch, bill.courtney@trw.com, shahram_davari@pmc-sierra.com, vfiroiu@nortelnetworks.com, stiliadi@bell-labs.com Pages: 16 Characters: 33896 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-diffserv-rfc2598bis-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3246.txt This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. This document is a product of the Differentiated Services Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020326171306.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3246 --OtherAccess Content-Type: Message/External-body; name="rfc3246.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020326171306.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 27 03:48: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 DAA19614 for ; Wed, 27 Mar 2002 03:48:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18088 for diffserv-archive@odin.ietf.org; Wed, 27 Mar 2002 03:48:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11546; Wed, 27 Mar 2002 03:30:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28087 for ; Tue, 26 Mar 2002 20:07:43 -0500 (EST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01870; Tue, 26 Mar 2002 20:07:40 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g2R17gR29797; Tue, 26 Mar 2002 17:07:42 -0800 (PST) Message-Id: <200203270107.g2R17gR29797@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 26 Mar 2002 17:07:42 -0800 From: RFC Editor Subject: [Diffserv] RFC 3247 on Supplemental Information Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3247 Title: Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior) Author(s): A. Charny, J. Bennet, K. Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C. Kalmanek, K. Ramakrishnan Status: Informational Date: March 2002 Mailbox: acharny@cisco.com, jcrb@motorola.com, Kent.Benson@tellabs.com, jean-yves.leboudec@epfl.ch, angela.chiu@celion.com, bill.courtney@trw.com, sahram_davari@pmc-sierra.com, vfiroiu@nortelnetworks.com, crk@research.att.com, kk@teraoptic.com Pages: 25 Characters: 53786 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-diffserv-ef-supplemental-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3247.txt This document was written during the process of clarification of RFC 2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. This document is a product of the Differentiated Services Working Group of the IETF. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020326170511.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3247 --OtherAccess Content-Type: Message/External-body; name="rfc3247.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020326170511.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 27 04:38:38 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 EAA20524 for ; Wed, 27 Mar 2002 04:38:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02589 for diffserv-archive@odin.ietf.org; Wed, 27 Mar 2002 04:38:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28521; Wed, 27 Mar 2002 04:26:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28466 for ; Wed, 27 Mar 2002 04:26:03 -0500 (EST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20207 for ; Wed, 27 Mar 2002 04:26:01 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id KAA141614; Wed, 27 Mar 2002 10:25:25 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2R9POq101742; Wed, 27 Mar 2002 10:25:24 +0100 Received: from dhcp22-167.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61658 from ; Wed, 27 Mar 2002 10:25:22 +0100 Message-Id: <3CA18FEF.B03F0FA4@hursley.ibm.com> Date: Wed, 27 Mar 2002 10:25:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Mandar R Patil Cc: diffserv@ietf.org Subject: Re: [Diffserv] Actual implementation of diffserv References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Could you please take this discussion to the diffserv implementation list? http://www.atnf.csiro.au/news/exploders/dsimplementation.html Thanks Brian Carpenter diffserv co-chair Mandar R Patil wrote: > > Friends: > Some questions related to diffserv. Hope those will be answered. > I am reading lot about diffserv and quality of service over IP. > Very good technology bound to change networking standards. I want to know > whether any enterprising networks as well as ISPs in US implements this. > Which are those networks in US using diffserv in thier networks. > CISCO is providing Cisco IOS Software Release 12.1(5)T for this. There may > be other products also following RFC 2475 standards. Are these products > actually used and where in US? > Thanks in advance! > Mandar > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 27 04:38: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 EAA20541 for ; Wed, 27 Mar 2002 04:38:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02619 for diffserv-archive@odin.ietf.org; Wed, 27 Mar 2002 04:38:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28113; Wed, 27 Mar 2002 04:24:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28071 for ; Wed, 27 Mar 2002 04:24:39 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20178 for ; Wed, 27 Mar 2002 04:24:37 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id KAA129140; Wed, 27 Mar 2002 10:23:11 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2R9NAq155844; Wed, 27 Mar 2002 10:23:10 +0100 Received: from dhcp22-167.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA57202 from ; Wed, 27 Mar 2002 10:23:08 +0100 Message-Id: <3CA18F68.4C839F2@hursley.ibm.com> Date: Wed, 27 Mar 2002 10:22:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Black_David@emc.com Cc: abdulmk@future.futsoft.com, diffserv@ietf.org Subject: Re: [Diffserv] Question on RSVP DiffServ References: <277DD60FB639D511AC0400B0D068B71E0293764A@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This discussion seems more relevant to ISSLL or NSIS. We are not (and will not be) chartered to discuss signalling issues in diffserv. Brian Black_David@emc.com wrote: > > Abdul, > > > I have a clarification regarding the use of RSVP for DiffServ: > > > > The rfcs 2996 and 2998 talk about the usage of RSVP in mapping IntServ > over > > DiffServ networks. One of the approaches is based on the BRs of the > DiffServ > > domain being able to understand RSVP messages and add DCLASS > object(eggress > > BR) in the RESV message (after mapping the InServ service to DiffServ > > PHB(s)). > > > > My doubt is, can't we use this approach for a pure DiffServ network where > we > > could add an object similar to the DCLASS object in the PATH message that > > would allow us to signal reservations for a particular PSC or a set of > PSCs. > > > > May be this could be done as a result of the negotiation of a > > Pipe SLA. > > This sort of approach could be used, but the DCLASS object is somewhat > problematic for this purpose. The next paragraph touches on the issue: > > > Each DS domain can apply their local remarking if the DSCP values used in > > the neighboring domains are known before hand. This could improve the > > predictability and also avoid over provisioning and other problems that we > > face with static provisioning. > > The issue with the DCLASS object is that the meaning of a DSCP value > is specific to each diffserv domain. The DCLASS object assumes RSVP's > hop by hop processing model, and specifically that if it crosses a > diffserv domain boundary, the relevant diffserv edge nodes will process > the RSVP messages modifying the DSCP(s) in the DCLASS object as necessary. > If this is not done, it's easy to get confused about which diffserv > domain should be used to interpret the contents of a DCLASS object. > FWIW, the scenario that motivated the specification of the DCLASS object > has exactly one diffserv domain, making this confusion impossible. > > One can expect that some of the diffserv edge nodes will be rather busy > doing other things (e.g., traffic forwarding, routing updates) and won't > want to handle RSVP. The preferred approach for signaling diffserv QoS > across diffserv domain boundaries is to use PHBIDs as defined in RFC 3140, > and that definition has been carefully worded so that it could be used to > signal IP Precedence if that were desired. PHBID-based signaling could > run among QoS managers in different diffserv domains without worrying about > domain boundary crossings making a hash of interpreting the DSCP values. > > > Please pardon me if this has been already discussed or sounds too silly > for > > wasting any time on. > > It makes some sense to me - a good step would be to write a draft for > an RSVP object to carry one or more PHBIDs and see how much > interest there is in implementing and using it. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 27 04:43: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 DAA19497 for ; Wed, 27 Mar 2002 03:44:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA16881 for diffserv-archive@odin.ietf.org; Wed, 27 Mar 2002 03:44:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11469; Wed, 27 Mar 2002 03:30:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27140 for ; Tue, 26 Mar 2002 20:04:23 -0500 (EST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01814; Tue, 26 Mar 2002 20:04:20 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g2R14IR27796; Tue, 26 Mar 2002 17:04:18 -0800 (PST) Message-Id: <200203270104.g2R14IR27796@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 26 Mar 2002 17:04:18 -0800 From: RFC Editor Subject: [Diffserv] RFC 3246 on An Expedited Forwarding PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3246 Title: An Expedited Forwarding PHB (Per-Hop Behavior) Author(s): B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis Status: Standards Track Date: March 2002 Mailbox: bsd@cisco.com, acharny@cisco.com, jcrb@motorola.com, Kent.Benson@tellabs.com, jean-yves.leboudec@epfl.ch, bill.courtney@trw.com, shahram_davari@pmc-sierra.com, vfiroiu@nortelnetworks.com, stiliadi@bell-labs.com Pages: 16 Characters: 33896 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-diffserv-rfc2598bis-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3246.txt This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. This document is a product of the Differentiated Services Working Group of the IETF. This document is now a Proposed Standard Protocol. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020326170146.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3246 --OtherAccess Content-Type: Message/External-body; name="rfc3246.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020326170146.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 27 08:49:19 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 IAA27671 for ; Wed, 27 Mar 2002 08:49:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05081 for diffserv-archive@odin.ietf.org; Wed, 27 Mar 2002 08:49:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29226; Wed, 27 Mar 2002 08:27:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29187 for ; Wed, 27 Mar 2002 08:27:25 -0500 (EST) Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26941 for ; Wed, 27 Mar 2002 08:27:22 -0500 (EST) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 21:27:13 +0800 Message-ID: <9C4C56CDF89E0440A6BD571E76D2387F023E232A@exs23.ex.nus.edu.sg> From: Xiao Lei To: "'diffserv@ietf.org'" Date: Wed, 27 Mar 2002 21:27:12 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D593.1A4E4350" Subject: [Diffserv] Anyone can give me the list of all the maillist for differentiate d service? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@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_001_01C1D593.1A4E4350 Content-Type: text/plain Dear all: Anyone can give me the list of all the maillist for differentiated service? Thanks very much! Xiao Lei ------_=_NextPart_001_01C1D593.1A4E4350 Content-Type: text/html Message
Dear all:
    Anyone can give me the list of all the maillist for differentiated service?
Thanks very much!
 
Xiao Lei
------_=_NextPart_001_01C1D593.1A4E4350-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Mar 27 18:56:50 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 SAA00027 for ; Wed, 27 Mar 2002 18:56:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA26248 for diffserv-archive@odin.ietf.org; Wed, 27 Mar 2002 18:56:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25013; Wed, 27 Mar 2002 18:32:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24987 for ; Wed, 27 Mar 2002 18:32:10 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29497 for ; Wed, 27 Mar 2002 18:32:06 -0500 (EST) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn2-237.cisco.com [10.82.240.237]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA27533; Wed, 27 Mar 2002 15:31:35 -0800 (PST) Message-Id: <4.3.2.7.2.20020327164457.019cd2a8@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Mar 2002 18:26:34 -0500 To: "Walter Weiss" From: John Schnizlein Subject: Re: [Diffserv] Re: why i should like pibs Cc: , "DiffServ2" , In-Reply-To: <007601c1d510$48304300$650a0a0a@ne.client2.attbi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org It seems time again for me to summarize my concern about COPS-PR and PIBs. The intensity of feeling, apparent in the Plenary, that the ADs have done other than what we expect of them both motivates me to repeat what was ignored some time ago in Policy Framework interim meetings and makes me recall that the little boy who said what he saw in the Emperor's New Clothes" fared poorly. The fundamental problem with distributing policy to traffic-forwarding devices rather than translating policy into configurations under the constraints of the composition (topology) and capabilities of the devices in the path of the traffic remains. It is essentially wishful thinking that individual devices can determine the correct configuration of their local parameters without the domain-wide information. I have not been persuaded that the capability-exchange between the PEP and PDP solves this problem. There are hints of importance of the domain-wide context in DiffServ's per-domain behavior (PDB) specifications. It is even a mistake IMHO to invite network administrators to establish policies their networks cannot deliver. Although consensus was never reached on the architecture for policy networking, the insistence that policy be independent of the devices and topology that started there seems to persist under the surface of the COPS-PR development. My concerns about distributing un-interpreted policy appears to be shared by the network operators who shared their view with people soliciting "requirements for network configuration" when they say they do not want policy, or even configuration, distributed to devices until they know what it will do to the network. Response to particular points: At 04:50 PM 3/26/2002, Walter Weiss wrote: >... First of all, the pervasive perspective that there is only one >operations organization is very misleading. ... Therefore, drawing >conclusions about the value of COPS or PIBS to operators is premature. Good point. Standardizing without expected value is not the IETF way. >I would also like to consider this issue from a requirements perspective. In >my view, we can divide operational needs into four areas: Stats Collection, >Events, Static config and Dynamic config. This taxonomy of operational needs for network management is novel. Instead of the 5 FCAPS categories, it creates 4, with a new distinction in configuration that may or may not have value. It also seems that this Dynamic Config has a lot in common with what has been supported in RADIUS as user profiles. Why is this not better treated as a QoS case of authorization? >I would also like to reconsider Bert's points. First, I would agree that the >level of interest in COPS-PR is relatively small. However, I would argue >that this is because Dynamic Config is only starting to become important as >mappings for QoS, Security, and Tunneling are coming to the forefront. Maybe we should see if this new category of Dynamic Config really develops before standardizing it into existence. >Second, I disagree that there is overlap with PIBs. While the DiffServ PIB >and MIB are nearly identical, this was done because it was assumed that they >were both addressing the config space that CLI is so clearly dominating. In >the absense of a common model for all config, I believe this was a mistake. Don't follow this. You think any correspondence in the data models for the DiffServ application is a mistake without a "common model for all config"? Wouldn't incremental steps be more practical? >Given the unique applicability of COPS-PR, PIBs should be defined >specifically for this purpose and only this purpose. Which unique applicability of COPS-PR is this? The newly proposed Dynamic Config? >On Bert's third point, >I would argue that the investment in PIBs is far smaller than he suggests. >Given the specific scope of applicability, PIBs would not be appropriate for >most IETF activities involving failure events or static config (routing, >transport and applications). Hence, the number of PIBs is relatively small. >Further, I do not believe that any of the alternatives on the table can meet >these requirements to the extent that COPS-PR can. > >I would agree with Juergen that what we have today is a hodge-podge of >protocols and mechanisms for configuration management and little incentive >for changing the situation. As such, I see two alternatives: >1. We can use COPS-PR and restrict it specifically to the area that it >addresses most effectively: dynamic config management (at the network edge). >2. We can block progress on all config drafts/standards to motivate a >solution to Juergen's larger issue of concerted participation in a single >and uniform set of standards. No one has proposed to "block progress on all config drafts/standards" up until this point. Way back in the Configuration Management BOF in Washington, I thought Bert supported Experimental status as the best way to explore the new ideas proposed with COPS-PR and PIBs. >We could also block the advancement of COPS-PR. However, that prevents us >from addressing the dynamic config space and does not advance an >alternative. Bert's original suggestion of Experimental seems again the best way to encourage use of the new ideas in COPS-PR. I have never seen him (or Randy, for that matter) try to "block advancement". John _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Mar 28 04:13: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 EAA19493 for ; Thu, 28 Mar 2002 04:13:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02643 for diffserv-archive@odin.ietf.org; Thu, 28 Mar 2002 04:13:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01026; Thu, 28 Mar 2002 03:57:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23782 for ; Wed, 27 Mar 2002 11:49:43 -0500 (EST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07396; Wed, 27 Mar 2002 11:49:41 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g2RGngm25034; Wed, 27 Mar 2002 08:49:42 -0800 (PST) Message-Id: <200203271649.g2RGngm25034@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 27 Mar 2002 08:49:42 -0800 From: RFC Editor Subject: [Diffserv] Corrected: RFC 3246 on An Expedited Forwarding PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3246 Title: An Expedited Forwarding PHB (Per-Hop Behavior) Author(s): B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis Status: Standards Track Date: March 2002 Mailbox: bsd@cisco.com, acharny@cisco.com, jcrb@motorola.com, Kent.Benson@tellabs.com, jean-yves.leboudec@epfl.ch, bill.courtney@trw.com, shahram_davari@pmc-sierra.com, vfiroiu@nortelnetworks.com, stiliadi@bell-labs.com Pages: 16 Characters: 33896 Obsoletes: 2598 I-D Tag: draft-ietf-diffserv-rfc2598bis-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3246.txt This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. This document is a product of the Differentiated Services Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020327084727.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3246 --OtherAccess Content-Type: Message/External-body; name="rfc3246.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020327084727.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html