From owner-rap@ops.ietf.org Thu Mar 7 07:00:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18763 for ; Thu, 7 Mar 2002 07:00:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iwY0-000DWV-00 for rap-data@psg.com; Thu, 07 Mar 2002 03:59:00 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16iwXz-000DWH-00 for rap@ops.ietf.org; Thu, 07 Mar 2002 03:58:59 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18506; Thu, 7 Mar 2002 06:58:55 -0500 (EST) Message-Id: <200203071158.GAA18506@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-access-bind-01.txt Date: Thu, 07 Mar 2002 06:58:55 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework for Binding Access Control to COPS Provisioning Author(s) : W. Weiss et al. Filename : draft-ietf-rap-access-bind-01.txt Pages : 107 Date : 06-Mar-02 There is an ever-growing distinction between edge and core functionality. While the core continues to focus on stability and pure forwarding functionality, the edges increasingly need to deal with dynamic capabilities like QoS management, VPN encapsulations, encryption, dynamic steering and service monitoring. The dynamic deployment of these functions is dependent on specific contextual knowledge such as the physical location of the data stream and the identity of the client or system generating the data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-access-bind-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-access-bind-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-access-bind-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020306143920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-access-bind-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-access-bind-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020306143920.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Thu Mar 7 07:00:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18776 for ; Thu, 7 Mar 2002 07:00:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iwY9-000DXN-00 for rap-data@psg.com; Thu, 07 Mar 2002 03:59:09 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16iwY8-000DXH-00 for rap@ops.ietf.org; Thu, 07 Mar 2002 03:59:08 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18541; Thu, 7 Mar 2002 06:59:05 -0500 (EST) Message-Id: <200203071159.GAA18541@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-feedback-frwk-02.txt Date: Thu, 07 Mar 2002 06:59:04 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework of COPS-PR Policy Usage Feedback Author(s) : D. Rawlins, A. Kulkarni et al. Filename : draft-ietf-rap-feedback-frwk-02.txt Pages : 7 Date : 06-Mar-02 Common Open Policy Services Protocol [COPS], RFC 2748, defined the capability of reporting information to the PDP. The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-feedback-frwk-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-feedback-frwk-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020306143944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-feedback-frwk-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-feedback-frwk-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020306143944.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Thu Mar 7 07:00:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18788 for ; Thu, 7 Mar 2002 07:00:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iwY5-000DXA-00 for rap-data@psg.com; Thu, 07 Mar 2002 03:59:05 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16iwY4-000DWw-00 for rap@ops.ietf.org; Thu, 07 Mar 2002 03:59:04 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18519; Thu, 7 Mar 2002 06:59:00 -0500 (EST) Message-Id: <200203071159.GAA18519@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-feedback-fr-pib-02.txt Date: Thu, 07 Mar 2002 06:59:00 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework of COPS-PR Policy Information Base for Policy Usage Feedback Author(s) : D. Rawlins et al. Filename : draft-ietf-rap-feedback-fr-pib-02.txt Pages : 28 Date : 06-Mar-02 Currently there are no policy classes defined for the PEP to convey provisioned policy usage feedback to the PDP. The purpose of this document is to define the policy usage feedback framework PIB that specifies the policy classes common for COPS feedback reports. The basic operation and objects for reporting usage information are defined in [COPS]. A specific clientSI feedback object named REPORT is defined in [COPS-PR]. A framework for approaching solicited and periodic usage feedback is described in [COPS-FEED-FRWK]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-feedback-fr-pib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-feedback-fr-pib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020306143930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-feedback-fr-pib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-feedback-fr-pib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020306143930.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Thu Mar 7 14:27:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17066 for ; Thu, 7 Mar 2002 14:27:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16j3Xn-0001h7-00 for rap-data@psg.com; Thu, 07 Mar 2002 11:27:15 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16j3Xm-0001h1-00 for rap@ops.ietf.org; Thu, 07 Mar 2002 11:27:14 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16j3Xm-000I6F-00 for rap@ops.ietf.org; Thu, 07 Mar 2002 11:27:14 -0800 From: Randy Bush Message-ID: <3C87BD37.1C41EF99@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 07 Mar 2002 14:19:19 -0500 From: Kevin Dubray To: rap@ops.ietf.org, mpls@uu.net, nsis@ietf.org CC: Randy Bush , Bert Wijnen Subject: RSVP Benchmarking Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] In the Benchmarking WG, an I-D regarding benchmarking Resource Reservation is going through a WG Last Call: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-benchres-term-01.txt If you have interest, please review the draft. Comments to bmwg@ietf.org are appreciated. Thanks. From owner-rap@ops.ietf.org Fri Mar 8 07:02:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00416 for ; Fri, 8 Mar 2002 07:02:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16jJ2f-0000Kl-00 for rap-data@psg.com; Fri, 08 Mar 2002 04:00:09 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16jJ2e-0000Kf-00 for rap@ops.ietf.org; Fri, 08 Mar 2002 04:00:08 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00086; Fri, 8 Mar 2002 07:00:06 -0500 (EST) Message-Id: <200203081200.HAA00086@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-rsvppcc-pib-01.txt Date: Fri, 08 Mar 2002 07:00:05 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : RSVP Policy Control Criteria PIB Author(s) : D. Rawlins et al. Filename : draft-ietf-rap-rsvppcc-pib-01.txt Pages : 32 Date : 07-Mar-02 This draft describes the use of COPS-PR for support of a PDP provisioning a PEP with RSVP policy control criteria and defines a RSVP policy control criteria PIB for this purpose. The RSVPCC-PIB described in the document is provided for definition of policies that are currently defined by the outsourcing model [2749]. It is designed to be scalable and flexible as well as extensible for accommodating future policy criteria A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvppcc-pib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-rsvppcc-pib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-rsvppcc-pib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020307120909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvppcc-pib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-rsvppcc-pib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307120909.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Mon Mar 11 21:01:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02019 for ; Mon, 11 Mar 2002 21:01:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16kba1-000Oxq-00 for rap-data@psg.com; Mon, 11 Mar 2002 17:59:57 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.35 #1) id 16kba1-000Oxk-00 for rap@ops.ietf.org; Mon, 11 Mar 2002 17:59:57 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.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 BAA17322 for ; Tue, 12 Mar 2002 01:59:55 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031118031120131 ; Mon, 11 Mar 2002 18:03:11 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 17:59:55 -0800 Message-ID: <59885C5E3098D511AD690002A5072D3C040B2A93@orsmsx111.jf.intel.com> From: "Hahn, Scott" To: rap@ops.ietf.org Cc: "Bert Wijnen (Bert) (E-mail)" , "Mark L. Stevens (E-mail)" Subject: Agenda items for RAP meeting in Minneapolis? Date: Mon, 11 Mar 2002 17:59:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk All, Here is a proposed agenda for the MN meeting. RAP will be meeting on TUESDAY, March 19, 2002 from 15:45-16:45. RAP WG Agenda (Preliminary) --------------------------------------------- 0. Agenda Bashing 1. Draft Status: (10 minutes) 2. Usage Feedback: (20 minutes) draft-ietf-rap-feedback-frwk-02.txt draft-ietf-rap-feedback-fr-pib-02.txt 3. COPS Framework: (10 minutes) draft-ietf-rap-cops-frwk-01.txt 4. Access Bind: (20 minutes) draft-ietf-rap-access-bind-01.txt If you have any items that you would like to present, please let me know and we will see what we can do. Thanks, -Scott From owner-rap@ops.ietf.org Wed Mar 13 05:35:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01913 for ; Wed, 13 Mar 2002 05:35:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16l64O-00098j-00 for rap-data@psg.com; Wed, 13 Mar 2002 02:33:20 -0800 Received: from p-mail1.rd.francetelecom.com ([193.49.124.31]) by psg.com with smtp (Exim 3.35 #1) id 16l64L-00098G-00 for rap@ops.ietf.org; Wed, 13 Mar 2002 02:33:17 -0800 Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Wed, 13 Mar 2002 11:32:32 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8202C95D2C@lat3721.rd.francetelecom.fr> From: NOISETTE Yoann FTRD/DMI/CAE To: rap@ops.ietf.org Subject: RE: Questions on framework-pib07 Date: Wed, 13 Mar 2002 11:32:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-a4d1b354-360c-11d6-ac22-00508b692753" Sender: owner-rap@ops.ietf.org Precedence: bulk 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-a4d1b354-360c-11d6-ac22-00508b692753 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CA7A.69F09580" ------_=_NextPart_001_01C1CA7A.69F09580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, The frameworkpib-07 draft has been submitted on january 31st.=20 A while back I sent an email to the list asking some questions about = the management of Role-Combinations (this mail is included below). I haven't seen any response to these questions, neither have I seen any comments on the new draft. Though many interesting features and = corrections have been introduced through the last versions, I think some have to be clearer explained (leading me, for instance, to require clarifications = on the points tackled in my former email).=20 Thanks for your replies. Yoann -----Message d'origine----- De : NOISETTE Yoann FTRD/DMI/CAE [mailto:yoann.noisette@rd.francetelecom.com] Envoy=E9 : lundi 4 f=E9vrier 2002 14:07 =C0 : rap@ops.ietf.org Objet : Questions on framework-pib07 I have some questions about the management of Role-Combinations as = described in =A72.2 of the document "draft-ietf-rap-frameworkpib-07.txt".=20 >>>> At any later time, the PDP can update the Role-Combinations = assigned >>>> to a specific interface, identified by IfIndex, or for an = aggregate, >>>> identified by IfCapSetName, via an unsolicited decision to the PEP = >>>> on any open request handle. The PDP does this by sending updated=20 >>>> PRIs for the frwkIfRoleComboTable. =3D> I suppose this update is done by the PDP for a given Client-Type, = but I think it would be good to give this precision in the text. Moreover, = the fact that the PDP can proceed using "any open request handle" leads me = to ask/think : 1) this means to me that the update impacts all instances of PIB, as = "any one" can be chosen. Thus all instances of PIB have the same role combos defined for the interfaces (for a given CT). Is that right ? Isn't it possible to have different role combos for an interface in different instances of PIB attached to different Handle on a given Client-Type ? = To rely on an simple example : Suppose I have two instances of PIB which I activate at different = times, let's say, one for the days of work, one for the week-end. I could = decide to give the role "comptability" during the days of work and "none" during = the week end to a given interface which I don't want to be used "with "comptability" configuration during the week end. 2) should(n't) the PDP use the active handle to proceed ? is it implementation specific ? 3) SHOULD or MUST (or ...) the frwkPibIncarnationId be changed by the = PDP when updating the Role-Combinations ?? Following in =A72.2 : >>>> When the Interface Role Combination associations are updated by = the=20 >>>> PDP, the PEP SHOULD send updated =E6full state=C6 requests for all = open=20 >>>> contexts (request handles). =3D> this sentence reenforces the idea I exposed above in 1)...=20 Therefore, the PEP will modify the required role combinations in all = the instances of PIB attached to the different existing contexts (handles). Isn't it a bit contradictory with the settlement in =A72.4 " [COPS-PR] supports multiple, disjoint, independent instances of the PIB to = represent multiple instances of configured policy.". I see the same kind of contradiction with the PEP changing the attribute = frwkPibIncarnationActive when necessary (=A72.4), the contradiction coming on the word = "independent"... Let's look rapidly at the way to proceed : a) when the PEP receives a Role Combination update from the PDP, it = passes this update on all the contexts (request handles) for the considered Client-type. Then it sends a success report. b) sending updated full state request is only SHOULD, therefore, if we = admit the Roles-Combinations of the interfaces in the different PIB instances = are the same, I see two possible inconsistencies : * the update has been done on the PEP's side, but if no full-state request is sent afterwards, the PDP doesn't have the updated Role-combinations in its own instances (cf. =A72.2 "the PDP must have = the previous request state that it maintained for that request handle"). * if for only some contexts, the PEP has sent updated full-state request, then on the PDP's side, some context are updated, others are = not, leading to have two different sets of Role-combinations at the same = time on different contexts... which is contradictory to the hypothesis stated = in b) above... Please correct me if I'm wrong... If not, this means that the document contains two possible inconsistencies, which could be avoided, for = instance by simply having the PDP update the different contexts on its side once = it has received the success report from the PEP... Finally, some typos : * page 23 : fwrPibIncarnationFullState : "It does not have any meaning = when sent from the PDP to the PEP" (instead of PDP in the text) * page 23 : fwrPibIncarnationFullState : "see section 2.3 for = details..." (instead of section 3.3 in the text) Thanks for your replies. Yoann Noisette ------_=_NextPart_001_01C1CA7A.69F09580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Questions on framework-pib07

Hi all,

The frameworkpib-07 draft has been submitted on = january 31st.

A while back I sent an email to the list asking some = questions about the management of Role-Combinations (this mail is = included below).

I haven't seen any response to these questions, = neither have I seen any comments on the new draft. Though many = interesting features and corrections have been introduced through the = last versions, I think some have to be clearer explained (leading me, = for instance, to require clarifications on the points tackled in my = former email).

Thanks for your replies.

Yoann

-----Message d'origine-----
De : NOISETTE Yoann FTRD/DMI/CAE
[mailto:yoann.noisett= e@rd.francetelecom.com]
Envoy=E9 : lundi 4 f=E9vrier 2002 14:07
=C0 : rap@ops.ietf.org
Objet : Questions on framework-pib07



I have some questions about the management of = Role-Combinations as described
in =A72.2 of the document = "draft-ietf-rap-frameworkpib-07.txt".

>>>>    At any later time, = the PDP can update the Role-Combinations assigned

>>>>    to a specific = interface, identified by IfIndex, or for an aggregate,

>>>>    identified by = IfCapSetName, via an unsolicited decision to the PEP
>>>>    on any open = request handle. The PDP does this by sending updated
>>>>    PRIs for the = frwkIfRoleComboTable.

=3D> I suppose this update is done by the PDP for = a given Client-Type, but I
think it would be good to give this precision in the = text. Moreover, the
fact that the PDP can proceed using "any open = request handle" leads me to
ask/think :

1) this means to me that the update impacts all = instances of PIB, as "any
one" can be chosen. Thus all instances of PIB = have the same role combos
defined for the interfaces (for a given CT). Is that = right ? Isn't it
possible to have different role combos for an = interface in different
instances of PIB attached to different Handle on a = given Client-Type ? To
rely on an simple example :
Suppose I have two instances of PIB which I activate = at different times,
let's say, one for the days of work, one for the = week-end. I could decide to
give the role "comptability" during the = days of work and "none" during the
week end to a given interface which I don't want to = be used "with
"comptability" configuration during the = week end.

2) should(n't) the PDP use the active handle to = proceed  ? is it
implementation specific ?

3) SHOULD or MUST (or ...) the frwkPibIncarnationId = be changed by the PDP
when updating the Role-Combinations ??

Following in =A72.2 :
>>>>    When the = Interface Role Combination associations are updated by the
>>>>    PDP, the PEP = SHOULD send updated =E6full state=C6 requests for all open
>>>>    contexts (request = handles).

=3D> this sentence reenforces the idea I exposed = above in 1)...
Therefore, the PEP will modify the required role = combinations in all the
instances of PIB attached to the different existing = contexts (handles).
Isn't it a bit contradictory with the settlement in = =A72.4 " [COPS-PR]
supports multiple, disjoint, independent instances = of the PIB to represent
multiple instances of configured policy.". I = see the same kind of
contradiction with the PEP changing the attribute = frwkPibIncarnationActive
when necessary (=A72.4), the contradiction coming on = the word "independent"...

Let's look rapidly at the way to proceed :
a) when the PEP receives a Role Combination update = from the PDP, it passes
this update on all the contexts (request handles) = for the considered
Client-type. Then it sends a success report.
b) sending updated full state request is only = SHOULD, therefore, if we admit
the Roles-Combinations of the interfaces in the = different PIB instances are
the same, I see two possible inconsistencies = :
        * the = update has been done on the PEP's side, but if no full-state
request is sent afterwards, the PDP doesn't have the = updated
Role-combinations in its own instances (cf. =A72.2 = "the PDP must have the
previous request state that it maintained for that = request handle").
        * if for = only some contexts, the PEP has sent updated full-state
request, then on the PDP's side, some context are = updated, others  are not,
leading to have two different sets of = Role-combinations at the same time on
different contexts... which is contradictory to the = hypothesis stated in b)
above...

Please correct me if I'm wrong... If not, this means = that the document
contains two possible inconsistencies, which could = be avoided, for instance
by simply having the PDP update the different = contexts on its side once it
has received the success report from the = PEP...

Finally, some typos :

* page 23 : fwrPibIncarnationFullState : "It = does not have any meaning when
sent from the PDP to the PEP" (instead of PDP = in the text)
* page 23 : fwrPibIncarnationFullState : "see = section 2.3 for details..."
(instead of section 3.3 in the text)

Thanks for your replies.

Yoann Noisette

------_=_NextPart_001_01C1CA7A.69F09580-- ------=_NextPartTM-000-a4d1b354-360c-11d6-ac22-00508b692753-- From owner-rap@ops.ietf.org Wed Mar 13 12:02:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11246 for ; Wed, 13 Mar 2002 12:02:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lC88-000FIt-00 for rap-data@psg.com; Wed, 13 Mar 2002 09:01:36 -0800 Received: from fmfdns02.fm.intel.com ([132.233.247.11] helo=thalia.fm.intel.com) by psg.com with esmtp (Exim 3.35 #1) id 16lC88-000FIm-00 for rap@ops.ietf.org; Wed, 13 Mar 2002 09:01:36 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.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 RAA01622 for ; Wed, 13 Mar 2002 17:01:34 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031309045230344 ; Wed, 13 Mar 2002 09:04:52 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 09:01:34 -0800 Message-ID: <59885C5E3098D511AD690002A5072D3C040B2E24@orsmsx111.jf.intel.com> From: "Hahn, Scott" To: "Hahn, Scott" , agenda@ietf.org Cc: rap@ops.ietf.org, "Mark L. Stevens (E-mail)" , "Bert Wijnen (Bert) (E-mail)" Subject: Agenda items for RAP meeting in Minneapolis? Date: Wed, 13 Mar 2002 09:01:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk > Here is the agenda for the MN meeting. RAP will be meeting on > TUESDAY, March 19, 2002 from 15:45-16:45. > > RAP WG Agenda (Preliminary) > --------------------------------------------- > 0. Agenda Bashing > 1. Draft Status: (10 minutes) > > 2. Usage Feedback: (20 minutes) > draft-ietf-rap-feedback-frwk-02.txt > draft-ietf-rap-feedback-fr-pib-02.txt > > 3. COPS Framework: (10 minutes) > draft-ietf-rap-cops-frwk-01.txt > > 4. Access Bind: (20 minutes) > draft-ietf-rap-access-bind-01.txt > > **** If time permits **** > > 5. A brief presentation of our work on cops-sls > (http://www.ietf.org/internet-drafts/draft-nguyen-rap-cops-sls-02.txt). From owner-rap@ops.ietf.org Mon Mar 18 09:16:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05687 for ; Mon, 18 Mar 2002 09:16:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mxuI-00004Z-00 for rap-data@psg.com; Mon, 18 Mar 2002 06:14:38 -0800 Received: from roam.psg.com.ietf53.cw.net ([166.63.185.232] helo=roam.psg.com) by psg.com with esmtp (Exim 3.35 #1) id 16mxuI-00004R-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 06:14:38 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16mxuG-0002Q0-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 08:14:36 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Randy Bush To: rap@ops.ietf.org, diffserv@ietf.org Cc: ipsec-policy@vpnc.org Subject: why i should like pibs Date: Mon, 18 Mar 2002 08:13:26 -0600 Sender: owner-rap@ops.ietf.org Precedence: bulk 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 From owner-rap@ops.ietf.org Mon Mar 18 11:17:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08705 for ; Mon, 18 Mar 2002 11:17:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mzo1-0002a1-00 for rap-data@psg.com; Mon, 18 Mar 2002 08:16:17 -0800 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by psg.com with esmtp (Exim 3.35 #1) id 16mzo1-0002Zu-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 08:16:17 -0800 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 g2IGG6h11404 for ; Mon, 18 Mar 2002 16:16:06 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 g2IGF4S03130 for ; Mon, 18 Mar 2002 16:15:04 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 Subject: RE: why i should like pibs 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" Sender: owner-rap@ops.ietf.org Precedence: bulk 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 > > From owner-rap@ops.ietf.org Mon Mar 18 12:28:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12434 for ; Mon, 18 Mar 2002 12:28:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n0vf-00044y-00 for rap-data@psg.com; Mon, 18 Mar 2002 09:28:15 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.35 #1) id 16n0ve-00044k-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 09:28:14 -0800 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) Subject: Re: why i should like pibs References: <59885C5E3098D511AD690002A5072D3C0451B938@orsmsx111.jf.intel.com> Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> 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 From owner-rap@ops.ietf.org Mon Mar 18 14:17:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16161 for ; Mon, 18 Mar 2002 14:17:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n2cd-0005qJ-00 for rap-data@psg.com; Mon, 18 Mar 2002 11:16:43 -0800 Received: from roam.psg.com.ietf53.cw.net ([166.63.185.232] helo=roam.psg.com) by psg.com with esmtp (Exim 3.35 #1) id 16n2cd-0005qD-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 11:16:43 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16n2cb-0003Hb-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 13:16:41 -0600 Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <02031813325100.00987@callisto.jdscons.com> Content-Transfer-Encoding: 8bit From: Jon Saperia To: Randy Bush , rap@ops.ietf.org, diffserv@ietf.org Subject: Re: why i should like pibs Date: Mon, 18 Mar 2002 13:16:22 -0500 Cc: ipsec-policy@vpnc.org, snmpconf@snmpconf.com Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [ post by non-subscriber ] 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 From owner-rap@ops.ietf.org Mon Mar 18 14:49:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17411 for ; Mon, 18 Mar 2002 14:49:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n388-0006Nn-00 for rap-data@psg.com; Mon, 18 Mar 2002 11:49:16 -0800 Received: from hqmail01out.ellacoya.com ([64.223.136.41] helo=hqmail01.ellacoya.com) by psg.com with esmtp (Exim 3.35 #1) id 16n387-0006Nf-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 11:49:15 -0800 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 Subject: RE: why i should like pibs 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" Sender: owner-rap@ops.ietf.org Precedence: bulk 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 > > From owner-rap@ops.ietf.org Mon Mar 18 16:03:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20026 for ; Mon, 18 Mar 2002 16:03:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n4Hb-0007lq-00 for rap-data@psg.com; Mon, 18 Mar 2002 13:03:07 -0800 Received: from [204.92.244.243] (helo=kanatamail.kanata.unispherenetworks.ca) by psg.com with esmtp (Exim 3.35 #1) id 16n4Ha-0007li-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 13:03:06 -0800 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 Subject: RE: why i should like pibs 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" Sender: owner-rap@ops.ietf.org Precedence: bulk > 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. -- From owner-rap@ops.ietf.org Mon Mar 18 16:48:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21562 for ; Mon, 18 Mar 2002 16:48:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n4y8-0008ax-00 for rap-data@psg.com; Mon, 18 Mar 2002 13:47:04 -0800 Received: from roam.psg.com.ietf53.cw.net ([166.63.185.232] helo=roam.psg.com) by psg.com with esmtp (Exim 3.35 #1) id 16n4y7-0008ar-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 13:47:03 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16n4y7-0004he-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 15:47:03 -0600 Message-ID: <090528C807DBD511A78200508B68D7A8157FC5@orsmsx112.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Sender: owner-rap@ops.ietf.org Precedence: bulk [ post by non-subscriber ] 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 From owner-rap@ops.ietf.org Mon Mar 18 18:17:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24973 for ; Mon, 18 Mar 2002 18:17:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n6MX-000A8i-00 for rap-data@psg.com; Mon, 18 Mar 2002 15:16:21 -0800 Received: from roam.psg.com ([166.63.185.232]) by psg.com with esmtp (Exim 3.35 #1) id 16n6MW-000A8a-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 15:16:21 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16n6MV-0004x4-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 17:16:19 -0600 Message-Id: <3C967184.41C12D4C@hursley.ibm.com> Mime-Version: 1.0 References: <090528C807DBD511A78200508B68D7A8157FC5@orsmsx112.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 19 Mar 2002 00:00:20 +0100 From: Brian E Carpenter 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 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] 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 From owner-rap@ops.ietf.org Mon Mar 18 21:51:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00943 for ; Mon, 18 Mar 2002 21:51:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n9iT-000Dzs-00 for rap-data@psg.com; Mon, 18 Mar 2002 18:51:13 -0800 Received: from roam.psg.com ([166.63.190.213]) by psg.com with esmtp (Exim 3.35 #1) id 16n9iS-000Dzl-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 18:51:12 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16n9iS-00050a-00 for rap@ops.ietf.org; Mon, 18 Mar 2002 20:51:12 -0600 Message-ID: <090528C807DBD511A78200508B68D7A8157FD6@orsmsx112.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Sender: owner-rap@ops.ietf.org Precedence: bulk [ post by non-subscriber ] 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 From owner-rap@ops.ietf.org Tue Mar 19 04:13:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17967 for ; Tue, 19 Mar 2002 04:13:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nFfL-000LRk-00 for rap-data@psg.com; Tue, 19 Mar 2002 01:12:23 -0800 Received: from jffdns01.or.intel.com ([134.134.248.3] helo=ganymede.or.intel.com) by psg.com with esmtp (Exim 3.35 #1) id 16nFfK-000LRe-00 for rap@ops.ietf.org; Tue, 19 Mar 2002 01:12:23 -0800 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 JAA18332 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 Subject: RE: why i should like pibs 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 Sender: owner-rap@ops.ietf.org Precedence: bulk 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 From owner-rap@ops.ietf.org Tue Mar 19 05:40:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18913 for ; Tue, 19 Mar 2002 05:40:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nH2R-000N6n-00 for rap-data@psg.com; Tue, 19 Mar 2002 02:40:19 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.35 #1) id 16nH2Q-000N6h-00; Tue, 19 Mar 2002 02:40:18 -0800 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) Subject: Re: why i should like pibs References: <10C8636AE359D4119118009027AE99870DA5DEC2@FMSMSX34> Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> 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 From owner-rap@ops.ietf.org Tue Mar 19 08:50:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21754 for ; Tue, 19 Mar 2002 08:50:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nJyW-0008Vw-00 for rap-data@psg.com; Tue, 19 Mar 2002 05:48:28 -0800 Received: from roam.psg.com ([166.63.190.213]) by psg.com with esmtp (Exim 3.35 #1) id 16nJyV-0008Vq-00 for rap@ops.ietf.org; Tue, 19 Mar 2002 05:48:27 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16nJyU-0005Ev-00 for rap@ops.ietf.org; Tue, 19 Mar 2002 07:48:26 -0600 Content-Type: text/plain 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 From: Jon Saperia 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 Cc: "'Weiss, Walter'" , "'Randy Bush'" , rap@ops.ietf.org, diffserv@ietf.org, ipsec-policy@vpnc.org Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [ post by non-subscriber ] 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 From owner-rap@ops.ietf.org Tue Mar 19 09:15:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22273 for ; Tue, 19 Mar 2002 09:15:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nKNy-0008ro-00 for rap-data@psg.com; Tue, 19 Mar 2002 06:14:46 -0800 Received: from roam.psg.com ([166.63.190.213]) by psg.com with esmtp (Exim 3.35 #1) id 16nKNx-0008ri-00 for rap@ops.ietf.org; Tue, 19 Mar 2002 06:14:45 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16nKNw-0005Gv-00 for rap@ops.ietf.org; Tue, 19 Mar 2002 08:14:44 -0600 Message-Id: <3C974652.D23D7C46@hursley.ibm.com> Mime-Version: 1.0 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 Date: Tue, 19 Mar 2002 15:08:18 +0100 From: Brian E Carpenter 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 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] 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 From owner-rap@ops.ietf.org Tue Mar 19 12:14:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27765 for ; Tue, 19 Mar 2002 12:14:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nNAr-000BKC-00 for rap-data@psg.com; Tue, 19 Mar 2002 09:13:25 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.35 #1) id 16nNAr-000BK6-00 for rap@ops.ietf.org; Tue, 19 Mar 2002 09:13:25 -0800 Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GT800J01D4DE5@firewall.wcom.com> for rap@ops.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" Subject: RE: why i should like pibs 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)" Sender: owner-rap@ops.ietf.org Precedence: bulk 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)-- From owner-rap@ops.ietf.org Tue Mar 19 16:47:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05081 for ; Tue, 19 Mar 2002 16:47:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nRRX-000FT1-00 for rap-data@psg.com; Tue, 19 Mar 2002 13:46:55 -0800 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by psg.com with esmtp (Exim 3.35 #1) id 16nRRS-000FSv-00 for rap@ops.ietf.org; Tue, 19 Mar 2002 13:46:52 -0800 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 g2JLjZb01536 for ; Tue, 19 Mar 2002 21:45:35 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 g2JLjg906291 for ; Tue, 19 Mar 2002 21:45:42 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002031913501405268 ; Tue, 19 Mar 2002 13:50:14 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 13:46:49 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F048E76EA@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'NOISETTE Yoann FTRD/DMI/CAE'" Cc: "'rap@ops.ietf.org'" Subject: RE: Questions on framework-pib07 Date: Tue, 19 Mar 2002 13:46:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA05081 I've tried to provide some clarification, Comments prefixed by Ravi. Ravi -----Original Message----- From: NOISETTE Yoann FTRD/DMI/CAE [mailto:yoann.noisette@rd.francetelecom.com] Sent: Monday, February 04, 2002 5:07 AM To: rap@ops.ietf.org Subject: Questions on framework-pib07 I have some questions about the management of Role-Combinations as described in §2.2 of the document "draft-ietf-rap-frameworkpib-07.txt". >>>> At any later time, the PDP can update the Role-Combinations assigned >>>> to a specific interface, identified by IfIndex, or for an aggregate, >>>> identified by IfCapSetName, via an unsolicited decision to the PEP >>>> on any open request handle. The PDP does this by sending updated >>>> PRIs for the frwkIfRoleComboTable. => I suppose this update is done by the PDP for a given Client-Type, but I think it would be good to give this precision in the text. Ravi> I agree, I'll add that clarification. Moreover, the fact that the PDP can proceed using "any open request handle" leads me to ask/think : 1) this means to me that the update impacts all instances of PIB, as "any one" can be chosen. Thus all instances of PIB have the same role combos defined for the interfaces (for a given CT). Is that right ? Isn't it possible to have different role combos for an interface in different instances of PIB attached to different Handle on a given Client-Type ? To rely on an simple example : Suppose I have two instances of PIB which I activate at different times, let's say, one for the days of work, one for the week-end. I could decide to give the role "comptability" during the days of work and "none" during the week end to a given interface which I don't want to be used "with "comptability" configuration during the week end. Ravi>Yoann, the draft doesnt mandate that, Note that it says in the same §2.2 "If the PDP does not receive updated requests on some request handles, the PEP must not be sent decision updates for that frwkIfRoleCombo updates, i.e., the PDP must have the previous request state that it maintained for that request handle. "' This should be probably clarified a little bit to say: "If the PDP does not receive updated requests on some request handles, the PEP must not be sent decision updates for the frwkIfRoleCombo updates for those request handles, i.e., the PDP must have the previous request state that it maintained for that request handle. "' This allows implementations that want the behaviour you described, and makes the behaviour unambigious for PDP implementations that dont receive updated requests on all handles - is that helpful?. 2) should(n't) the PDP use the active handle to proceed ? is it implementation specific ? Ravi>The PDP will always use the active handle to proceed, does the draft say otherwise? 3) SHOULD or MUST (or ...) the frwkPibIncarnationId be changed by the PDP when updating the Role-Combinations ?? Ravi>Since the roles can, theoritically, also be updated by the PEP at a later time, we left the incarnation table to be an indication of the installed configuration ie the install tables. Following in §2.2 : >>>> When the Interface Role Combination associations are updated by the >>>> PDP, the PEP SHOULD send updated æfull stateÆ requests for all open >>>> contexts (request handles). => this sentence reenforces the idea I exposed above in 1)... Therefore, the PEP will modify the required role combinations in all the instances of PIB attached to the different existing contexts (handles). Isn't it a bit contradictory with the settlement in §2.4 " [COPS-PR] supports multiple, disjoint, independent instances of the PIB to represent multiple instances of configured policy.". I see the same kind of contradiction with the PEP changing the attribute frwkPibIncarnationActive when necessary (§2.4), the contradiction coming on the word "independent"... Ravi> Note that we used the word SHOULD and not MUST when we specified that the PEP should send updated full state requests for all open handles, we did this since we felt this makes PDP implementations less complex, but, yes like you pointed it - it may be required in some scenarios. Let's look rapidly at the way to proceed : a) when the PEP receives a Role Combination update from the PDP, it passes this update on all the contexts (request handles) for the considered Client-type. Then it sends a success report. b) sending updated full state request is only SHOULD, therefore, if we admit the Roles-Combinations of the interfaces in the different PIB instances are the same, I see two possible inconsistencies : * the update has been done on the PEP's side, but if no full-state request is sent afterwards, the PDP doesn't have the updated Role-combinations in its own instances (cf. §2.2 "the PDP must have the previous request state that it maintained for that request handle"). * if for only some contexts, the PEP has sent updated full-state request, then on the PDP's side, some context are updated, others are not, leading to have two different sets of Role-combinations at the same time on different contexts... which is contradictory to the hypothesis stated in b) above... Ravi>So, I hope the above clarifications resolve this - that if the PEP does not send updated requests on a subset of the handles, it must expect updates only on that subset; and the PDP must not expect updated requests on any handles other that the one it sent the decision on, and if it does get updated requests for other handles, it must honor them with a decision. Please correct me if I'm wrong... If not, this means that the document contains two possible inconsistencies, which could be avoided, for instance by simply having the PDP update the different contexts on its side once it has received the success report from the PEP... Finally, some typos : * page 23 : fwrPibIncarnationFullState : "It does not have any meaning when sent from the PDP to the PEP" (instead of PDP in the text) * page 23 : fwrPibIncarnationFullState : "see section 2.3 for details..." (instead of section 3.3 in the text) Ravi> Thanks for pointing these out, I'll address them in the IESG version. Ravi>Thanks for the thorough review.. Ravi Thanks for your replies. Yoann Noisette From owner-rap@ops.ietf.org Tue Mar 19 23:02:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13870 for ; Tue, 19 Mar 2002 23:02:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nXIX-000Kn7-00 for rap-data@psg.com; Tue, 19 Mar 2002 20:02:01 -0800 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by psg.com with esmtp (Exim 3.35 #1) id 16nXIX-000Kmz-00 for rap@ops.ietf.org; Tue, 19 Mar 2002 20:02:01 -0800 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 g2K44JQ14717 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" Subject: RE: why i should like pibs Date: Tue, 19 Mar 2002 23:01:57 -0500 Message-ID: Thread-Topic: why i should like pibs Thread-Index: AcHOh8rWfbkohePWSTOxuHnRyLcUewBOSbHA From: To: , , Cc: X-OriginalArrivalTime: 20 Mar 2002 04:01:58.0753 (UTC) FILETIME=[FB76E510:01C1CFC3] Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA13870 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 From owner-rap@ops.ietf.org Wed Mar 20 12:54:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07858 for ; Wed, 20 Mar 2002 12:54:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nkGK-00099A-00 for rap-data@psg.com; Wed, 20 Mar 2002 09:52:36 -0800 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by psg.com with esmtp (Exim 3.35 #1) id 16nkGJ-00098z-00 for rap@ops.ietf.org; Wed, 20 Mar 2002 09:52:35 -0800 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 g2KHqLM16498 for ; Wed, 20 Mar 2002 17:52:21 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 g2KHpPk28481 for ; Wed, 20 Mar 2002 17:51:25 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 Subject: RE: why i should like pibs 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 Sender: owner-rap@ops.ietf.org Precedence: bulk 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 ;-) From owner-rap@ops.ietf.org Wed Mar 20 14:15:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10709 for ; Wed, 20 Mar 2002 14:15:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nlYH-000Atz-00 for rap-data@psg.com; Wed, 20 Mar 2002 11:15:13 -0800 Received: from mailhost2.unispherenetworks.com ([65.194.140.138]) by psg.com with esmtp (Exim 3.35 #1) id 16nlYH-000Atq-00 for rap@ops.ietf.org; Wed, 20 Mar 2002 11:15:13 -0800 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 Subject: RE: why i should like pibs 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" Sender: owner-rap@ops.ietf.org Precedence: bulk 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. From owner-rap@ops.ietf.org Wed Mar 20 15:22:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13390 for ; Wed, 20 Mar 2002 15:22:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nmbP-000CQ2-00 for rap-data@psg.com; Wed, 20 Mar 2002 12:22:31 -0800 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.ca.nortel.com) by psg.com with esmtp (Exim 3.35 #1) id 16nmbP-000CPv-00; Wed, 20 Mar 2002 12:22:31 -0800 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 Subject: RE: why i should like pibs 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 Sender: owner-rap@ops.ietf.org Precedence: bulk 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. From owner-rap@ops.ietf.org Thu Mar 21 05:27:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08179 for ; Thu, 21 Mar 2002 05:27:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nzmZ-0005oq-00 for rap-data@psg.com; Thu, 21 Mar 2002 02:26:55 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.35 #1) id 16nzmY-0005oj-00; Thu, 21 Mar 2002 02:26:55 -0800 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) Subject: Re: why i should like pibs References: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> Sender: owner-rap@ops.ietf.org Precedence: bulk [ 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 From owner-rap@ops.ietf.org Thu Mar 21 05:29:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08238 for ; Thu, 21 Mar 2002 05:29:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nzpG-0005st-00 for rap-data@psg.com; Thu, 21 Mar 2002 02:29:42 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.35 #1) id 16nzpF-0005sn-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 02:29:41 -0800 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 g2LATX7V031463; Thu, 21 Mar 2002 11:29:33 +0100 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g2LATXX12182; Thu, 21 Mar 2002 11:29:33 +0100 Date: Thu, 21 Mar 2002 11:29:33 +0100 Message-Id: <200203211029.g2LATXX12182@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: rap@ops.ietf.org In-reply-to: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> (david.durham@intel.com) Subject: Re: why i should like pibs References: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> Sender: owner-rap@ops.ietf.org Precedence: bulk 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 From owner-rap@ops.ietf.org Thu Mar 21 05:31:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08271 for ; Thu, 21 Mar 2002 05:31:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nzqk-0005vJ-00 for rap-data@psg.com; Thu, 21 Mar 2002 02:31:14 -0800 Received: from p-mail2.rd.francetelecom.com ([193.49.124.32]) by psg.com with smtp (Exim 3.35 #1) id 16nzqg-0005vC-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 02:31:11 -0800 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Thu, 21 Mar 2002 11:24:15 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8202C95D60@lat3721.rd.francetelecom.fr> From: NOISETTE Yoann FTRD/DMI/CAE To: "'Sahita, Ravi'" Cc: "'rap@ops.ietf.org'" Subject: RE: Questions on framework-pib07 Date: Thu, 21 Mar 2002 11:24:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e8860f6c-3ca6-11d6-b1e9-00508b69ab48" Sender: owner-rap@ops.ietf.org Precedence: bulk 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-e8860f6c-3ca6-11d6-b1e9-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D0C2.964E9610" ------_=_NextPart_001_01C1D0C2.964E9610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ravi, thanks for the clarifications you gave to me on these questions... I = still however need some more ;-) 1- concerning the handle to be used by the PDP to update role combos, = you say "Ravi>The PDP will always use the active handle to proceed, does = the draft say otherwise?" No, the draft doesn't say otherwise, but it does say enough IMO. It = just says "on any open request handle"... Perhaps would it be clearer for = guys like me if the following was added: "The request handle used by the PDP = for the Role-Combinations update MUST be the active one when the PDP = proceeds". Though I agree now this is implicit, I think this would help = comprehension. 2- Ravi>This should be probably clarified a little bit to say: "If the PDP does not receive updated requests on some request = handles, the PEP must not be sent decision updates for the frwkIfRoleCombo updates for those request handles, i.e., the PDP must have the=20 previous request state that it maintained for that request handle. = "'=20 This allows implementations that want the behaviour you described, and makes the behaviour unambigious for PDP implementations that dont receive updated requests on all handles - is that helpful?. Yoann> So the Role Combos update is potentially applicable to all = Request handles. If the PEP doesn't send updated request on some handles the = PEP and the PDP keep the previous request state for these handles, OK. But if I quote another part of =A72.2 "If the role-combination updates were sent by the PDP, the=20 PEP SHOULD send these updated requests only if it can process the=20 unsolicited decision containing the frwkIfRoleCombo PRIs=20 successfully and it MUST do so after sending the success report for=20 the unsolicited decision. If the PEP failed to process the decision=20 (i.e., the frwkIfRoleCombo PRIs) it MUST only send a failure report=20 to the PDP." Yoann> What criteria are used by the PEP to choose to update one handle = and not another one (implementation specific ??) Wouldn't it be simpler if = the update decision was only applied on the active handle ? If after receiving the decision from the PDP, the PEP updates the Role Combos for another handle (another than the active one) and = doesn't send any updated request for this (as it is only SHOULD), how does the = PDP knows this particular handle has been updated ? I think if the PEP = updates another handle, the PEP MUST send an updated request. 3- Ravi>So, I hope the above clarifications resolve this - that if the = PEP does not send updated requests on a subset of the handles, it must=20 expect updates only on that subset (Yoann> sorry, I don't see your = point here...) ; and the PDP must not expect updated requests on any handles other = that the one it sent the decision on, and if it does get updated requests for = other handles, it must honor them with a decision. (Yoann> agree) Thanks for your feedback on these question. Sorry if I'm a bit slow in understanding points that are perhaps obvious... Yoann =09 -----Message d'origine----- De : Sahita, Ravi [mailto:ravi.sahita@intel.com] Envoy=E9 : mardi 19 mars 2002 22:47 =C0 : 'NOISETTE Yoann FTRD/DMI/CAE' Cc : 'rap@ops.ietf.org' Objet : RE: Questions on framework-pib07 I've tried to provide some clarification,=20 Comments prefixed by Ravi. Ravi -----Original Message----- From: NOISETTE Yoann FTRD/DMI/CAE [mailto:yoann.noisette@rd.francetelecom.com] Sent: Monday, February 04, 2002 5:07 AM To: rap@ops.ietf.org Subject: Questions on framework-pib07 I have some questions about the management of Role-Combinations as = described in =A72.2 of the document "draft-ietf-rap-frameworkpib-07.txt".=20 >>>> At any later time, the PDP can update the Role-Combinations = assigned >>>> to a specific interface, identified by IfIndex, or for an = aggregate, >>>> identified by IfCapSetName, via an unsolicited decision to the PEP = >>>> on any open request handle. The PDP does this by sending updated=20 >>>> PRIs for the frwkIfRoleComboTable. =3D> I suppose this update is done by the PDP for a given Client-Type, = but I think it would be good to give this precision in the text.=20 Ravi> I agree, I'll add that clarification. Moreover, the fact that the PDP can proceed using "any open request handle" leads me = to ask/think : 1) this means to me that the update impacts all instances of PIB, as = "any one" can be chosen. Thus all instances of PIB have the same role combos defined for the interfaces (for a given CT). Is that right ? Isn't it possible to have different role combos for an interface in different instances of PIB attached to different Handle on a given Client-Type ? = To rely on an simple example : Suppose I have two instances of PIB which I activate at different = times, let's say, one for the days of work, one for the week-end. I could = decide to give the role "comptability" during the days of work and "none" during = the week end to a given interface which I don't want to be used "with "comptability" configuration during the week end. Ravi>Yoann, the draft doesnt mandate that, Note that it says in the=20 same =A72.2 "If the PDP does not receive updated requests on some request = handles, the PEP must not be sent decision updates for that frwkIfRoleCombo=20 updates, i.e., the PDP must have the previous request state that it=20 maintained for that request handle. "' This should be probably clarified a little bit to say: "If the PDP does not receive updated requests on some request = handles, the PEP must not be sent decision updates for the frwkIfRoleCombo updates for those request handles, i.e., the PDP must have the=20 previous request state that it maintained for that request handle. = "'=20 This allows implementations that want the behaviour you described, and makes the behaviour unambigious for PDP implementations that dont = receive updated requests on all handles - is that helpful?. 2) should(n't) the PDP use the active handle to proceed ? is it implementation specific ? Ravi>The PDP will always use the active handle to proceed, does the draft say otherwise? 3) SHOULD or MUST (or ...) the frwkPibIncarnationId be changed by the = PDP when updating the Role-Combinations ?? Ravi>Since the roles can, theoritically, also be updated by the PEP at a later time, we left the incarnation table to be an indication of the installed configuration ie the install tables. Following in =A72.2 : >>>> When the Interface Role Combination associations are updated by = the=20 >>>> PDP, the PEP SHOULD send updated =E6full state=C6 requests for all = open=20 >>>> contexts (request handles). =3D> this sentence reenforces the idea I exposed above in 1)...=20 Therefore, the PEP will modify the required role combinations in all = the instances of PIB attached to the different existing contexts (handles). Isn't it a bit contradictory with the settlement in =A72.4 " [COPS-PR] supports multiple, disjoint, independent instances of the PIB to = represent multiple instances of configured policy.". I see the same kind of contradiction with the PEP changing the attribute = frwkPibIncarnationActive when necessary (=A72.4), the contradiction coming on the word = "independent"... Ravi> Note that we used the word SHOULD and not MUST when we specified that the PEP should send updated full state requests for all open = handles, we did this since we felt this makes PDP implementations less complex, = but, yes like you pointed it - it may be required in some scenarios. Let's look rapidly at the way to proceed : a) when the PEP receives a Role Combination update from the PDP, it = passes this update on all the contexts (request handles) for the considered Client-type. Then it sends a success report. b) sending updated full state request is only SHOULD, therefore, if we = admit the Roles-Combinations of the interfaces in the different PIB instances = are the same, I see two possible inconsistencies : * the update has been done on the PEP's side, but if no full-state request is sent afterwards, the PDP doesn't have the updated Role-combinations in its own instances (cf. =A72.2 "the PDP must have = the previous request state that it maintained for that request handle"). * if for only some contexts, the PEP has sent updated full-state request, then on the PDP's side, some context are updated, others are = not, leading to have two different sets of Role-combinations at the same = time on different contexts... which is contradictory to the hypothesis stated = in b) above... Ravi>So, I hope the above clarifications resolve this - that if the PEP does not send updated requests on a subset of the handles, it must=20 expect updates only on that subset; and the PDP must not expect=20 updated requests on any handles other that the one it sent the decision on, and if it does get updated requests for other handles, it must = honor them with a decision. Please correct me if I'm wrong... If not, this means that the document contains two possible inconsistencies, which could be avoided, for = instance by simply having the PDP update the different contexts on its side once = it has received the success report from the PEP... Finally, some typos : * page 23 : fwrPibIncarnationFullState : "It does not have any meaning = when sent from the PDP to the PEP" (instead of PDP in the text) * page 23 : fwrPibIncarnationFullState : "see section 2.3 for = details..." (instead of section 3.3 in the text) Ravi> Thanks for pointing these out, I'll address them in the IESG = version. Ravi>Thanks for the thorough review.. Ravi Thanks for your replies. Yoann Noisette ------_=_NextPart_001_01C1D0C2.964E9610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Questions on framework-pib07

Ravi,

thanks for the clarifications you gave to me on these = questions... I still however need some more ;-)

1- concerning the handle to be used by the PDP to = update role combos, you say "Ravi>The PDP will always use the = active handle to proceed, does the draft say = otherwise?"

No, the draft doesn't say otherwise, but it does say = enough IMO. It just says "on any open request handle"... = Perhaps would it be clearer for guys like me if the following was = added: "The request handle used by the PDP for the = Role-Combinations update MUST be the active one when the PDP = proceeds". Though I agree now this is implicit, I think this would = help comprehension.

2- Ravi>This should be probably clarified a little = bit to say:
  "If the PDP does not receive updated = requests on some request handles,
   the PEP must not be sent decision = updates for the frwkIfRoleCombo
   updates for those request handles, = i.e., the PDP must have the
   previous request state that it = maintained for that request handle. "'
        This = allows implementations that want the behaviour you described, = and
        makes the = behaviour unambigious for PDP implementations that dont receive
        updated = requests on all handles - is that helpful?.

Yoann> So the Role Combos update is potentially = applicable to all Request handles. If the PEP doesn't send updated = request on some handles the PEP and the PDP keep the previous request = state for these handles, OK. But if I quote another part of = =A72.2

"If the role-combination updates were sent by = the PDP, the
   PEP SHOULD send these updated requests = only if it can process the
   unsolicited decision containing the = frwkIfRoleCombo PRIs
   successfully and it MUST do so after = sending the success report for
   the unsolicited decision. If the PEP = failed to process the decision
   (i.e., the frwkIfRoleCombo PRIs) it = MUST only send a failure report
   to the PDP."

Yoann> What criteria are used by the PEP to choose = to update one handle and not another one (implementation specific ??) = Wouldn't it be simpler if the update decision was only applied on the = active handle ?

        If after = receiving the decision from the PDP, the PEP updates the Role Combos = for another handle (another than the active one) and doesn't send any = updated request for this (as it is only SHOULD), how does the PDP knows = this particular handle has been updated ? I think if the PEP updates = another handle, the PEP MUST send an updated request.

3- Ravi>So, I hope the above clarifications = resolve this - that if the PEP
does not send updated requests on a subset of the = handles, it must
expect updates only on that subset (Yoann> sorry, = I don't see your point here...)
; and the PDP must not expect updated requests on = any handles other that the one it sent the decision on, and if it does = get updated requests for other handles, it must honor

them with a decision. (Yoann> agree)

Thanks for your feedback on these question. Sorry if = I'm a bit slow in understanding points that are perhaps = obvious...

Yoann
       =20

-----Message d'origine-----
De : Sahita, Ravi [mailto:ravi.sahita@intel.com]<= /FONT>
Envoy=E9 : mardi 19 mars 2002 22:47
=C0 : 'NOISETTE Yoann FTRD/DMI/CAE'
Cc : 'rap@ops.ietf.org'
Objet : RE: Questions on framework-pib07



I've tried to provide some clarification,
Comments prefixed by Ravi.

Ravi

-----Original Message-----
From: NOISETTE Yoann FTRD/DMI/CAE
[mailto:yoann.noisett= e@rd.francetelecom.com]
Sent: Monday, February 04, 2002 5:07 AM
To: rap@ops.ietf.org
Subject: Questions on framework-pib07



I have some questions about the management of = Role-Combinations as described
in =A72.2 of the document = "draft-ietf-rap-frameworkpib-07.txt".

>>>>    At any later time, = the PDP can update the Role-Combinations assigned
>>>>    to a specific = interface, identified by IfIndex, or for an aggregate,
>>>>    identified by = IfCapSetName, via an unsolicited decision to the PEP
>>>>    on any open = request handle. The PDP does this by sending updated
>>>>    PRIs for the = frwkIfRoleComboTable.

=3D> I suppose this update is done by the PDP for = a given Client-Type, but I
think it would be good to give this precision in the = text.

Ravi> I agree, I'll add that clarification.

Moreover, the
fact that the PDP can proceed using "any open = request handle" leads me to
ask/think :

1) this means to me that the update impacts all = instances of PIB, as "any
one" can be chosen. Thus all instances of PIB = have the same role combos
defined for the interfaces (for a given CT). Is that = right ? Isn't it
possible to have different role combos for an = interface in different
instances of PIB attached to different Handle on a = given Client-Type ? To
rely on an simple example :
Suppose I have two instances of PIB which I activate = at different times,
let's say, one for the days of work, one for the = week-end. I could decide to
give the role "comptability" during the = days of work and "none" during the
week end to a given interface which I don't want to = be used "with
"comptability" configuration during the = week end.

Ravi>Yoann, the draft doesnt mandate that, Note = that it says in the
same =A72.2
  "If the PDP does not receive updated = requests on some request handles,
   the PEP must not be sent decision = updates for that frwkIfRoleCombo
   updates, i.e., the PDP must have the = previous request state that it
   maintained for that request handle. = "'
This should be probably clarified a little bit to = say:
  "If the PDP does not receive updated = requests on some request handles,
   the PEP must not be sent decision = updates for the frwkIfRoleCombo
   updates for those request handles, = i.e., the PDP must have the
   previous request state that it = maintained for that request handle. "'
This allows implementations that want the behaviour = you described, and
makes the behaviour unambigious for PDP = implementations that dont receive
updated requests on all handles - is that = helpful?.


2) should(n't) the PDP use the active handle to = proceed  ? is it
implementation specific ?

Ravi>The PDP will always use the active handle to = proceed, does
the draft say otherwise?


3) SHOULD or MUST (or ...) the frwkPibIncarnationId = be changed by the PDP
when updating the Role-Combinations ??

Ravi>Since the roles can, theoritically, also be = updated by the PEP
at a later time, we left the incarnation table to be = an indication
of the installed configuration ie the install = tables.


Following in =A72.2 :
>>>>    When the = Interface Role Combination associations are updated by the
>>>>    PDP, the PEP = SHOULD send updated =E6full state=C6 requests for all open
>>>>    contexts (request = handles).

=3D> this sentence reenforces the idea I exposed = above in 1)...
Therefore, the PEP will modify the required role = combinations in all the
instances of PIB attached to the different existing = contexts (handles).
Isn't it a bit contradictory with the settlement in = =A72.4 " [COPS-PR]
supports multiple, disjoint, independent instances = of the PIB to represent
multiple instances of configured policy.". I = see the same kind of
contradiction with the PEP changing the attribute = frwkPibIncarnationActive
when necessary (=A72.4), the contradiction coming on = the word "independent"...

Ravi> Note that we used the word SHOULD and not = MUST when we specified
that the PEP should send updated full state requests = for all open handles,
we did this since we felt this makes PDP = implementations less complex, but,
yes like you pointed it - it may be required in some = scenarios.


Let's look rapidly at the way to proceed :
a) when the PEP receives a Role Combination update = from the PDP, it passes
this update on all the contexts (request handles) = for the considered
Client-type. Then it sends a success report.
b) sending updated full state request is only = SHOULD, therefore, if we admit
the Roles-Combinations of the interfaces in the = different PIB instances are
the same, I see two possible inconsistencies = :
        * the = update has been done on the PEP's side, but if no full-state
request is sent afterwards, the PDP doesn't have the = updated
Role-combinations in its own instances (cf. =A72.2 = "the PDP must have the
previous request state that it maintained for that = request handle").
        * if for = only some contexts, the PEP has sent updated full-state
request, then on the PDP's side, some context are = updated, others  are not,
leading to have two different sets of = Role-combinations at the same time on
different contexts... which is contradictory to the = hypothesis stated in b)
above...

Ravi>So, I hope the above clarifications resolve = this - that if the PEP
does not send updated requests on a subset of the = handles, it must
expect updates only on that subset; and the PDP must = not expect
updated requests on any handles other that the one = it sent the decision
on, and if it does get updated requests for other = handles, it must honor
them with a decision.


Please correct me if I'm wrong... If not, this means = that the document
contains two possible inconsistencies, which could = be avoided, for instance
by simply having the PDP update the different = contexts on its side once it
has received the success report from the = PEP...

Finally, some typos :

* page 23 : fwrPibIncarnationFullState : "It = does not have any meaning when
sent from the PDP to the PEP" (instead of PDP = in the text)
* page 23 : fwrPibIncarnationFullState : "see = section 2.3 for details..."
(instead of section 3.3 in the text)

Ravi> Thanks for pointing these out, I'll address = them in the IESG version.

Ravi>Thanks for the thorough review..
Ravi

Thanks for your replies.

Yoann Noisette

------_=_NextPart_001_01C1D0C2.964E9610-- ------=_NextPartTM-000-e8860f6c-3ca6-11d6-b1e9-00508b69ab48-- From owner-rap@ops.ietf.org Thu Mar 21 11:46:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16734 for ; Thu, 21 Mar 2002 11:46:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o5gl-000GqA-00 for rap-data@psg.com; Thu, 21 Mar 2002 08:45:19 -0800 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 3.35 #1) id 16o5gk-000Gq3-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 08:45:18 -0800 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2LGj0205885; Thu, 21 Mar 2002 11:45:01 -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 HLCVLWLP; Thu, 21 Mar 2002 11:45:00 -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 HB94TTK2; Thu, 21 Mar 2002 11:44:58 -0500 Message-Id: <5.0.0.25.0.20020321113605.0203f010@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:43:26 -0500 To: Juergen Schoenwaelder From: Kwok Ho Chan Subject: Re: why i should like pibs Cc: david.durham@intel.com, rap@ops.ietf.org In-Reply-To: <200203211029.g2LATXX12182@haerke.ibr.cs.tu-bs.de> References: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rap@ops.ietf.org Precedence: bulk Juergen: Thank you very much for the list. The Connection Orient + State-full-ness between the PEP and Server may be an important feature of COPS-PR+PIBs. It allows the Server/PDP to allocate resources for specific services with clear delegation of responsibility. Hope you see the combination of features as an advantage also. -- Kwok -- At 11:29 AM 3/21/02 +0100, Juergen Schoenwaelder wrote: >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 From owner-rap@ops.ietf.org Thu Mar 21 11:48:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16846 for ; Thu, 21 Mar 2002 11:48:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o5jI-000GxI-00 for rap-data@psg.com; Thu, 21 Mar 2002 08:47:56 -0800 Received: from p-mail2.rd.francetelecom.com ([193.49.124.32]) by psg.com with smtp (Exim 3.35 #1) id 16o5jG-000Gx1-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 08:47:54 -0800 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Thu, 21 Mar 2002 17:47:29 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8202C95D67@lat3721.rd.francetelecom.fr> From: NOISETTE Yoann FTRD/DMI/CAE To: rap@ops.ietf.org Subject: Interface and equipment dedicated policy Date: Thu, 21 Mar 2002 17:47:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e8862896-3ca6-11d6-b1e9-00508b69ab48" Sender: owner-rap@ops.ietf.org Precedence: bulk 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-e8862896-3ca6-11d6-b1e9-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D0F8.20ED1640" ------_=_NextPart_001_01C1D0F8.20ED1640 Content-Type: text/plain; charset="iso-8859-1" Hi all, We are actually using COPS-PR to dynamically provision IPSec tunnels, based on the framework PIB and the IPSec PIB drafts. To proceed, we need for some part of the configuration to address policies to one particular interface only. According to draft-framworkpib-07, this is possible : "We point out that, in the event that the administrator needs to have unique policy for each interface, this can be achieved by configuring each interface with a unique role." I'm not medium, but I believe that the deployment of services thanks to COPS-PR may require to be able to address each interface in some circumstances. Therefore, my question is: should this be taken into account in the definition of roles ? For instance, adding systematically the corresponding Ifindex to the role combination of an interface could be a means to proceed, and this would not heavily impact the use of roles. For instance, roles wouldn't lose the level of indirection their provide. In this context, suppose we have three interfaces: Roles A, B, R1 and Ifindex1 are assigned to interface I1 Roles A, B, R2 and Ifindex2 are assigned to interface I2 Roles A, B, R2 and Ifindex3 are assigned to interface I3 A policy applied to "*+Ifindex1" will only apply to I1 A policy applied to "*+A+B+R2" will only apply to I2 and I3 A policy applied to "*+A+B" will apply to I1, I2 and I3 Furthemore, some services may in the future require to push policy intended for the equipment, and not a given (subset of) interface(s). For instance, when using AAA, the Radius server could be provided that way, and so could be a CA/PKI server for other purposes...etc. Should this also be taken into account by the framework PIB, by for instance, defining a special pseudo-interface, with a specific unique role, that would in fact represent the device and would be used by the different client-types to configure features on the device itself, independantly of the interfaces, when they need it ?? Thanks for your reactions. Yoann ------_=_NextPart_001_01C1D0F8.20ED1640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interface and equipment dedicated policy

    Hi all,

    We are actually using COPS-PR to = dynamically provision IPSec tunnels, based on the framework PIB and the = IPSec PIB drafts. To proceed, we need for some part of the = configuration to address policies to one particular interface only. = According to draft-framworkpib-07, this is possible :

    "We point out that, in the event = that the administrator needs to have
       unique policy for each = interface, this can be achieved by
       configuring each = interface with a unique role."

    I'm not medium, but I believe that the = deployment of services thanks to COPS-PR may require to be able to = address each interface in some circumstances. Therefore, my question = is:  should this be taken into account in the definition of roles = ? For instance, adding systematically the corresponding Ifindex to the = role combination of an interface could be a means to proceed, and this = would not heavily impact the use of roles. For instance, roles wouldn't = lose the level of indirection their provide.

    In this context, suppose we have three = interfaces:
       
            = Roles A, B, R1 and Ifindex1 are assigned to interface I1
            = Roles A, B, R2 and Ifindex2 are assigned to interface I2
            Roles A, B, R2 and Ifindex3 are assigned to interface = I3

    A policy applied to = "*+Ifindex1" will only apply to I1
    A policy applied to = "*+A+B+R2" will only apply to I2 and I3
    A policy applied to "*+A+B" = will apply to I1, I2 and I3

    Furthemore, some services may in the = future require to push policy intended for the equipment, and not a = given (subset of) interface(s). For instance, when using AAA, the = Radius server could be provided that way, and so could be a CA/PKI = server for other purposes...etc.

    Should this also be taken into account = by the framework PIB, by for instance, defining a special = pseudo-interface, with a specific unique role, that would in fact = represent the device and would be used by the different client-types to = configure features on the device itself, independantly of the = interfaces, when they need it  ??

Thanks for your reactions.

Yoann

------_=_NextPart_001_01C1D0F8.20ED1640-- ------=_NextPartTM-000-e8862896-3ca6-11d6-b1e9-00508b69ab48-- From owner-rap@ops.ietf.org Thu Mar 21 11:56:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17271 for ; Thu, 21 Mar 2002 11:56:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o5rb-000HGD-00 for rap-data@psg.com; Thu, 21 Mar 2002 08:56:31 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.35 #1) id 16o5rZ-000HFU-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 08:56:30 -0800 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 g2LGuMSU026255; Thu, 21 Mar 2002 17:56:22 +0100 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g2LGuLH17129; Thu, 21 Mar 2002 17:56:21 +0100 Date: Thu, 21 Mar 2002 17:56:21 +0100 Message-Id: <200203211656.g2LGuLH17129@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: khchan@NortelNetworks.com CC: rap@ops.ietf.org In-reply-to: <5.0.0.25.0.20020321113605.0203f010@zbl6c002.corpeast.baynetworks.com> (message from Kwok Ho Chan on Thu, 21 Mar 2002 11:43:26 -0500) Subject: Re: why i should like pibs References: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> <5.0.0.25.0.20020321113605.0203f010@zbl6c002.corpeast.baynetworks.com> Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Kwok Ho Chan writes: Kwok> Juergen: Thank you very much for the list. The Connection Kwok> Orient + State-full-ness between the PEP and Server may be an Kwok> important feature of COPS-PR+PIBs. It allows the Server/PDP to Kwok> allocate resources for specific services with clear delegation Kwok> of responsibility. Hope you see the combination of features as Kwok> an advantage also. -- Kwok -- The feature is "shared state". COPS-PR uses TCP and keep-alives to _implement_ that feature. I agree that TCP simplifies the realization of shared state from an implementation point of view - perhaps this is what you were saying... /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Thu Mar 21 11:59:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17389 for ; Thu, 21 Mar 2002 11:59:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o5uE-000HK1-00 for rap-data@psg.com; Thu, 21 Mar 2002 08:59:14 -0800 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 3.35 #1) id 16o5uD-000HJv-00; Thu, 21 Mar 2002 08:59:14 -0800 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 Subject: Re: why i should like pibs 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 Sender: owner-rap@ops.ietf.org Precedence: bulk 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 From owner-rap@ops.ietf.org Thu Mar 21 12:07:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17804 for ; Thu, 21 Mar 2002 12:07:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o623-000HbS-00 for rap-data@psg.com; Thu, 21 Mar 2002 09:07:19 -0800 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by psg.com with esmtp (Exim 3.35 #1) id 16o61s-000HbI-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 09:07:18 -0800 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 g2LH5eW10873 for ; Thu, 21 Mar 2002 17:05:40 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 g2LH3aL26004 for ; Thu, 21 Mar 2002 17:03:36 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 Subject: RE: why i should like pibs 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" Sender: owner-rap@ops.ietf.org Precedence: bulk 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 From owner-rap@ops.ietf.org Thu Mar 21 12:19:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18294 for ; Thu, 21 Mar 2002 12:19:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o6Di-000HwF-00 for rap-data@psg.com; Thu, 21 Mar 2002 09:19:22 -0800 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by psg.com with esmtp (Exim 3.35 #1) id 16o6Di-000Hw9-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 09:19:22 -0800 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 g2LHI5v17774 for ; Thu, 21 Mar 2002 17:18:05 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 g2LHIB813509 for ; Thu, 21 Mar 2002 17:18:11 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 Subject: why i should like pibs 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" Sender: owner-rap@ops.ietf.org Precedence: bulk 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 From owner-rap@ops.ietf.org Thu Mar 21 12:31:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18758 for ; Thu, 21 Mar 2002 12:31:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o6PQ-000IJV-00 for rap-data@psg.com; Thu, 21 Mar 2002 09:31:28 -0800 Received: from roam.psg.com ([166.63.190.213]) by psg.com with esmtp (Exim 3.35 #1) id 16o6PP-000IJP-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 09:31:27 -0800 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 Subject: Re: why i should like pibs References: <5.0.0.25.0.20020321114636.025e83f0@zbl6c002.corpeast.baynetworks.com> Message-Id: Date: Thu, 21 Mar 2002 11:31:22 -0600 Sender: owner-rap@ops.ietf.org Precedence: bulk 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 From owner-rap@ops.ietf.org Thu Mar 21 16:16:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25807 for ; Thu, 21 Mar 2002 16:16:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o9ry-0001BU-00 for rap-data@psg.com; Thu, 21 Mar 2002 13:13:10 -0800 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.35 #1) id 16o9ry-0001BL-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 13:13:10 -0800 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 g2LLD4113330 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 Subject: RE: why i should like pibs 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" Sender: owner-rap@ops.ietf.org Precedence: bulk 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 From owner-rap@ops.ietf.org Thu Mar 21 17:20:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27399 for ; Thu, 21 Mar 2002 17:20:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oAuv-0005Vw-00 for rap-data@psg.com; Thu, 21 Mar 2002 14:20:17 -0800 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by psg.com with esmtp (Exim 3.35 #1) id 16oAuu-0005Vo-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 14:20:16 -0800 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 g2LMK1p09277 for ; Thu, 21 Mar 2002 22:20:01 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) 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 g2LMJ6C26959 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 Subject: RE: why i should like pibs 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 Sender: owner-rap@ops.ietf.org Precedence: bulk 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 From owner-rap@ops.ietf.org Thu Mar 21 17:58:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28697 for ; Thu, 21 Mar 2002 17:58:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oBVJ-00082L-00 for rap-data@psg.com; Thu, 21 Mar 2002 14:57:53 -0800 Received: from mailhost2.unispherenetworks.com ([65.194.140.138]) by psg.com with esmtp (Exim 3.35 #1) id 16oBVJ-00082B-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 14:57:53 -0800 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 Subject: RE: why i should like pibs --- AAARRRGH - ENOUGH! ;-) 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" Sender: owner-rap@ops.ietf.org Precedence: bulk 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. From owner-rap@ops.ietf.org Thu Mar 21 20:48:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02568 for ; Thu, 21 Mar 2002 20:48:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oEA1-000KIK-00 for rap-data@psg.com; Thu, 21 Mar 2002 17:48:05 -0800 Received: from roam.psg.com ([166.63.185.23]) by psg.com with esmtp (Exim 3.35 #1) id 16oEA1-000KI8-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 17:48:05 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16oE9z-0000s7-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 19:48:03 -0600 Message-Id: <3C9A697D.E7C80228@hursley.ibm.com> Mime-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 22 Mar 2002 00:15:09 +0100 From: Brian E Carpenter 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 Sender: owner-rap@ops.ietf.org Precedence: bulk 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 From owner-rap@ops.ietf.org Fri Mar 22 00:37:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09618 for ; Fri, 22 Mar 2002 00:37:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oHis-000B6S-00 for rap-data@psg.com; Thu, 21 Mar 2002 21:36:18 -0800 Received: from samar.sasken.com ([164.164.56.2]) by psg.com with esmtp (Exim 3.35 #1) id 16oHiq-000B6E-00 for rap@ops.ietf.org; Thu, 21 Mar 2002 21:36:17 -0800 Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g2M5aDK24258; Fri, 22 Mar 2002 11:06:13 +0530 (IST) Received: from localhost (manojs@localhost) by pcz-manojs.sasken.com (8.9.3/8.9.3) with ESMTP id LAA04799; Fri, 22 Mar 2002 11:06:12 +0530 Date: Fri, 22 Mar 2002 11:06:12 +0530 (IST) From: Manoj Sontakke X-Sender: manojs@pcz-manojs.sasken.com To: ravi.sahita@intel.com, shriharsha.hegde@intel.com cc: rap@ops.ietf.org Subject: MPLS setup pib Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rap@ops.ietf.org Precedence: bulk Hi Harsha / Ravi We are implementing some of the PIBs. I don't see any discussion on MPLS setup PIB. Is it because is is not part of any working group ? Or the discussions are happening on some other mailing list ? Manoj From owner-rap@ops.ietf.org Fri Mar 22 09:36:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22557 for ; Fri, 22 Mar 2002 09:36:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oMCN-0002JC-00 for rap-data@psg.com; Fri, 22 Mar 2002 02:23:03 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.35 #1) id 16oMCM-0002J5-00 for rap@ops.ietf.org; Fri, 22 Mar 2002 02:23:02 -0800 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 g2MAMrnR021021; Fri, 22 Mar 2002 11:22:53 +0100 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g2MAMrC28085; Fri, 22 Mar 2002 11:22:53 +0100 Date: Fri, 22 Mar 2002 11:22:53 +0100 Message-Id: <200203221022.g2MAMrC28085@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: ravi.sahita@intel.com CC: rap@ops.ietf.org In-reply-to: <65D5A07B5098D511BDDA0002A508E64F048E76F9@orsmsx110.jf.intel.com> (ravi.sahita@intel.com) Subject: Re: why i should like pibs References: <65D5A07B5098D511BDDA0002A508E64F048E76F9@orsmsx110.jf.intel.com> Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Sahita, Ravi writes: Ravi> I've added some items in addition to what you've enumerated. Ravi> Some of these are direct effects of the PIB data model, and some Ravi> of them because of usage of the data model with COPS-PR. [...] Ravi> These I think are in addition to what you and Dave have Ravi> mentioned. I think this is all covered under item (c). I personally have no interest to into the details at this point in time. Dave and I already agree that we disagree about how much improvement the SPPI brings us. /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Fri Mar 22 09:36:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22583 for ; Fri, 22 Mar 2002 09:36:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oLKj-000Pe5-00 for rap-data@psg.com; Fri, 22 Mar 2002 01:27:37 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.35 #1) id 16oLKi-000Pdy-00 for rap@ops.ietf.org; Fri, 22 Mar 2002 01:27:37 -0800 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 g2M9RYLX018678; Fri, 22 Mar 2002 10:27:34 +0100 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g2M9RYU27399; Fri, 22 Mar 2002 10:27:34 +0100 Date: Fri, 22 Mar 2002 10:27:34 +0100 Message-Id: <200203220927.g2M9RYU27399@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: rap@ops.ietf.org In-reply-to: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> (david.durham@intel.com) Subject: Re: why i should like pibs References: <10C8636AE359D4119118009027AE99870DA5DEC4@FMSMSX34> Sender: owner-rap@ops.ietf.org Precedence: bulk [Since people want to have something in the records for our historians...] >>>>> Durham, David writes: >> 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> [Dave] By the time you integrate all the COPS-PR features and Dave> advancements into SNMP, you still get COPS-PR, just 5 years too Dave> late. But, perhaps the best reason of all for COPS-PR and PIBs Dave> is that you don't have the "SNMP community process" that you Dave> just described. This touches the real issue: The work in the IETF network management area is way too much controlled by vendors rather than the users who need to operate networks. Example: Almost every SNMP user I know of who had to retrieve large tables knows very well that the overall speed sucks (and I am not referring here to those implementations that suffer from specific problems in their instrumentation). The IETF and the rules of the standards process have been used by the SNMP community continously to block forward process in order to satisfy some vendor interests, ignoring the real user interests. Because this problem persisted a long time, we finally got COPS-PR which tries to address some user interests but which is also driven to a large part by vendor interests - it is just another camp of vendors. And now these vendor gangs use the IETF and the rules of the standards process to fight against each other, certainly not the users interest. I have heard from operators that they really have no interest in getting a new protocol every time the IETF fails to resolve deadlock situations or has battles between vendors. For the people running networks, every new management standard just adds to the technology nirvana and makes things worse and more expensive. A future where we have MIBs/SNMP for monitoring, PIBs/COPS-PR for "dynamic" configuration, CLIs (standard and non-standard) for "static" configuration, Radius/Diameter for service installation / activation / termination, policies and LDAP for automated reconfiguration, ... is really a poor end result if you look at it from the perspective of someone who has to operate networks in cost effective ways. Sure, a some set of vendors (especially toolkit providers) make money with all these competing technologies while all the other vendors pay a price to support multiple technologies. And the users who operate networks are the real loosers since they only have the option to either deal with all of this stuff or to bind themself to just one or two vendors. This is my understanding of the current situation. Sure, I am simplifying quite a bit and I am putting some things to an extreme. But I certainly believe that in order to do something good for the Internet and the people who actually keep the Internet running, the IETF should find ways to give actual users a more effective direct feedback channel into the standards process. /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Fri Mar 22 12:28:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26638 for ; Fri, 22 Mar 2002 12:28:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oSnt-0005EH-00 for rap-data@psg.com; Fri, 22 Mar 2002 09:26:13 -0800 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by psg.com with esmtp (Exim 3.35 #1) id 16oSns-0005EB-00 for rap@ops.ietf.org; Fri, 22 Mar 2002 09:26:13 -0800 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 g2MHPve07064 for ; Fri, 22 Mar 2002 17:25:57 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 g2MHP2l17796 for ; Fri, 22 Mar 2002 17:25:02 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002032209253628670 ; Fri, 22 Mar 2002 09:25:36 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 09:26:10 -0800 Message-ID: <59885C5E3098D511AD690002A5072D3C0325E88B@orsmsx111.jf.intel.com> From: "Hegde, Shriharsha" To: "'Manoj Sontakke'" Cc: rap@ops.ietf.org Subject: RE: MPLS setup pib Date: Fri, 22 Mar 2002 09:26:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Yes Manoj: Once everyone -I mean everyone- has enough reasons to like the PIBs we will submit an updated PIB at a relevant WG. thanks, harsha -----Original Message----- From: Manoj Sontakke [mailto:manojs@sasken.com] Sent: Thursday, March 21, 2002 9:36 PM To: ravi.sahita@intel.com; shriharsha.hegde@intel.com Cc: rap@ops.ietf.org Subject: MPLS setup pib Hi Harsha / Ravi We are implementing some of the PIBs. I don't see any discussion on MPLS setup PIB. Is it because is is not part of any working group ? Or the discussions are happening on some other mailing list ? Manoj From owner-rap@ops.ietf.org Mon Mar 25 07:19:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07455 for ; Mon, 25 Mar 2002 07:19:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pTOC-000D0p-00 for rap-data@psg.com; Mon, 25 Mar 2002 04:15:52 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16pTOC-000D0i-00 for rap@ops.ietf.org; Mon, 25 Mar 2002 04:15:52 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16pTOC-0009fr-00 for rap@ops.ietf.org; Mon, 25 Mar 2002 04:15:52 -0800 Message-ID: <91A311FF6A85D3118DDF0060080C3D8202007957@lat3721.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e7b4b8d3-3f3f-11d6-ac22-00508b692753" From: JACQUENET Christian FTRD/DMI/CAE To: "'rap@ops.ietf.org'" , "'Randy Bush'" , "'Wijnen, Bert (Bert)'" Subject: Support to the PIB standardisation effort (long message) Date: Mon, 25 Mar 2002 11:53:18 +0100 Sender: owner-rap@ops.ietf.org Precedence: bulk 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-e7b4b8d3-3f3f-11d6-ac22-00508b692753 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D3EB.4610DC90" ------_=_NextPart_001_01C1D3EB.4610DC90 Content-Type: text/plain; charset="iso-8859-1" [ post by non-subscriber ] 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 / / /___/__/___/_____/_/__/____ "It's not jewelry she's talkin' about, /__/ /__________________________/_ It really don't cost that much." /_______________________________/ - Pearl necklace. ------_=_NextPart_001_01C1D3EB.4610DC90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support to the PIB standardisation effort (long message)

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_01C1D3EB.4610DC90-- ------=_NextPartTM-000-e7b4b8d3-3f3f-11d6-ac22-00508b692753-- From owner-rap@ops.ietf.org Tue Mar 26 16:58:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26877 for ; Tue, 26 Mar 2002 16:58:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pyvl-000Ju8-00 for rap-data@psg.com; Tue, 26 Mar 2002 13:56:37 -0800 Received: from rwcrmhc51.attbi.com ([204.127.198.38]) by psg.com with esmtp (Exim 3.35 #1) id 16pyvk-000Ju2-00 for rap@ops.ietf.org; Tue, 26 Mar 2002 13:56:36 -0800 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: Subject: Re: why i should like pibs 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 Sender: owner-rap@ops.ietf.org Precedence: bulk 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 > From owner-rap@ops.ietf.org Wed Mar 27 19:48:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00899 for ; Wed, 27 Mar 2002 19:48:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qO4i-000K1X-00 for rap-data@psg.com; Wed, 27 Mar 2002 16:47:32 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16qO4h-000K1R-00 for rap@ops.ietf.org; Wed, 27 Mar 2002 16:47:31 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16qO4h-000LR5-00 for rap@ops.ietf.org; Wed, 27 Mar 2002 16:47:31 -0800 Message-Id: <4.3.2.7.2.20020327164457.019cd2a8@diablo.cisco.com> In-Reply-To: <007601c1d510$48304300$650a0a0a@ne.client2.attbi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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" , Sender: owner-rap@ops.ietf.org Precedence: bulk [ post by non-subscriber ] 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