From diffserv-admin@ietf.org Sun Sep 2 05:30:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08129 for ; Sun, 2 Sep 2001 05:30:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17860; Sun, 2 Sep 2001 05:17:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17806 for ; Sun, 2 Sep 2001 05:14:27 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07928 for ; Sun, 2 Sep 2001 05:13:02 -0400 (EDT) From: francis.arts@alcatel.be Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f829BDH08232 for ; Sun, 2 Sep 2001 11:13:55 +0200 (MET DST) Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256ABB.0031BB9D ; Sun, 2 Sep 2001 11:03:12 +0200 X-Lotus-FromDomain: ALCATEL To: Sanjeev Chakravarty cc: diffserv@ietf.org Message-ID: Date: Sun, 2 Sep 2001 11:03:07 +0200 Subject: Re: [Diffserv] DSCP tag consistency in Service Provider's network Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW" Content-Disposition: inline Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Sanjeev, > Question is, in order to provide a particular class of service (eg., Gold) > to a customer, does a service provider will always mark the customer's IP > packets with the same DSCP value while the packet is inside the service > provider's network? The marking operation is typically done when the packets are received at the borders of the network. Whether or not all packets received from the customer, are marked with the same DSCP, depends on the SLA between the customer and the service provider. Example: The in-profile packets received from the customer may be marked with AF11 while out-of-profile packets may be marked with AF12. Best regards, Francis. ----------------- Sanjeev Chakravarty on 01/09/2001 01:25:47 To: diffserv@ietf.org cc: (bcc: Francis ARTS/BE/ALCATEL) Subject: [Diffserv] DSCP tag consistency in Service Provider's network Hi, Question is, in order to provide a particular class of service (eg., Gold) to a customer, does a service provider will always mark the customer's IP packets with the same DSCP value while the packet is inside the service provider's network? Thanks, Sanjeev Chakravarty --0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+RFNDUCB0 YWcgY29uc2lzdGVuY3kgaW4gU2VydmljZSBQcm92aWRlcidzIG5ldHdvcms8L1RJVExFPg0KPC9I RUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5IaSw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5RdWVzdGlvbiBpcywgaW4gb3JkZXIgdG8gcHJvdmlkZSBhIHBhcnRpY3VsYXIg Y2xhc3Mgb2Ygc2VydmljZSAoZWcuLCBHb2xkKSB0byBhIGN1c3RvbWVyLCBkb2VzIGEgc2Vydmlj ZSBwcm92aWRlciB3aWxsIGFsd2F5cyBtYXJrIHRoZSBjdXN0b21lcidzIElQIHBhY2tldHMgd2l0 aCB0aGUgc2FtZSBEU0NQIHZhbHVlIHdoaWxlIHRoZSBwYWNrZXQgaXMgaW5zaWRlIHRoZSBzZXJ2 aWNlIHByb3ZpZGVyJ3MgbmV0d29yaz88L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhh bmtzLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlNhbmplZXYgQ2hha3JhdmFydHk8 L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4= --0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Sep 2 05:38:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08274 for ; Sun, 2 Sep 2001 05:38:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18050; Sun, 2 Sep 2001 05:25:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17932 for ; Sun, 2 Sep 2001 05:22:22 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07991 for ; Sun, 2 Sep 2001 05:20:58 -0400 (EDT) From: francis.arts@alcatel.be Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f829J9j08407 for ; Sun, 2 Sep 2001 11:21:51 +0200 (MET DST) Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256ABB.0031BB9D ; Sun, 2 Sep 2001 11:03:12 +0200 X-Lotus-FromDomain: ALCATEL To: Sanjeev Chakravarty cc: diffserv@ietf.org Message-ID: Date: Sun, 2 Sep 2001 11:03:07 +0200 Subject: Re: [Diffserv] DSCP tag consistency in Service Provider's network Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW" Content-Disposition: inline Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Sanjeev, > Question is, in order to provide a particular class of service (eg., Gold) > to a customer, does a service provider will always mark the customer's IP > packets with the same DSCP value while the packet is inside the service > provider's network? The marking operation is typically done when the packets are received at the borders of the network. Whether or not all packets received from the customer, are marked with the same DSCP, depends on the SLA between the customer and the service provider. Example: The in-profile packets received from the customer may be marked with AF11 while out-of-profile packets may be marked with AF12. Best regards, Francis. ----------------- Sanjeev Chakravarty on 01/09/2001 01:25:47 To: diffserv@ietf.org cc: (bcc: Francis ARTS/BE/ALCATEL) Subject: [Diffserv] DSCP tag consistency in Service Provider's network Hi, Question is, in order to provide a particular class of service (eg., Gold) to a customer, does a service provider will always mark the customer's IP packets with the same DSCP value while the packet is inside the service provider's network? Thanks, Sanjeev Chakravarty --0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+RFNDUCB0 YWcgY29uc2lzdGVuY3kgaW4gU2VydmljZSBQcm92aWRlcidzIG5ldHdvcms8L1RJVExFPg0KPC9I RUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5IaSw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5RdWVzdGlvbiBpcywgaW4gb3JkZXIgdG8gcHJvdmlkZSBhIHBhcnRpY3VsYXIg Y2xhc3Mgb2Ygc2VydmljZSAoZWcuLCBHb2xkKSB0byBhIGN1c3RvbWVyLCBkb2VzIGEgc2Vydmlj ZSBwcm92aWRlciB3aWxsIGFsd2F5cyBtYXJrIHRoZSBjdXN0b21lcidzIElQIHBhY2tldHMgd2l0 aCB0aGUgc2FtZSBEU0NQIHZhbHVlIHdoaWxlIHRoZSBwYWNrZXQgaXMgaW5zaWRlIHRoZSBzZXJ2 aWNlIHByb3ZpZGVyJ3MgbmV0d29yaz88L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhh bmtzLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlNhbmplZXYgQ2hha3JhdmFydHk8 L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4= --0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Sep 2 06:17:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08139 for ; Sun, 2 Sep 2001 05:30:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17766; Sun, 2 Sep 2001 05:09:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17727 for ; Sun, 2 Sep 2001 05:06:33 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07873 for ; Sun, 2 Sep 2001 05:05:09 -0400 (EDT) From: francis.arts@alcatel.be Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f8293HL08054 for ; Sun, 2 Sep 2001 11:05:59 +0200 (MET DST) Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256ABB.0031BB9D ; Sun, 2 Sep 2001 11:03:12 +0200 X-Lotus-FromDomain: ALCATEL To: Sanjeev Chakravarty cc: diffserv@ietf.org Message-ID: Date: Sun, 2 Sep 2001 11:03:07 +0200 Subject: Re: [Diffserv] DSCP tag consistency in Service Provider's network Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW" Content-Disposition: inline Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Sanjeev, > Question is, in order to provide a particular class of service (eg., Gold) > to a customer, does a service provider will always mark the customer's IP > packets with the same DSCP value while the packet is inside the service > provider's network? The marking operation is typically done when the packets are received at the borders of the network. Whether or not all packets received from the customer, are marked with the same DSCP, depends on the SLA between the customer and the service provider. Example: The in-profile packets received from the customer may be marked with AF11 while out-of-profile packets may be marked with AF12. Best regards, Francis. ----------------- Sanjeev Chakravarty on 01/09/2001 01:25:47 To: diffserv@ietf.org cc: (bcc: Francis ARTS/BE/ALCATEL) Subject: [Diffserv] DSCP tag consistency in Service Provider's network Hi, Question is, in order to provide a particular class of service (eg., Gold) to a customer, does a service provider will always mark the customer's IP packets with the same DSCP value while the packet is inside the service provider's network? Thanks, Sanjeev Chakravarty --0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+RFNDUCB0 YWcgY29uc2lzdGVuY3kgaW4gU2VydmljZSBQcm92aWRlcidzIG5ldHdvcms8L1RJVExFPg0KPC9I RUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5IaSw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5RdWVzdGlvbiBpcywgaW4gb3JkZXIgdG8gcHJvdmlkZSBhIHBhcnRpY3VsYXIg Y2xhc3Mgb2Ygc2VydmljZSAoZWcuLCBHb2xkKSB0byBhIGN1c3RvbWVyLCBkb2VzIGEgc2Vydmlj ZSBwcm92aWRlciB3aWxsIGFsd2F5cyBtYXJrIHRoZSBjdXN0b21lcidzIElQIHBhY2tldHMgd2l0 aCB0aGUgc2FtZSBEU0NQIHZhbHVlIHdoaWxlIHRoZSBwYWNrZXQgaXMgaW5zaWRlIHRoZSBzZXJ2 aWNlIHByb3ZpZGVyJ3MgbmV0d29yaz88L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhh bmtzLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlNhbmplZXYgQ2hha3JhdmFydHk8 L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4= --0__=uhURwBkIrVViVlW6GBLCyu5XLHfCg7nWzzKi456F8EfaiNzWUGluQqOW-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Sep 2 08:21:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09660 for ; Sun, 2 Sep 2001 08:21:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21005; Sun, 2 Sep 2001 08:09:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20974 for ; Sun, 2 Sep 2001 08:09:02 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09467 for ; Sun, 2 Sep 2001 08:07:36 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f82C90p10434 for ; Sun, 2 Sep 2001 08:09:00 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sun, 2 Sep 2001 14:08:54 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D56323A@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: diffserv@ietf.org Date: Sun, 2 Sep 2001 14:08:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] DiffServ MIB rev 12 review Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Normally I have just some other MIB doctor do my IESG review. Harrie Hazewinkel is that MIB doctor for this MIB and he has done a review of earlier versions and is working on review of rev 12 too. I have also done some more detailed review myself, because - this seems a MIB that can not just be used for monitoring but also for configuration. The co-operation between the DiffServ WG and the SNMPCONF WG have been very good on that topic I believe. - A lot of effort has been spend on this MIB, and potentially a lot of people will implement it. - Some Generic MIB (SMI) issues have come out as a result. We're discussing some of these in SMIng, EOS WGs and on the mibs@ops.ietf.org mailing list. Therefor I wanted to check out this MIB in more detail as well. Here is my comments when reviewing. These items are all more or less serious in my view. ---------------------------------------------------- 1.Are the tables persistent or not? I do not see the use of StorageType TC, neither do I see any words in the DESCRIPTION clauses about the persistency of the tables. I'd prefer the use of StorageType. But having heard some of the issues at implementation time, I am happy if there is only a few words about persistency in the DESCRIPTION clause of each table. Another storage-type-like TC is being worked on by Juergen Schoenwaelder and Steve Moulto. This to try and address some of the issues that have been raised on the existing StorageType TC. But you may decide that you don't want to wait for that work to finish. I hear that we'll get a new draft on this in the coming week. 2.In the compliances, I see a separate group for the set of diffServXxxNextFree objects. The idea is that these only need to be implemented when write access (i.e. row creation) is supported by the implementation. However, one might decide to do an implementation with support for write-access (i,e, row creation), yet one might not implement all OBJECT-GROUPs, and so one would end up with some of these diffServXxxNextFree objects for GROUPS that one does not implement/support. The solution I think is to remove the diffServMibStaticGroup and include each of these objects in the related OBJECT-GROUP and add a line aka: OBJECT diffServClfrNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not required for a read-only implementation." 3.I also seriously propose that we make 2 compliance statements The one you currently have (which allows read-only access) and another one named diffServMIBFullCompliance (or diffServMIBConfigurationCompliance or such) that REQUIRES all implemented objects to be read-write. I would hope that this will encourage implementers to go for a SNMP configurable Diffserv Capable device. 4.You are using a new TC IndexInteger for Indices. That is good! I would change ".. as an SNMP Index" into ".. as a table Index". Bit... you use the same TC for the diffServXxxNextFree objects. I guess it is understandble, but what I often see is that people allow in such objects a special value of zero to indicate that no new entries/rows can be created. It would address the concern that was posted to diffserv mlist yday where someone want to limit the range to 4096. So I would suggest to add another TC aka: IndexIntegerNextFree ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An integer which may be used as an Index in a table. The special value of 0 indicates that no more new entries can be created in the relevant table. When a MIB is used for configuration, an object with this SYNTAX always contains a legal value (if non-zero) for an index that is not currently used in the relevant table. The Command Generator (Network Management Application) reads this variable and uses the (non-zero) value read when creating a new row with an SNMP SET. When the SET is performed, the Command Responder (agent) must determine whether the value is indeed still unused; Two Network Management Applications may attempt to create a row (configuration entry) simultaneously and use the same value. If it is currently unused, the SET succeeds and the Command Responder (agent) changes the value of this object, according to an implementation-specific algorithm. If the value is in use, however, the SET fails. The Network Management Application must then re-read this variable to obtain a new useable value. An OBJECT-TYPE definition using this SYNTAX MUST specify the relevant table for which the object is providing this functionality. " SYNTAX INTEGER (0..2147483647) By doing this, you might also get rid of 13 or so paragprahps in sections 3.2.1 through 3.5.4. that basically say the same thing as above. 5. diffServClfrId and diffServElementClfrId are using the same object (diffServClfrNextFree), which is OK, since the entries in the two tables are related to each other. But is there a sequence in which such entries must be created? For example do you first create an entry in diffServClfrTable and then one or more entries in diffServClfrElementTable? If the order is not prescribed, then there might be a risk that two management applications obtain the diffServClfrNext, and that one of them creates an entry in diffServClfrTable, while the other starts creating entry(ies) in diffServClfrElementTable. I suggest it would be wise to add some words about this? 6. I think that a lot of the comment lines that we see just before all the tables SHOULD be moved into the DESCRIPTION clause of the table definitions. 7. For diffServClfrElementSpecific, it says that only ONE element (per classifier) may have the value zeroDotZero. Yet it specifies zeroDotZero as the default value. Is that then wise? 8. For diffServMeterSpecific, you should state what happens if the ptr is pointing to a non-existing entry or if the ptr is zeroDotZero. Same question for diffServActionSpecific 9. I think that diffServParamType should have a syntax of AutonomousType as defined in SMIv2-TC (RFC2579). 10. diffServTBParameterInterval has syntax of Unsigned32. I wonder what the value zero means? Either it is not valid (and then you should specify a range), or it may have special meaning, which you should then specify in the DESCRIPTION clause. 11. The definitions of diffserv paramter types (i.e. OIDs for things like diffServTBParamSimpleTokenBucket and such) are OK. However, I think I would organize them under somthing like diffServAdmin OBJECT IDENTIFIER { diffServMib 3 } That is define one place for administrative things and registrations. You have another set of these starting on page 81 12. The 2nd para in the DESCRIPTION clause of diffServDscpMarkActDscp is not needed. RFC2578 clearly explains that in this case the index column can and should be made accessible. If you keep the 2nd para, then it seem to me that you should not be talking about an OBJECT-IDENTITY but about an OBJECT IDENTIFIER instead. 13. You seem to have discontinuity timestamps (like the diffServCountActDisconTime) per row. Is this really what you want? I don't think I have ever seen it implemented at the row level. I don't think that that is what we intended discontinuity timers for either. It seems to add an extra object to each row while I wonder if discontinuity indeed - happens often - if it does happen, does it then only apply to one row, or does it apply to multiple or possibly all rows in the table. A discontinuity timer per table or per MIB is what we have seen more often. This has been done in a few more tables, so it applies to them as well. 14. For diffServCountActStatus, it says that "Any writable value may be modified....". I guess literally the statement is correct. But it reads strange if the only writable object in this table/row is this object itself. 15. Is zero a valid value for diffServShapingRateLevel, and if so does that have a special meaning? If not, then must exclude zero via a range specification. 16. The comments at the beginning of diffServMIBCompliance probably are much better moved into the DESCRIPTION clause. Otherwise you loose them when the MIB gets extracted. 17. I wonder if at the places where you use the InetAddressType, InetAddress, InetAddressPrefixLength, if dns names are allowed. If not, then you have to specify so in the compliance section. I am also discussing with a few people if this MIB should be written such that one would NOT have to support createAndWait (since several vendor-type people have claimed that this make SET support so difficult and complex to implement). The tables in this MIB are such (I believe) that we could specify that only CreateAndGo MUST be supported, because each row fits in a 484-octet packet (so we do not need to go through the generic discussion if it indeed MUSt fit in such a small packet). Further I have a set of editorial nits that I will send directly to Fred, no need to waste bandwidth on this list for that. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 3 13:43:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12463 for ; Mon, 3 Sep 2001 13:43:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24896; Mon, 3 Sep 2001 13:18:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24867 for ; Mon, 3 Sep 2001 13:18:06 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12219 for ; Mon, 3 Sep 2001 13:16:41 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA07188; Mon, 3 Sep 2001 18:17:33 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA33804; Mon, 3 Sep 2001 18:17:33 +0100 Message-ID: <3B93BB24.3F8A8002@hursley.ibm.com> Date: Mon, 03 Sep 2001 12:17:25 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] on E_a and E_p- RFC2598bis References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit (d_j - f_j) != (D_j - F_j) That fooled me the first time I read it, too. There is no redundancy. (Also, the document has passed Last Call.) Brian demir wrote: > > RFC2598bis > - E_a is the error term for the treatment of the EF aggregate. > Note that E_a represents the worst case deviation between actual > departure time of an EF packet and ideal departure time of the > same packet, i.e. E_a provides an upper bound on (d_j - f_j) for > > - E_p is the error term for the treatment of individual EF > packets. Note that E_p represents the worst case deviation between > actual departure time of an EF packet and ideal departure time of > the same packet, i.e. E_p provides an upper bound on (D_j - F_j) > > In the above text, both "Note that" for E_a and E_p notes the same thing. > > Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 3 22:22:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17289 for ; Mon, 3 Sep 2001 22:22:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03037; Mon, 3 Sep 2001 22:05:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03006 for ; Mon, 3 Sep 2001 22:05:16 -0400 (EDT) Received: from mail.etang.com (smtp.etang.com [202.101.42.207]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17173 for ; Mon, 3 Sep 2001 22:03:46 -0400 (EDT) Received: from bear (unknown [202.108.240.3]) by mail.etang.com (Postfix) with ESMTP id 1A1A91CB2DA94 for ; Tue, 4 Sep 2001 10:13:37 +0800 (CST) Date: Tue, 4 Sep 2001 10:12:15 +0800 From: Vincent Wang To: "DiffServ@ietf.org" X-mailer: FoxMail 4.0 beta 1 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====002_Dragon884444672166_=====" Message-Id: <20010904021337.1A1A91CB2DA94@mail.etang.com> Subject: [Diffserv] new droppers,new meters Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --=====002_Dragon884444672166_===== Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBoYXZlIHJlYWQgYSBsb3Qgb2YgdGhpbmdzIGFib3V0IERpZmZTZXJ2LCBpbmNsdWRpbmcgYWxs IHJlbGF0ZWQNClJGQ3MgYW5kIHBhcGVycy4gQnV0IEkgZG8gbm90IGZpbmQgYW55IGNsdWUgZm9y IEFGJ3MgRGlmZlNlcnYuDQpJbiBBRidzIERpZmZTZXJ2LCBpdHMgcmVhbCBtZWFuaW5nIGlzIHRo YXQgRGlmZi1tYWNybyBmbG93cw0KcmVjZWl2ZSBEaWZmLW1hY3JvIGZsb3dzIHRyZWF0bWVudDsg QnV0IHRoZSBEaWZmZXJlbmNlIE1ldHJpY3MgDQpiZXR3ZWVuIHRoZXNlIERpZmZlcmVudCBtYWNy byBmbG93cyBpcyBuZXZlciBzdGF0ZWQuDQpTbyBEaWZmU2VydiBpcyBqdXN0IGEgZnJhbWV3b3Jr IGZvciBtYWNybyBmbG93cyB0cmVhdG1lbnQuIElmIA0Kd2Ugd2FudCB0byBnZXQgcmVhbGx5IG1l YW5pbmdmdWwgdGhpbmcgLHN1Y2ggYXMgZGlmZmVyZW50IG1hY3JvDQpmbG93cyBnZXR0aW5nIGJl dHRlciBRb1MobG93IGxhdGVuY3ksIGhpZ2ggdGhyb3VnaHB1dCBhbmQgbG93DQpqaXR0ZXIpLHdl IG11c3QgZGVwbG95IG5ldyBtZWNoYW5pc20gKCBuZXcgZHJvcHBlcnMsbmV3IG1ldGVycykNCi4N CkFtIEkgcmlnaHQ/DQo= --=====002_Dragon884444672166_===== Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxtZXRhIGh0dHAtZXF1aXZlPSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD1HQjIzMTIiPg0KPG1ldGEgaHR0cC1lcXVpdmU9IkNvbnRlbnQt VHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUdCMjMxMiI+DQo8TUVUQSBOQU1FPSJH RU5FUkFUT1IiIENvbnRlbnQ9Ik1pY3Jvc29mdCBESFRNTCBFZGl0aW5nIENvbnRyb2wiPg0KPFRJ VExFPjwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjxQPkkgaGF2ZSByZWFkIGEgbG90IG9mIHRo aW5ncyBhYm91dCBEaWZmU2VydiwgaW5jbHVkaW5nIGFsbCByZWxhdGVkPC9QPg0KPFA+UkZDcyBh bmQgcGFwZXJzLiBCdXQgSSBkbyBub3QgZmluZCBhbnkgY2x1ZSBmb3IgQUYncyBEaWZmU2Vydi48 L1A+DQo8UD5JbiBBRidzIERpZmZTZXJ2LCBpdHMgcmVhbCBtZWFuaW5nIGlzIHRoYXQgRGlmZi1t YWNybyBmbG93czwvUD4NCjxQPnJlY2VpdmUgRGlmZi1tYWNybyBmbG93cyB0cmVhdG1lbnQ7IEJ1 dCB0aGUgRGlmZmVyZW5jZSBNZXRyaWNzIDwvUD4NCjxQPmJldHdlZW4gdGhlc2UgRGlmZmVyZW50 IG1hY3JvIGZsb3dzIGlzIG5ldmVyIHN0YXRlZC48L1A+DQo8UD5TbyBEaWZmU2VydiBpcyBqdXN0 IGEgZnJhbWV3b3JrIGZvciBtYWNybyBmbG93cyB0cmVhdG1lbnQuIElmIDwvUD4NCjxQPndlIHdh bnQgdG8gZ2V0IHJlYWxseSBtZWFuaW5nZnVsIHRoaW5nICxzdWNoIGFzIGRpZmZlcmVudCBtYWNy bzwvUD4NCjxQPmZsb3dzIGdldHRpbmcgYmV0dGVyIFFvUyhsb3cgbGF0ZW5jeSwgaGlnaCB0aHJv dWdocHV0IGFuZCBsb3c8L1A+DQo8UD5qaXR0ZXIpLHdlIG11c3QgZGVwbG95IG5ldyBtZWNoYW5p c20gKCBuZXcgZHJvcHBlcnMsbmV3IG1ldGVycyk8L1A+DQo8UD4uPC9QPg0KPFA+QW0gSSByaWdo dD88L1A+DQo8L0JPRFk+DQo8L0hUTUw+DQo= --=====002_Dragon884444672166_=====-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 4 07:09:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07886 for ; Tue, 4 Sep 2001 07:09:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19983; Tue, 4 Sep 2001 06:50:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19952 for ; Tue, 4 Sep 2001 06:50:22 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07368; Tue, 4 Sep 2001 06:48:56 -0400 (EDT) Message-Id: <200109041048.GAA07368@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Sep 2001 06:48:56 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-12.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Management Information Base for the Differentiated Services Architecture Author(s) : F. Baker, K. Chan, A. Smith Filename : draft-ietf-diffserv-mib-12.txt Pages : 111 Date : 31-Aug-01 This memo describes a SMIv2 MIB for a device implementing the Differentiated Services Architecture [DSARCH], described in detail by the Informal Management Model for Diffserv Routers [MODEL]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-mib-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-mib-12.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: <20010831143445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010831143445.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 4 13:30:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22207 for ; Tue, 4 Sep 2001 13:30:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00755; Tue, 4 Sep 2001 13:07:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00724 for ; Tue, 4 Sep 2001 13:07:31 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21585 for ; Tue, 4 Sep 2001 13:06:06 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA12060; Tue, 4 Sep 2001 18:06:54 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA53054; Tue, 4 Sep 2001 18:06:55 +0100 Message-ID: <3B95085D.41382C6F@hursley.ibm.com> Date: Tue, 04 Sep 2001 11:59:09 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Vincent Wang CC: "DiffServ@ietf.org" Subject: Re: [Diffserv] new droppers,new meters References: <20010904021337.1A1A91CB2DA94@mail.etang.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Vincent Wang wrote: > > I have read a lot of things about DiffServ, including all related > > RFCs and papers. But I do not find any clue for AF's DiffServ. > > In AF's DiffServ, its real meaning is that Diff-macro flows > > receive Diff-macro flows treatment; But the Difference Metrics > > between these Different macro flows is never stated. No, it is an individual network operator's choice how many AF classes to implement and what parameters each class will have. That is an operational choice, and nothing to do with the standard. > So DiffServ is just a framework for macro flows treatment. If > > we want to get really meaningful thing ,such as different macro > > flows getting better QoS(low latency, high throughput and low > > jitter),we must deploy new mechanism ( new droppers,new meters) As you will see in the MIB, behaviors such as AF are constructed from well known mechanisms. It is a question of setting the parameters of existing droppers etc to values that produce the behavior that you want for each traffic class. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 4 15:24:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25181 for ; Tue, 4 Sep 2001 15:24:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04485; Tue, 4 Sep 2001 15:07:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04452 for ; Tue, 4 Sep 2001 15:06:53 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24683 for ; Tue, 4 Sep 2001 15:05:26 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id MAA20058; Tue, 4 Sep 2001 12:06:42 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA06895; Tue, 4 Sep 2001 12:06:42 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA20743; Tue, 4 Sep 2001 15:06:35 -0400 (EDT) Message-Id: <200109041906.PAA20743@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Steve Blake cc: ah_smith@pacbell.net, "Brian E Carpenter" , diffserv@ietf.org Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt In-reply-to: Your message of "Thu, 30 Aug 2001 18:56:55 EDT." <200108302256.SAA06857@castillo.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Sep 2001 15:06:34 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > > > I haven't seen any response to these questions. I'd like to see > > a response from the authors ASAP so that we are sure we can > > issue a Last Call at the same time as the MIB. > > > Ashley Shi wrote: > > > > > > Can any author clarify the following questions for Appendix A? > > > > > > 1) Is the token interval used the same as the token update interval? If > > > yes, its definition in informal model is not consistent with most > > > implementations. The token update interval is a preconfigured value for > > > token bucket meter, which is not directly correlated with B/R, for > > > example, a implementation may use 2000 updates per sec, anther one may > > > use 4000 updates per sec. > > This is Fred Baker's text, I believe. He and I apparently have divergent > ideas about how token buckets ought to behave, so I don't want to claim > to speak authoritatively about this part of the text, but I believe that > the text assumes that the "token interval" == actual token update interval. > > The model you have in mind is more consistent with the model in A.4, > I think. > > > > 2) The description for strict token bucket on page 50 doesn't match the > > > mathematical model in A.4. > > > The description implies when new tokens to the bucket, the upper > > > bound B deesn''t hold. > > > The mathematical model does bound the number of tokens in the bucket > > > by bucket size B. > > I believe that you are correct. I know of at least four implementations > that behave as described in A.4; I have no doubt that there are > counterexamples that behave as described in A.2. The discrepancy has to > do with how frequently one thinks that tokens are replenished. A.4 assumes > that this happens with a granularity that depends on precision with > which time intervals are calculated. > > I don't know how to reconcile the two models, other than by calling > A.4 the really really strict token bucket. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven L. Blake I'll agree with Steve. Perhaps Fred can clarify. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 4 16:27:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26905 for ; Tue, 4 Sep 2001 16:27:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06243; Tue, 4 Sep 2001 16:13:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06215 for ; Tue, 4 Sep 2001 16:13:49 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26516 for ; Tue, 4 Sep 2001 16:12:24 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA26274; Tue, 4 Sep 2001 21:13:14 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA52664; Tue, 4 Sep 2001 21:13:12 +0100 Message-ID: <3B953213.EE8FA6B0@hursley.ibm.com> Date: Tue, 04 Sep 2001 14:57:07 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Grossman CC: Steve Blake , ah_smith@pacbell.net, diffserv@ietf.org Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt References: <200109041906.PAA20743@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit At this stage, we need precise proposed change(s) to the text, or nothing will happen. Brian Dan Grossman wrote: > > > > > > I haven't seen any response to these questions. I'd like to see > > > a response from the authors ASAP so that we are sure we can > > > issue a Last Call at the same time as the MIB. > > > > > Ashley Shi wrote: > > > > > > > > Can any author clarify the following questions for Appendix A? > > > > > > > > 1) Is the token interval used the same as the token update interval? If > > > > yes, its definition in informal model is not consistent with most > > > > implementations. The token update interval is a preconfigured value for > > > > token bucket meter, which is not directly correlated with B/R, for > > > > example, a implementation may use 2000 updates per sec, anther one may > > > > use 4000 updates per sec. > > > > This is Fred Baker's text, I believe. He and I apparently have divergent > > ideas about how token buckets ought to behave, so I don't want to claim > > to speak authoritatively about this part of the text, but I believe that > > the text assumes that the "token interval" == actual token update interval. > > > > The model you have in mind is more consistent with the model in A.4, > > I think. > > > > > > 2) The description for strict token bucket on page 50 doesn't match the > > > > mathematical model in A.4. > > > > The description implies when new tokens to the bucket, the upper > > > > bound B deesn''t hold. > > > > The mathematical model does bound the number of tokens in the bucket > > > > by bucket size B. > > > > I believe that you are correct. I know of at least four implementations > > that behave as described in A.4; I have no doubt that there are > > counterexamples that behave as described in A.2. The discrepancy has to > > do with how frequently one thinks that tokens are replenished. A.4 assumes > > that this happens with a granularity that depends on precision with > > which time intervals are calculated. > > > > I don't know how to reconcile the two models, other than by calling > > A.4 the really really strict token bucket. > > > > > > Regards, > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Steven L. Blake > I'll agree with Steve. Perhaps Fred can clarify. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 4 17:04:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27937 for ; Tue, 4 Sep 2001 17:04:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07272; Tue, 4 Sep 2001 16:51:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07243 for ; Tue, 4 Sep 2001 16:51:44 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27644 for ; Tue, 4 Sep 2001 16:50:18 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f84KpKv07199; Tue, 4 Sep 2001 13:51:20 -0700 (PDT) Message-Id: <5.1.0.14.2.20010904132233.050a5730@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 13:26:03 -0700 To: Dan Grossman From: Fred Baker Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt Cc: Steve Blake , ah_smith@pacbell.net, "Brian E Carpenter" , diffserv@ietf.org In-Reply-To: <200109041906.PAA20743@noah.dma.isg.mot.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 12:06 PM 9/4/2001, Dan Grossman wrote: >Perhaps Fred can clarify. there is an extensive discussion in the archives, as well as in your and my private mailboxes. Since the model is now largely irrelevant (it describes *a* way diffserv might be implemented, but is mostly OBE, and goes way too far into designing a router to be even remotely considered to be the One True Way That All Of Us Will Rip Out Our Existing Code And Hardware And Re-implement It), I'm personally willing to see the text you're concerned about removed. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 4 17:24:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28398 for ; Tue, 4 Sep 2001 17:24:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08032; Tue, 4 Sep 2001 17:12:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08001 for ; Tue, 4 Sep 2001 17:12:47 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28055 for ; Tue, 4 Sep 2001 17:11:15 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA28808 for ; Tue, 4 Sep 2001 14:12:40 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA28772 for ; Tue, 4 Sep 2001 14:12:40 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA13094; Tue, 4 Sep 2001 17:12:39 -0400 (EDT) Message-Id: <200109042112.RAA13094@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Fred Baker cc: Steve Blake , ah_smith@pacbell.net, "Brian E Carpenter" , diffserv@ietf.org Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt In-reply-to: Your message of "Tue, 04 Sep 2001 13:26:03 EDT." <5.1.0.14.2.20010904132233.050a5730@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Sep 2001 17:12:38 -0400 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > At 12:06 PM 9/4/2001, Dan Grossman wrote: > >Perhaps Fred can clarify. > > there is an extensive discussion in the archives, as well as in your and my > private mailboxes. > > Since the model is now largely irrelevant (it describes *a* way diffserv > might be implemented, but is mostly OBE, and goes way too far into > designing a router to be even remotely considered to be the One True Way > That All Of Us Will Rip Out Our Existing Code And Hardware And Re-implement > It), I'm personally willing to see the text you're concerned about removed. > I'm going to have to apolgise here. My last note was a shoot-from-the-hip response, out of context of some subsequent emails. I was simply wondering whether there's a simple clarification to the original question, not to relaunch a past battle. Frankly, I haven't had much time to think about it. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 4 17:32:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28629 for ; Tue, 4 Sep 2001 17:32:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08243; Tue, 4 Sep 2001 17:16:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08218 for ; Tue, 4 Sep 2001 17:16:45 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28156 for ; Tue, 4 Sep 2001 17:15:18 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA17242 for ; Tue, 4 Sep 2001 22:16:12 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA46252 for ; Tue, 4 Sep 2001 22:16:13 +0100 Message-ID: <3B954015.13391F01@hursley.ibm.com> Date: Tue, 04 Sep 2001 15:56:53 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] FYI: draft-ietf-diffserv-model-06.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffservers, draft-ietf-diffserv-model-06.txt, which is a current WG draft, has temporarily disappeared from the IETF site, due to being >6 months old. It will be back within a couple of days. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 4 17:42:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28817 for ; Tue, 4 Sep 2001 17:42:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08629; Tue, 4 Sep 2001 17:26:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08592 for ; Tue, 4 Sep 2001 17:26:08 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28414 for ; Tue, 4 Sep 2001 17:24:42 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA33810; Tue, 4 Sep 2001 22:25:35 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA28540; Tue, 4 Sep 2001 22:25:34 +0100 Message-ID: <3B954230.D0E576E0@hursley.ibm.com> Date: Tue, 04 Sep 2001 16:05:52 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: Dan Grossman , Steve Blake , ah_smith@pacbell.net, diffserv@ietf.org Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt References: <5.1.0.14.2.20010904132233.050a5730@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Fred raises an interesting thought. The informal model has, I think, been quite useful in developing the MIB and PIB, but it was never intended to describe any real implementation, and the MIB and PIB are the standards-track items. There will be a WG Last Call fairly soon for the MIB, PIB, and model - unless people think that the model is indeed OBE and should be retired with honour rather than becoming an RFC. Opinions welcome. Brian Fred Baker wrote: > > At 12:06 PM 9/4/2001, Dan Grossman wrote: > >Perhaps Fred can clarify. > > there is an extensive discussion in the archives, as well as in your and my > private mailboxes. > > Since the model is now largely irrelevant (it describes *a* way diffserv > might be implemented, but is mostly OBE, and goes way too far into > designing a router to be even remotely considered to be the One True Way > That All Of Us Will Rip Out Our Existing Code And Hardware And Re-implement > It), I'm personally willing to see the text you're concerned about removed. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 4 18:13:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29508 for ; Tue, 4 Sep 2001 18:13:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10055; Tue, 4 Sep 2001 18:01:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09998 for ; Tue, 4 Sep 2001 18:00:55 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29130 for ; Tue, 4 Sep 2001 17:59:29 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA22332; Tue, 4 Sep 2001 23:00:18 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA36502; Tue, 4 Sep 2001 23:00:15 +0100 Message-ID: <3B954FE7.9FB16F71@hursley.ibm.com> Date: Tue, 04 Sep 2001 17:04:23 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker , Dan Grossman , Steve Blake , ah_smith@pacbell.net, diffserv@ietf.org Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt References: <5.1.0.14.2.20010904132233.050a5730@mira-sjcm-2.cisco.com> <3B954230.D0E576E0@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Answering my own thought... the PIB at least contains many, many (non-normative) references to the model draft. It would be a lot of work to remove them. Since the model says it "is not intended as a guide to system implementation nor as a formal modelling description," I believe we do not need to insist on every detail, and I don't personally see a problem with the way Appendix A is now, but if Fred can tell us exactly what to delete, we can certainly do so. Brian Brian E Carpenter wrote: > > Fred raises an interesting thought. The informal model has, I think, been > quite useful in developing the MIB and PIB, but it was never intended > to describe any real implementation, and the MIB and PIB are the > standards-track items. There will be a WG Last Call fairly soon for > the MIB, PIB, and model - unless people think that the model is indeed > OBE and should be retired with honour rather than becoming an RFC. > Opinions welcome. > > Brian > > Fred Baker wrote: > > > > At 12:06 PM 9/4/2001, Dan Grossman wrote: > > >Perhaps Fred can clarify. > > > > there is an extensive discussion in the archives, as well as in your and my > > private mailboxes. > > > > Since the model is now largely irrelevant (it describes *a* way diffserv > > might be implemented, but is mostly OBE, and goes way too far into > > designing a router to be even remotely considered to be the One True Way > > That All Of Us Will Rip Out Our Existing Code And Hardware And Re-implement > > It), I'm personally willing to see the text you're concerned about removed. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 4 18:29:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29862 for ; Tue, 4 Sep 2001 18:29:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10511; Tue, 4 Sep 2001 18:15:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10488 for ; Tue, 4 Sep 2001 18:15:19 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29520 for ; Tue, 4 Sep 2001 18:13:52 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f84MF3v10500; Tue, 4 Sep 2001 15:15:03 -0700 (PDT) Message-Id: <5.1.0.14.2.20010904150957.0652d1f8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 15:14:22 -0700 To: Ashley Shi From: Fred Baker Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt Cc: yoramb@microsoft.com, steven.blake@ericsson.com, dan@dma.isg.mot.com, andrew@allegronetworks.com, diffserv@ietf.org, Dave McDysan , Lei Yao In-Reply-To: <3B7AE3F6.68F8B3E2@mci.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 11:04 PM 8/14/2001, Ashley Shi wrote: >1) Is the token interval used the same as the token update interval? As I understand things, there is a difference between specification and implementation. The specification is that: token rate == token burst size/token interval The implementation may be, as you suggest and as I implemented in Cisco gear lo these many moons ago, that there is a much smaller burst and interval that are used for actually updating it, or alternatively that the bucket is refilled at irregular intervals, or a variety of other things. In the text, I tried to describe the specification, not the implementation. >2) The description for strict token bucket on page 50 doesn't match the >mathematical model in A.4. I'll leave that to the author of A.4 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 5 01:58:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12698 for ; Wed, 5 Sep 2001 01:58:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25393; Wed, 5 Sep 2001 01:44:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25361 for ; Wed, 5 Sep 2001 01:44:17 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10820 for ; Wed, 5 Sep 2001 01:42:52 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f855hsv24196; Tue, 4 Sep 2001 22:43:55 -0700 (PDT) Message-Id: <5.1.0.14.2.20010904223231.064429d8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 22:33:32 -0700 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt Cc: Dan Grossman , Steve Blake , ah_smith@pacbell.net, diffserv@ietf.org In-Reply-To: <3B954FE7.9FB16F71@hursley.ibm.com> References: <5.1.0.14.2.20010904132233.050a5730@mira-sjcm-2.cisco.com> <3B954230.D0E576E0@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:04 PM 9/4/2001, Brian E Carpenter wrote: >I don't personally see a problem with the way Appendix A is now, but if >Fred can tell us >exactly what to delete, we can certainly do so. basically, I'm saying that if the text I contributed is causing a problem (Appendix A), rip it out. If it's not, leave it in. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 5 02:24:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20530 for ; Wed, 5 Sep 2001 02:24:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26141; Wed, 5 Sep 2001 02:11:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26118 for ; Wed, 5 Sep 2001 02:11:18 -0400 (EDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20355 for ; Wed, 5 Sep 2001 02:09:53 -0400 (EDT) Received: from ANDREWHOME (user-vcauogd.dsl.mindspring.com [216.175.98.13]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with SMTP id f856BE511667; Tue, 4 Sep 2001 23:11:14 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Brian E Carpenter" Cc: Subject: RE: [Diffserv] doubts on draft-ietf-differv-model-06.txt Date: Tue, 4 Sep 2001 23:31:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3B954230.D0E576E0@hursley.ibm.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Glad to hear that Fred is nominating the Model draft for a long-overdue New Year's honour (for long and arduous public service, I assume, not because it is a famous sporting personality). I think people should try reading the title of the Model draft as well as reading its abstract: it's a model for thinking about management of Diffserv devices, it is not an implementation model. I don't know why some of you are still confused about that. If there is material in the draft that goes beyond the advertised scope then that should be pruned. If there are areas that are not covered then there should be material added (within the boundaries of time schedules and rough consensus of course). But, Fred, please don't misrepresent the intended purpose and exaggerate in such a manner. [In case you're wondering, that was an opinion in favour of keeping the draft on track for publication as an informational RFC, sanctioned by this WG, if not by Fred]. Andrew Smith -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Tuesday, September 04, 2001 2:06 PM To: Fred Baker Cc: Dan Grossman; Steve Blake; ah_smith@pacbell.net; diffserv@ietf.org Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt Fred raises an interesting thought. The informal model has, I think, been quite useful in developing the MIB and PIB, but it was never intended to describe any real implementation, and the MIB and PIB are the standards-track items. There will be a WG Last Call fairly soon for the MIB, PIB, and model - unless people think that the model is indeed OBE and should be retired with honour rather than becoming an RFC. Opinions welcome. Brian Fred Baker wrote: > > At 12:06 PM 9/4/2001, Dan Grossman wrote: > >Perhaps Fred can clarify. > > there is an extensive discussion in the archives, as well as in your and my > private mailboxes. > > Since the model is now largely irrelevant (it describes *a* way diffserv > might be implemented, but is mostly OBE, and goes way too far into > designing a router to be even remotely considered to be the One True Way > That All Of Us Will Rip Out Our Existing Code And Hardware And Re-implement > It), I'm personally willing to see the text you're concerned about removed. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 5 07:01:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23544 for ; Wed, 5 Sep 2001 07:01:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03322; Wed, 5 Sep 2001 06:46:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03297 for ; Wed, 5 Sep 2001 06:46:30 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22715; Wed, 5 Sep 2001 06:45:04 -0400 (EDT) Message-Id: <200109051045.GAA22715@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 05 Sep 2001 06:45:04 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-rfc2598bis-02.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : An Expedited Forwarding PHB Author(s) : B. Davie et al. Filename : draft-ietf-diffserv-rfc2598bis-02.txt Pages : 17 Date : 04-Sep-01 The PHB (per-hop behavior) is a basic building block in the Differentiated Services architecture. This document defines a PHB called Expedited Forwarding (EF). EF is intended to provide a building block for low delay and low loss services by ensuring that the EF aggregate is served at a certain configured rate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-rfc2598bis-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-diffserv-rfc2598bis-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-diffserv-rfc2598bis-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: <20010904141154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-rfc2598bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-rfc2598bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010904141154.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 5 10:12:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03347 for ; Wed, 5 Sep 2001 10:12:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09193; Wed, 5 Sep 2001 09:59:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09161 for ; Wed, 5 Sep 2001 09:59:36 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02166 for ; Wed, 5 Sep 2001 09:58:08 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA05344 for ; Wed, 5 Sep 2001 14:58:57 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA43774 for ; Wed, 5 Sep 2001 14:58:57 +0100 Message-ID: <3B9630A4.933A8AD6@hursley.ibm.com> Date: Wed, 05 Sep 2001 09:03:16 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-rfc2598bis-02.txt References: <200109051045.GAA22715@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit fyi, this was a very minor editorial update in response to IESG comments. Brian Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Differentiated Services Working Group of the IETF. > > Title : An Expedited Forwarding PHB > Author(s) : B. Davie et al. > Filename : draft-ietf-diffserv-rfc2598bis-02.txt > Pages : 17 > Date : 04-Sep-01 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 5 10:14:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03625 for ; Wed, 5 Sep 2001 10:14:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09559; Wed, 5 Sep 2001 10:03:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09532 for ; Wed, 5 Sep 2001 10:03:33 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02457 for ; Wed, 5 Sep 2001 10:02:04 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA31282; Wed, 5 Sep 2001 15:02:55 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA55788; Wed, 5 Sep 2001 15:02:54 +0100 Message-ID: <3B96318E.702E41E3@hursley.ibm.com> Date: Wed, 05 Sep 2001 09:07:10 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jaeyoung Kim CC: diffserv@ietf.org Subject: Re: [Diffserv] What happened to "diffserv-framework" draft? References: <20010824141004.A4128@enisei.postech.ac.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit We dropped it as a WG item a long time ago, as there seemed to be no way of reaching WG consensus about it. Brian Carpenter diffserv co-chair Jaeyoung Kim wrote: > > Hi, > > I'm curious about the reason why the 'diffserv-framework' draft > titled "A Framework for Differentiated Services" by Y. Bernet et al. has been > excluded from the list of formal documents of the DiffServ working group. > I think the draft contains lots of helpful concepts and discussions > when provisioning DiffServ networks. However, the latest revision was > made on February 1999 and now it seems not maintained any more. > > Did the IETF committee think the draft contains too implementation-specific > topics to be a formal RFC? I'm sure there should be enough reasons for > this draft and would like to know them. Thanks in advance. > > Best regards, > Jay Kim > > -- > ============================================================================ > __/\__ ** Remember Yesterday, Dream about Tomorrow, but ... LIVE TODAY !!! > \ /\ / ------------------------------------------------------------------- > /_\/_\ ** jay@postech.ac.kr http://home.postech.ac.kr/~jay > \/ ** Jaeyoung Kim Computer Science & Engineering, POSTECH, KOREA > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 5 10:14:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03642 for ; Wed, 5 Sep 2001 10:14:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09601; Wed, 5 Sep 2001 10:03:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09569 for ; Wed, 5 Sep 2001 10:03:43 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02490 for ; Wed, 5 Sep 2001 10:02:18 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f85E3N200449 for ; Wed, 5 Sep 2001 10:03:23 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Sep 2001 16:03:17 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D62DD31@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Brian E Carpenter , diffserv@ietf.org Subject: RE: [Diffserv] doubts on draft-ietf-differv-model-06.txt Date: Wed, 5 Sep 2001 16:03:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org And so does the MIB. I would think it would be worthwhile to keep the doc as and informational RFC. If current thinking has changed, you might wriet something about that in the introduction. But certainly we have used that document to form our current thinking of the MIB (and PIB) have we not. Bert > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: woensdag 5 september 2001 0:04 > To: Fred Baker; Dan Grossman; Steve Blake; ah_smith@pacbell.net; > diffserv@ietf.org > Subject: Re: [Diffserv] doubts on draft-ietf-differv-model-06.txt > > > Answering my own thought... the PIB at least contains many, many > (non-normative) references to the model draft. It would be a lot > of work to remove them. > > Since the model says it "is not intended as a > guide to system implementation nor as a formal modelling description," > I believe we do not need to insist on every detail, and I > don't personally > see a problem with the way Appendix A is now, but if Fred can tell us > exactly what to delete, we can certainly do so. > > Brian > > Brian E Carpenter wrote: > > > > Fred raises an interesting thought. The informal model has, > I think, been > > quite useful in developing the MIB and PIB, but it was > never intended > > to describe any real implementation, and the MIB and PIB are the > > standards-track items. There will be a WG Last Call fairly soon for > > the MIB, PIB, and model - unless people think that the > model is indeed > > OBE and should be retired with honour rather than becoming an RFC. > > Opinions welcome. > > > > Brian > > > > Fred Baker wrote: > > > > > > At 12:06 PM 9/4/2001, Dan Grossman wrote: > > > >Perhaps Fred can clarify. > > > > > > there is an extensive discussion in the archives, as well > as in your and my > > > private mailboxes. > > > > > > Since the model is now largely irrelevant (it describes > *a* way diffserv > > > might be implemented, but is mostly OBE, and goes way too far into > > > designing a router to be even remotely considered to be > the One True Way > > > That All Of Us Will Rip Out Our Existing Code And > Hardware And Re-implement > > > It), I'm personally willing to see the text you're > concerned about removed. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 5 13:08:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11220 for ; Wed, 5 Sep 2001 13:08:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16717; Wed, 5 Sep 2001 12:45:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12556 for ; Tue, 4 Sep 2001 01:13:27 -0400 (EDT) Received: from tlv1.axerra.com ([192.114.163.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20839 for ; Tue, 4 Sep 2001 01:12:02 -0400 (EDT) Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 08:10:49 +0200 Message-ID: From: Sasha Vainshtein To: "'Vincent Wang'" , DiffServ@ietf.org Subject: RE: [Diffserv] new droppers,new meters Date: Tue, 4 Sep 2001 08:10:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13508.52D473B0" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13508.52D473B0 Content-Type: text/plain; charset="gb2312" Vincent, AFAIK the following documents define metering and marking schemes suitable for AF: * RFC 2697 "Single Rate Three Color Marking Scheme" * RFC 2698 "Two Rate Three Color Marking Scheme" * RFC 2859 "A Time Sliding Window Three Colour Marker". Hopefully this note will be useful. Sorry for using HTML in ths message. _____ With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: Vincent Wang [mailto:nsdos@etang.com] Sent: Tuesday, September 04, 2001 4:12 AM To: DiffServ@ietf.org Subject: [Diffserv] new droppers,new meters I have read a lot of things about DiffServ, including all related RFCs and papers. But I do not find any clue for AF's DiffServ. In AF's DiffServ, its real meaning is that Diff-macro flows receive Diff-macro flows treatment; But the Difference Metrics between these Different macro flows is never stated. So DiffServ is just a framework for macro flows treatment. If we want to get really meaningful thing ,such as different macro flows getting better QoS(low latency, high throughput and low jitter),we must deploy new mechanism ( new droppers,new meters) . Am I right? ------_=_NextPart_001_01C13508.52D473B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Vincent,
AFAIK=20 the following documents define metering and marking schemes suitable = for=20 AF:
  • RFC=20 2697 "Single=20 Rate Three Color Marking Scheme"
  • RFC=20 2698 "Two=20 Rate Three Color Marking Scheme"
  • RFC=20 2859 "A=20 Time Sliding Window Three Colour = Marker".
Hopefully this note will be = useful.
Sorry=20 for using HTML in ths message.
With best regards,
          &nb= sp;           &nb= sp;           =20 Sasha = Vainshtein
email:     sasha@axerra.com
tel:       +972-3-7659993=20 (office)
          =20 +972-8-9254948 (res.)
          =20 +972-58-674833 (cell.)
 
-----Original Message-----
From: Vincent Wang=20 [mailto:nsdos@etang.com]
Sent: Tuesday, September 04, 2001 = 4:12=20 AM
To: DiffServ@ietf.org
Subject: [Diffserv] new=20 droppers,new meters

I have read a lot of things about DiffServ, including all = related

RFCs and papers. But I do not find any clue for AF's DiffServ.

In AF's DiffServ, its real meaning is that Diff-macro flows

receive Diff-macro flows treatment; But the Difference Metrics =

between these Different macro flows is never stated.

So DiffServ is just a framework for macro flows treatment. If

we want to get really meaningful thing ,such as different = macro

flows getting better QoS(low latency, high throughput and low

jitter),we must deploy new mechanism ( new droppers,new = meters)

.

Am I right?

------_=_NextPart_001_01C13508.52D473B0-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 5 14:06:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13521 for ; Wed, 5 Sep 2001 14:06:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18182; Wed, 5 Sep 2001 13:47:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18151 for ; Wed, 5 Sep 2001 13:47:38 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12208 for ; Wed, 5 Sep 2001 13:46:09 -0400 (EDT) Received: from KGUNDAMARAJU ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id AEH29617; Wed, 5 Sep 2001 13:46:50 -0400 (EDT) Message-ID: <001701c13633$53e5b6c0$6200a8c0@KGUNDAMARAJU> From: "Krishna Gundamaraju" To: "Sasha Vainshtein" , "'Vincent Wang'" , References: Subject: Re: [Diffserv] new droppers,new meters Date: Wed, 5 Sep 2001 13:50:57 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C13611.C9E75710" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C13611.C9E75710 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, I have a basic question. The RFC 2697 while explaining the operation = in the color aware mode says that the color of the incoming packets may = be changed based on its notion of tokens. My question is should we also = change the DSCP byte accordingly when changing the color? Or this change = in color has only local significance and the DSCP byte should be left = unchanged? Please clarify. Thanks in advance Krishna G ----- Original Message -----=20 From: Sasha Vainshtein=20 To: 'Vincent Wang' ; DiffServ@ietf.org=20 Sent: Tuesday, September 04, 2001 2:10 AM Subject: RE: [Diffserv] new droppers,new meters Vincent, AFAIK the following documents define metering and marking schemes = suitable for AF: a.. RFC 2697 "Single Rate Three Color Marking Scheme"=20 b.. RFC 2698 "Two Rate Three Color Marking Scheme"=20 c.. RFC 2859 "A Time Sliding Window Three Colour Marker". Hopefully this note will be useful. Sorry for using HTML in ths message. -------------------------------------------------------------------------= ----- With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: Vincent Wang [mailto:nsdos@etang.com] Sent: Tuesday, September 04, 2001 4:12 AM To: DiffServ@ietf.org Subject: [Diffserv] new droppers,new meters I have read a lot of things about DiffServ, including all related RFCs and papers. But I do not find any clue for AF's DiffServ. In AF's DiffServ, its real meaning is that Diff-macro flows receive Diff-macro flows treatment; But the Difference Metrics=20 between these Different macro flows is never stated. So DiffServ is just a framework for macro flows treatment. If=20 we want to get really meaningful thing ,such as different macro flows getting better QoS(low latency, high throughput and low jitter),we must deploy new mechanism ( new droppers,new meters) . Am I right? ------=_NextPart_000_0013_01C13611.C9E75710 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
 
    I have a basic = question.=20 The RFC 2697 while explaining the operation in the color aware mode says = that=20 the color of the incoming packets may be changed based on its notion of = tokens.=20 My question is should we also change the DSCP byte accordingly when = changing the=20 color? Or this change in color has only local significance and the DSCP=20 byte should be left unchanged? Please clarify.
 
    Thanks in = advance
 
Krishna G
 
----- Original Message -----
From:=20 Sasha = Vainshtein=20
Sent: Tuesday, September 04, = 2001 2:10=20 AM
Subject: RE: [Diffserv] new = droppers,new=20 meters

Vincent,
AFAIK the following documents define = metering and=20 marking schemes suitable for AF:
  • RFC=20 2697 "Single=20 Rate Three Color Marking Scheme"=20
  • RFC=20 2698 "Two=20 Rate Three Color Marking Scheme"=20
  • RFC=20 2859 "A=20 Time Sliding Window Three Colour = Marker".
Hopefully this note will be=20 useful.
Sorry for using HTML in ths=20 message.
With best regards,
          &nbs= p;            = ;           =20 Sasha = Vainshtein
email:     sasha@axerra.com
=
tel:       +972-3-7659993=20 (office)
          =20 +972-8-9254948 (res.)
          =20 +972-58-674833 (cell.)
 
-----Original Message-----
From: Vincent Wang=20 [mailto:nsdos@etang.com]
Sent: Tuesday, September 04, 2001 = 4:12=20 AM
To: DiffServ@ietf.org
Subject: [Diffserv] new = droppers,new meters

I have read a lot of things about DiffServ, including all = related

RFCs and papers. But I do not find any clue for AF's = DiffServ.

In AF's DiffServ, its real meaning is that Diff-macro flows

receive Diff-macro flows treatment; But the Difference Metrics =

between these Different macro flows is never stated.

So DiffServ is just a framework for macro flows treatment. If =

we want to get really meaningful thing ,such as different = macro

flows getting better QoS(low latency, high throughput and low

jitter),we must deploy new mechanism ( new droppers,new = meters)

.

Am I right?

------=_NextPart_000_0013_01C13611.C9E75710-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 5 14:30:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15212 for ; Wed, 5 Sep 2001 14:30:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19396; Wed, 5 Sep 2001 14:13:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19347 for ; Wed, 5 Sep 2001 14:13:02 -0400 (EDT) Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13786 for ; Wed, 5 Sep 2001 14:11:36 -0400 (EDT) Received: (qmail 27875 invoked by uid 104); 5 Sep 2001 18:12:27 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 1.734905 secs); 05/09/2001 11:12:25 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 5 Sep 2001 18:12:25 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id f85ICJM25186; Wed, 5 Sep 2001 11:12:19 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 11:13:42 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CC9E1@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Krishna Gundamaraju'" , Sasha Vainshtein , "'Vincent Wang'" , DiffServ@ietf.org Subject: RE: [Diffserv] new droppers,new meters Date: Wed, 5 Sep 2001 11:13:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13636.7BAF3B60" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13636.7BAF3B60 Content-Type: text/plain; charset="gb2312" Hi, You should change the DSCP as well. -Shahram -----Original Message----- From: Krishna Gundamaraju [mailto:krishna.gundamaraju@kenetec.com] Sent: Wednesday, September 05, 2001 1:51 PM To: Sasha Vainshtein; 'Vincent Wang'; DiffServ@ietf.org Subject: Re: [Diffserv] new droppers,new meters Hi, I have a basic question. The RFC 2697 while explaining the operation in the color aware mode says that the color of the incoming packets may be changed based on its notion of tokens. My question is should we also change the DSCP byte accordingly when changing the color? Or this change in color has only local significance and the DSCP byte should be left unchanged? Please clarify. Thanks in advance Krishna G ----- Original Message ----- From: Sasha Vainshtein To: 'Vincent Wang' ; DiffServ@ietf.org Sent: Tuesday, September 04, 2001 2:10 AM Subject: RE: [Diffserv] new droppers,new meters Vincent, AFAIK the following documents define metering and marking schemes suitable for AF: * RFC 2697 "Single Rate Three Color Marking Scheme" * RFC 2698 "Two Rate Three Color Marking Scheme" * RFC 2859 "A Time Sliding Window Three Colour Marker". Hopefully this note will be useful. Sorry for using HTML in ths message. _____ With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: Vincent Wang [mailto:nsdos@etang.com] Sent: Tuesday, September 04, 2001 4:12 AM To: DiffServ@ietf.org Subject: [Diffserv] new droppers,new meters I have read a lot of things about DiffServ, including all related RFCs and papers. But I do not find any clue for AF's DiffServ. In AF's DiffServ, its real meaning is that Diff-macro flows receive Diff-macro flows treatment; But the Difference Metrics between these Different macro flows is never stated. So DiffServ is just a framework for macro flows treatment. If we want to get really meaningful thing ,such as different macro flows getting better QoS(low latency, high throughput and low jitter),we must deploy new mechanism ( new droppers,new meters) . Am I right? ------_=_NextPart_001_01C13636.7BAF3B60 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
 
You=20 should change the DSCP as well.
 
-Shahram
-----Original Message-----
From: Krishna = Gundamaraju=20 [mailto:krishna.gundamaraju@kenetec.com]
Sent: Wednesday, = September=20 05, 2001 1:51 PM
To: Sasha Vainshtein; 'Vincent Wang';=20 DiffServ@ietf.org
Subject: Re: [Diffserv] new droppers,new=20 meters

Hi,
 
    I have a = basic question.=20 The RFC 2697 while explaining the operation in the color aware mode = says that=20 the color of the incoming packets may be changed based on its notion = of=20 tokens. My question is should we also change the DSCP byte = accordingly when=20 changing the color? Or this change in color has only local = significance and=20 the DSCP byte should be left unchanged? Please = clarify.
 
    Thanks in = advance
 
Krishna G
 
----- Original Message -----
From:=20 Sasha=20 Vainshtein
To: 'Vincent Wang' ; DiffServ@ietf.org
Sent: Tuesday, September 04, = 2001 2:10=20 AM
Subject: RE: [Diffserv] new=20 droppers,new meters

Vincent,
AFAIK the following documents define = metering and=20 marking schemes suitable for AF:
  • RFC 2697 "Single=20 Rate Three Color Marking Scheme"=20
  • RFC 2698 "Two=20 Rate Three Color Marking Scheme"=20
  • RFC 2859 "A=20 Time Sliding Window Three Colour = Marker".
Hopefully this note will be=20 useful.
Sorry for using HTML in ths=20 message.
With best regards,
          &nb= sp;           &nb= sp;           =20 Sasha = Vainshtein
email:     sasha@axerra.com
tel:       +972-3-7659993=20 (office)
          =20 +972-8-9254948 (res.)
          =20 +972-58-674833 (cell.)
 
-----Original Message-----
From: Vincent Wang=20 [mailto:nsdos@etang.com]
Sent: Tuesday, September 04, = 2001 4:12=20 AM
To: DiffServ@ietf.org
Subject: [Diffserv] = new=20 droppers,new meters

I have read a lot of things about DiffServ, including all = related

RFCs and papers. But I do not find any clue for AF's = DiffServ.

In AF's DiffServ, its real meaning is that Diff-macro = flows

receive Diff-macro flows treatment; But the Difference Metrics =

between these Different macro flows is never stated.

So DiffServ is just a framework for macro flows treatment. If =

we want to get really meaningful thing ,such as different = macro

flows getting better QoS(low latency, high throughput and = low

jitter),we must deploy new mechanism ( new droppers,new = meters)

.

Am I = right?

------_=_NextPart_001_01C13636.7BAF3B60-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 6 18:41:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10596 for ; Thu, 6 Sep 2001 18:41:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07180; Thu, 6 Sep 2001 18:19:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07149 for ; Thu, 6 Sep 2001 18:19:29 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10163 for ; Thu, 6 Sep 2001 18:18:02 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f86MJ7p14137; Thu, 6 Sep 2001 15:19:07 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f86MIuq10590; Thu, 6 Sep 2001 15:18:56 -0700 (PDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id PAA15793; Thu, 6 Sep 2001 15:18:55 -0700 (PDT) Message-Id: <5.1.0.14.2.20010906142651.01f4e520@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Sep 2001 15:12:32 -0700 To: "Wijnen, Bert (Bert)" From: Fred Baker Subject: Re: [Diffserv] DiffServ MIB rev 12 review Cc: diffserv@ietf.org In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0D56323A@nl0006exch002u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 05:08 AM 9/2/2001, Wijnen, Bert (Bert) wrote: >13. You seem to have discontinuity timestamps (like the > diffServCountActDisconTime) per row. Is this really > what you want? I don't think I have ever seen it > implemented at the row level. I don't think that that > is what we intended discontinuity timers for either. > It seems to add an extra object to each row while I > wonder if discontinuity indeed > - happens often > - if it does happen, does it then only apply to > one row, or does it apply to multiple or possibly > all rows in the table. > A discontinuity timer per table or per MIB is what > we have seen more often. > > This has been done in a few more tables, so it applies > to them as well. Willing enough to move it to the table (right beside ...NextFree) or to the MIB level. It seems, though, that this makes an assumption about the operating system which is problematic. If the architecture of a single CPU which controls and manages a few devices - the usual low-end router design - fine. If you have a distributed system, in which you can pull out interface cards or add new ones, which themselves implement the forwarding, the diffserv processing, and by the way the counters, a discontinuity timestamp for the table or MIB seems to not serve. before writing this, though, I did a bunch of research. What would you think of copying the 802.3 MIB's approach? From RFC 2665's dot3StatsAlignmentErrors: ... Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 6 19:10:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11386 for ; Thu, 6 Sep 2001 19:10:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09035; Thu, 6 Sep 2001 19:01:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08973 for ; Thu, 6 Sep 2001 19:01:09 -0400 (EDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11044 for ; Thu, 6 Sep 2001 18:59:43 -0400 (EDT) Received: from ANDREWHOME (user-vcauogd.dsl.mindspring.com [216.175.98.13]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id QAA10442; Thu, 6 Sep 2001 16:01:05 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Fred Baker" , "Wijnen, Bert \(Bert\)" Cc: Subject: RE: [Diffserv] DiffServ MIB rev 12 review Date: Thu, 6 Sep 2001 16:21:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <5.1.0.14.2.20010906142651.01f4e520@mira-sjcm-2.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I thought that, when we originally discussed this, that we wanted to have discontinuity indicators at the interface level, but I don't recall why we decided not to do that. I agree with Fred that per-MIB or per-table is not sufficient and I agree with Bert that per-row seems like overkill. Another alternative might be to tie this to the entity MIB e.g. with an OID-pointer - I remember discussing that with some people at one of the early snmpconf meetings but the feeling seemd to be that entity MIB was not implemented widely-enough for this to be viable. Is this something for a new "Discontinuity Indicator MIB"? Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Fred Baker Sent: Thursday, September 06, 2001 3:13 PM To: Wijnen, Bert (Bert) Cc: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ MIB rev 12 review At 05:08 AM 9/2/2001, Wijnen, Bert (Bert) wrote: >13. You seem to have discontinuity timestamps (like the > diffServCountActDisconTime) per row. Is this really > what you want? I don't think I have ever seen it > implemented at the row level. I don't think that that > is what we intended discontinuity timers for either. > It seems to add an extra object to each row while I > wonder if discontinuity indeed > - happens often > - if it does happen, does it then only apply to > one row, or does it apply to multiple or possibly > all rows in the table. > A discontinuity timer per table or per MIB is what > we have seen more often. > > This has been done in a few more tables, so it applies > to them as well. Willing enough to move it to the table (right beside ...NextFree) or to the MIB level. It seems, though, that this makes an assumption about the operating system which is problematic. If the architecture of a single CPU which controls and manages a few devices - the usual low-end router design - fine. If you have a distributed system, in which you can pull out interface cards or add new ones, which themselves implement the forwarding, the diffserv processing, and by the way the counters, a discontinuity timestamp for the table or MIB seems to not serve. before writing this, though, I did a bunch of research. What would you think of copying the 802.3 MIB's approach? From RFC 2665's dot3StatsAlignmentErrors: ... Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 6 20:01:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12489 for ; Thu, 6 Sep 2001 20:01:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10667; Thu, 6 Sep 2001 19:45:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10636 for ; Thu, 6 Sep 2001 19:45:00 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12073 for ; Thu, 6 Sep 2001 19:43:33 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f86Nimv16898; Thu, 6 Sep 2001 16:44:48 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f86NiQ125831; Thu, 6 Sep 2001 16:44:26 -0700 (PDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id QAA27762; Thu, 6 Sep 2001 16:44:26 -0700 (PDT) Message-Id: <5.1.0.14.2.20010906155804.0206cec8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Sep 2001 16:02:17 -0700 To: "Wijnen, Bert (Bert)" , diffserv@ietf.org From: Fred Baker Subject: Re: [Diffserv] DiffServ MIB rev 12 review In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0D56323A@nl0006exch002u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 05:08 AM 9/2/2001, Wijnen, Bert (Bert) wrote: >15. Is zero a valid value for diffServShapingRateLevel, and > if so does that have a special meaning? > If not, then must exclude zero via a range specification. OK, so most shapers are single rate or dual rate; I can see having three or four rates, though I'm not sure why one would do that. It seems I have a choice of ranges for this: 1..2 (differentiates between a single and dual rate shaper, precludes ever doing anything else) 1..2147483647 (leaves plenty of room for future creativity...) 1..something else I'm putting 1..32, on the theory that 1..2 would be enough but leaving 32 levels leaves plenty of rope for those inclined to hang themselves. Any issues, or other opinions? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 7 05:17:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04689 for ; Fri, 7 Sep 2001 05:17:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02031; Fri, 7 Sep 2001 04:55:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02000 for ; Fri, 7 Sep 2001 04:55:14 -0400 (EDT) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04429 for ; Fri, 7 Sep 2001 04:53:45 -0400 (EDT) From: Asim.Khan@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id JAA23039; Fri, 7 Sep 2001 09:54:42 +0100 (BST) Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 07 Sep 2001 09:50:45 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Sep 2001 09:48:56 +0100 Message-Id: To: diffserv@ietf.org Date: Fri, 7 Sep 2001 09:48:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Behaviour of different flows in Diffserv network Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi All, I have this question regarding a situation when the different flows are aggregated at the Diffserv network edge with similar constraints. They get allocated a particular DSCP to receice a treatment through the diffserv network. What would happen lets say that there is a mixture of TCP and UDP flows in that aggregate and they hit congestion. What effect would it have on those indivdual flows though part of an aggregate but under congestion situation TCP and UDP flow behave differently. Regards Asim Vodafone _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 7 05:39:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05003 for ; Fri, 7 Sep 2001 05:39:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02827; Fri, 7 Sep 2001 05:20:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02797 for ; Fri, 7 Sep 2001 05:20:24 -0400 (EDT) Received: from givenchy (IDENT:postfix@mailhost.6wind.com [212.234.238.114]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04702 for ; Fri, 7 Sep 2001 05:18:55 -0400 (EDT) Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy (Postfix) with ESMTP id 2818B7E0; Fri, 7 Sep 2001 11:27:21 +0200 (CEST) Received: from 6wind.com (6bunny.6wind.com [10.0.0.115]) by intranet.6wind.com (Postfix) with ESMTP id 9F54EB51E; Fri, 7 Sep 2001 11:19:46 +0200 (CEST) Message-ID: <3B989183.943E1CED@6wind.com> Date: Fri, 07 Sep 2001 11:21:07 +0200 From: Christophe Gouault Organization: 6WIND X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: fr,en MIME-Version: 1.0 To: Asim.Khan@vf.vodafone.co.uk Cc: diffserv@ietf.org Subject: Re: [Diffserv] Behaviour of different flows in Diffserv network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Asim.Khan@vf.vodafone.co.uk wrote: > Hi All, > I have this question regarding a situation when the different flows are > aggregated at the Diffserv network edge with similar constraints. They get > allocated a particular DSCP to receice a treatment through the diffserv > network. What would happen lets say that there is a mixture of TCP and UDP > flows in that aggregate and they hit congestion. What effect would it have > on those indivdual flows though part of an aggregate but under congestion > situation TCP and UDP flow behave differently. > > Regards > Asim > Vodafone > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html Hi Asim, IMHO, since TCP and UDP behave differently in congestion situations, they shouldn't be aggregated in the same class of service. Only flows with similar constraints should be aggregated. Christophe. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 7 08:35:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10034 for ; Fri, 7 Sep 2001 08:35:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07654; Fri, 7 Sep 2001 08:20:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07625 for ; Fri, 7 Sep 2001 08:20:42 -0400 (EDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09138 for ; Fri, 7 Sep 2001 08:19:14 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA08920; Fri, 7 Sep 2001 07:18:25 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87CKYu261792; Fri, 7 Sep 2001 08:20:39 -0400 Importance: Normal Subject: RE: [Diffserv] DiffServ MIB rev 12 review To: Cc: "Fred Baker" , "Wijnen, Bert \(Bert\)" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Fri, 7 Sep 2001 08:33:38 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 09/07/2001 08:20:39 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org First, I agree with Fred and Andrew that since the entries in the DiffServ MIB tables encompass all the interfaces in the box, with just simple integer indexes, a per-MIB or per-table discontinuity indicator just isn't going to be sufficient. At one point I think at least some of the counters were tied to ifCounterDiscontinuityTime, and that's when I raised the question of whether it's possible to change an interface's DiffServ datapath configuration without taking the interface down to make the change. If this is possible, then I don't think that ifCounterDiscontinuityTime is sufficient. Suppose, for example, that because of a change in Classifier configuration, a point in the datapath that used to see packets with DSCP 10 now sees packets with DSCPs 20-30. If the element at this point in the datapath is a counter, it's nonsense for a management application to take a delta between the counter value at some time before the configuration change and its value at some time after the change, since this will combine counts of two different classes of packets. So there needs to be a way to tell the application not to take this delta. I'm also not sure about Bert's statement that per-row discontinuity indicators are unusual. Certainly ifCounterDiscontinuityTime is a per-row object, and we defined several more such objects back when we were doing the SNA MIBs. I think we should just think through the circumstances in which we need for the agent to tell the management application "Don't take a delta!", and then let the discontinuity indicators fall wherever they fall. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrew Smith" @ietf.org on 09/06/2001 07:21:19 PM Please respond to Sent by: diffserv-admin@ietf.org To: "Fred Baker" , "Wijnen, Bert \(Bert\)" cc: Subject: RE: [Diffserv] DiffServ MIB rev 12 review I thought that, when we originally discussed this, that we wanted to have discontinuity indicators at the interface level, but I don't recall why we decided not to do that. I agree with Fred that per-MIB or per-table is not sufficient and I agree with Bert that per-row seems like overkill. Another alternative might be to tie this to the entity MIB e.g. with an OID-pointer - I remember discussing that with some people at one of the early snmpconf meetings but the feeling seemd to be that entity MIB was not implemented widely-enough for this to be viable. Is this something for a new "Discontinuity Indicator MIB"? Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Fred Baker Sent: Thursday, September 06, 2001 3:13 PM To: Wijnen, Bert (Bert) Cc: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ MIB rev 12 review At 05:08 AM 9/2/2001, Wijnen, Bert (Bert) wrote: >13. You seem to have discontinuity timestamps (like the > diffServCountActDisconTime) per row. Is this really > what you want? I don't think I have ever seen it > implemented at the row level. I don't think that that > is what we intended discontinuity timers for either. > It seems to add an extra object to each row while I > wonder if discontinuity indeed > - happens often > - if it does happen, does it then only apply to > one row, or does it apply to multiple or possibly > all rows in the table. > A discontinuity timer per table or per MIB is what > we have seen more often. > > This has been done in a few more tables, so it applies > to them as well. Willing enough to move it to the table (right beside ...NextFree) or to the MIB level. It seems, though, that this makes an assumption about the operating system which is problematic. If the architecture of a single CPU which controls and manages a few devices - the usual low-end router design - fine. If you have a distributed system, in which you can pull out interface cards or add new ones, which themselves implement the forwarding, the diffserv processing, and by the way the counters, a discontinuity timestamp for the table or MIB seems to not serve. before writing this, though, I did a bunch of research. What would you think of copying the 802.3 MIB's approach? From RFC 2665's dot3StatsAlignmentErrors: ... Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 7 12:20:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAB18945 for ; Fri, 7 Sep 2001 12:20:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15409; Fri, 7 Sep 2001 11:55:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15381 for ; Fri, 7 Sep 2001 11:55:52 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18017 for ; Fri, 7 Sep 2001 11:54:24 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f87FtZv22615; Fri, 7 Sep 2001 08:55:35 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f87FtEU16825; Fri, 7 Sep 2001 08:55:14 -0700 (PDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA24562; Fri, 7 Sep 2001 08:55:13 -0700 (PDT) Message-Id: <5.1.0.14.2.20010907084248.04010228@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Sep 2001 08:46:04 -0700 To: "Robert Moore" From: Fred Baker Subject: RE: [Diffserv] DiffServ MIB rev 12 review Cc: , "Wijnen, Bert \(Bert\)" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 05:33 AM 9/7/2001, Robert Moore wrote: >At one point I think at least some of the counters >were tied to ifCounterDiscontinuityTime, and that's >when I raised the question of whether it's possible >to change an interface's DiffServ datapath >configuration without taking the interface down to >make the change. If this is possible, then I don't >think that ifCounterDiscontinuityTime is sufficient. I think this is a very difficult case, and I'm not sure what discontinuity timer to apply at all, except perhaps one for the entire MIB that says "something changed", as in a configuration event occurred which may or may not be relevant to any given counter. Putting a timestamp on each row doesn't handle it, because you're postulating that the change was that some other row was created and pointed at the row in question, which the row may not know anything about. How would you suggest we handle it? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 7 13:21:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21121 for ; Fri, 7 Sep 2001 13:21:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18194; Fri, 7 Sep 2001 12:55:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18159 for ; Fri, 7 Sep 2001 12:55:17 -0400 (EDT) Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20291 for ; Fri, 7 Sep 2001 12:53:50 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA26484; Fri, 7 Sep 2001 11:53:01 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87GtFu107432; Fri, 7 Sep 2001 12:55:15 -0400 Importance: Normal Subject: RE: [Diffserv] DiffServ MIB rev 12 review To: Fred Baker Cc: , "Wijnen, Bert \(Bert\)" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Fri, 7 Sep 2001 13:08:20 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 09/07/2001 12:55:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org You're right - it's going to be very difficult for an agent to determine which row-level indicators to reset for a given configuration change. But what do we expect a management application to do? We've set up an architecture that says "It's OK to compute deltas for a counter, and treat them as valid management data, unless a designated discontinuity indicator tells you otherwise." So maybe we do have to fall back to a MIB-level indicator that's updated every time anything in the entire DiffServ configuration changes. Each time there's a config change this will result in a lot of false positives, where valid deltas for counters unrelated to the change are treated as invalid. But this is preferable to a false negative, where we allow the management application to treat as valid a delta that is in fact invalid. So, whether or not you intended to, I think you've talked me into a single MIB-level discontinuity indicator for all the DiffServ counters in the device. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com Fred Baker @ietf.org on 09/07/2001 11:46:04 AM Sent by: diffserv-admin@ietf.org To: Robert Moore/Raleigh/IBM@IBMUS cc: , "Wijnen, Bert \(Bert\)" , Subject: RE: [Diffserv] DiffServ MIB rev 12 review At 05:33 AM 9/7/2001, Robert Moore wrote: >At one point I think at least some of the counters >were tied to ifCounterDiscontinuityTime, and that's >when I raised the question of whether it's possible >to change an interface's DiffServ datapath >configuration without taking the interface down to >make the change. If this is possible, then I don't >think that ifCounterDiscontinuityTime is sufficient. I think this is a very difficult case, and I'm not sure what discontinuity timer to apply at all, except perhaps one for the entire MIB that says "something changed", as in a configuration event occurred which may or may not be relevant to any given counter. Putting a timestamp on each row doesn't handle it, because you're postulating that the change was that some other row was created and pointed at the row in question, which the row may not know anything about. How would you suggest we handle it? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 7 14:36:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23478 for ; Fri, 7 Sep 2001 14:36:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21413; Fri, 7 Sep 2001 14:14:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21382 for ; Fri, 7 Sep 2001 14:14:28 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22631 for ; Fri, 7 Sep 2001 14:13:00 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f87IDox00116; Fri, 7 Sep 2001 11:13:50 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f87IDn811818; Fri, 7 Sep 2001 11:13:49 -0700 (PDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA11593; Fri, 7 Sep 2001 11:13:47 -0700 (PDT) Message-Id: <5.1.0.14.2.20010907102527.03a99b28@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Sep 2001 11:11:15 -0700 To: "Robert Moore" From: Fred Baker Subject: RE: [Diffserv] DiffServ MIB rev 12 review Cc: , "Wijnen, Bert \(Bert\)" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 10:08 AM 9/7/2001, Robert Moore wrote: >So, whether or not you intended to, I think you've >talked me into a single MIB-level discontinuity >indicator for all the DiffServ counters in the device. any other opinions? I don't know that I see a lot of other MIBs whose discontinuity timestamps try to keep track of not-directly-related configuration changes. It seems to me that it is perhaps too hard of a problem to solve, and that it is actually not a discontinuity in the sense that the term is generally used. Other usages of discontinuity timers relate to adding and removing interfaces, restarting processes, and so on, not reconfigurations. I could argue that the counters in the count action may start counting more stuff if they are fed more traffic, but they will invariably have counted the stuff that went by them, both before and after. This is not a discontinuity of the counter, but a change in what it is fed. It is analogous to an interface going up or down, or the traffic crossing it being changed by a change in routing. The counter ifInOctets has not seen a discontinuity, but its rate of change is certainly different because it is being fed more traffic. In fact, the more I think about it, I *do* argue that. I think the proper use of a discontinuity timestamp is to know when the counter may have missed something it was legitimately fed, not when the feed to it changed. I think I have argued myself into believing that the Interface's discontinuity timestamp is exactly the right discontinuity indicator. Comparison documents (every current MIB I see that has a discontinuity timestamp, plus the SMI comments on discontinuity timestamps): http://www.ietf.org/rfc/rfc2021.txt 2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2. S. Waldbusser. January 1997. (Format: TXT=262223 bytes) (Status: US:) (Status: PROPOSED STANDARD) LastCreateTime ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes an object that stores the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data." SYNTAX TimeStamp http://www.ietf.org/rfc/rfc2562.txt 2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB). K. White, R. Moore. April 1999. (Format: TXT=110633 bytes) (Status: US:) (Status: PROPOSED STANDARD) The sliding transaction counter AvgCountTrans is not used for updating the MIB object tn3270eRtDataCountTrans: this object is an ordinary SMI Counter32, which maintains a total count of transactions since its last discontinuity event. The sliding counters are used only for calculating averages. A discontinuity object, tn3270eRtDataDiscontinuityTime, can be used by a management application to detect when the values of the counter objects in this table may have been reset, or otherwise experienced a discontinuity. A possible cause for such a discontinuity is the TN3270E server's being stopped or restarted. This object returns a meaningful value regardless of which collection control options were selected. tn3270eRtDataDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which one or more of this entry's counter objects suffered a discontinuity. This may happen if a TN3270E server is stopped and then restarted, and local methods are used to set up collection policy (tn3270eRtCollCtlTable entries)." ::= { tn3270eRtDataEntry 20 } http://www.ietf.org/rfc/rfc2564.txt 2564 Application Management MIB. C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia. May 1999. (Format: TXT=183314 bytes) (Status: US:) (Status: PROPOSED STANDARD) Since rows in most of these tables will come and go with the running application elements whose information is contained in them, sysUpTime.0 is not appropriate as a discontinuity indicator for counters in these tables. By defining separate discontinuity indicators for the rows in these tables, entries can come and go as needed without causing other objects to appear to have discontinuities. As required by [15], the discontinuity indicators for the various information objects in these tables are identified in the relevant DESCRIPTION clauses. Note that a discontinuity in one of these counters does not imply a sysUpTime.0 discontinuity, nor does a sysUpTime.0 discontinuity imply a discontinuity in any of these counters. applOpenChannelOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute records the value of sysUpTime.0 when this channel was opened and this entry was added to this table. This attribute serves as a discontinuity indicator for the counter attributes in this entry and for any corresponding entries in the applOpenConnectionTable, applOpenFileTable, and the applTransactionStreamTable." ::= { applOpenChannelEntry 4 } the corresponding (same value for applElmtOrSvc, applElmtOrSvcId, and applOpenChannelIndex) applOpenChannelOpenTime object serves as a discontinuity indicator. " INDEX { applElmtOrSvc, applElmtOrSvcId, applOpenChannelIndex, applTransactFlowDirection, applTransactFlowReqRsp } ::= { applTransactFlowTable 1 } http://www.ietf.org/rfc/rfc2578.txt 2578 Structure of Management Information Version 2 (SMIv2). K. McCloghrie, D. Perkins, J. Schoenwaelder. April 1999. (Format: TXT=89712 bytes) (Obsoletes RFC1902) (Also STD0058) (Status: US:) (Status: STANDARD) Counters have no defined "initial" value, and thus, a single value of a Counter has (in general) no information content. Discontinuities in the monotonically increasing value normally occur at re- initialization of the management system, and at other times as specified in the description of an object-type using this ASN.1 type. If such other times can occur, for example, the creation of an object instance at times other than re-initialization, then a corresponding object should be defined, with an appropriate SYNTAX clause, to indicate the last discontinuity. Examples of appropriate SYNTAX clause include: TimeStamp (a textual convention defined in [3]), DateAndTime (another textual convention from [3]) or TimeTicks. (paragraph occurs twice, almost verbatim) http://www.ietf.org/rfc/rfc2863.txt 2863 The Interfaces Group MIB. K. McCloghrie, F. Kastenholz. June 2000. (Format: TXT=155014 bytes) (Obsoletes RFC2233) (Status: US:) (Status: DRAFT STANDARD) When the new interface is the same as an old interface, but a discontinuity in the value of the interface's counters cannot be avoided, the ifTable has (until now) required that a new ifIndex value be assigned to the returning interface. That is, either all counter values have had to be retained during the absence of an interface in order to use the same ifIndex value on that interface's return, or else a new ifIndex value has had to be assigned to the returning interface. Both alternatives have proved to be burdensome to some implementations: To address this, a new object, ifCounterDiscontinuityTime, has been defined to record the time of the last discontinuity in an interface's counters. By monitoring the value of this new object, a management application can now detect counter discontinuities without the ifIndex value of the interface being changed. Thus, an agent which implements this new object should, when a new interface is the same as an old interface, retain that interface's ifIndex value and update if necessary the interface's value of ifCounterDiscontinuityTime. With this new object, a management application must, when calculating differences between counter values retrieved on successive polls, discard any calculated difference for which the value of ifCounterDiscontinuityTime is different for the two polls. (Note that this test must be performed in addition to the normal checking of sysUpTime to detect an agent re-initialization.) Since such discards are a waste of network management processing and bandwidth, an agent should not update the value of ifCounterDiscontinuityTime unless absolutely necessary. Note, however, that the addition of ifCounterDiscontinuityTime does not change the fact that: the following paragraph shows up in each counter's DESCRIPTION in the Interface MIB: Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." http://www.ietf.org/rfc/rfc2981.txt 2981 Event MIB. R. Kavasseri (Editor of this version). October 2000. (Format: TXT=98248 bytes) (Status: US:) (Status: PROPOSED STANDARD) mteTriggerDeltaDiscontinuityID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or DateAndTime object that indicates a discontinuity in the value at mteTriggerValueID. This object supports normal checking for a discontinuity in a counter. Note that if this object does not point to sysUpTime discontinuity checking MUST still check sysUpTime for an overall discontinuity. Bad object identifiers or a mismatch between truncating the identifier and the value of mteDeltaDiscontinuityIDWildcard result in operation as one would expect when providing the wrong identifier to a Get operation. The Get will fail or get the wrong object. If the value syntax of those objects is not usable, that results in an error that terminates the sample with a 'badType' error code." DEFVAL { sysUpTimeInstance } ::= { mteTriggerDeltaEntry 1 } mteTriggerDeltaDiscontinuityIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether mteTriggerDeltaDiscontinuityID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard. Note that the value of this object will be the same as that of the corresponding instance of mteTriggerValueIDWildcard when the corresponding mteTriggerDeltaDiscontinuityIDType OBJECT-TYPE SYNTAX INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value 'timeTicks' indicates the mteTriggerDeltaDiscontinuityID of this row is of syntax TimeTicks. The value 'timeStamp' indicates syntax TimeStamp. The value 'dateAndTime' indicates syntax DateAndTime." DEFVAL { timeTicks } ::= { mteTriggerDeltaEntry 3 } Bad object identifiers or a mismatch between truncating the identifier and the value of mteDeltaDiscontinuityIDWildcard result in operation as one would expect when providing the wrong identifier to a Get operation. The Get will fail or get the wrong object. If the object is not available it is omitted from the notification." ::= { mteObjectsEntry 2 } http://www.ietf.org/rfc/rfc2982.txt 2982 Distributed Management Expression MIB. R. Kavasseri (Editor of this version). October 2000. (Format: TXT=81371 bytes) (Status: US:) (Status: PROPOSED STANDARD) The interface-specific discontinuity indicator is supplied only for ifInOctets since invalidating that sample will invalidate an attempt at evaluation, effectively invalidating ifOutOctets as well (correctly, because it has the same indicator). http://www.ietf.org/rfc/rfc3014.txt 3014 Notification Log MIB. R. Kavasseri. November 2000. (Format: TXT=48287 bytes) (Status: US:) (Status: PROPOSED STANDARD) The log contains the Notifications and the objects that came in their variable binding list, indexed by an integer that reflects when the entry was made. An application that wants to collect all logged Notifications or to know if it may have missed any can keep track of the highest index it has retrieved and start from there on its next poll, checking sysUpTime for a discontinuity that would have reset the index and perhaps have lost entries. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 7 15:29:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25603 for ; Fri, 7 Sep 2001 15:29:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23956; Fri, 7 Sep 2001 15:13:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23928 for ; Fri, 7 Sep 2001 15:13:15 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25213 for ; Fri, 7 Sep 2001 15:11:47 -0400 (EDT) Received: from KGUNDAMARAJU ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id AEI81756; Fri, 7 Sep 2001 15:12:38 -0400 (EDT) Message-ID: <001801c137d1$9ee9cea0$6200a8c0@KGUNDAMARAJU> From: "Krishna Gundamaraju" To: References: Date: Fri, 7 Sep 2001 15:16:39 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C137B0.17A73390" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Diffserv] DiffServ Classes to 802.1 P mapping Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C137B0.17A73390 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Hi, Does DiffServ recommend any 802.1P values for each of the PHBs? = Please clarify and point me to the appropriate reference. Thanks in advance. Krishna G ----- Original Message -----=20 From: Sasha Vainshtein=20 To: 'Vincent Wang' ; DiffServ@ietf.org=20 Sent: Tuesday, September 04, 2001 2:10 AM Subject: RE: [Diffserv] new droppers,new meters Vincent, AFAIK the following documents define metering and marking schemes = suitable for AF: a.. RFC 2697 "Single Rate Three Color Marking Scheme"=20 b.. RFC 2698 "Two Rate Three Color Marking Scheme"=20 c.. RFC 2859 "A Time Sliding Window Three Colour Marker". Hopefully this note will be useful. Sorry for using HTML in ths message. -------------------------------------------------------------------------= ----- With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: Vincent Wang [mailto:nsdos@etang.com] Sent: Tuesday, September 04, 2001 4:12 AM To: DiffServ@ietf.org Subject: [Diffserv] new droppers,new meters I have read a lot of things about DiffServ, including all related RFCs and papers. But I do not find any clue for AF's DiffServ. In AF's DiffServ, its real meaning is that Diff-macro flows receive Diff-macro flows treatment; But the Difference Metrics=20 between these Different macro flows is never stated. So DiffServ is just a framework for macro flows treatment. If=20 we want to get really meaningful thing ,such as different macro flows getting better QoS(low latency, high throughput and low jitter),we must deploy new mechanism ( new droppers,new meters) . Am I right? ------=_NextPart_000_0015_01C137B0.17A73390 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
Hi,
 
    Does DiffServ = recommend any=20 802.1P values for each of the PHBs? Please clarify and point me to the=20 appropriate reference.
 
    Thanks in = advance.
 
Krishna G
----- Original Message -----
From:=20 Sasha = Vainshtein=20
Sent: Tuesday, September 04, = 2001 2:10=20 AM
Subject: RE: [Diffserv] new = droppers,new=20 meters

Vincent,
AFAIK the following documents define = metering and=20 marking schemes suitable for AF:
  • RFC=20 2697 "Single=20 Rate Three Color Marking Scheme"=20
  • RFC=20 2698 "Two=20 Rate Three Color Marking Scheme"=20
  • RFC=20 2859 "A=20 Time Sliding Window Three Colour = Marker".
Hopefully this note will be=20 useful.
Sorry for using HTML in ths=20 message.
With best regards,
          &nbs= p;            = ;           =20 Sasha = Vainshtein
email:     sasha@axerra.com
=
tel:       +972-3-7659993=20 (office)
          =20 +972-8-9254948 (res.)
          =20 +972-58-674833 (cell.)
 
-----Original Message-----
From: Vincent Wang=20 [mailto:nsdos@etang.com]
Sent: Tuesday, September 04, 2001 = 4:12=20 AM
To: DiffServ@ietf.org
Subject: [Diffserv] new = droppers,new meters

I have read a lot of things about DiffServ, including all = related

RFCs and papers. But I do not find any clue for AF's = DiffServ.

In AF's DiffServ, its real meaning is that Diff-macro flows

receive Diff-macro flows treatment; But the Difference Metrics =

between these Different macro flows is never stated.

So DiffServ is just a framework for macro flows treatment. If =

we want to get really meaningful thing ,such as different = macro

flows getting better QoS(low latency, high throughput and low

jitter),we must deploy new mechanism ( new droppers,new = meters)

.

Am I right?

------=_NextPart_000_0015_01C137B0.17A73390-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 7 15:59:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26313 for ; Fri, 7 Sep 2001 15:59:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25453; Fri, 7 Sep 2001 15:45:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25428 for ; Fri, 7 Sep 2001 15:45:10 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25978 for ; Fri, 7 Sep 2001 15:43:41 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f87JhL279733; Fri, 7 Sep 2001 12:43:21 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3B992530.62A3A1D9@packetdesign.com> Date: Fri, 07 Sep 2001 12:51:12 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Asim.Khan@vf.vodafone.co.uk CC: diffserv@ietf.org Subject: Re: [Diffserv] Behaviour of different flows in Diffserv network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Asim.Khan@vf.vodafone.co.uk wrote: > > Hi All, > I have this question regarding a situation when the different flows are > aggregated at the Diffserv network edge with similar constraints. They get > allocated a particular DSCP to receice a treatment through the diffserv > network. What would happen lets say that there is a mixture of TCP and UDP > flows in that aggregate and they hit congestion. What effect would it have > on those indivdual flows though part of an aggregate but under congestion > situation TCP and UDP flow behave differently. > This is a critical element to *doing* diffserv that some of us have emphasized from the start. If you cannot structure the rules for aggregating the traffic such that the traffic is treated "sensibly", then you'd better go back to the drawing board to come up with something else. I think Brian and I tried to capture this importance concern in RFC3086 for defining the Per-Domain Behaviors. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 7 16:06:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26518 for ; Fri, 7 Sep 2001 16:06:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25883; Fri, 7 Sep 2001 15:55:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25852 for ; Fri, 7 Sep 2001 15:55:37 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26204 for ; Fri, 7 Sep 2001 15:54:09 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f87Jstv21255; Fri, 7 Sep 2001 12:54:55 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f87JsXn26963; Fri, 7 Sep 2001 12:54:33 -0700 (PDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id MAA29885; Fri, 7 Sep 2001 12:54:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20010907125339.03a4f428@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Sep 2001 12:54:08 -0700 To: "Krishna Gundamaraju" From: Fred Baker Subject: Re: [Diffserv] DiffServ Classes to 802.1 P mapping Cc: In-Reply-To: <001801c137d1$9ee9cea0$6200a8c0@KGUNDAMARAJU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 12:16 PM 9/7/2001, Krishna Gundamaraju wrote: > Does DiffServ recommend any 802.1P values for each of the PHBs? > Please clarify and point me to the appropriate reference. we discussed that at one point, but no current proposal is before the house. You might suggest one... _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 7 18:25:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00252 for ; Fri, 7 Sep 2001 18:25:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00556; Fri, 7 Sep 2001 18:06:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00524 for ; Fri, 7 Sep 2001 18:06:51 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29866 for ; Fri, 7 Sep 2001 18:05:22 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA16790; Fri, 7 Sep 2001 23:06:19 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA48954; Fri, 7 Sep 2001 23:06:19 +0100 Message-ID: <3B9942BB.2F96C87@hursley.ibm.com> Date: Fri, 07 Sep 2001 16:57:15 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fred Baker CC: Krishna Gundamaraju , DiffServ@ietf.org Subject: Re: [Diffserv] DiffServ Classes to 802.1 P mapping References: <5.1.0.14.2.20010907125339.03a4f428@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Well, I believe that 802.1p was working on this (just as the ATM Forum was working on diffserv-to-ATM mappings, and MPLS is working on diffserv-to-MPLS mappings. So this has never been considered as in the scope of this WG. You have to be careful anyway. 802.1p supports crude priority, and diffserv behaviors are not priorities. Brian Fred Baker wrote: > > At 12:16 PM 9/7/2001, Krishna Gundamaraju wrote: > > Does DiffServ recommend any 802.1P values for each of the PHBs? > > Please clarify and point me to the appropriate reference. > > we discussed that at one point, but no current proposal is before the > house. You might suggest one... > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Sep 8 11:58:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27034 for ; Sat, 8 Sep 2001 11:58:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26364; Sat, 8 Sep 2001 11:37:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26266 for ; Sat, 8 Sep 2001 11:37:36 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26814 for ; Sat, 8 Sep 2001 11:36:07 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20108 for ; Sat, 8 Sep 2001 11:36:32 -0400 (EDT) Received: from itc-eml1.lannet.com (h149-49-38-51.avaya.com [149.49.38.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20089 for ; Sat, 8 Sep 2001 11:36:31 -0400 (EDT) Received: by ITC-EML1 with Internet Mail Service (5.5.2650.21) id ; Sat, 8 Sep 2001 18:36:19 +0300 Message-ID: <18609D34D984D31183780090279CF7E004980A50@ITC-EML1> From: Dan Romascanu To: Brian E Carpenter , Fred Baker Cc: Krishna Gundamaraju , DiffServ@ietf.org, Ran Ish-Shalom Subject: RE: [Diffserv] DiffServ Classes to 802.1 P mapping Date: Sat, 8 Sep 2001 18:36:17 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1387C.00876D20" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1387C.00876D20 Content-Type: text/plain; charset="iso-8859-8" I would doubt that there is any work in the IEEE 802.1 WG on this respect. This is not only because I did not hear about it from my colleagues attending this IEEE activity, but also because the IEEE 802 project tends to limit its scope to the 'lower' two layers, and its approach is typically generic, or other said agnostic relative to services carried by the layers 'above'. Regards, Dan > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, September 07, 2001 11:57 PM > To: Fred Baker > Cc: Krishna Gundamaraju; DiffServ@ietf.org > Subject: Re: [Diffserv] DiffServ Classes to 802.1 P mapping > > > Well, I believe that 802.1p was working on this (just as the ATM Forum > was working on diffserv-to-ATM mappings, and MPLS is working on > diffserv-to-MPLS mappings. So this has never been considered as > in the scope of this WG. > > You have to be careful anyway. 802.1p supports crude priority, and > diffserv behaviors are not priorities. > > Brian > > Fred Baker wrote: > > > > At 12:16 PM 9/7/2001, Krishna Gundamaraju wrote: > > > Does DiffServ recommend any 802.1P values for each of > the PHBs? > > > Please clarify and point me to the appropriate reference. > > > > we discussed that at one point, but no current proposal is > before the > > house. You might suggest one... > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html ------_=_NextPart_001_01C1387C.00876D20 Content-Type: text/html; charset="iso-8859-8" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DiffServ Classes to 802.1 P mapping

I would doubt that there is any work in the IEEE = 802.1 WG on this respect. This is not only because I did not hear about = it from my colleagues attending this IEEE activity, but also because = the IEEE 802 project tends to limit its scope to the 'lower' two = layers, and its approach is typically generic, or other said agnostic = relative to services carried by the layers 'above'.

Regards,

Dan
 

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
> Sent: Friday, September 07, 2001 11:57 = PM
> To: Fred Baker
> Cc: Krishna Gundamaraju; = DiffServ@ietf.org
> Subject: Re: [Diffserv] DiffServ Classes to = 802.1 P mapping
>
>
> Well, I believe that 802.1p was working on this = (just as the ATM Forum
> was working on diffserv-to-ATM mappings, and = MPLS is working on
> diffserv-to-MPLS mappings. So this has never = been considered as
> in the scope of this WG.
>
> You have to be careful anyway. 802.1p supports = crude priority, and
> diffserv behaviors are not priorities.
>
>   Brian
>
> Fred Baker wrote:
> >
> > At 12:16 PM 9/7/2001, Krishna Gundamaraju = wrote:
> > >     Does DiffServ = recommend any 802.1P values for each of
> the PHBs?
> > > Please clarify and point me to the = appropriate reference.
> >
> > we discussed that at one point, but no = current proposal is
> before the
> > house. You might suggest one...
> >
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> https://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
> http://www2.ietf.org/mail-archive/working-groups/diffs= erv/curr
ent/maillist.html

------_=_NextPart_001_01C1387C.00876D20-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Sep 8 15:46:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29002 for ; Sat, 8 Sep 2001 15:46:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01288; Sat, 8 Sep 2001 15:32:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01257 for ; Sat, 8 Sep 2001 15:32:48 -0400 (EDT) Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28821 for ; Sat, 8 Sep 2001 15:31:17 -0400 (EDT) Received: from [10.0.1.6] (ppp-206-170-32-35.snfc21.pacbell.net [206.170.32.35]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with ESMTP id f88JWcN40324; Sat, 8 Sep 2001 15:32:38 -0400 User-Agent: Microsoft-Entourage/9.0.2509 Date: Sat, 08 Sep 2001 12:32:40 -0700 Subject: Re: [Diffserv] DiffServ MIB rev 12 review From: Harrie Hazewinkel To: Fred Baker , Robert Moore CC: Andrew Smith , Bert Wijnen , IETF differintiated services Message-ID: In-Reply-To: <5.1.0.14.2.20010907102527.03a99b28@mira-sjcm-2.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit On 9/7/01 11:11, "Fred Baker" wrote: > At 10:08 AM 9/7/2001, Robert Moore wrote: >> So, whether or not you intended to, I think you've >> talked me into a single MIB-level discontinuity >> indicator for all the DiffServ counters in the device. > > any other opinions? No, I agree here with Fred's view. I believe it is more a decision on what is a counter discontinuity and what is a configuration change?? Below I have some examples for this. For some I already have 2 answers. 1) A counter element has a problem. - Yes, this is a discontinuity. 2) An agent has a problem and causes a discontinuity for the counters. Most likely it will be more then 1 counter. - Yes, this is discontinuity. 3) A classifier which this counter element feeds has a different range of DSCP values. Is this a discontinuity of the counter?? - No, the counter is not discontinued, but the configuration changed what is counted and the management application needs to learn this. - Yes, the traffic through the counter has changed and thus it is a discontinuity. 4) An extra element has the counter as the 'next element' causing the counter to have more traffic. Is this a discontinuity of the counter?? - No, the counter is not discontinued, but the configuration changed what is counted and the management application needs to learn this. - Yes, the traffic through the counter has changed and thus it is a discontinuity. 5) An interface has errors and therefore all traffic passing it influences the counters later in the data path. Is this a discontinuity of the counter?? - Yes, the data path as seen as 1 object (including counters) is discontinued. 6) (partial equal to 5) An error has happened in a data path element that feeds the counter. Is this a discontinuity?? - Yes, if the data path is seen as a complete object. IMHO, it is more a matter of what will we recognize as discontinuity and what is a configuration change?? As a possible solution I would suggest to get consensus on "what is a counter discontinuity??" and "what is a configuration change??". Then both need to be added to the draft. I also believe we cannot specify all possible cases and thus implementations will do this differently. The best we can do is provide guidance for implementors. Harrie > I don't know that I see a lot of other MIBs whose > discontinuity timestamps try to keep track of not-directly-related > configuration changes. It seems to me that it is perhaps too hard of a > problem to solve, and that it is actually not a discontinuity in the sense > that the term is generally used. Other usages of discontinuity timers > relate to adding and removing interfaces, restarting processes, and so on, > not reconfigurations. > > I could argue that the counters in the count action may start counting more > stuff if they are fed more traffic, but they will invariably have counted > the stuff that went by them, both before and after. This is not a > discontinuity of the counter, but a change in what it is fed. It is > analogous to an interface going up or down, or the traffic crossing it > being changed by a change in routing. The counter ifInOctets has not seen a > discontinuity, but its rate of change is certainly different because it is > being fed more traffic. > > In fact, the more I think about it, I *do* argue that. I think the proper > use of a discontinuity timestamp is to know when the counter may have > missed something it was legitimately fed, not when the feed to it changed. > I think I have argued myself into believing that the Interface's > discontinuity timestamp is exactly the right discontinuity indicator. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Sep 8 17:50:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00049 for ; Sat, 8 Sep 2001 17:50:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03479; Sat, 8 Sep 2001 17:32:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03448 for ; Sat, 8 Sep 2001 17:31:59 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29839 for ; Sat, 8 Sep 2001 17:30:30 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f88LVv909326 for ; Sat, 8 Sep 2001 17:31:57 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 8 Sep 2001 23:31:51 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D7159D8@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Harrie Hazewinkel , Fred Baker , Robert Moore Cc: Andrew Smith , IETF differintiated services Subject: RE: [Diffserv] DiffServ MIB rev 12 review Date: Sat, 8 Sep 2001 23:31:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I think the important things to consider are: - If we have diiscontinuity time per row, then a nm app will have to retrieve for all rows not only the counters, but also the discontinuity timer. So if it retries a table of counters, it also retries a lot of discontinuity timers It then has to check each of those timers, every time it obtains all these counter. Typically such NM apps do that say every 15 mins or so. In order to do the check, the NM app probably also keeps all these discontinuity timers. - If we have one discontinuity timer per table, then NM picks up the one discontinuity timer and the whole table of counters. It checks the discontinuity timer, and if not changed since last time, then all counter can be handled, if it changed, then all counters for that table start afresh (which may cause some loss of data for every counter). NM app needs to keep one discontinutity timer per table. - If we have one such timer for the whole MIB then the granularity is even more coarse So how often do these things happen? If only occasionally (say less than once a day), then I think one discontinuity timer per table or (if less than once a week) one per the whole MIB is fine. If they happen a lot (say once an hour) then maybe you want to go per row. I also think, that if because of some config change, some more (or less for that matter) data comes by at a specific counter, that such is not a discontinuity. But that is a personal opinion. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Sep 9 23:19:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19749 for ; Sun, 9 Sep 2001 23:19:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07477; Sun, 9 Sep 2001 22:58:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07454 for ; Sun, 9 Sep 2001 22:58:26 -0400 (EDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19436 for ; Sun, 9 Sep 2001 22:56:35 -0400 (EDT) Received: from ANDREWHOME (user-vcauogd.dsl.mindspring.com [216.175.98.13]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id TAA02481; Sun, 9 Sep 2001 19:57:59 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Krishna Gundamaraju" Cc: "P802.1" , Subject: RE: [Diffserv] DiffServ Classes to 802.1 P mapping Date: Sun, 9 Sep 2001 20:18:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3B9942BB.2F96C87@hursley.ibm.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Krishna, I don't believe IEEE 802.1 ever has looked at standardising how other upper layers map onto its own mechanisms: the 802 architecture just publishes a "service interface" to the upper layer to use as it sees fit. So an IETF group ought to look at the IP->IEEE802 mapping, if indeed it is a problem worthy of standardisation (the ISSLL WG looked into how to map IntServ architecture onto IEEE 802 networks in great and gory detail and there is much published material there that is also applicable to DiffServ - start at http://www.ietf.org/html.charters/issll-charter.html). I think it best this way around (but I wish the ATM and MPLS fora luck in their labours). To be accurate, Brian, IEEE 802.1 supports 8 traffic classes and all conformant implementations must support *at least* strict priority queueing between *at least* 2 classes: other mechanisms (e.g. WRR, CBQ) are allowed and are widely implemented. Last time I heard 802.1 discuss adding mechanisms to this standard (about 1 1/2 years ago I think - someone will correct me if I'm wrong - I'm rather a "lapsed" attendee of 802.1), the general consensus was that the work done by the DiffServ working group provided sufficient documentation of class-based queueing mechanisms and their management, that these were very much applicable to 802.1 switches/routers as well as to Diffserv ones (it's just a different classifier) and that 802.1 didn't need to, and shouldn't, do more. I think that is still a sensible position for 802.1 to take (and it does make the DiffServ Model, PIB and MIB drafts all the more important). It wouldn't be a good idea to have multiple standards groups working on overlapping things: architecturally speaking QoS policing, queueing and scheduling mechanisms are (almost) layer-independent. The only pieces that are really "owned" by one or other layer are classifier elements (DSCP, 6-tuple, IEEE802.1p etc.) - everything else only needs writing down once: mappings from QoS mechanisms specified at one layer to those specified by another usually end in tears, or at least not quite the intended effect. Andrew Smith -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Friday, September 07, 2001 2:57 PM To: Fred Baker Cc: Krishna Gundamaraju; DiffServ@ietf.org Subject: Re: [Diffserv] DiffServ Classes to 802.1 P mapping Well, I believe that 802.1p was working on this (just as the ATM Forum was working on diffserv-to-ATM mappings, and MPLS is working on diffserv-to-MPLS mappings. So this has never been considered as in the scope of this WG. You have to be careful anyway. 802.1p supports crude priority, and diffserv behaviors are not priorities. Brian Fred Baker wrote: > > At 12:16 PM 9/7/2001, Krishna Gundamaraju wrote: > > Does DiffServ recommend any 802.1P values for each of the PHBs? > > Please clarify and point me to the appropriate reference. > > we discussed that at one point, but no current proposal is before the > house. You might suggest one... > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 10 21:14:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07921 for ; Mon, 10 Sep 2001 21:14:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24543; Mon, 10 Sep 2001 21:00:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08600 for ; Mon, 10 Sep 2001 12:33:04 -0400 (EDT) Received: from web20403.mail.yahoo.com (web20403.mail.yahoo.com [216.136.226.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21496 for ; Mon, 10 Sep 2001 12:31:35 -0400 (EDT) Message-ID: <20010910163303.23733.qmail@web20403.mail.yahoo.com> Received: from [64.124.150.130] by web20403.mail.yahoo.com via HTTP; Mon, 10 Sep 2001 09:33:03 PDT Date: Mon, 10 Sep 2001 09:33:03 -0700 (PDT) From: Cristian Popa To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] CAC framework Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hello, Do you know if and where I could find documents describing the CAC for diffserv framework? Thanks, Cristian __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 10 21:14:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07926 for ; Mon, 10 Sep 2001 21:14:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24551; Mon, 10 Sep 2001 21:00:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03290 for ; Mon, 10 Sep 2001 10:03:16 -0400 (EDT) Received: from pigpen.lucentctc.com (pigpen.lucentctc.com [199.93.237.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15717 for ; Mon, 10 Sep 2001 10:01:46 -0400 (EDT) Received: by pigpen.lucentctc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Sep 2001 10:02:39 -0400 Message-ID: From: "Ish-shalom, Ran" To: "Romascano, Dan" , Brian E Carpenter , Fred Baker Cc: Krishna Gundamaraju , DiffServ@ietf.org, "Ish-shalom, Ran" Subject: RE: [Diffserv] DiffServ Classes to 802.1 P mapping Date: Mon, 10 Sep 2001 10:02:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-8" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Although I missed the last IEEE 802.1 meetings, I believe that I am still very updated with the work going on there. There are no official work items or proposals as yet. There were some thoughts and e-mails exchanges in the 802.1 mailing list about this subject but no one has initiated any work on this subject. the only work related to this that I have seen is: mapping IntServ to DiffServ: http://search.ietf.org/internet-drafts/draft-ietf-issll-ds-map-01.txt mapping IntServ on IEEE 802 networks: ftp://ftp.isi.edu/in-notes/rfc2815.txt Regards Ran From: Dan Romascanu [mailto:dromasca@avaya.com] Sent: Saturday, September 08, 2001 11:36 AM To: Brian E Carpenter; Fred Baker Cc: Krishna Gundamaraju; DiffServ@ietf.org; Ran Ish-Shalom Subject: RE: [Diffserv] DiffServ Classes to 802.1 P mapping I would doubt that there is any work in the IEEE 802.1 WG on this respect. This is not only because I did not hear about it from my colleagues attending this IEEE activity, but also because the IEEE 802 project tends to limit its scope to the 'lower' two layers, and its approach is typically generic, or other said agnostic relative to services carried by the layers 'above'. Regards, Dan > -----Original Message----- > From: Brian E Carpenter [ mailto:brian@hursley.ibm.com ] > Sent: Friday, September 07, 2001 11:57 PM > To: Fred Baker > Cc: Krishna Gundamaraju; DiffServ@ietf.org > Subject: Re: [Diffserv] DiffServ Classes to 802.1 P mapping > > > Well, I believe that 802.1p was working on this (just as the ATM Forum > was working on diffserv-to-ATM mappings, and MPLS is working on > diffserv-to-MPLS mappings. So this has never been considered as > in the scope of this WG. > > You have to be careful anyway. 802.1p supports crude priority, and > diffserv behaviors are not priorities. > > Brian > > Fred Baker wrote: > > > > At 12:16 PM 9/7/2001, Krishna Gundamaraju wrote: > > > Does DiffServ recommend any 802.1P values for each of > the PHBs? > > > Please clarify and point me to the appropriate reference. > > > > we discussed that at one point, but no current proposal is > before the > > house. You might suggest one... > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 10 21:23:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08123 for ; Mon, 10 Sep 2001 21:23:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25202; Mon, 10 Sep 2001 21:14:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25171 for ; Mon, 10 Sep 2001 21:14:43 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07909 for ; Mon, 10 Sep 2001 21:13:14 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id CAA22486; Tue, 11 Sep 2001 02:14:11 +0100 Received: from hursley.ibm.com ([9.29.3.171]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id CAA20554; Tue, 11 Sep 2001 02:14:10 +0100 Message-ID: <3B9D6436.51AD0C92@hursley.ibm.com> Date: Mon, 10 Sep 2001 20:09:10 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Ish-shalom, Ran" CC: "Romascano, Dan" , Fred Baker , Krishna Gundamaraju , DiffServ@ietf.org Subject: Re: [Diffserv] DiffServ Classes to 802.1 P mapping References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit OK, then I was correct that it has been discussed (literally). This isn't a diffserv WG item. Probably it would fit best into ISSLL. If people think it is useful, please take it to ISSLL. However, since diffserv is not priority-based, you might consider first whether any useful mapping to 802.1p can logically exist. Brian "Ish-shalom, Ran" wrote: > > Although I missed the last IEEE 802.1 meetings, I believe that I am still > very updated with the work going on there. There are no official work items > or proposals as yet. > There were some thoughts and e-mails exchanges in the 802.1 mailing list > about this subject but no one has initiated any work on this subject. > the only work related to this that I have seen is: > > mapping IntServ to DiffServ: > http://search.ietf.org/internet-drafts/draft-ietf-issll-ds-map-01.txt > > mapping IntServ on IEEE 802 networks: > ftp://ftp.isi.edu/in-notes/rfc2815.txt > > > > Regards > Ran > > > > From: Dan Romascanu [mailto:dromasca@avaya.com] > Sent: Saturday, September 08, 2001 11:36 AM > To: Brian E Carpenter; Fred Baker > Cc: Krishna Gundamaraju; DiffServ@ietf.org; Ran Ish-Shalom > Subject: RE: [Diffserv] DiffServ Classes to 802.1 P mapping > > I would doubt that there is any work in the IEEE 802.1 WG on this respect. > This is not only because I did not hear about it from my colleagues > attending this IEEE activity, but also because the IEEE 802 project tends to > limit its scope to the 'lower' two layers, and its approach is typically > generic, or other said agnostic relative to services carried by the layers > 'above'. > > Regards, > > Dan > > > > -----Original Message----- > > From: Brian E Carpenter [ mailto:brian@hursley.ibm.com > ] > > Sent: Friday, September 07, 2001 11:57 PM > > To: Fred Baker > > Cc: Krishna Gundamaraju; DiffServ@ietf.org > > Subject: Re: [Diffserv] DiffServ Classes to 802.1 P mapping > > > > > > Well, I believe that 802.1p was working on this (just as the ATM Forum > > was working on diffserv-to-ATM mappings, and MPLS is working on > > diffserv-to-MPLS mappings. So this has never been considered as > > in the scope of this WG. > > > > You have to be careful anyway. 802.1p supports crude priority, and > > diffserv behaviors are not priorities. > > > > Brian > > > > Fred Baker wrote: > > > > > > At 12:16 PM 9/7/2001, Krishna Gundamaraju wrote: > > > > Does DiffServ recommend any 802.1P values for each of > > the PHBs? > > > > Please clarify and point me to the appropriate reference. > > > > > > we discussed that at one point, but no current proposal is > > before the > > > house. You might suggest one... > > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 13 22:03:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22087 for ; Thu, 13 Sep 2001 22:03:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04729; Thu, 13 Sep 2001 21:27:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04700 for ; Thu, 13 Sep 2001 21:27:24 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20411 for ; Thu, 13 Sep 2001 21:27:16 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f8E1QCx21395 for ; Thu, 13 Sep 2001 18:26:12 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f8E1QC928992 for ; Thu, 13 Sep 2001 18:26:12 -0700 (PDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id SAA17647 for ; Thu, 13 Sep 2001 18:26:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20010910153812.03a0e9b8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Sep 2001 08:39:00 -0700 To: diffserv@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] yet another MIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Please review ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-13.txt ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-13.txt This has been sent off to internet-drafts for posting, and responds to comments from Harrie Hazewinkel and Bert Wijnen, as well as on the list. There is another issue on the table, and as no consensus seems to be developing among the folks talking about it (there are some on each side, and one that has expressed a preference for both sides), I'm opening it to a wider audience. This MIB has two compliance clauses: one for read only capability, and one for read/write. Some would like them named diffServMIBReadWriteCompliance and diffServMIBReadOnlyCompliance and some would like them named diffServMIBFullCompliance and diffServMIBCompliance The argument is basically a political one - shall we give them names that describe what they mean, or shall we give them names that indicate that this working group would like to see vendors pressured in the direction of read/write implementations? Compliance with either clause is indeed compliance: a vendor can claim full compliance to the compliance clause he chooses. But by naming it in the latter way, the vendor might be pushed by a customer to implement "diffServMIBFullCompliance" (read/write capability) even though the customer plans to use an SNMPv1 browser such as HP Openview, because the customer unknowledgably believes that full compliance has something to do with implementation of all of the objects. I'd appreciate working group commentary and consensus. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 13 22:47:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24868 for ; Thu, 13 Sep 2001 22:47:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06732; Thu, 13 Sep 2001 22:26:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06701 for ; Thu, 13 Sep 2001 22:26:36 -0400 (EDT) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23045 for ; Thu, 13 Sep 2001 22:26:19 -0400 (EDT) Received: from ANDREWHOME (user-vcaurna.dsl.mindspring.com [216.175.110.234]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id TAA01414; Thu, 13 Sep 2001 19:25:42 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Fred Baker" , Subject: RE: [Diffserv] yet another MIB Date: Thu, 13 Sep 2001 19:45:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <5.1.0.14.2.20010910153812.03a0e9b8@mira-sjcm-2.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Fred wrote: > Some would like them named > > diffServMIBReadWriteCompliance > and diffServMIBReadOnlyCompliance > > and some would like them named > > diffServMIBFullCompliance > and diffServMIBCompliance and some suggested the compromise of: diffServMIBFullCompliance and diffServMIBReadOnlyCompliance which, I believe, encapsulates the sentiment that, if you only implement half the objects, you shouldn't get to claim "full" anything. I would propose we adopt this naming. I'll ignore Fred's rant about stupid customers which I do not think is relevant to this discussion. Andrew Smith -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Fred Baker Sent: Monday, September 17, 2001 8:39 AM To: diffserv@ietf.org Subject: [Diffserv] yet another MIB Please review ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-13.txt ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-13.txt This has been sent off to internet-drafts for posting, and responds to comments from Harrie Hazewinkel and Bert Wijnen, as well as on the list. There is another issue on the table, and as no consensus seems to be developing among the folks talking about it (there are some on each side, and one that has expressed a preference for both sides), I'm opening it to a wider audience. This MIB has two compliance clauses: one for read only capability, and one for read/write. Some would like them named diffServMIBReadWriteCompliance and diffServMIBReadOnlyCompliance and some would like them named diffServMIBFullCompliance and diffServMIBCompliance The argument is basically a political one - shall we give them names that describe what they mean, or shall we give them names that indicate that this working group would like to see vendors pressured in the direction of read/write implementations? Compliance with either clause is indeed compliance: a vendor can claim full compliance to the compliance clause he chooses. But by naming it in the latter way, the vendor might be pushed by a customer to implement "diffServMIBFullCompliance" (read/write capability) even though the customer plans to use an SNMPv1 browser such as HP Openview, because the customer unknowledgably believes that full compliance has something to do with implementation of all of the objects. I'd appreciate working group commentary and consensus. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 14 15:26:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25068 for ; Fri, 14 Sep 2001 15:26:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06087; Fri, 14 Sep 2001 13:37:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06057 for ; Fri, 14 Sep 2001 13:37:30 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22671 for ; Fri, 14 Sep 2001 13:37:59 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f8EHaxa11827 for ; Fri, 14 Sep 2001 13:37:00 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Sep 2001 19:36:54 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D7D0056@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Fred Baker , diffserv@ietf.org Subject: RE: [Diffserv] yet another MIB Date: Fri, 14 Sep 2001 19:36:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Fred, when I do a syntax check with SMICng, I get C:\smicng\work>smicng diffserv.inc W: f(diffserv.mi2), (1189,1) Item "diffServActionInterface" is not contained in any group defined in the current module W: f(diffserv.mi2), (8,48) "TimeStamp" imported but not used Can you pls fix those in the next go around. Bert > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: maandag 17 september 2001 17:39 > To: diffserv@ietf.org > Subject: [Diffserv] yet another MIB > > > Please review > > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-13.txt > > ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-13.txt > ... snip ... _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat Sep 15 11:33:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20971 for ; Sat, 15 Sep 2001 11:32:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07745; Sat, 15 Sep 2001 11:10:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07713 for ; Sat, 15 Sep 2001 11:10:16 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20725 for ; Sat, 15 Sep 2001 11:10:14 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f8FFAHe00964 for ; Sat, 15 Sep 2001 11:10:17 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 15 Sep 2001 17:10:11 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D7D00E3@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: diffserv@ietf.org Date: Sat, 15 Sep 2001 17:10:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] New diffserv MIB (rev 13) and MIB Compliance Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org You may have noticed that Fred has posted a new diffserv mib. It has (at my suggestion) been updated to contain two compliance statements. Fred has writes: Some would like them named diffServMIBReadWriteCompliance and diffServMIBReadOnlyCompliance and some would like them named diffServMIBFullCompliance and diffServMIBCompliance I am among the some (actually I proposed) who think that they should be named: diffServMIBFullCompliance diffServMIBReadOnlyCompliance My reasoning/argumentation/thinking is that: - This MIB has got a lot of attention so that it can also be used for configuration (with SNMP) of diffserv capable devices. The Diffserv WG and MIB authors have worked with the SNMPCONF and RAP WG people to also look at it from the perspective of allowing configuration on a network-wide basis, or for policy-based configuration. - I have proposed a limited set of values for RowStatus (i.e. no need to support createAndWait and notInService, so that we reduce the complexity at the agent side. So that means that (for this MIB), when a row/entry is created, one MUST send all the values for all columnar objects for the whole row (as an aside, for this MIB such SNMP SET PDUs will all fit even in a 484 octet SNMP PDU). This is a first step to try and alleviate some concerns about SNMP SET complexity. - We traditionally have used only one compliance statement that had the form of the diffServMIBReadOnly compliance. We always named it just something like diffServMIBCompliance. This means that vendors who implement the MIB in read-only mode claim the same compliance as those who implement in read-write mode. Also for customers, when they ask a vendor for MIB compliance, this means that they need to explicitly state if they want them to do read-only or read-write coimpliance. So it seems better to actually do 2 compliance statements. - The ReadOnly compliance allows people to implement read-only but also read-write. - The ReadWrite (or in my view better the Full) compliance requires people to implement read-write, so that you can configure with SNMP. - ReadWrite compliance of course expresses what the compliance means namely that you implement in read-write mode as opposed to just read-only mode. - But to be fair, the ReadOnly compliance is really only a partial implementation of the functionality of the MIB. I figured I would not want to give that a negative name of something like diffServMibPartialCompliance. - Instead I proposed to give a ReadWrite implementation a positive spin using a name of diffServMIBFullCompliance. And to be fair again, a read-write implementation is indeed a FULL compliance with ALL the functionality that the MIB provides. - And it is also fair to say, that I have a little hope that by the use of FullCompliance, we might encourage people just a tidbit to indeed implement and use the full functionality of the MIB. Of course every customer and vendor will evaluate the cost/benefit ratio of each compliance before they ask for it or implement it. That is, in the end the market decides. - Let me also add that we already have examples of the use of a FULL compliance with other partial compliances, like in RFC2573, where we do have on snmpNotifyFullCompliance and a few other partial compliance statements. Other examples can be found in RFC1628, RFC2594, RFC2789 and RFC2837. So it is not new to show people what is needed for FULL compliance. Anyway, as Fred asked, if you have an opinion on this, it would be good to express this on this mailing list. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun Sep 16 17:01:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15171 for ; Sun, 16 Sep 2001 17:01:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00611; Sun, 16 Sep 2001 16:36:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00580 for ; Sun, 16 Sep 2001 16:36:13 -0400 (EDT) Received: from h0001027441c5.ne.mediaone.net (h0001027441c5.ne.mediaone.net [24.128.60.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14532 for ; Sun, 16 Sep 2001 16:35:25 -0400 (EDT) Received: from europa-h0001027441c5.ne.mediaone.net (europa [192.168.20.40]) by h0001027441c5.ne.mediaone.net (8.9.3/8.8.7) with ESMTP id OAA26603; Sun, 16 Sep 2001 14:06:48 -0400 Received: from jdscons.com (localhost [127.0.0.1]) by europa-h0001027441c5.ne.mediaone.net (8.9.3+Sun/8.9.3) with ESMTP id OAA26962; Sun, 16 Sep 2001 14:00:18 -0400 (EDT) Message-Id: <200109161800.OAA26962@europa-h0001027441c5.ne.mediaone.net> To: Fred Baker cc: diffserv@ietf.org Subject: Re: [Diffserv] yet another MIB From: Jon Saperia In-reply-to: Your message of Mon, 17 Sep 2001 08:39:00 -0700. <5.1.0.14.2.20010910153812.03a0e9b8@mira-sjcm-2.cisco.com> Date: Sun, 16 Sep 2001 14:00:18 -0400 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Please review > > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-13.txt > ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-13.txt > > This has been sent off to internet-drafts for posting, and responds to > comments from Harrie Hazewinkel and Bert Wijnen, as well as on the list. > > There is another issue on the table, and as no consensus seems to be > developing among the folks talking about it (there are some on each side, > and one that has expressed a preference for both sides), I'm opening it to > a wider audience. > > This MIB has two compliance clauses: one for read only capability, and one > for read/write. Some would like them named > > diffServMIBReadWriteCompliance > and diffServMIBReadOnlyCompliance > > and some would like them named > > diffServMIBFullCompliance > and diffServMIBCompliance > > The argument is basically a political one - shall we give them names that > describe what they mean, or shall we give them names that indicate that > this working group would like to see vendors pressured in the direction of > read/write implementations? Compliance with either clause is indeed > compliance: a vendor can claim full compliance to the compliance clause he > chooses. But by naming it in the latter way, the vendor might be pushed by > a customer to implement "diffServMIBFullCompliance" (read/write capability) > even though the customer plans to use an SNMPv1 browser such as HP > Openview, because the customer unknowledgably believes that full compliance > has something to do with implementation of all of the objects. The quick summary to my points below is that Andrew said it well. I support: > and some suggested the compromise of: > > diffServMIBFullCompliance > and diffServMIBReadOnlyCompliance > > I agree that in some respects the issue is a political one. I can see how Fred would put things the way he did. I have a different view however, based on the following. 1. SNMP has been intended for configuration since the earliest days. A review of even the early SNMP RFCs reveals that more than monitoring was intended. 2. One of the arguments that was made early on when 'writable' SNMP objects were objected to by the IESG is that security was not very good for SNMP, that argument is no longer true. I am aware of some of these objections since I have been on the receiving end of them from time to time. 3. To properly manage a protocol, I think one needs to configure it as well, thus the desire for configuration objects. The MIB Modules that we have developed in the IETF to this point have been partial to my way of thinking since for the most part, write objects were fairly uncommon. A MIB Module that included read/write to facilitate configuration would be more in keeping with a fully specified management interface where a read only would be a partial one. I am aware of the strong feelings for and against SNMP-based configuration objects, but for the time being, as far as I know, we have only one management standard. If the IETF would like to create a new one, or create one for read and write that could be done. For now, I think we do the community a disservice to not make clear what full compliance with the standard for the management of our protocols means. Full compliance means you support the full management interface to the protocol/standard. One reason for providing the SNMP objects is that they can at least expose what the protocol engineers think are reasonable 'knobs' to control the standard aspects of a protocol even if the knobs are implemented via proprietary CLI commands only. In a sense, the SNMP configuration objects can have significant value by acting as a canonical form for the community. Of course, I think of them as more important than that, they should be implemented and some vendors do that. We should not control them by not providing a standard set of knobs. This makes everyone's job more difficult. With this said, I am pleased that so much effort has been placed on trying to get the right configuration and counter objects into the document. That is the most important part, and is an improvement over where we were. /jon > > I'd appreciate working group commentary and consensus. > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > Thanks, /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 17 07:49:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09179 for ; Mon, 17 Sep 2001 07:49:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26249; Mon, 17 Sep 2001 06:59:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26219 for ; Mon, 17 Sep 2001 06:59:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07687; Mon, 17 Sep 2001 06:59:54 -0400 (EDT) Message-Id: <200109171059.GAA07687@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 17 Sep 2001 06:59:54 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-13.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Management Information Base for the Differentiated Services Architecture Author(s) : F. Baker, K. Chan, A. Smith Filename : draft-ietf-diffserv-mib-13.txt Pages : 123 Date : 14-Sep-01 This memo describes an SMIv2 MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-mib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-mib-13.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: <20010914103631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010914103631.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 17 12:08:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14829 for ; Mon, 17 Sep 2001 12:08:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03792; Mon, 17 Sep 2001 11:34:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03761 for ; Mon, 17 Sep 2001 11:34:28 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14051 for ; Mon, 17 Sep 2001 11:34:26 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA17752; Mon, 17 Sep 2001 16:33:14 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA57454; Mon, 17 Sep 2001 16:33:13 +0100 Message-ID: <3BA616F9.809DC01@hursley.ibm.com> Date: Mon, 17 Sep 2001 10:30:01 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: Fred Baker , diffserv@ietf.org Subject: Re: [Diffserv] yet another MIB References: <2413FED0DFE6D111B3F90008C7FA61FB0D7D0056@nl0006exch002u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Let's treat this as an early Last Call comment. Brian "Wijnen, Bert (Bert)" wrote: > > Fred, when I do a syntax check with SMICng, I get > > C:\smicng\work>smicng diffserv.inc > W: f(diffserv.mi2), (1189,1) Item "diffServActionInterface" > is not contained in any group defined in the current module > W: f(diffserv.mi2), (8,48) "TimeStamp" imported but not used > > Can you pls fix those in the next go around. > > Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 17 12:08:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14841 for ; Mon, 17 Sep 2001 12:08:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04188; Mon, 17 Sep 2001 11:49:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04158 for ; Mon, 17 Sep 2001 11:49:31 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14416 for ; Mon, 17 Sep 2001 11:49:29 -0400 (EDT) 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 f8HFmHs00597 for ; Mon, 17 Sep 2001 11:48:18 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Sep 2001 17:48:11 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D7D056F@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Brian E Carpenter Cc: Fred Baker , diffserv@ietf.org Subject: RE: [Diffserv] yet another MIB Date: Mon, 17 Sep 2001 17:48:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Sure, no problem with that. Bert > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: maandag 17 september 2001 17:30 > To: Wijnen, Bert (Bert) > Cc: Fred Baker; diffserv@ietf.org > Subject: Re: [Diffserv] yet another MIB > > > Let's treat this as an early Last Call comment. > > Brian > > "Wijnen, Bert (Bert)" wrote: > > > > Fred, when I do a syntax check with SMICng, I get > > > > C:\smicng\work>smicng diffserv.inc > > W: f(diffserv.mi2), (1189,1) Item "diffServActionInterface" > > is not contained in any group defined in the current module > > W: f(diffserv.mi2), (8,48) "TimeStamp" imported but not used > > > > Can you pls fix those in the next go around. > > > > Bert > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 17 12:08:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14853 for ; Mon, 17 Sep 2001 12:08:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03879; Mon, 17 Sep 2001 11:37:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03848 for ; Mon, 17 Sep 2001 11:36:57 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14085 for ; Mon, 17 Sep 2001 11:36:56 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA30628 for ; Mon, 17 Sep 2001 16:35:44 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA43302 for ; Mon, 17 Sep 2001 16:35:45 +0100 Message-ID: <3BA6178F.29059996@hursley.ibm.com> Date: Mon, 17 Sep 2001 10:32:31 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org Subject: Consensus call: Re: [Diffserv] New diffserv MIB (rev 13) and MIB Compliance References: <2413FED0DFE6D111B3F90008C7FA61FB0D7D00E3@nl0006exch002u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit "Wijnen, Bert (Bert)" wrote: ... > I am among the some (actually I proposed) who think that they > should be named: > > diffServMIBFullCompliance > diffServMIBReadOnlyCompliance This looks like a compromise with several people supporting it. If this is *unacceptable* to you please say so *now*. Brian Carpenter diffserv co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 17 12:19:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15138 for ; Mon, 17 Sep 2001 12:19:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04353; Mon, 17 Sep 2001 11:55:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04322 for ; Mon, 17 Sep 2001 11:55:12 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@[134.169.34.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14506 for ; Mon, 17 Sep 2001 11:55:10 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell.ibr.cs.tu-bs.de [134.169.34.34]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id RAA05308; Mon, 17 Sep 2001 17:54:28 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA08674; Mon, 17 Sep 2001 17:54:28 +0200 Date: Mon, 17 Sep 2001 17:54:28 +0200 Message-Id: <200109171554.RAA08674@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: diffserv@ietf.org Subject: [Diffserv] Re: New diffserv MIB (rev 13) and MIB Compliance Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I generally think that having two compliance statements is good. I agree with Bert's statement that ReadOnly compliance is really only a partial implementation of the functionality of the MIB and as such I see his motivation for diffServMIBCompliance and diffServMIBFullCompliance. On the other hand, I do not have a very strong feeling about these names and I will certainly not object against the other choice. On the technical side, I am wondering why the WRITE-SYNTAX requires support for active(1). This is basically a no-op if I only support createAndGo(4) and destroy(6) since the row will always be active(1) during the time it exists. As a service to implementors, we might want to say at some place (perhaps in the DESCRIPTION of the compliance statement) that agents which implement only createAndGo(4) and destroy(6) must respond with a wrongValue error if they receive a set request with createAndWait(5) or notInService(2). (This is defined in RFC 2579 but requires some search to actually find it.) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Muehlenpfordtstr. 23, 38106 Braunschweig, Germany Fax: +49 531 391 5936 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 17 18:26:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23012 for ; Mon, 17 Sep 2001 18:26:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16740; Mon, 17 Sep 2001 17:30:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14615 for ; Mon, 17 Sep 2001 16:46:32 -0400 (EDT) Received: from longmail2.lboard.com ([63.109.116.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21470 for ; Mon, 17 Sep 2001 16:46:29 -0400 (EDT) Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Sep 2001 16:44:53 -0400 Message-ID: From: Ed Ellesson To: "'diffserv@ietf.org'" Cc: "'Joel M. Halpern'" , "'Wijnen, Bert (Bert)'" Date: Mon, 17 Sep 2001 16:44:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] FW: Terminology for Policy-Based Management Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org DiffServ WG: Thanks for your help with the subject draft! We have requested that the IESG consider it for Informational status, as noted below. Ed and Joel > -----Original Message----- > From: Ed Ellesson > Sent: Monday, September 17, 2001 3:54 PM > To: 'Wijnen, Bert (Bert)' > Cc: 'Joel M. Halpern'; 'andreaw@cisco.com'; 'policy@ietf.org'; > 'john.schnizlein@cisco.com'; 'john.strassner@intelliden.com'; > 'mscherling@xcert.com'; 'bquinn@celoxnetworks.com'; 'jay@jandg.net'; > 'herzog@iphighway.com'; 'ahuynh@lucent.com'; 'mark.carlson@sun.com'; > 'waldbusser@nextbeacon.com'; 'Randy Bush' > Subject: Terminology for Policy-Based Management > > Bert, > > Please forward the following draft to the IESG for consideration as an > Informational RFC: > > http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-04.txt > > The content of this revised draft represents the rough consensus of our > working group, coordinated with the following working groups, based on the > comments received on the prior draft (-03) during the multiple working > group extended last call, which completed in early June, prior to the > London IETF. The resulting revisions were discussed and accepted on both > the policy framework working group mailing list, as well as the mailing > list of the working group from which each comment was received. > > The revised draft (-04) was posted prior to the London IETF, and was > reviewed at the policy wg meeting in London. The minutes of that meeting > reflect the wg decision to forward this revised draft to the IESG. No > further comments have been received on the policy wg mailing list. > > Working groups participating in the extended working group last call of > the prior draft (-03), resulting in the revised draft (-04): > Policy > DiffServ > RAP > IPSP > SNMPCONF > AAA > AAAArch (IRTF) > MPLS > > We will also forward a copy of this notice/request to each of these wg's > mailing lists. Thanks to the authors and all those who submitted > comments! > > Sincerely, > > Ed Ellesson, with Joel Halpern > Co-chairs, Policy Framework WG > > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 17 18:27:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23025 for ; Mon, 17 Sep 2001 18:27:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16095; Mon, 17 Sep 2001 17:21:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16068 for ; Mon, 17 Sep 2001 17:21:52 -0400 (EDT) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22029 for ; Mon, 17 Sep 2001 17:21:49 -0400 (EDT) Received: from windriver.com (mountain.dallas.wrs.com [204.181.204.71]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id QAA22375; Mon, 17 Sep 2001 16:16:46 -0500 (CDT) Message-ID: <3BA6691E.64B5913@windriver.com> Date: Mon, 17 Sep 2001 16:20:30 -0500 From: Tom Irwin X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: diffserv@ietf.org Subject: Re: [Diffserv] yet another MIB References: <5.1.0.14.2.20010910153812.03a0e9b8@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi Fred: Your latest MIB file name indicates draft 13, but the file text indicates draft 14. Is this the correct MIB? I get several MIB compile errors in the compliance section using the industry standard Epilogue Technology "Emissary SNMP MIB Compiler, version 9.1". Here is an example error message: processing object DIFFSERV-MIB:diffServMaxRateStatus diffserv14.mi2:2704: A named number list may be applied only to the INTEGER type itself, and not to a type derived from the INTEGER type. Associated MIB text: OBJECT diffServDataPathStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." In order to compile the MIB, I had to comment out every similar occurance. Would you please correct these errors? Thank you, Tom Irwin. Fred Baker wrote: > > Please review > > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-13.txt > ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-13.txt > > This has been sent off to internet-drafts for posting, and responds to > comments from Harrie Hazewinkel and Bert Wijnen, as well as on the list. > > There is another issue on the table, and as no consensus seems to be > developing among the folks talking about it (there are some on each side, > and one that has expressed a preference for both sides), I'm opening it to > a wider audience. > > This MIB has two compliance clauses: one for read only capability, and one > for read/write. Some would like them named > > diffServMIBReadWriteCompliance > and diffServMIBReadOnlyCompliance > > and some would like them named > > diffServMIBFullCompliance > and diffServMIBCompliance > > The argument is basically a political one - shall we give them names that > describe what they mean, or shall we give them names that indicate that > this working group would like to see vendors pressured in the direction of > read/write implementations? Compliance with either clause is indeed > compliance: a vendor can claim full compliance to the compliance clause he > chooses. But by naming it in the latter way, the vendor might be pushed by > a customer to implement "diffServMIBFullCompliance" (read/write capability) > even though the customer plans to use an SNMPv1 browser such as HP > Openview, because the customer unknowledgably believes that full compliance > has something to do with implementation of all of the objects. > > I'd appreciate working group commentary and consensus. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 17 19:17:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24532 for ; Mon, 17 Sep 2001 19:17:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18237; Mon, 17 Sep 2001 18:25:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18179 for ; Mon, 17 Sep 2001 18:25:04 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22963 for ; Mon, 17 Sep 2001 18:24:29 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f8HMNUO13982; Mon, 17 Sep 2001 15:23:30 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f8HMNHv26626; Mon, 17 Sep 2001 15:23:17 -0700 (PDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id PAA11187; Mon, 17 Sep 2001 15:23:16 -0700 (PDT) Message-Id: <5.1.0.14.2.20010917145801.031ee308@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Sep 2001 15:01:03 -0700 To: Tom Irwin From: Fred Baker Subject: Re: [Diffserv] yet another MIB Cc: diffserv@ietf.org In-Reply-To: <3BA6691E.64B5913@windriver.com> References: <5.1.0.14.2.20010910153812.03a0e9b8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 02:20 PM 9/17/2001, Tom Irwin wrote: >I get several MIB compile errors in the compliance section using the >industry standard Epilogue Technology "Emissary SNMP MIB Compiler, >version 9.1". > >Here is an example error message: >processing object DIFFSERV-MIB:diffServMaxRateStatus >diffserv14.mi2:2704: A named number list may be applied only to the >INTEGER type itself, and not to a type derived from the INTEGER type. > >Associated MIB text: >OBJECT diffServDataPathStatus >SYNTAX RowStatus { active(1) } >WRITE-SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } >DESCRIPTION > "Support for createAndWait and notInService is not required." that text was produced by Bert Wijnen, who swears on a stack of appropriately holy books (all of them RFCs) that this is correct. It also passes Frank Strauss's smilint and Bert's copy of smicng. dueling compilers :^) _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 17 19:17:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24605 for ; Mon, 17 Sep 2001 19:17:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18149; Mon, 17 Sep 2001 18:22:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18118 for ; Mon, 17 Sep 2001 18:22:28 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22934 for ; Mon, 17 Sep 2001 18:22:26 -0400 (EDT) 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 f8HMLFO14046 for ; Mon, 17 Sep 2001 18:21:15 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Sep 2001 00:21:09 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D7D05EF@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Tom Irwin , Fred Baker Cc: diffserv@ietf.org Subject: RE: [Diffserv] yet another MIB Date: Tue, 18 Sep 2001 00:21:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Tom, We have had this discussion quite a while ago. The SMIv2 authors/editors agree that the constructs are valid. I believe we have discussed this on the mibs@ops.ietf.org mailing list too, but certainly we have discussed it in the disman mailing list. RFC2925 has similar constructs, and that is when the discussion first came up. For all I know, at least one of the authors of the Epilogue code is a participating/contributing member to the disman wg, so he is aware of this. I will check with him.... or you can do so too. Bert > -----Original Message----- > From: Tom Irwin [mailto:tom.irwin@windriver.com] > Sent: maandag 17 september 2001 23:21 > To: Fred Baker > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] yet another MIB > > > Hi Fred: > > Your latest MIB file name indicates draft 13, but the file text > indicates draft 14. Is this the correct MIB? > > > I get several MIB compile errors in the compliance section using the > industry standard Epilogue Technology "Emissary SNMP MIB Compiler, > version 9.1". > > Here is an example error message: > processing object DIFFSERV-MIB:diffServMaxRateStatus > diffserv14.mi2:2704: A named number list may be applied only to the > INTEGER type itself, and not to a type derived from the INTEGER type. > > Associated MIB text: > OBJECT diffServDataPathStatus > SYNTAX RowStatus { active(1) } > WRITE-SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } > DESCRIPTION > "Support for createAndWait and notInService is not required." > > > In order to compile the MIB, I had to comment out every similar > occurance. Would you please correct these errors? > > Thank you, > Tom Irwin. > > > Fred Baker wrote: > > > > Please review > > > > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-13.txt > ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-13.txt > > This has been sent off to internet-drafts for posting, and responds to > comments from Harrie Hazewinkel and Bert Wijnen, as well as on the list. > > There is another issue on the table, and as no consensus seems to be > developing among the folks talking about it (there are some on each side, > and one that has expressed a preference for both sides), I'm opening it to > a wider audience. > > This MIB has two compliance clauses: one for read only capability, and one > for read/write. Some would like them named > > diffServMIBReadWriteCompliance > and diffServMIBReadOnlyCompliance > > and some would like them named > > diffServMIBFullCompliance > and diffServMIBCompliance > > The argument is basically a political one - shall we give them names that > describe what they mean, or shall we give them names that indicate that > this working group would like to see vendors pressured in the direction of > read/write implementations? Compliance with either clause is indeed > compliance: a vendor can claim full compliance to the compliance clause he > chooses. But by naming it in the latter way, the vendor might be pushed by > a customer to implement "diffServMIBFullCompliance" (read/write capability) > even though the customer plans to use an SNMPv1 browser such as HP > Openview, because the customer unknowledgably believes that full compliance > has something to do with implementation of all of the objects. > > I'd appreciate working group commentary and consensus. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 18 11:07:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22111 for ; Tue, 18 Sep 2001 11:07:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19586; Tue, 18 Sep 2001 10:07:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19555 for ; Tue, 18 Sep 2001 10:07:35 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20554 for ; Tue, 18 Sep 2001 10:07:33 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f8IE6qb07664 for ; Tue, 18 Sep 2001 10:06:53 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Sep 2001 16:06:46 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D7D08C1@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: diffserv@ietf.org Date: Tue, 18 Sep 2001 16:06:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] diffserv mib rev 13 - do we need Counter32 objects Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, as you can all see, the MIB does have a set of Counter64 objects, and it also has a set of "shadow" counter32 objects that in many cases contain the low order 32 bits of the Counter64 objects. Fred did this, because I pointed him to other mibs (like IF-MIB) a year or more ago when I first saw the diffserv mib. It does however make the MIB bigger and a bit more complex than needed. Lately, various other WGs have asked me if we really MUST provide 32bit "shadow" counters for MIBs where just plain 64-bit counters would make the most sense. As a result, I have been checking our RFCs and discussed this with the SMIv2 ediotors. It turns out that we do NOT have any rules in any RFCs that say that you must always have such "shadow" counter32 objects. So that means that WGs can actually decide if they want/need the 32-bit counters or not. When discussing this with Fred, my understanding is that he would also prefer to just eliminate the 32-bit counters from the diffserv MIB. And I am fine with that. So I hope that the WG chairs will entertain a bit of discussion on this, or at least YESorNO emails to see if we have consensus to remove the 32-bit counters. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 18 15:23:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00177 for ; Tue, 18 Sep 2001 15:23:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26560; Tue, 18 Sep 2001 13:44:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26529 for ; Tue, 18 Sep 2001 13:44:50 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27517 for ; Tue, 18 Sep 2001 13:44:48 -0400 (EDT) Received: from FRED-W2K5.cisco.com (sjc-vpn2-388.cisco.com [10.21.113.132]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8IHhbC11296; Tue, 18 Sep 2001 10:43:37 -0700 (PDT) Message-Id: <5.1.0.14.2.20010918101938.0a72d3b0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Sep 2001 10:40:37 -0700 To: diffserv@ietf.org From: Fred Baker Subject: Re: [Diffserv] diffserv mib rev 13 - do we need Counter32 objects Cc: diffserv@ietf.org In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0D7D08C1@nl0006exch002u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 07:06 AM 9/18/2001, Wijnen, Bert (Bert) wrote: >When discussing this with Fred, my understanding is that >he would also prefer to just eliminate the 32-bit counters >from the diffserv MIB. And I am fine with that. A little history might be relevant here. In the first SNMP SMI, all counters were 32 bit quantities. This worked well enough for counters that moved at a slow rate, but had difficulties with packet and octet counters for higher speed lines. It was my opinion (and I was not alone, but I will speak only for myself here) at the time that such counters should always be 64 bit values, an opinion which was politically incorrect. A compromise of sorts was reached during the development of SMIv2. In this, a Counter64 type was defined, but its use was limited to counters that could be expected to count at a high rate. The definitive use of this is in RFC 1573, RFC 2233, and now RFC 2863. As a result, any MIB developed under SMIv2 has two counters for any packet or octet counter supported, and a rather complicated set of rules under which each counter should be implemented, related to line rate. The implementation rules seem to assume that an agent is redeveloped for each product implementation, which seems ludicrous - who among us doesn't re-use software? An example of the complexity shows up in the currently posted diff-serv MIB, which describes three different cases of what-must-be-implemented-by-whom in the counter realm, depending on the line speeds implemented by the device. Personally, I continue to believe that any packet or octet counter that increments in normal use should be 64 bit. This will allow us to scale through anything I can honestly predict, and covers the low end as well. I would like to see this become a BCP, and applied to all MIBs rather than to individual MIBs in special cases. Maybe I will have my way in SMIng, I don't know. That has been a loop I have left to others, due to some combination of lack of cycles and frustration with the historical difficulty of making even small advances. The argument against this might be that this requires cost in hardware - rebuilding of ASICs, and dedication of memory to tables. It does in fact require 32 more bits in memory somewhere. I will argue that the ASIC issue can be worked around by reading the counter and storing it in a 64 bit location maintained by software - something implementations often do anyway for other reasons. The additional memory implied, however, is not (in my opinion) a killer issue - if you can support the MIB at all, the memory implied itself a relatively small part of it. But then, as we all know, I'm a heretic :^) _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 18 15:58:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01059 for ; Tue, 18 Sep 2001 15:58:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27928; Tue, 18 Sep 2001 14:36:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27899 for ; Tue, 18 Sep 2001 14:36:37 -0400 (EDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28709 for ; Tue, 18 Sep 2001 14:36:33 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id UAA07620 for ; Tue, 18 Sep 2001 20:35:23 +0200 Received: from [9.29.3.174] by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA66132 from ; Tue, 18 Sep 2001 20:35:20 +0200 Message-Id: <3BA76D3B.2A7AE00B@hursley.ibm.com> Date: Tue, 18 Sep 2001 10:50:19 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] WG Last Call: MIB version 13 and Informal Model Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffservers, It is proposed to forward draft-ietf-diffserv-mib-13.txt to the IESG for publication as a Proposed Standard RFC. It is also proposed to forward draft-ietf-diffserv-model-06.txt to the IESG for publication as an Informational RFC. Any final comments on these drafts should be sent to the WG list at diffserv@ietf.org within two weeks, i.e. at the latest on October 2, 2001. There is one known open issue (the MIB conformance statement) to be resolved during this period. Thanks Brian Carpenter + Kathie Nichols diffserv WG co-chairs _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 18 16:51:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02036 for ; Tue, 18 Sep 2001 16:51:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00111; Tue, 18 Sep 2001 15:53:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00073 for ; Tue, 18 Sep 2001 15:53:19 -0400 (EDT) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00938 for ; Tue, 18 Sep 2001 15:53:14 -0400 (EDT) Received: from windriver.com (mountain.dallas.wrs.com [204.181.204.71]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id OAA12083; Tue, 18 Sep 2001 14:48:16 -0500 (CDT) Message-ID: <3BA7A5E0.CE0CB605@windriver.com> Date: Tue, 18 Sep 2001 14:52:00 -0500 From: Tom Irwin X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Diff Serv Subject: Re: [Diffserv] WG Last Call: MIB version 13 and Informal Model References: <3BA76D3B.2A7AE00B@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Brian, sorry, but I'm confused about which version of the "draft-ietf-diffserv-mib-13.txt" that we are reviewing. 1) draft-ietf-diffserv-mib-13.txt which was dated Mon, 17 Sep 2001 05:59:54 (CDT) and has "draft-ietf-diffserv-mib-13.txt" in the file and a LAST-UPDATED "200109130000Z" -or- 2) or version Fred posted Date: Mon, 17 Sep 2001 10:39:00 (CDT) at ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-13.txt has "draft-ietf-diffserv-mib-14.txt" in the file and a LAST-UPDATED "200109152300Z". Thanks, Tom. Brian E Carpenter wrote: > > Diffservers, > > It is proposed to forward > draft-ietf-diffserv-mib-13.txt > to the IESG for publication as a Proposed Standard RFC. > > It is also proposed to forward > draft-ietf-diffserv-model-06.txt > to the IESG for publication as an Informational RFC. > > Any final comments on these drafts should be sent to the WG list at > diffserv@ietf.org within two weeks, i.e. at the latest on October 2, 2001. > There is one known open issue (the MIB conformance statement) > to be resolved during this period. > > Thanks > > Brian Carpenter + Kathie Nichols > diffserv WG co-chairs > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 18 17:26:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02711 for ; Tue, 18 Sep 2001 17:26:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01471; Tue, 18 Sep 2001 16:32:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01444 for ; Tue, 18 Sep 2001 16:31:58 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01723 for ; Tue, 18 Sep 2001 16:31:56 -0400 (EDT) Received: from FRED-W2K5.cisco.com (sjc-vpn2-388.cisco.com [10.21.113.132]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8IKUfC13647; Tue, 18 Sep 2001 13:30:41 -0700 (PDT) Message-Id: <5.1.0.14.2.20010918131236.0a655a80@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Sep 2001 13:15:52 -0700 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] WG Last Call: MIB version 13 and Informal Model Cc: Diff Serv In-Reply-To: <3BA76D3B.2A7AE00B@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 08:50 AM 9/18/2001, Brian E Carpenter wrote: >Any final comments on these drafts should be sent to the WG list at >diffserv@ietf.org within two weeks, i.e. at the latest on October 2, 2001. >There is one known open issue (the MIB conformance statement) >to be resolved during this period. I am accumulating changes in ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-14.txt and ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-14.txt. I believe that the conformance issue is closed with Bert, and I will of course include any edits that are agreed to. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 18 17:46:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03045 for ; Tue, 18 Sep 2001 17:46:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00707; Tue, 18 Sep 2001 16:05:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00676 for ; Tue, 18 Sep 2001 16:05:54 -0400 (EDT) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01175 for ; Tue, 18 Sep 2001 16:05:50 -0400 (EDT) Received: (from leinen@localhost) by babar.switch.ch (8.10.2+Sun/8.10.2) id f8IK4aG14570; Tue, 18 Sep 2001 22:04:36 +0200 (MEST) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: "Wijnen, Bert (Bert)" Cc: diffserv@ietf.org Subject: Re: [Diffserv] diffserv mib rev 13 - do we need Counter32 objects References: <2413FED0DFE6D111B3F90008C7FA61FB0D7D08C1@nl0006exch002u.nl.lucent.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0D7D08C1@nl0006exch002u.nl.lucent.com> Date: 18 Sep 2001 22:04:36 +0200 Message-ID: Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.105 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> "wb(" == Wijnen, Bert (Bert) writes: > So I hope that the WG chairs will entertain a bit of > discussion on this, or at least YESorNO emails to see > if we have consensus to remove the 32-bit counters. Removing the 32-bit counters is fine with me (an operator :-). -- Simon. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 18 18:07:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03542 for ; Tue, 18 Sep 2001 18:07:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03503; Tue, 18 Sep 2001 17:31:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03467 for ; Tue, 18 Sep 2001 17:31:36 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02785 for ; Tue, 18 Sep 2001 17:31:33 -0400 (EDT) Received: from FRED-W2K5.cisco.com (sjc-vpn2-388.cisco.com [10.21.113.132]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8ILUNC26796 for ; Tue, 18 Sep 2001 14:30:23 -0700 (PDT) Message-Id: <5.1.0.14.2.20010918131830.026b1f18@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Sep 2001 13:58:26 -0700 To: diffserv@ietf.org From: Fred Baker Subject: Re: [Diffserv] diffserv mib rev 13 - do we need Counter32 objects Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org For the record, If we were to remove the Counter32 objects from the MIB, it would look something like this. ftp://ftpeng.cisco.com/fred/diffserv-mib/marked.draft-ietf-diffserv-mib-14.txt _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 18 18:15:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03765 for ; Tue, 18 Sep 2001 18:15:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02920; Tue, 18 Sep 2001 17:18:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02893 for ; Tue, 18 Sep 2001 17:18:39 -0400 (EDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02547 for ; Tue, 18 Sep 2001 17:18:36 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id XAA08668; Tue, 18 Sep 2001 23:17:27 +0200 Received: from lig32-227-254-57.us.lig-dial.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51642 from ; Tue, 18 Sep 2001 23:17:23 +0200 Message-Id: <3BA7BA6F.BD19147E@hursley.ibm.com> Date: Tue, 18 Sep 2001 16:19:43 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Tom Irwin Cc: Diff Serv Subject: Re: [Diffserv] WG Last Call: MIB version 13 and Informal Model References: <3BA76D3B.2A7AE00B@hursley.ibm.com> <3BA7A5E0.CE0CB605@windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The last call is for the -13 draft at the IETF site and its mirrors. The -14 version is where Fred is keeping track of changes as we proceed with the last call. Brian Tom Irwin wrote: > > Brian, sorry, but I'm confused about which version of the > "draft-ietf-diffserv-mib-13.txt" that we are reviewing. > > 1) draft-ietf-diffserv-mib-13.txt which was dated Mon, 17 Sep 2001 > 05:59:54 (CDT) and has "draft-ietf-diffserv-mib-13.txt" in the file and > a LAST-UPDATED "200109130000Z" > > -or- > > 2) or version Fred posted Date: Mon, 17 Sep 2001 10:39:00 (CDT) at > ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-13.txt > has "draft-ietf-diffserv-mib-14.txt" in the file and a LAST-UPDATED > "200109152300Z". > > Thanks, Tom. > > Brian E Carpenter wrote: > > > > Diffservers, > > > > It is proposed to forward > > draft-ietf-diffserv-mib-13.txt > > to the IESG for publication as a Proposed Standard RFC. > > > > It is also proposed to forward > > draft-ietf-diffserv-model-06.txt > > to the IESG for publication as an Informational RFC. > > > > Any final comments on these drafts should be sent to the WG list at > > diffserv@ietf.org within two weeks, i.e. at the latest on October 2, 2001. > > There is one known open issue (the MIB conformance statement) > > to be resolved during this period. > > > > Thanks > > > > Brian Carpenter + Kathie Nichols > > diffserv WG co-chairs _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 18 19:13:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04738 for ; Tue, 18 Sep 2001 19:12:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05550; Tue, 18 Sep 2001 18:25:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05520 for ; Tue, 18 Sep 2001 18:25:09 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03958 for ; Tue, 18 Sep 2001 18:25:05 -0400 (EDT) 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 f8IMNuA00839 for ; Tue, 18 Sep 2001 18:23:56 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Sep 2001 00:23:50 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D7D0996@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Fred Baker , diffserv@ietf.org Subject: RE: [Diffserv] diffserv mib rev 13 - do we need Counter32 objects Date: Wed, 19 Sep 2001 00:23:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org OK, I think that looks good. But you cannot have a group in the MANDATORY-GROUPS and also as a conditional group (I think). It seems that you now have made the diffServCounterGroup mandatory, and that you have repeated that group as a conditional group also to state that ifCounterDiscontinuityGroup must be implemented IF this group is implemeted (I highlighted the IF, beause there is no IF I think, since you made it mandatory.) And so the stament on ifDiscontinuityGroup in just above the MANDATORY-GROUPS can say it all. If my understanding is correct that the Counter group is now indeed mandatory, then I think you change and simplify this: MODULE IF-MIB -- The interfaces MIB, RFC2863 | GROUP ifCounterDiscontinuityGroup | DESCRIPTION | "This group is mandatory if any counters in the diffServMIB are | supported by the implementation. If it is is supported or | implemented, then the ifCounterDiscontinuityGroup must also be | supported or implemented." | MODULE -- This Module MANDATORY-GROUPS { diffServMIBDataPathGroup, diffServMIBClfrGroup, diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, diffServMIBActionGroup, diffServMIBAlgDropGroup, diffServMIBQGroup, diffServMIBSchedulerGroup, diffServMIBMaxRateGroup, diffServMIBMinRateGroup, | diffServMIBCounterGroup | } GROUP diffServMIBCounterGroup * DESCRIPTION "If this group is implemented, the ifCounterDiscontinuityGroup | from the IF-MIB must also be implemented." into: MODULE IF-MIB -- The interfaces MIB, RFC2863 | MANDATORY-GROUPS { | ifCounterDiscontinuityGroup | } MODULE -- This Module MANDATORY-GROUPS { diffServMIBDataPathGroup, diffServMIBClfrGroup, diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, diffServMIBActionGroup, diffServMIBAlgDropGroup, diffServMIBQGroup, diffServMIBSchedulerGroup, diffServMIBMaxRateGroup, diffServMIBMinRateGroup, | diffServMIBCounterGroup | } See how things keep getting simpler :-) Bert > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: dinsdag 18 september 2001 22:58 > To: diffserv@ietf.org > Subject: Re: [Diffserv] diffserv mib rev 13 - do we need Counter32 > objects > > > For the record, If we were to remove the Counter32 objects > from the MIB, it > would look something like this. > > ftp://ftpeng.cisco.com/fred/diffserv-mib/marked.draft-ietf-dif > fserv-mib-14.txt > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr > ent/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 18 22:42:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08584 for ; Tue, 18 Sep 2001 22:41:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11232; Tue, 18 Sep 2001 22:09:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11201 for ; Tue, 18 Sep 2001 22:08:59 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07317 for ; Tue, 18 Sep 2001 22:08:55 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8J27hC08815; Tue, 18 Sep 2001 19:07:43 -0700 (PDT) Message-Id: <5.1.0.14.2.20010918183025.0a9cd510@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Sep 2001 18:31:21 -0700 To: "Wijnen, Bert (Bert)" From: Fred Baker Subject: RE: [Diffserv] diffserv mib rev 13 - do we need Counter32 objects Cc: diffserv@ietf.org In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0D7D0996@nl0006exch002u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:23 PM 9/18/2001, Wijnen, Bert (Bert) wrote: > MODULE IF-MIB -- The interfaces MIB, RFC2863 | > MANDATORY-GROUPS { | > ifCounterDiscontinuityGroup | > } > > MODULE -- This Module > MANDATORY-GROUPS { > diffServMIBDataPathGroup, diffServMIBClfrGroup, > diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, > diffServMIBActionGroup, diffServMIBAlgDropGroup, > diffServMIBQGroup, diffServMIBSchedulerGroup, > diffServMIBMaxRateGroup, diffServMIBMinRateGroup, | > diffServMIBCounterGroup | > } twist my arm... it's posted as such. I'm not going to make this a permanent change, though, until someone tells me this represents a consensus, or the AD tells me to just do it. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 19 14:48:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08623 for ; Wed, 19 Sep 2001 14:48:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13212; Wed, 19 Sep 2001 13:12:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13181 for ; Wed, 19 Sep 2001 13:12:15 -0400 (EDT) Received: from infomail.es (ncc3.infomail.es [195.235.39.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06662 for ; Wed, 19 Sep 2001 13:12:14 -0400 (EDT) Received: from hp ([213.99.110.252]) by infomail.es (Tid InfoMail Exchanger v2.20) with SMTP id #1000919382.264350001; Wed, 19 Sep 2001 19:09:42 +0200 Message-ID: <006a01c1412e$b5222760$4220a8c0@hp> From: "Marck Gendra" To: Date: Wed, 19 Sep 2001 19:15:40 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C1413F.784DE340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Infomail-Id: 1000919382.6743010A81106E.59382 Subject: [Diffserv] Token Bucket Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C1413F.784DE340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, actually I'm making some tests with diffserv and Cisco routers. The tests consist of transmission of some video streams (UDP) and = varying the parameters of the Token Bucket (both parameters: average = rate and burst size). I would like to know if there must be any = correlation between the graphics obtained? Could anybody tell me where can i find detailed information on Token = Bucket algorithm and tests results related on Token Bucket? Thanks. ------=_NextPart_000_0067_01C1413F.784DE340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
actually I'm making some tests with = diffserv and=20 Cisco routers.
The tests consist of transmission of = some video=20 streams (UDP) and varying the parameters of the Token Bucket (both = parameters:=20 average rate and burst size). I would like to know if there must be any=20 correlation between the graphics obtained?
Could anybody tell me where can i find = detailed=20 information on Token Bucket algorithm and tests results related on Token = Bucket?
 
Thanks.
------=_NextPart_000_0067_01C1413F.784DE340-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 19 18:20:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11811 for ; Wed, 19 Sep 2001 18:20:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21148; Wed, 19 Sep 2001 17:40:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21120 for ; Wed, 19 Sep 2001 17:40:23 -0400 (EDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11482 for ; Wed, 19 Sep 2001 17:40:22 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id XAA08492; Wed, 19 Sep 2001 23:39:12 +0200 Received: from [9.29.3.174] by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51342 from ; Wed, 19 Sep 2001 23:39:05 +0200 Message-Id: <3BA909A3.E247338D@hursley.ibm.com> Date: Wed, 19 Sep 2001 16:09:55 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Marck Gendra Cc: diffserv@ietf.org Subject: Re: [Diffserv] Token Bucket References: <006a01c1412e$b5222760$4220a8c0@hp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, This isn't a diffserv standards issue. Please try the diffserv-interest list. http://www.ietf.org/mailman/listinfo/diffserv-interest Brian > Marck Gendra wrote: > > Hi, > > actually I'm making some tests with diffserv and Cisco routers. > The tests consist of transmission of some video streams (UDP) and varying the parameters of the Token Bucket (both parameters: > average rate and burst size). I would like to know if there must be any correlation between the graphics obtained? > Could anybody tell me where can i find detailed information on Token Bucket algorithm and tests results related on Token > Bucket? > > Thanks. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 20 01:48:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20004 for ; Thu, 20 Sep 2001 01:48:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02616; Thu, 20 Sep 2001 01:04:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02587 for ; Thu, 20 Sep 2001 01:04:23 -0400 (EDT) Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17626 for ; Thu, 20 Sep 2001 01:04:19 -0400 (EDT) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f8K53TV21074 for ; Thu, 20 Sep 2001 10:33:29 +0530 (IST) Received: from localhost (viswa@localhost) by sunsv2.sasken.com (8.9.3/8.9.3) with ESMTP id KAA23267 for ; Thu, 20 Sep 2001 10:33:24 +0530 (IST) Date: Thu, 20 Sep 2001 10:33:23 +0530 (IST) From: Viswanath A To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org unsubscibe _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 20 03:59:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03275 for ; Thu, 20 Sep 2001 03:59:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13569; Thu, 20 Sep 2001 03:32:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13542 for ; Thu, 20 Sep 2001 03:32:33 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02990 for ; Thu, 20 Sep 2001 03:32:29 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell.ibr.cs.tu-bs.de [134.169.34.34]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id JAA11999; Thu, 20 Sep 2001 09:31:50 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA12254; Thu, 20 Sep 2001 09:31:50 +0200 Date: Thu, 20 Sep 2001 09:31:50 +0200 Message-Id: <200109200731.JAA12254@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: fred@cisco.com CC: diffserv@ietf.org, diffserv@ietf.org In-reply-to: <5.1.0.14.2.20010918101938.0a72d3b0@mira-sjcm-2.cisco.com> (message from Fred Baker on Tue, 18 Sep 2001 10:40:37 -0700) Subject: Re: [Diffserv] diffserv mib rev 13 - do we need Counter32 objects References: <5.1.0.14.2.20010918101938.0a72d3b0@mira-sjcm-2.cisco.com> Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> Remco van de Meent writes: Remco> While converting the old stools debian package to scli, I Remco> noticed that the doc/stools.info file is still there, Remco> mentioning stools instead of scli. Yes. I am undecided about it. Either put much more work into it to make it actually useful, or just remove it altogether. I plan to put the LISA 2001 paper into the distribution once it is done. /js _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 20 15:31:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19767 for ; Thu, 20 Sep 2001 15:31:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07565; Thu, 20 Sep 2001 15:01:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07532 for ; Thu, 20 Sep 2001 15:01:03 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19172 for ; Thu, 20 Sep 2001 15:00:58 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell.ibr.cs.tu-bs.de [134.169.34.34]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id VAA01832; Thu, 20 Sep 2001 21:00:15 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id VAA17312; Thu, 20 Sep 2001 21:00:15 +0200 Date: Thu, 20 Sep 2001 21:00:15 +0200 Message-Id: <200109201900.VAA17312@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: fred@cisco.com CC: diffserv@ietf.org In-reply-to: message from Fred Baker on Tue, 18 Sep 2001 13:58:26 -0700 Subject: Re: [Diffserv] diffserv mib rev 13 - do we need Counter32 objects References: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> Fred Baker writes: Fred> For the record, If we were to remove the Counter32 objects from Fred> the MIB, it would look something like this. Fred> ftp://ftpeng.cisco.com/fred/diffserv-mib/marked.draft-ietf-diffserv-mib-14.txt You probably also want to remove the IMPORT of Counter32 since it is not used anymore. /js _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 24 11:53:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20388 for ; Mon, 24 Sep 2001 11:53:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26592; Mon, 24 Sep 2001 11:30:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26542 for ; Mon, 24 Sep 2001 11:30:43 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19147 for ; Mon, 24 Sep 2001 11:30:35 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8OFU8u18370; Mon, 24 Sep 2001 08:30:08 -0700 (PDT) Message-Id: <5.1.0.14.2.20010922162924.0277efb8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Sep 2001 08:30:00 -0700 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] WG Last Call: MIB version 13 and Informal Model Cc: Diff Serv In-Reply-To: <3BA76D3B.2A7AE00B@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org question: flip the coin and tell me how it is coming down. Do I, or do I not, remove the Counter32 objects from the MIB we will publish? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 24 16:18:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29712 for ; Mon, 24 Sep 2001 16:18:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05544; Mon, 24 Sep 2001 15:59:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05513 for ; Mon, 24 Sep 2001 15:59:51 -0400 (EDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29281 for ; Mon, 24 Sep 2001 15:59:43 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id VAA09628; Mon, 24 Sep 2001 21:59:18 +0200 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA43278 from ; Mon, 24 Sep 2001 21:59:15 +0200 Message-Id: <3BAF8E9D.38C5646B@hursley.ibm.com> Date: Mon, 24 Sep 2001 14:50:53 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Fred Baker Cc: Diff Serv Subject: Re: [Diffserv] WG Last Call: MIB version 13 and Informal Model References: <5.1.0.14.2.20010922162924.0277efb8@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit As far as I can read the tealeaves we should remove them. Brian Fred Baker wrote: > > question: flip the coin and tell me how it is coming down. > > Do I, or do I not, remove the Counter32 objects from the MIB we will publish? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Sep 24 17:38:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01764 for ; Mon, 24 Sep 2001 17:38:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08020; Mon, 24 Sep 2001 17:25:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07989 for ; Mon, 24 Sep 2001 17:25:27 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01469 for ; Mon, 24 Sep 2001 17:25:15 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8OLOnd25399; Mon, 24 Sep 2001 14:24:49 -0700 (PDT) Message-Id: <5.1.0.14.2.20010924140315.02311518@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Sep 2001 14:07:48 -0700 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] WG Last Call: MIB version 13 and Informal Model Cc: Diff Serv In-Reply-To: <3BAF8E9D.38C5646B@hursley.ibm.com> References: <5.1.0.14.2.20010922162924.0277efb8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 12:50 PM 9/24/2001, Brian E Carpenter wrote: >As far as I can read the tealeaves we should remove them. done The files ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-14.txt and ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-14.txt reflect that to the best of my knowledge. You called to close the last call on Oct 2; on Oct 3, I plan to post said document, or whatever derivative of it is the order of the day. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 25 12:08:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07704 for ; Tue, 25 Sep 2001 12:08:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12353; Tue, 25 Sep 2001 11:42:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12295 for ; Tue, 25 Sep 2001 11:42:35 -0400 (EDT) Received: from mail.covalent.net (162-39.84.64.covalent.net [64.84.39.162] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06908 for ; Tue, 25 Sep 2001 11:42:30 -0400 (EDT) Received: (qmail 1814 invoked from network); 25 Sep 2001 15:42:03 -0000 Received: from emperor.sfo.covalent.net (HELO ?10.0.0.176?) (10.0.0.176) by mail.covalent.net with SMTP; 25 Sep 2001 15:42:03 -0000 User-Agent: Microsoft-Entourage/9.0.2509 Date: Tue, 25 Sep 2001 08:42:04 -0700 From: Harrie Hazewinkel To: IETF diffserv WG Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] diffServActionInterface, diffServMIBCounterGroup Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, A) I believe there is a minor problem with the diffServActionInterface. The diffServActionInterface description says: "..... If this is unspecified or unknown, the value is zero. ...." It is unclear what the value will be when the entry belongs to multiple interfaces. In other words, which value should the diffServActionInterface get when the counter action is part of a datapath that is merged from multiple interfaces. I propose a small change that includes the assignment of the value zero to the diffServActionInterface in this case. Changed text: "..... If this is unspecified or unknown or the entry belongs to a datapath that is merged from multiple interfaces, the value is zero. ...." B) Do we still want to refer to 'high speed' for all the counters?? I suggest we delete "This object should be used on high-speed interfaces." from the descriptions that go with the Counter64 typed objects. Also the description of the diffServMIBCounterGroup?? I propose a DESCRIPTION for the diffServMIBCounterGroup like: "A collection of objects providing information specific to packet-oriented network interfaces." C) Minor minor nit: - The functions in the description of of the 'rate-tables' go beyond the line length. (Search for 'ifSpeed') - The type Counter64 for the diffServCountActOctets and diffServCountActPkts are not aligned in the entry definition. Harrie _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 25 15:02:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12145 for ; Tue, 25 Sep 2001 15:02:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18783; Tue, 25 Sep 2001 14:31:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18751 for ; Tue, 25 Sep 2001 14:31:33 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11522 for ; Tue, 25 Sep 2001 14:31:28 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8PIUad13016; Tue, 25 Sep 2001 11:30:36 -0700 (PDT) Message-Id: <5.1.0.14.2.20010925105651.046f2398@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Sep 2001 11:12:19 -0700 To: Harrie Hazewinkel From: Fred Baker Subject: Re: [Diffserv] diffServActionInterface, diffServMIBCounterGroup Cc: IETF diffserv WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 08:42 AM 9/25/2001, Harrie Hazewinkel wrote: >It is unclear what the value will be when the entry belongs to multiple >interfaces. I'm not convinced that it can, really. The parameters, found in whatever diffServActionSpecific points to, could apply to multiple interfaces, but the action itself applies to a single interface - at least to my line of reasoning. How about: "..... If this is indeterminate, the value is zero. ...." Beyond that, care to check the current markup to see that I did what you said correctly? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Sep 25 16:06:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13683 for ; Tue, 25 Sep 2001 16:06:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21101; Tue, 25 Sep 2001 15:34:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21069 for ; Tue, 25 Sep 2001 15:34:29 -0400 (EDT) Received: from mail.covalent.net (162-39.84.64.covalent.net [64.84.39.162] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12939 for ; Tue, 25 Sep 2001 15:34:22 -0400 (EDT) Received: (qmail 30323 invoked from network); 25 Sep 2001 19:33:52 -0000 Received: from emperor.sfo.covalent.net (HELO ?10.0.0.176?) (10.0.0.176) by mail.covalent.net with SMTP; 25 Sep 2001 19:33:52 -0000 User-Agent: Microsoft-Entourage/9.0.2509 Date: Tue, 25 Sep 2001 12:33:52 -0700 Subject: Re: [Diffserv] diffServActionInterface, diffServMIBCounterGroup From: Harrie Hazewinkel To: Fred Baker CC: IETF diffserv WG Message-ID: In-Reply-To: <5.1.0.14.2.20010925105651.046f2398@mira-sjcm-2.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit On 9/25/01 11:12, "Fred Baker" wrote: > At 08:42 AM 9/25/2001, Harrie Hazewinkel wrote: >> It is unclear what the value will be when the entry belongs to multiple >> interfaces. > > I'm not convinced that it can, really. The parameters, found in whatever > diffServActionSpecific points to, could apply to multiple interfaces, but > the action itself applies to a single interface - at least to my line of > reasoning. How about: > > "..... If this is indeterminate, the value is zero. ...." Sounds good to me. > > Beyond that, care to check the current markup to see that I did what you > said correctly? Just checked looks OK to me. Harrie _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 26 12:07:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22023 for ; Wed, 26 Sep 2001 12:07:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02587; Wed, 26 Sep 2001 11:22:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02554 for ; Wed, 26 Sep 2001 11:22:18 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20931 for ; Wed, 26 Sep 2001 11:22:15 -0400 (EDT) Received: from xxxx.ibr.cs.tu-bs.de (IDENT:schoenw@xxxx.ibr.cs.tu-bs.de [134.169.34.73]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with SMTP id RAA15427; Wed, 26 Sep 2001 17:22:17 +0200 (MET DST) Message-Id: <200109261522.RAA15427@mumm.ibr.cs.tu-bs.de> Received: by xxxx.ibr.cs.tu-bs.de (sSMTP sendmail emulation); Wed, 26 Sep 2001 17:22:16 +0200 Date: Wed, 26 Sep 2001 17:22:16 +0200 From: Juergen Schoenwaelder To: DIFFSERV WG Subject: [Diffserv] IndexInteger vs. InstanceId Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The DiffServ MIB uses the IndexInteger TC which is an Unsigned32 (1..2147483647) while the DiffServ PIB uses the SPPI InstanceId which is an Unsigned32 (1..4294967295). This basically means that it is possible to create instances via COPS-PR which you can not monitor with SNMP without introducing a mapping between IndexInteger and InstanceId values. Perhaps it is more useful to change IndexInteger to Unsigned32 (1..4294967295) and IndexIntegerNextFree to just Unsigned32. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Muehlenpfordtstr. 23, 38106 Braunschweig, Germany Fax: +49 531 391 5936 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 26 12:28:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22748 for ; Wed, 26 Sep 2001 12:28:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05547; Wed, 26 Sep 2001 12:13:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05511 for ; Wed, 26 Sep 2001 12:13:33 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22262 for ; Wed, 26 Sep 2001 12:13:30 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f8QGDWf00658 for ; Wed, 26 Sep 2001 12:13:32 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Sep 2001 18:13:26 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D94FA80@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Juergen Schoenwaelder , DIFFSERV WG Subject: RE: [Diffserv] IndexInteger vs. InstanceId Date: Wed, 26 Sep 2001 18:13:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Inline > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: woensdag 26 september 2001 17:22 > To: DIFFSERV WG > Subject: [Diffserv] IndexInteger vs. InstanceId > > The DiffServ MIB uses the IndexInteger TC which is an Unsigned32 > (1..2147483647) while the DiffServ PIB uses the SPPI InstanceId > which is an Unsigned32 (1..4294967295). > > This basically means that it is possible to create instances via > COPS-PR which you can not monitor with SNMP without introducing a > mapping between IndexInteger and InstanceId values. > > Perhaps it is more useful to change IndexInteger to Unsigned32 > (1..4294967295) and IndexIntegerNextFree to just Unsigned32. > I would cetainly want them to be in sync. Could also lower the value in the PIB to get in sync with the MIB of course Vut in my version of the MIB, they already are Unsigned32 (1..4294967295) Unsigned32 (0..4294967295) respectively. Have you picked up the latest rev from Fred which he keeps up to date with fixes on issues raised to the list? Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 26 13:07:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23662 for ; Wed, 26 Sep 2001 13:07:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07364; Wed, 26 Sep 2001 12:51:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07317 for ; Wed, 26 Sep 2001 12:51:15 -0400 (EDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23309 for ; Wed, 26 Sep 2001 12:51:13 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id SAA07910; Wed, 26 Sep 2001 18:50:42 +0200 Received: from [9.29.3.174] by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59724 from ; Wed, 26 Sep 2001 18:50:39 +0200 Message-Id: <3BB20C32.F7264422@hursley.ibm.com> Date: Wed, 26 Sep 2001 12:11:14 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: Juergen Schoenwaelder , DIFFSERV WG Subject: Re: [Diffserv] IndexInteger vs. InstanceId References: <2413FED0DFE6D111B3F90008C7FA61FB0D94FA80@nl0006exch002u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The statement by the PIB authors has always been that they will align with the MIB, so I think that is what should happen here too. Brian "Wijnen, Bert (Bert)" wrote: > > Inline > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > > Sent: woensdag 26 september 2001 17:22 > > To: DIFFSERV WG > > Subject: [Diffserv] IndexInteger vs. InstanceId > > > > The DiffServ MIB uses the IndexInteger TC which is an Unsigned32 > > (1..2147483647) while the DiffServ PIB uses the SPPI InstanceId > > which is an Unsigned32 (1..4294967295). > > > > This basically means that it is possible to create instances via > > COPS-PR which you can not monitor with SNMP without introducing a > > mapping between IndexInteger and InstanceId values. > > > > Perhaps it is more useful to change IndexInteger to Unsigned32 > > (1..4294967295) and IndexIntegerNextFree to just Unsigned32. > > > I would cetainly want them to be in sync. Could also lower the > value in the PIB to get in sync with the MIB of course > > Vut in my version of the MIB, they already are > Unsigned32 (1..4294967295) Unsigned32 (0..4294967295) respectively. > Have you picked up the latest rev from Fred which he keeps up > to date with fixes on issues raised to the list? > > Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 26 15:10:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26682 for ; Wed, 26 Sep 2001 15:10:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11017; Wed, 26 Sep 2001 14:36:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10986 for ; Wed, 26 Sep 2001 14:36:10 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25888 for ; Wed, 26 Sep 2001 14:36:08 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8QIZdv16979; Wed, 26 Sep 2001 11:35:39 -0700 (PDT) Message-Id: <5.1.0.14.2.20010926102516.048464b8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Sep 2001 10:38:25 -0700 To: diffserv@ietf.org From: Fred Baker Cc: David Perkins Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] comments from Dave Perkins regarding RowPointers Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Dave Perkins sent a note to the authors of the MIB with a set of comments. Many of them are at a nit level, and will be handled directly. This, however, calls for some working group comment. >6) With use of pointers it is useful to have "reference > counts". There are none in the MIB module, and it > is not strictly necessary since a management application > can (and most likely will) compute them. This such > be pointed out somewhere in the text of the document. I can solve this two ways: - I can add a usage counter to each of the tables, which when non-zero suggests that the wise network manager will not delete the given row, or - I can put a comment into the text that says that a network manager using this for configuration should implement such a counter internally. The latter may be interesting in a multimanager sense; before deleting anything, manager should get-bulk the entire MIB and recheck its counters, in case someone else has done something amusing. On the other hand, I can't think of very many MIBs that implement usage counters. Thoughts? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 26 15:15:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26760 for ; Wed, 26 Sep 2001 15:15:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11060; Wed, 26 Sep 2001 14:36:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11025 for ; Wed, 26 Sep 2001 14:36:43 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25894 for ; Wed, 26 Sep 2001 14:36:41 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8QIZev16986; Wed, 26 Sep 2001 11:35:40 -0700 (PDT) Message-Id: <5.1.0.14.2.20010926104255.024b2d48@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Sep 2001 10:43:12 -0700 To: Juergen Schoenwaelder From: Fred Baker Subject: Re: [Diffserv] IndexInteger vs. InstanceId Cc: DIFFSERV WG In-Reply-To: <200109261522.RAA15427@mumm.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 08:22 AM 9/26/2001, Juergen Schoenwaelder wrote: >The DiffServ MIB uses the IndexInteger TC which is an Unsigned32 >(1..2147483647) while the DiffServ PIB uses the SPPI InstanceId >which is an Unsigned32 (1..4294967295). the current MIB markup matches the PIB... _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Sep 26 16:18:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27874 for ; Wed, 26 Sep 2001 16:18:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13339; Wed, 26 Sep 2001 15:36:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13310 for ; Wed, 26 Sep 2001 15:36:18 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27172 for ; Wed, 26 Sep 2001 15:36:15 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8QJZjv00932; Wed, 26 Sep 2001 12:35:45 -0700 (PDT) Message-Id: <5.1.0.14.2.20010926114111.04753fa8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Sep 2001 11:42:29 -0700 To: diffserv@ietf.org From: Fred Baker Cc: David Perkins Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] comments from Dave Perkins regarding Discontinuity Timers Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Dave Perkins sent a note to the authors of the MIB with a set of comments. Many of them are at a nit level, and will be handled directly. This, however, calls for some working group comment. >8) It seems like counter discontinuities can occur whenever > counters are added/removed to/from the "action chain", and > not just interface discontinuity events. (And for any other > chain.) If so, then the rows that contain counters should > have a discontinuity timestamp column. This revisits a discussion we had a couple of weeks ago. I'm looking to the working group for guidance here I can readily enough add the discontinuity timestamps back, one beside every pair of counters. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 05:03:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24128 for ; Thu, 27 Sep 2001 05:03:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09307; Thu, 27 Sep 2001 04:38:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09277 for ; Thu, 27 Sep 2001 04:38:31 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23829 for ; Thu, 27 Sep 2001 04:38:29 -0400 (EDT) Received: from haerke.ibr.cs.tu-bs.de (IDENT:schoenw@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with SMTP id KAA20296; Thu, 27 Sep 2001 10:38:16 +0200 (MET DST) Message-Id: <200109270838.KAA20296@mumm.ibr.cs.tu-bs.de> Received: by haerke.ibr.cs.tu-bs.de (sSMTP sendmail emulation); Thu, 27 Sep 2001 10:38:16 +0200 Date: Thu, 27 Sep 2001 10:38:16 +0200 From: Juergen Schoenwaelder To: fred@cisco.com CC: diffserv@ietf.org, dperkins@dsperkins.com In-reply-to: <5.1.0.14.2.20010926102516.048464b8@mira-sjcm-2.cisco.com> (message from Fred Baker on Wed, 26 Sep 2001 10:38:25 -0700) Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers References: <5.1.0.14.2.20010926102516.048464b8@mira-sjcm-2.cisco.com> Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> Fred Baker writes: [...] Fred> I can solve this two ways: - I can add a usage counter to each Fred> of the tables, which when non-zero suggests that the wise Fred> network manager will not delete the given row, or - I can put a Fred> comment into the text that says that a network manager using Fred> this for configuration should implement such a counter Fred> internally. Fred> The latter may be interesting in a multimanager sense; before Fred> deleting anything, manager should get-bulk the entire MIB and Fred> recheck its counters, in case someone else has done something Fred> amusing. This won't work since someone still can modify the MIB while you retrieve and process it. I think there is another option: Require that the agent keeps reference counters internally and that requests to destroy rows will result in an error if there are still pointers to this row. This means that managers only need to check the whole MIB when there really is a conflict to be resolved. Of course, managers need to use an intelligent strategy to destroy rows and you probably also want to make sure that the agent does not allow circular dependencies (not sure the current MIB allows that or not). /js _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 06:43:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAB25323 for ; Thu, 27 Sep 2001 06:43:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11731; Thu, 27 Sep 2001 06:22:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11702 for ; Thu, 27 Sep 2001 06:22:27 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24919 for ; Thu, 27 Sep 2001 06:22:27 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8RALIv09390; Thu, 27 Sep 2001 03:21:19 -0700 (PDT) Message-Id: <5.1.0.14.2.20010927030852.02ad1df0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Sep 2001 03:10:27 -0700 To: Juergen Schoenwaelder From: Fred Baker Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers Cc: diffserv@ietf.org, dperkins@dsperkins.com In-Reply-To: <200109270838.KAA20296@mumm.ibr.cs.tu-bs.de> References: <5.1.0.14.2.20010926102516.048464b8@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010926102516.048464b8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:38 AM 9/27/2001, Juergen Schoenwaelder wrote: >I think there is another option: Require that the agent keeps >reference counters internally and that requests to destroy rows will >result in an error if there are still pointers to this row. In that case, one could argue that we are changing the RowStatus variable. I think you have a good idea here, but I suspect that it requires noting that in the DESCRIPTION. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 06:53:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25460 for ; Thu, 27 Sep 2001 06:53:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12351; Thu, 27 Sep 2001 06:34:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12318 for ; Thu, 27 Sep 2001 06:34:21 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAB25187 for ; Thu, 27 Sep 2001 06:34:21 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8RAXHv13754; Thu, 27 Sep 2001 03:33:17 -0700 (PDT) Message-Id: <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Sep 2001 03:29:31 -0700 To: Juergen Schoenwaelder From: Fred Baker Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers Cc: diffserv@ietf.org, dperkins@dsperkins.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:38 AM 9/27/2001, Juergen Schoenwaelder wrote: >I think there is another option: Require that the agent keeps >reference counters internally and that requests to destroy rows will >result in an error if there are still pointers to this row. Here is a proposed approach to that. Tell me if it works for you. Section 4.3 is modified in this way: >4.3. Conceptual row creation and deletion > >A number of conceptual tables defined in this MIB use as an index an >arbitrary integer value, unique across the scope of the agent. In order >to help with multi-manager row-creation problems, a mechanism must be >provided to allow a manager to obtain unique values for such an index >and to ensure that, when used, the manager knows whether it got what it >wanted or not. > >Typically, such a table has an associated NextFree variable e.g. >diffServClfrNextFree which provides a suitable value for the index of >the next row to be created e.g. diffServClfrElementClfrId. The value >zero is used to indicate that the agent can configure no more entries. >The table also has a columnar Status attribute with RowStatus syntax >[6]. > >Generally, if a manager attempts to create a row, the agent will create | >the row and return success. If the agent has insufficient resources or >such a row already exists, then it returns an error. A manager must be >prepared to try again in such circumstances, probably by re-reading the >NextFree to obtain a new index value in case a second manager had got in >between the first manager's read of the NextFree value and the first | >manager's row-creation attempt. > >To simplify management creation and deletion of rows in this MIB, the | >agent is expected assist in maintaining its consistency. It may | >accomplish this by maintaining internal usage counters for any row that | >might be pointed to by a RowPointer, or by any equivalent means. When a | >RowPointer is created or written, and the row it points to does not | >exist, the SET returns an error. When a RowStatus variable is set to | >'destroy' but the usage counter is non-zero, the SET returns no error | >but the indicated row is left intact. | > >The use of RowStatus is covered in more detail in [6]. | In addition, various RowStatus variables (all except diffServDataPathStatus) get the following description: > "The status of this conceptual row. All writable objects in this | > row may be modified at any time. Setting this variable to | > 'destroy' when the MIB contains one or more RowPointers pointing | > to it has no effect." Is that what you mean? And is that a good approach for us? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 07:03:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25871 for ; Thu, 27 Sep 2001 07:03:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12809; Thu, 27 Sep 2001 06:47:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12778 for ; Thu, 27 Sep 2001 06:47:51 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25390 for ; Thu, 27 Sep 2001 06:47:50 -0400 (EDT) Received: from haerke.ibr.cs.tu-bs.de (IDENT:schoenw@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with SMTP id MAA20782; Thu, 27 Sep 2001 12:47:47 +0200 (MET DST) Message-Id: <200109271047.MAA20782@mumm.ibr.cs.tu-bs.de> Received: by haerke.ibr.cs.tu-bs.de (sSMTP sendmail emulation); Thu, 27 Sep 2001 12:47:47 +0200 Date: Thu, 27 Sep 2001 12:47:47 +0200 From: Juergen Schoenwaelder To: fred@cisco.com CC: diffserv@ietf.org In-reply-to: <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> (message from Fred Baker on Thu, 27 Sep 2001 03:29:31 -0700) Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers References: <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> Fred Baker writes: Fred> Here is a proposed approach to that. Tell me if it works for Fred> you. >To simplify management creation and deletion of rows in this MIB, the | >agent is expected assist in maintaining its consistency. It may | >accomplish this by maintaining internal usage counters for any row that | >might be pointed to by a RowPointer, or by any equivalent means. When a | >RowPointer is created or written, and the row it points to does not | >exist, the SET returns an error. When a RowStatus variable is set to | >'destroy' but the usage counter is non-zero, the SET returns no error | >but the indicated row is left intact. | Fred> Is that what you mean? And is that a good approach for us? I think the agent should return an inconsistentValue error in both cases. I also think that this is inline with RFC 2579 note (7) on page 10. Not returning an error means that the manager has to poll again each time it tries to delete a row. Otherwise, the text covers pretty much what I had in mind. /js _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 08:08:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27615 for ; Thu, 27 Sep 2001 08:08:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15143; Thu, 27 Sep 2001 07:52:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15108 for ; Thu, 27 Sep 2001 07:52:18 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27024 for ; Thu, 27 Sep 2001 07:52:16 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f8RBplr11045 for ; Thu, 27 Sep 2001 07:51:48 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Sep 2001 13:51:40 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D94FCDB@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Juergen Schoenwaelder , fred@cisco.com Cc: diffserv@ietf.org Subject: RE: [Diffserv] comments from Dave Perkins regarding RowPointers Date: Thu, 27 Sep 2001 13:51:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Inline Juergen answers Fred: > | > Fred> Is that what you mean? And is that a good approach for us? > > I think the agent should return an inconsistentValue error in both > cases. I also think that this is inline with RFC 2579 note (7) on page > 10. Not returning an error means that the manager has to poll again > each time it tries to delete a row. > > Otherwise, the text covers pretty much what I had in mind. > I agree with Juergen that an error should be returned and that 'inconsistentValue' is the best error code to return. And I think this should then be added to all the description clauses of RowPointers and RowStatus objects. Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 08:32:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28416 for ; Thu, 27 Sep 2001 08:32:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16057; Thu, 27 Sep 2001 08:18:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16026 for ; Thu, 27 Sep 2001 08:18:18 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27880 for ; Thu, 27 Sep 2001 08:18:16 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8RCHGv20745; Thu, 27 Sep 2001 05:17:16 -0700 (PDT) Message-Id: <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Sep 2001 05:16:51 -0700 To: Juergen Schoenwaelder From: Fred Baker Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers Cc: diffserv@ietf.org In-Reply-To: <200109271047.MAA20782@mumm.ibr.cs.tu-bs.de> References: <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:47 AM 9/27/2001, Juergen Schoenwaelder wrote: >I think the agent should return an inconsistentValue error in both >cases. that works for me in the case where a RowPointer is set to point to a non-existent object. I have a usability concern in the RowStatus case, however. Suppose that I wanted to remove a classifier. That classifier consists of: one classifier entry N classifier element entries N MultiField filter descriptions. So the logical thing for me to do is send a single SET with 2*N+1 RowStatus variables, all set to "destroy". Suppose, however, that N/2 of the MultiField filter descriptions were re-used by someone else. Since I don't know that, as I understand SNMP processing, each time I send the SET I will get back an error and a pointer to the offending VarBind. I will therefore send the SET N/2 times, getting back that error and removing the indicated RowStatus variable, and then finally send a SET that takes effect. This seems to me a colossal waste. Wouldn't it be better to swallow those errors, and simply remove the rows that could be removed at the time? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 09:04:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29451 for ; Thu, 27 Sep 2001 09:04:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17246; Thu, 27 Sep 2001 08:50:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17215 for ; Thu, 27 Sep 2001 08:50:53 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29063 for ; Thu, 27 Sep 2001 08:50:51 -0400 (EDT) Received: from haerke.ibr.cs.tu-bs.de (IDENT:schoenw@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with SMTP id OAA21531; Thu, 27 Sep 2001 14:50:44 +0200 (MET DST) Message-Id: <200109271250.OAA21531@mumm.ibr.cs.tu-bs.de> Received: by haerke.ibr.cs.tu-bs.de (sSMTP sendmail emulation); Thu, 27 Sep 2001 14:50:44 +0200 Date: Thu, 27 Sep 2001 14:50:44 +0200 From: Juergen Schoenwaelder To: fred@cisco.com CC: diffserv@ietf.org In-reply-to: <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> (message from Fred Baker on Thu, 27 Sep 2001 05:16:51 -0700) Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers References: <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> Fred Baker writes: Fred> I have a usability concern in the RowStatus case, Fred> however. Suppose that I wanted to remove a classifier. That Fred> classifier consists of: Fred> one classifier entry N classifier element entries N Fred> MultiField filter descriptions. Fred> So the logical thing for me to do is send a single SET with Fred> 2*N+1 RowStatus variables, all set to "destroy". Fred> Suppose, however, that N/2 of the MultiField filter descriptions Fred> were re-used by someone else. Since I don't know that, as I Fred> understand SNMP processing, each time I send the SET I will get Fred> back an error and a pointer to the offending VarBind. I will Fred> therefore send the SET N/2 times, getting back that error and Fred> removing the indicated RowStatus variable, and then finally send Fred> a SET that takes effect. Fred> This seems to me a colossal waste. Wouldn't it be better to Fred> swallow those errors, and simply remove the rows that could be Fred> removed at the time? Perhaps. I was concerned about rows that hang around without any other rows pointing to them anymore and where the manager(s) think the row has already been successfully deleted. This basically requires that managers implement a kind of garbage collection mechanism which destroys rows which have already been destroyed but still hang around in the agent. Another option: If a manager sends a destroy but the agent can not remove the row since it still is being referenced, then it reports success and sets a flag which causes the agent to destroy the row as soon as the reference count comes down to 0. So it becomes the agent's job to clean things up and the 'destroy' more or less becomes as 'release' operation. /js _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 09:52:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00788 for ; Thu, 27 Sep 2001 09:52:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18694; Thu, 27 Sep 2001 09:30:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18637 for ; Thu, 27 Sep 2001 09:29:59 -0400 (EDT) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00185 for ; Thu, 27 Sep 2001 09:29:59 -0400 (EDT) Received: from oemcomputer (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id f8RDTUY04553 for ; Thu, 27 Sep 2001 13:29:30 GMT Message-Id: <4.2.2.20010927092548.00c5dbb0@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 27 Sep 2001 09:29:05 -0400 To: diffserv@ietf.org From: "Joel M. Halpern" Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers In-Reply-To: <200109271250.OAA21531@mumm.ibr.cs.tu-bs.de> References: <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org It seems to me that this is a general SNMP problem that was introduced and ignored when row pointers were introduced into SNMP. (Quite possibly properly ignored. It may well be that the right answer is "do nothing".) As such, I really think it is NOT the diffserv working groups job to craft and introduce a solution to this problem. The proposed solutions have signficant impact if used as a model for other MIBs, and I think that if this problem is to be address, EoS would be the place to discuss it, not diffserv. This was not a fatal flaw in other MIBs that have row pointers, so I conclude that we have merely surfaced a general issue by putting more weight on an existing mechanism. Yours, Joel M. Halpern > >>>>> Fred Baker writes: > >Fred> I have a usability concern in the RowStatus case, >Fred> however. Suppose that I wanted to remove a classifier. That >Fred> classifier consists of: > >Fred> one classifier entry N classifier element entries N >Fred> MultiField filter descriptions. > >Fred> So the logical thing for me to do is send a single SET with >Fred> 2*N+1 RowStatus variables, all set to "destroy". > >Fred> Suppose, however, that N/2 of the MultiField filter descriptions >Fred> were re-used by someone else. Since I don't know that, as I >Fred> understand SNMP processing, each time I send the SET I will get >Fred> back an error and a pointer to the offending VarBind. I will >Fred> therefore send the SET N/2 times, getting back that error and >Fred> removing the indicated RowStatus variable, and then finally send >Fred> a SET that takes effect. > >Fred> This seems to me a colossal waste. Wouldn't it be better to >Fred> swallow those errors, and simply remove the rows that could be >Fred> removed at the time? > >Perhaps. I was concerned about rows that hang around without any other >rows pointing to them anymore and where the manager(s) think the row >has already been successfully deleted. This basically requires that >managers implement a kind of garbage collection mechanism which >destroys rows which have already been destroyed but still hang around >in the agent. > >Another option: If a manager sends a destroy but the agent can not >remove the row since it still is being referenced, then it reports >success and sets a flag which causes the agent to destroy the row as >soon as the reference count comes down to 0. So it becomes the agent's >job to clean things up and the 'destroy' more or less becomes as >'release' operation. > >/js > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 09:59:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00921 for ; Thu, 27 Sep 2001 09:59:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19697; Thu, 27 Sep 2001 09:48:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19587 for ; Thu, 27 Sep 2001 09:48:01 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00633 for ; Thu, 27 Sep 2001 09:48:00 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8RDlXv04202 for ; Thu, 27 Sep 2001 06:47:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20010927055440.02785db8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Sep 2001 05:54:53 -0700 To: diffserv@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Fwd: Re: comments from Dave Perkins regarding RowPointers Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >Date: Wed, 26 Sep 2001 12:26:45 -0700 (PDT) >From: "David T. Perkins" >X-Sender: dperkins@shell4.bayarea.net >To: Fred Baker >cc: bwijnen@lucent.com >Subject: Re: comments from Dave Perkins regarding RowPointers > >HI, > >If the following makes sense to send to others, then please >forward... > >One of the big questions for me is can/would the MIB be used >in > 1) a MIB browser? (I don't think so) > 2) by a simple management app (it doesn't remember any config > info, so when someone wants to do some configuration, then > it must muck around with MIB objects) (If so, then adding > "helper objects" (such as the nextIndex and the reference > counts (a gauge)), are helpful. And maybe other objects would > be helpful, but don't have a good feel until I've worked > on developing an application). > 3) by sophisticated management apps (for these, they create > data structs that mirror the MIB information, and monitor > config changes to keep their data structs in synch) > (For such apps, there is no need for helper objects, > since any needed helper objects are in the manager's > data structs) > > From my limited knowledge/experience, I believe that really >only type #3 applications for configuration will be created. >If someone does #1 or #2, they will really be toy apps. >(Debugging/testing with a MIB browers could be done, but it >would be painful.) > >Now, for monitoring counters, as long as the configuration >is unchanged, this would be easy to do with #1 or a #2-like >application. > >For a management app that reports configuration, I can't see >the use of any helper objects. But again, someone that has >more domain knowledge/experience than I should try to >do this with the current objects. (Oh, there are one >type of helper objects that could be useful for reporting >apps, and those are "number of table entry" objects. They would be >used to help with creating optimal GETBULK requests. >For each table, get the current number of table entries. >Then do a GETBULK for that number. Of course, you need >some timestamp or serial number that you check before >and after retrieving all table data to make sure nothing >has changed.) > >Regards, >/david t. perkins _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 10:02:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01016 for ; Thu, 27 Sep 2001 10:02:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19724; Thu, 27 Sep 2001 09:48:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19595 for ; Thu, 27 Sep 2001 09:48:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00635 for ; Thu, 27 Sep 2001 09:48:01 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8RDlYv04212 for ; Thu, 27 Sep 2001 06:47:34 -0700 (PDT) Message-Id: <5.1.0.14.2.20010927055506.02318e98@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Sep 2001 05:55:17 -0700 To: diffserv@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Fwd: FW: diffserv mib - read this first Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >From: "Wijnen, Bert (Bert)" >To: Fred Baker >Cc: Harrie Hazewinkel , > David Perkins > , > Brian E Carpenter >Subject: FW: diffserv mib - read this first >Date: Wed, 26 Sep 2001 11:46:00 +0200 >X-Mailer: Internet Mail Service (5.5.2650.21) > >Dave, thanks for your (extensive and detailed) review. > >Fred/Harrie, >As you may have noticed, I often ask the one or more of the >3 editors of the SMIv2 documents to also take a look at a >specific MIB. Since we are doing a few "firsts" in this MIB, >and since this MIB may turn out to be a vital one, I also >did ask Dave to take a look at it. > >Brian, I copied you as the WG chair who is mostly managing >the MIB effort in the WG. > >Fred, could you distribute this to other authors/editors if >you think they want to be involved in the discussion or >answering of this review. Possibly you want to take care of >nits just by yourself and discuss serious issues with >more people. Possibly you might want to bring (or ask Dave >to brinG) some issues to the mailing list. > >I am sending a second email in which I discuss the topics >I find most important. Below is a copy of the whole >email from Dave, without any comments on my part. > >Bert > >-----Original Message----- >From: David T. Perkins [mailto:dperkins@dsperkins.com] >Sent: woensdag 26 september 2001 4:39 >To: Wijnen, Bert (Bert) >Subject: Re: diffserv mib > > >HI, > >Below are comments. Feel free to send to the MIB authors: > >------------------------------------------------- >Comments on draft-ietf-diffserv-mib-14.txt >dtp: 2001-09-24 > >Reviewer Background >- expert in MIB design issues >- has a general knowledge of subject matter >- has no operational (deployment) experience in subject matter >- has no implementation experience with an SNMP agent in providing > access routines for objects defined in the MIB module, but > has extensive experience implementing SNMP agent access routines >- has no implementation experience writing code that performs > the functions described in the MIB module, but has experience > in system software implementation >- has no implementation experience with an SNMP-based (or CLI-based) > management application using the objects defined > in the MIB module, but has extensive experience in management > application design > >Primary objective >- check the compliance specifications to determine if they > should including group inCounterDiscontinuityGroup > >Secondary objectives >- check the MIB module for conformance to the rules of the SMI > and rules for IETF MIB modules in standards-track RFCs > >- check the MIB module for understandability, usability, and > following of generally acepted design approaches > >Results >- Primary objective: > If there is a dependency on the object ifCounterDiscontinuityTime, > which is the only member of group inCounterDiscontinuityGroup, > then including the group in a MODULE-COMPLIANCE is appropriate. > That is, the discontinuity indicator for counters must have > the same implementation requirement as counters. If not, a > management application would not be able to determine when > a discontinuity occured. MODULE-COMPLIANCE specifications > are really the MIB designer's opinion as to the objects > (and notifications) that are needed to write useful management > applications! > > However, in descriptions of counters in the > MIB module there is a statement that a discontinuity of the > interface counters will result in the DIFFSERV counters. I > don't believe that this is the case (but since I have not > written the code, I can not be authorative!) Also, it appears > to me that there are other other events that may cause a > discontinuity that are not documented. An IF counter > discontinuity occurs when 1) the device is rebooted and > the counter values are not saved in persistent storage > across reboots (very typical not to save values across > reboots), 2) when hardware for an interface is reset > and hardware counters are also reset, or 3) the hardware > for an interface is removed from the system and then > re-inserted (or different hardware inserted) > If the hardware to implement the counters in this MIB > module are ways found on the line cards for the > interfaces, then linking them is appropriate. Is this > really the implementation approach? > >High level comments >1) The subject matter and the definitions in the I-D are > complex, but are quite well covered. The document and > definitions were at a much higher quality than that > usually found in RFCs. > >2) A few typos were noticed. These are: > a) page 9, section 3.3, 8th line, replace > "schedule their traffic and the same time" with > "schedule their traffic at the same time" > b) page 12, section 3.4.4, 2nd pp, 4th line, replace > "points to in to determine" with > "points to in order to determine" or simply > "points to determine" > c) page 17, middle pp, line 3, replace > "WFQ control both queue" with > "WFQ controls both queue" > d) In figures 7 and 8, different capalization rules are used > for TRTCM and SRTCM. The I-D is inconsistent is usage. > Suggest consistent usage, where possisble, throughout > the document. > e) Page 29, section 5, 5th line, replace > "limit on the type" with > "limit the type" > f) Page 86, DESCRIPTION for object diffServSchedulerPriority, > removed extra leading spaced : " For use with... > >3) There different styles that MIB designers follow in table design. > I believe that the following style is "best", and suggest > that it be followed: > The definition of the table object contains a general > description of the purpose and use of the table. Additionally, > the description should describe how many rows in the > table should exist and what this depends on. For example, > if a table contained attributes for a physical device like > temperature sensors, the description would include > text like the following: "the number of entries is > the number of temperature sensors installed on the > system". If the entries represent instances of resources > that are configured, then there should be some guidance > such as "there are typically 2 to 3 configured per > network interface". The count and its relationship > to other items in the system helps with understanding > and helps management application developers in chosing > appropriate data structures and access strategies. > The primary information to be communicated in the > description for the row object is whether or not > entries can be created or deleted by SET operations > to the objects in the table, and if so, the name > of the RowStatus object (or other object used to > control the operations). Also, if there are existance > relationships with other tables, then these need > to be described in the DESCRIPTION clause for the > row. Note that the SMI requires text in the description > clause for the row object for each index object > that is defined in another table. > Finally, all descriptions of the table really should be > in the DESCRIPTION clause and not in ASN.1 comments. > Many MIB browers and other tools "throw away" ASN.1 > comments. > > If the above style is used, then it is very easy for MIB > users (agent/instrumentation developers and management app > developers) to write code. Otherwise, they have to hunt > through the definitions in the MIB module or description > text before the MIB module. > > In the table definitions in this MIB module, there were two > big problems for me: > a) there were no hints as to how many rows would exist > in the tables > b) ASN.1 comments were used to describe the tables instead > of having the descriptions totally in the DESCRIPTION > clauses. > >4) One of the big tasks for management applications is keeping > their value for configuration consistent with the configuration > in the managed system. This must be done because configuration > may be changed by another manager and/or through another management > interface. That is, even if only a single SNMP management > system can change configuration, the configuration can still > be changed by CLI commands or applying a new config file. > In the current MIB module, there are no aids for management > applications to easily check if configuration has been changed. > These can be timestamp objects and/or serial number type objects > that a manager can poll to determine if configuration has > been changed. Whether there is one for all config changes > or one per section depends on the expected amount of configuration > change and the size of the configuration information, and also > on the potential problems that can occur when a manager's > value of configuration is inconsistent with the config on > the managed system. (I don't have the expert knowledge or > experience to suggest how many such objects be added. But > this needs to be considered.) > >5) This MIB module includes much usage of RowPointer objects. > I believe the description is not complete. The text is > pretty much consistent in saying that a RowPointer with > a value of zeroDotZero or a non-existing instance has the > same behavior, but what is not covered is when the row's > RowStatus value is not 'active' (that is a RowStatus value > of 'notInService' or 'notReady'). The text for each > RowPointer object needs to be checked and updated, if needed. > >6) With use of pointers it is useful to have "reference > counts". There are none in the MIB module, and it > is not strictly necessary since a management application > can (and most likely will) compute them. This such > be pointed out somewhere in the text of the document. > >7) In many of the uses of the RowPointer, there is text > like the following: "the RowPointer should point to > an instance of one of: ...". How many of these would > be better if "should" was replaced by "must". > If some flexibility is needed to potentially add > new tables, then the "should" must stay, but additional > constraints can be specified. > >8) It seems like counter discontinuities can occur whenever > counters are added/removed to/from the "action chain", and > not just interface discontinuity events. (And for any other > chain.) If so, then the rows that contain counters should > have a discontinuity timestamp column. > >Specific Comments >1) The text for section 3.3.1 describes the definition > of the table based on the limitations of SNMP MIB design. > I not familure with the issues, but would appreciate > further description of the problem, because I might > be able to help develop another solution than that in > the MIB module. > >2) The DSCP mark table is interesting. As written, table > diffServDscpMarkActTable must contain a row for each > possible supported value of DSCP. It might be better > to have the table contain two objects. The first, > the DSCP value (and index), and the second, a RowStatus > object. Thus, rows could be added or removed. > >3) On page 27, the last paragraph describes a path through > a device that is indeterminate. It uses the term "dangling > RowPointer" without defining what the term means. > >4) The row object diffServDataPathEntry must describe in > the DESCRIPTION clause the use of index ifIndex (since this > is an object from another table). This must include answers > to the following questions: > a) can rows be created in the table for rows that > do not exist in the IF table. For example if there > is no row in the IF table with index 1, can a row > be created in Data Path table with first index of 1. > b) if a row in the IF table is "deleted" for which > rows exist in Data Path table, are those rows > also deleted? > >5) It seems like object diffServDataPathStart should have > DEFVAL value of zeroDotZero. Otherwise, the RowStatus > value could have value of notReady. > >6) Object diffServClfrElementNextFree doesn't really work > as it is currently defined. Table diffServClfrElementTable > "expands" table diffServClfrTable. That is, for each > row in table diffServClfrTable, there can be zero, one, > or more rows in table diffServClfrElementTable, and the > second index value for rows in table diffServClfrElementTable > should be independent. But, the object diffServClfrElementNextFree > makes them related. Shown below are example index allocations > using diffServClfrElementNextFree, and ones using another > (and more natural) allocation strategy: > > with diffServClfrElementNextFree: > table table > diffServClfrTable diffServClfrElementTable > 1 1,1 > 1,4 > 1,7 > 2 2,3 > 2,6 > 3 3,2 > 3,5 > > with "natural" allocation: > table table > diffServClfrTable diffServClfrElementTable > 1 1,1 > 1,2 > 1,3 > 2 2,1 > 2,2 > 3 3,1 > 3,2 > > There are two ways to obtain the natural allocation, which > are to 1) add the object diffServClfrElementNextFree as a > column to table diffServClfrTable, or 2) create a new > table indexed by object diffServClfrId containing > object diffServClfrElementNextFree. > >7) The row object diffServClfrElementEntry must describe in the > DESCRIPTION clause the use of index diffServClfrId (since this > is an object from another table). This must include answers > to the following questions: > a) can rows be created in the table for rows that > do not exist in the table diffServClfrTable. > b) if a row in table diffServClfrTable is deleted for > which rows exist in table diffServClfrElementTable, > are those rows also deleted? (Also, what happens > when rows in table diffServClfrTable are made > "notInService"?) > >8) It seems appropriate that the TC for object > diffServMultiFieldClfrAddrType be restricted to IPv4 > and IPv6 addresses using the "{ }" > construct. > >9) What is the value (existance) of object diffServMultiFieldClfrFlowId > when the data type is IPv4? > >10) Why is object diffServActionInterface "read-create". > Shouldn't it have value "read-only"? Also, isn't it > possible for multiple interfaces to use the same row > in table diffServActionTable? If so, then what value > is appropriate here. Bottom line, this object looks > problematic, and unless further description resolves > these issues, then should be removed. In general, there > are no other objects to help out managers, other than > the "nextFree" objects. This just doesn't seem as > important as other potential manager assistance > objects. > >11) The RowPointer object diffServSchedulerMaxRate points > to a "family" of rows. Which row in the family should > it point (probably the first). But can it point to > any? > >12) The description of object diffServMaxRateLevel says that > "an arbitary number of rates" can be supported. This is > somewhat confusing to me. There are two items that > are mashed together, which are rate parameter sets, > and levels within a set. Clarification is suggested > of the text. > >13) The definition and use of Counter Object Groups says > that the groups are mutually exclusive. I'm not sure > what the MIB designers really wanted. However, I don't > believe it is approapriate to say in compliance > specifications what you cannot implement. It is always > valid and appropriate to implement counters that have > a higher capacity than that actually needed. And it is > not useful in many situations to provide counters > with lower capacity than needed. However, saying > that the instances must not exist is going too far. > >------------------------------------------------- > >/david t. perkins _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 10:13:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01351 for ; Thu, 27 Sep 2001 10:13:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20377; Thu, 27 Sep 2001 10:00:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20317 for ; Thu, 27 Sep 2001 10:00:00 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00932 for ; Thu, 27 Sep 2001 09:59:58 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA84020 for ; Thu, 27 Sep 2001 08:57:10 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8RDxTW142386 for ; Thu, 27 Sep 2001 09:59:29 -0400 Importance: Normal Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers To: diffserv@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore" Date: Thu, 27 Sep 2001 10:13:15 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 09/27/2001 09:59:29 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I agree with Joel here. There's nothing about RowPointers, RowStatus, use counts, clean-up, etc. that's in any way unique to DiffServ or the DiffServ MIB. Sometimes it's useful for a particular MIB / WG to advance the state of the art relative to general issues such as these, with the hope that their good example will be picked up across the rest of the SNMP world. But I don't think this is one of those times, because the issues require more thought than the DiffServ WG is going to be able to give them at this stage of the MIB's development. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Joel M. Halpern" @ietf.org on 09/27/2001 09:29:05 AM Sent by: diffserv-admin@ietf.org To: diffserv@ietf.org cc: Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers It seems to me that this is a general SNMP problem that was introduced and ignored when row pointers were introduced into SNMP. (Quite possibly properly ignored. It may well be that the right answer is "do nothing".) As such, I really think it is NOT the diffserv working groups job to craft and introduce a solution to this problem. The proposed solutions have signficant impact if used as a model for other MIBs, and I think that if this problem is to be address, EoS would be the place to discuss it, not diffserv. This was not a fatal flaw in other MIBs that have row pointers, so I conclude that we have merely surfaced a general issue by putting more weight on an existing mechanism. Yours, Joel M. Halpern > >>>>> Fred Baker writes: > >Fred> I have a usability concern in the RowStatus case, >Fred> however. Suppose that I wanted to remove a classifier. That >Fred> classifier consists of: > >Fred> one classifier entry N classifier element entries N >Fred> MultiField filter descriptions. > >Fred> So the logical thing for me to do is send a single SET with >Fred> 2*N+1 RowStatus variables, all set to "destroy". > >Fred> Suppose, however, that N/2 of the MultiField filter descriptions >Fred> were re-used by someone else. Since I don't know that, as I >Fred> understand SNMP processing, each time I send the SET I will get >Fred> back an error and a pointer to the offending VarBind. I will >Fred> therefore send the SET N/2 times, getting back that error and >Fred> removing the indicated RowStatus variable, and then finally send >Fred> a SET that takes effect. > >Fred> This seems to me a colossal waste. Wouldn't it be better to >Fred> swallow those errors, and simply remove the rows that could be >Fred> removed at the time? > >Perhaps. I was concerned about rows that hang around without any other >rows pointing to them anymore and where the manager(s) think the row >has already been successfully deleted. This basically requires that >managers implement a kind of garbage collection mechanism which >destroys rows which have already been destroyed but still hang around >in the agent. > >Another option: If a manager sends a destroy but the agent can not >remove the row since it still is being referenced, then it reports >success and sets a flag which causes the agent to destroy the row as >soon as the reference count comes down to 0. So it becomes the agent's >job to clean things up and the 'destroy' more or less becomes as >'release' operation. > >/js > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 10:53:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03011 for ; Thu, 27 Sep 2001 10:53:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22426; Thu, 27 Sep 2001 10:38:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22400 for ; Thu, 27 Sep 2001 10:38:41 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02322 for ; Thu, 27 Sep 2001 10:38:40 -0400 (EDT) Received: from haerke.ibr.cs.tu-bs.de (IDENT:schoenw@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with SMTP id QAA22467; Thu, 27 Sep 2001 16:38:34 +0200 (MET DST) Message-Id: <200109271438.QAA22467@mumm.ibr.cs.tu-bs.de> Received: by haerke.ibr.cs.tu-bs.de (sSMTP sendmail emulation); Thu, 27 Sep 2001 16:38:34 +0200 Date: Thu, 27 Sep 2001 16:38:34 +0200 From: Juergen Schoenwaelder To: joel@longsys.com CC: diffserv@ietf.org In-reply-to: <4.2.2.20010927092548.00c5dbb0@localhost> (joel@longsys.com) Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers References: <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> <4.2.2.20010927092548.00c5dbb0@localhost> Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> Joel M Halpern writes: Joel> The proposed solutions have signficant impact if used as a model Joel> for other MIBs, and I think that if this problem is to be Joel> address, EoS would be the place to discuss it, not diffserv. Joel> This was not a fatal flaw in other MIBs that have row pointers, Joel> so I conclude that we have merely surfaced a general issue by Joel> putting more weight on an existing mechanism. DiffServ makes extensive use of RowPointers so I think it is appropriate to address the issue for the DiffServ MIB. This does not mean that the DiffServ solution (whatever that will be) must be adopted by other WGs. Generalizing the problem and putting it into other WG charters will not help us getting interoperable MIB implementations for DiffServ any time soon. RMON is another classic example of a WG which had to address several more fundamental SNMP issues just because there was no general solution available when RMON needed them. I do not see this in principle as a problem. Fred is trying hard to come up with a good MIB and I think it would be wrong to delay the forward progress in coming up with a robust MIB definition which will hopefully lead to interoperable implementations on agents and managers. /js _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 16:05:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12236 for ; Thu, 27 Sep 2001 16:05:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01212; Thu, 27 Sep 2001 15:38:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01184 for ; Thu, 27 Sep 2001 15:38:28 -0400 (EDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11659 for ; Thu, 27 Sep 2001 15:37:55 -0400 (EDT) Received: from ANDREWHOME (user-vcaura0.dsl.mindspring.com [216.175.109.64]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id MAA01727; Thu, 27 Sep 2001 12:37:47 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Juergen Schoenwaelder" Cc: Subject: RE: [Diffserv] comments from Dave Perkins regarding RowPointers Date: Thu, 27 Sep 2001 12:58:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200109271438.QAA22467@mumm.ibr.cs.tu-bs.de> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit That may be true but overloading "RowStatus" and "RowPointer" with multiple-reference semantics would be a confusing approach, I think - I'd suggest this needs a new TC if we choose to do it. But you wrote that "I was concerned about rows that hang around without any other rows pointing to them anymore" but I think that the burden of deciding if this is the case (and of deciding if it is then appropriate to delete the offending row) should be on the "manager" not the "agent". We already have language to define what happens if there is a dangling reference so there should not be a need for the agent to keep reference counters, at least not for the purposes of deciding when a "destroy" works or not - of course agents *may* well use reference counters internally to decide e.g. when to push/pull a filter entry to/from hardware. My 2c. Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Juergen Schoenwaelder Sent: Thursday, September 27, 2001 7:39 AM To: joel@longsys.com Cc: diffserv@ietf.org Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers >>>>> Joel M Halpern writes: Joel> The proposed solutions have signficant impact if used as a model Joel> for other MIBs, and I think that if this problem is to be Joel> address, EoS would be the place to discuss it, not diffserv. Joel> This was not a fatal flaw in other MIBs that have row pointers, Joel> so I conclude that we have merely surfaced a general issue by Joel> putting more weight on an existing mechanism. DiffServ makes extensive use of RowPointers so I think it is appropriate to address the issue for the DiffServ MIB. This does not mean that the DiffServ solution (whatever that will be) must be adopted by other WGs. Generalizing the problem and putting it into other WG charters will not help us getting interoperable MIB implementations for DiffServ any time soon. RMON is another classic example of a WG which had to address several more fundamental SNMP issues just because there was no general solution available when RMON needed them. I do not see this in principle as a problem. Fred is trying hard to come up with a good MIB and I think it would be wrong to delay the forward progress in coming up with a robust MIB definition which will hopefully lead to interoperable implementations on agents and managers. /js _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 16:33:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12941 for ; Thu, 27 Sep 2001 16:33:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02473; Thu, 27 Sep 2001 16:21:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02441 for ; Thu, 27 Sep 2001 16:21:26 -0400 (EDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12532 for ; Thu, 27 Sep 2001 16:21:23 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id WAA12700; Thu, 27 Sep 2001 22:20:55 +0200 Received: from [9.29.3.173] by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA82348 from ; Thu, 27 Sep 2001 22:20:53 +0200 Message-Id: <3BB38960.9965BCF4@hursley.ibm.com> Date: Thu, 27 Sep 2001 15:17:36 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Juergen Schoenwaelder Cc: joel@longsys.com, diffserv@ietf.org Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers References: <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> <4.2.2.20010927092548.00c5dbb0@localhost> <200109271438.QAA22467@mumm.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit It seems to me that returning a fault on attempting to delete something that has an outstanding reference is an implementation issue. I don't see it as something that should be reflected in the MIB itself. And if it's an implementation issue, it sounds like a SHOULD to be inserted somewhere generic. As in SHOULD return an inconsistentValue error Also as WG Chair I will object to this MIB being held up to resolve a generic problem - whatever solution applies here SHOULD apply to every MIB with row pointers. Brian Juergen Schoenwaelder wrote: > > >>>>> Joel M Halpern writes: > > Joel> The proposed solutions have signficant impact if used as a model > Joel> for other MIBs, and I think that if this problem is to be > Joel> address, EoS would be the place to discuss it, not diffserv. > Joel> This was not a fatal flaw in other MIBs that have row pointers, > Joel> so I conclude that we have merely surfaced a general issue by > Joel> putting more weight on an existing mechanism. > > DiffServ makes extensive use of RowPointers so I think it is > appropriate to address the issue for the DiffServ MIB. This > does not mean that the DiffServ solution (whatever that will > be) must be adopted by other WGs. > > Generalizing the problem and putting it into other WG charters will > not help us getting interoperable MIB implementations for DiffServ any > time soon. RMON is another classic example of a WG which had to > address several more fundamental SNMP issues just because there was no > general solution available when RMON needed them. I do not see this in > principle as a problem. > > Fred is trying hard to come up with a good MIB and I think it would be > wrong to delay the forward progress in coming up with a robust MIB > definition which will hopefully lead to interoperable implementations > on agents and managers. > > /js _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Sep 27 16:34:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12953 for ; Thu, 27 Sep 2001 16:34:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02536; Thu, 27 Sep 2001 16:23:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02513 for ; Thu, 27 Sep 2001 16:23:17 -0400 (EDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12561 for ; Thu, 27 Sep 2001 16:23:14 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id WAA08552; Thu, 27 Sep 2001 22:22:43 +0200 Received: from [9.29.3.173] by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59132 from ; Thu, 27 Sep 2001 22:22:41 +0200 Message-Id: <3BB389C8.FA00E3BB@hursley.ibm.com> Date: Thu, 27 Sep 2001 15:19:20 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Fred Baker Cc: diffserv@ietf.org, David Perkins Subject: Re: [Diffserv] comments from Dave Perkins regarding Discontinuity Timers References: <5.1.0.14.2.20010926114111.04753fa8@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Fred Baker wrote: > > Dave Perkins sent a note to the authors of the MIB with a set of comments. > Many of them are at a nit level, and will be handled directly. This, > however, calls for some working group comment. > > >8) It seems like counter discontinuities can occur whenever > > counters are added/removed to/from the "action chain", and > > not just interface discontinuity events. (And for any other > > chain.) If so, then the rows that contain counters should > > have a discontinuity timestamp column. > > This revisits a discussion we had a couple of weeks ago. I'm looking to the > working group for guidance here I can readily enough add the discontinuity > timestamps back, one beside every pair of counters. I don't think so. The consensus for what you have now seemed fairly clear (as far as any consensus is clear on a 2000 member list with about ten active particpants). Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 06:18:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08491 for ; Fri, 28 Sep 2001 06:18:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28087; Fri, 28 Sep 2001 05:56:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28056 for ; Fri, 28 Sep 2001 05:56:37 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08341 for ; Fri, 28 Sep 2001 05:56:30 -0400 (EDT) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id LAA28180; Fri, 28 Sep 2001 11:56:35 +0200 (MET DST) Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id f8S9uY024043; Fri, 28 Sep 2001 11:56:34 +0200 Date: Fri, 28 Sep 2001 11:56:34 +0200 Message-Id: <200109280956.f8S9uY024043@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: brian@hursley.ibm.com CC: diffserv@ietf.org In-reply-to: <3BB38960.9965BCF4@hursley.ibm.com> (message from Brian E Carpenter on Thu, 27 Sep 2001 15:17:36 -0500) Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers References: <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> <4.2.2.20010927092548.00c5dbb0@localhost> <200109271438.QAA22467@mumm.ibr.cs.tu-bs.de> <3BB38960.9965BCF4@hursley.ibm.com> Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org >>>>> Brian E Carpenter writes: Brian> Also as WG Chair I will object to this MIB being held up to Brian> resolve a generic problem - whatever solution applies here Brian> SHOULD apply to every MIB with row pointers. I fail to parse that. Please explain. /js _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 12:11:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18625 for ; Fri, 28 Sep 2001 12:11:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07408; Fri, 28 Sep 2001 11:45:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07379 for ; Fri, 28 Sep 2001 11:45:29 -0400 (EDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17975 for ; Fri, 28 Sep 2001 11:45:22 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA07940; Fri, 28 Sep 2001 17:44:57 +0200 Received: from [9.29.3.171] by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA19784 from ; Fri, 28 Sep 2001 17:44:54 +0200 Message-Id: <3BB49B83.BF7FC2BE@hursley.ibm.com> Date: Fri, 28 Sep 2001 10:47:16 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Juergen Schoenwaelder Cc: diffserv@ietf.org Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers References: <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927032319.0292cf08@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010927051021.02a5dec8@mira-sjcm-2.cisco.com> <4.2.2.20010927092548.00c5dbb0@localhost> <200109271438.QAA22467@mumm.ibr.cs.tu-bs.de> <3BB38960.9965BCF4@hursley.ibm.com> <200109280956.f8S9uY024043@haerke.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Juergen, I mean we should not further delay this MIB, which is a year late. If there is a generic problem with dangling row pointers, the O&M area should go away and fix it separately, imho. Brian Juergen Schoenwaelder wrote: > > >>>>> Brian E Carpenter writes: > > Brian> Also as WG Chair I will object to this MIB being held up to > Brian> resolve a generic problem - whatever solution applies here > Brian> SHOULD apply to every MIB with row pointers. > > I fail to parse that. Please explain. > > /js > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 16:20:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24176 for ; Fri, 28 Sep 2001 16:20:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18321; Fri, 28 Sep 2001 15:57:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18288 for ; Fri, 28 Sep 2001 15:56:58 -0400 (EDT) Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23549 for ; Fri, 28 Sep 2001 15:56:49 -0400 (EDT) Received: (qmail 28282 invoked by uid 104); 28 Sep 2001 19:56:23 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4163. . Clean. Processed in 3.631538 secs); 28 Sep 2001 19:56:23 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 28 Sep 2001 19:56:17 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id f8SJuEl08435 for ; Fri, 28 Sep 2001 12:56:14 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 12:59:03 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA62@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'diffserv@ietf.org'" Date: Fri, 28 Sep 2001 12:59:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] diffserv MIB counts Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, According to diffserv MIB, should the green, yellow and red packets be counted individually? Also should they be counted both before and after metering? Thanks, Shahram _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 17:04:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24721 for ; Fri, 28 Sep 2001 17:04:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20231; Fri, 28 Sep 2001 16:51:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20210 for ; Fri, 28 Sep 2001 16:51:36 -0400 (EDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24538 for ; Fri, 28 Sep 2001 16:51:28 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id WAA12744; Fri, 28 Sep 2001 22:50:57 +0200 Received: from [9.29.3.171] by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35972 from ; Fri, 28 Sep 2001 22:50:55 +0200 Message-Id: <3BB4E349.E51335A8@hursley.ibm.com> Date: Fri, 28 Sep 2001 15:53:29 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Shahram Davari Cc: "'diffserv@ietf.org'" Subject: Re: [Diffserv] diffserv MIB counts References: <4B6D09F3B826D411A67300D0B706EFDE5CCA62@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Are you asking for a specific change to the MIB, since we are in Last Call? Brian Shahram Davari wrote: > > Hi, > > According to diffserv MIB, should the green, yellow and red packets be counted individually? Also should they be counted both before and after metering? > > Thanks, > Shahram _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 17:08:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24777 for ; Fri, 28 Sep 2001 17:08:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20373; Fri, 28 Sep 2001 16:57:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20342 for ; Fri, 28 Sep 2001 16:57:49 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24588 for ; Fri, 28 Sep 2001 16:57:39 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8SKv5q27127; Fri, 28 Sep 2001 13:57:06 -0700 (PDT) Message-Id: <5.1.0.14.2.20010928134038.0467dd88@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Sep 2001 13:43:07 -0700 To: Shahram Davari From: Fred Baker Subject: Re: [Diffserv] diffserv MIB counts Cc: "'diffserv@ietf.org'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE5CCA62@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 12:59 PM 9/28/2001, Shahram Davari wrote: >According to diffserv MIB, should the green, yellow and red packets be >counted individually? Also should they be counted both before and after >metering? The Meter or the classifier (depending on where this is implemented) divides them into green, yellow, an red sub-aggregates, and lets you put count actions in line. The functional data paths then go through a random drop action, which might apply differing min-threshold and max-threshold values to the queue, and dumps them into the same queue. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 17:30:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25217 for ; Fri, 28 Sep 2001 17:30:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21710; Fri, 28 Sep 2001 17:17:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21685 for ; Fri, 28 Sep 2001 17:17:51 -0400 (EDT) Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24953 for ; Fri, 28 Sep 2001 17:17:43 -0400 (EDT) Received: (qmail 24828 invoked by uid 104); 28 Sep 2001 21:17:17 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4163. . Clean. Processed in 2.92215 secs); 28 Sep 2001 21:17:18 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 28 Sep 2001 21:17:12 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id f8SLH8l23696; Fri, 28 Sep 2001 14:17:09 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 14:19:57 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA64@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Fred Baker'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] diffserv MIB counts Date: Fri, 28 Sep 2001 14:19:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Fred, Can we conclude that a count action can be placed almost anywhere (in line)? Yours, -Shahram > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, September 28, 2001 4:43 PM > To: Shahram Davari > Cc: 'diffserv@ietf.org' > Subject: Re: [Diffserv] diffserv MIB counts > > > At 12:59 PM 9/28/2001, Shahram Davari wrote: > >According to diffserv MIB, should the green, yellow and red > packets be > >counted individually? Also should they be counted both > before and after > >metering? > > The Meter or the classifier (depending on where this is implemented) > divides them into green, yellow, an red sub-aggregates, and > lets you put > count actions in line. The functional data paths then go > through a random > drop action, which might apply differing min-threshold and > max-threshold > values to the queue, and dumps them into the same queue. > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 17:39:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25417 for ; Fri, 28 Sep 2001 17:39:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21984; Fri, 28 Sep 2001 17:26:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21956 for ; Fri, 28 Sep 2001 17:26:05 -0400 (EDT) Received: from illustrious.cnchost.com (illustrious.concentric.net [207.155.252.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25110 for ; Fri, 28 Sep 2001 17:25:57 -0400 (EDT) Received: from cthulhu.dominetsystems.com ([216.112.67.194]) by illustrious.cnchost.com id RAA17012; Fri, 28 Sep 2001 17:26:01 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Date: Fri, 28 Sep 2001 14:26:01 -0700 From: Denton Gentry To: diffserv@ietf.org Message-ID: <41860000.1001712361@localhost> In-Reply-To: <5.1.0.14.2.20010910153812.03a0e9b8@mira-sjcm-2.cisco.com> References: <5.1.0.14.2.20010910153812.03a0e9b8@mira-sjcm-2.cisco.com> X-Mailer: Mulberry/2.1.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Diffserv] Typos in draft-ietf-diffserv-mib-13.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I hope I'm not about to make a fool out of myself, but I believe there are several typos in Section 3.4.4 of draft13 of the diffServ MIB. These are not substantive problems, merely editorial. The last sentence of the second paragraph in section 3.4.4 reads: "The action inspects the diffServQEntry that diffSeervAlgQMeasure points to in to determine whether the packet should be dropped." 1. I believe "diffSeervAlgQMeasure" should be "diffServAlgDropQMeasure" 2. I believe "points to in to" should be "points to in order to" --Denny _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 18:12:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26077 for ; Fri, 28 Sep 2001 18:12:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23283; Fri, 28 Sep 2001 17:59:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23251 for ; Fri, 28 Sep 2001 17:58:56 -0400 (EDT) Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25720 for ; Fri, 28 Sep 2001 17:58:47 -0400 (EDT) Received: (qmail 4428 invoked by uid 104); 28 Sep 2001 21:58:23 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4163. . Clean. Processed in 2.300005 secs); 28 Sep 2001 21:58:23 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 28 Sep 2001 21:58:19 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id f8SLwGl03759 for ; Fri, 28 Sep 2001 14:58:16 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 15:01:04 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA66@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'diffserv@ietf.org'" Date: Fri, 28 Sep 2001 15:01:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Extending of FTN MIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, It seems that FTN MIB is based on IP packets entering LSPs/tunnels. Now that PWE3 is working on L2 over MPLS, don't we need to extend the FTN MIB to cover L2 packets/cells? Yours, Shahram _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 18:12:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26090 for ; Fri, 28 Sep 2001 18:12:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23142; Fri, 28 Sep 2001 17:54:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23109 for ; Fri, 28 Sep 2001 17:54:34 -0400 (EDT) Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25631 for ; Fri, 28 Sep 2001 17:54:26 -0400 (EDT) Received: (qmail 24045 invoked by uid 104); 28 Sep 2001 21:54:01 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4163. . Clean. Processed in 0.683929 secs); 28 Sep 2001 21:54:01 -0000 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 28 Sep 2001 21:54:00 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id f8SLrxM04502; Fri, 28 Sep 2001 14:54:00 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 14:56:48 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA65@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Denton Gentry'" , diffserv@ietf.org Subject: RE: [Diffserv] Typos in draft-ietf-diffserv-mib-13.txt Date: Fri, 28 Sep 2001 14:56:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, There might also be some typos in page 111 and 112 too: 1)In high speed interfaces if we are using High counters (64-bit), why do we still need 32-bit counters? 2) diffserMIBHCCounterGroup: Is the diffservAlgRandomDropHCPkts correct or should it be diffservAlgRandomDropPkts? Also shouldn't the diffservAlgRandomDropOctets be added? 3) Is he omission of AlgRandomdrop counters in diffserMIBVHCCounterGroup intentional? 4) Why the diffserMIBCounterGroup has diffservCountActionNextFree, but the other HC and VHC groups don't? Yours, -Shahram > -----Original Message----- > From: Denton Gentry [mailto:denny@dominetsystems.com] > Sent: Friday, September 28, 2001 5:26 PM > To: diffserv@ietf.org > Subject: [Diffserv] Typos in draft-ietf-diffserv-mib-13.txt > > > I hope I'm not about to make a fool out of myself, but I believe > there are several typos in Section 3.4.4 of draft13 of the diffServ > MIB. These are not substantive problems, merely editorial. > The last sentence of the second paragraph in section 3.4.4 reads: > > "The action inspects the diffServQEntry that diffSeervAlgQMeasure > points to in to determine whether the packet should be dropped." > > 1. I believe "diffSeervAlgQMeasure" should be > "diffServAlgDropQMeasure" > 2. I believe "points to in to" should be "points to in order to" > > --Denny > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 18:37:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26646 for ; Fri, 28 Sep 2001 18:36:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24428; Fri, 28 Sep 2001 18:20:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24397 for ; Fri, 28 Sep 2001 18:20:46 -0400 (EDT) Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26268 for ; Fri, 28 Sep 2001 18:20:39 -0400 (EDT) Received: (qmail 5344 invoked by uid 104); 28 Sep 2001 22:20:15 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4163. . Clean. Processed in 3.297909 secs); 28 Sep 2001 22:20:15 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 28 Sep 2001 22:20:08 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id f8SMK4l09214 for ; Fri, 28 Sep 2001 15:20:04 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Sep 2001 15:22:53 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA67@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'diffserv@ietf.org'" Subject: FW: [Diffserv] Extending of FTN MIB Date: Fri, 28 Sep 2001 15:22:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Sorry, this was meant for MPLS WG. -----Original Message----- From: Shahram Davari Sent: Friday, September 28, 2001 6:01 PM To: 'diffserv@ietf.org' Subject: [Diffserv] Extending of FTN MIB Hi, It seems that FTN MIB is based on IP packets entering LSPs/tunnels. Now that PWE3 is working on L2 over MPLS, don't we need to extend the FTN MIB to cover L2 packets/cells? Yours, Shahram _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 18:42:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26742 for ; Fri, 28 Sep 2001 18:42:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25127; Fri, 28 Sep 2001 18:32:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25098 for ; Fri, 28 Sep 2001 18:32:01 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26555 for ; Fri, 28 Sep 2001 18:31:54 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8SMVDq27279; Fri, 28 Sep 2001 15:31:13 -0700 (PDT) Message-Id: <5.1.0.14.2.20010928144855.0465eeb0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Sep 2001 14:49:07 -0700 To: Shahram Davari From: Fred Baker Subject: RE: [Diffserv] diffserv MIB counts Cc: "'diffserv@ietf.org'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE5CCA64@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I'm going to have some comments separated by pictures. Don't read a paragraph, see the start of a picture, and assume you have the substance of the note. There's a test at the end :^) At 02:19 PM 9/28/2001, Shahram Davari wrote: >Can we conclude that a count action can be placed almost anywhere (in line)? yes, anywhere it makes sense. In context, I think you have a pretty simple picture, one of the following two. I think if you change them in any way, you get a mess; classification has to come before counting, and queuing has to come after. Discarding has to also come after counting and before queuing, because you want the packet presented to be in the total counter, but to potentially not get into the queue. +-----------------------------------------------------+ | Classifier | +--------+-----------------+-----------------+--------+ | Green | Yellow | Red | | | +----+----+ +----+----+ +----+----+ | Count | | Count | | Count | | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +----+----+ +----+----+ +----+----+ | Random | | Random | | Random | | Drop | | Drop | | Drop | | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +--------+-----------------+-----------------+--------+ | Queue | +--------------------------+--------------------------+ | +----+----+ | Count | | Action | +----+----+ | +-----------------------------------------------------+ | Classifier | +--------+--------------------------------------------+ |Green| Yellow| Red | | | +--+-----+-------+--+ Fail +--------------------+ | Meter +------+ Meter | +--+----------------+ +---+-------+--------+ | Succeed (Green) | |Fail (Red) | +---------+ | | | Succeed (Yellow)| +----+----+ +----+----+ +----+----+ | Count | | Count | | Count | | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +----+----+ +----+----+ +----+----+ | Random | | Random | | Random | | Drop | | Drop | | Drop | | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +--------+-----------------+-----------------+--------+ | Queue | +--------------------------+--------------------------+ | +----+----+ | Count | | Action | +----+----+ | Now, this is slightly more explicit than the picture on page 23 in the MIB, because I ran out of bits to do ASCII Art in. That picture is: +-----------------------+ | diffServDataPathStart | +-----------+-----------+ | +----------+ | +--+--+ +-----+ +-----+ +-----+ +-----+ | AF1 +-----+ AF2 +-----+ AF3 +-----+ AF4 +-----+ EF | +-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+ ||| ||| ||| ||| | | +-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+ |trTCM| |trTCM| |trTCM| |trTCM| |srTCM| |Meter| |Meter| |Meter| |Meter| |Meter| +-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+ ||| ||| ||| ||| | | +-+||---+ +-+||---+ +-+||---+ +-+||---+ +-+-|---+ |+-+|----+ |+-+|----+ |+-+|----+ |+-+|----+ |+--+----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||Actions| +||Actions| +||Actions| +||Actions| +||Actions| +| | +| | +| | +| | +| | +-+-----+ +-+-----+ +-+-----+ +-+-----+ +-+-----+ | ||| ||| ||| ||| | +-+++--+ +-+++--+ +-+++--+ +-+++--+ +--+---+ | Queue| | Queue| | Queue| | Queue| | Queue| +--+---+ +--+---+ +--+---+ +--+---+ +--+---+ | | | | | +--+-----------+-----------+-----------+---+ | | WFQ/WRR Scheduler | | +--------------------------------------+---+ | | | +-----+-----------+----+ | Priority Scheduler | +----------+-----------+ | V Figure 8: combined EF and AF implementation The problem I have at this point is that I thought this was all covered in section 3.6.1 of the document; I believe it is verbally, but it sounds like it didn't make sense to you, or at least that the picture might have helped. Would it help you if I took the two pictures above, and a corollary picture for EF, and added them somewhere in that section? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Sep 28 19:50:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27541 for ; Fri, 28 Sep 2001 19:50:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26955; Fri, 28 Sep 2001 19:32:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26924 for ; Fri, 28 Sep 2001 19:32:01 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27396 for ; Fri, 28 Sep 2001 19:31:55 -0400 (EDT) Received: from FRED-W2K5.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8SNVCq29124; Fri, 28 Sep 2001 16:31:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20010928154957.02b28a70@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Sep 2001 15:54:42 -0700 To: Shahram Davari From: Fred Baker Subject: RE: [Diffserv] Typos in draft-ietf-diffserv-mib-13.txt Cc: "'Denton Gentry'" , diffserv@ietf.org In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE5CCA65@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org You'll find the current markup (complete with the error mentioned a bit ago fixed) at ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-14.txt and ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-14.txt At 02:56 PM 9/28/2001, Shahram Davari wrote: >1)In high speed interfaces if we are using High counters (64-bit), why do >we still need 32-bit counters? the current markup lacks 32 bit counters. >2) diffserMIBHCCounterGroup: Is the diffservAlgRandomDropHCPkts correct or >should it be diffservAlgRandomDropPkts? Also shouldn't the >diffservAlgRandomDropOctets be added? > >3) Is he omission of AlgRandomdrop counters in diffserMIBVHCCounterGroup >intentional? > >4) Why the diffserMIBCounterGroup has diffservCountActionNextFree, but the >other HC and VHC groups don't? The current markup has one group: diffServMIBCounterGroup OBJECT-GROUP OBJECTS { diffServCountActOctets, diffServCountActPkts, diffServAlgDropOctets, diffServAlgDropPkts, diffServAlgRandomDropOctets, diffServAlgRandomDropPkts, diffServCountActStorage, diffServCountActStatus, diffServCountActNextFree } STATUS current DESCRIPTION "A collection of objects providing information specific to packet-oriented network interfaces." ::= { diffServMIBGroups 9 } _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html